This statement stood out to me.<p>> I have a similar thought about "there's no reason for software to be slow" BTW; in many cases, if you use AI to speed up some flow, you will add a bunch of messy code that will be overfit for the use case you tested on and will neither generalize, perf-wise, for all the use cases you should care about, nor will be maintainable upon future changes.<p>LLMs have hardened hundreds of apps where I work.<p>Maybe it's a language-specific thing. Most of the time, in Java, LLMs take into consideration tradeoffs (especially if they are part of the initial prompt) and actively explains them. It generally won't make messy workarounds, without a lot of extra prompting forcing it to do so.<p>Ofc, if you have:<p>- Functional tests - you'll be able to see it in the execution times of specific APIs<p>- Stress testing - performance profiling is the most important output artifact
> Maybe it's a language-specific thing. Most of the time, in Java, LLMs take into consideration tradeoffs (especially if they are part of the initial prompt) and actively explains them. It generally won't make messy workarounds, without a lot of extra prompting forcing it to do so.<p>Claude in its current Opus 5.5 form has made some wild reaches in response to reasonable-seeming prompts. For instance: "this error is getting swallowed, make sure the real termination message exposes the root cause" -> discovering that the issue is actually in a third party library that isn't exposing the original error except so through logs, so doing some hackery to inject a log-capturer that gets the stdout, buffers it, and looks for the message in order to re-throw based on that...<p>And it can demonstrate that working, but it's added some fragile and/or unintended consequences like (a) string matching on a particular WARN log message of a particular version of the lib, and (b) buffering those logs such that there were now cases where they would never make it to the actual output stream before the program terminating.<p>It's certainly <i>capable</i> of being used smarter than that, but it's also <i>really easy</i> to end up with messy fragile stuff if you get lazy about reviewing the output.
> "this error is getting swallowed, make sure the real termination message exposes the root cause"<p>Without judgement, I think this illustrates a fundamental objection the anti-AI crowd raises.<p>The example prompt requires no understanding of what's happening, before suggesting action. Where I work, process requires that a PR review for a solution, has to have a corresponding explanation of why, or it's marked <i>needs work</i>
I don't disagree.<p>I think there's some nuance here though between "fully anti-AI" and "be careful with that power saw."<p>That example I mentioned didn't make it to production. It got noticed and fixed more properly by the person who submitted the first prompt before it even went to PR.<p>But a lot of times things in that same vein can be solved sufficiently with a "dumb" prompt like that, so a one-line prompt to get a PR drafted in the background for the dumb stuff can be a pretty good time saver.<p>The art is not skimping on your attention to the bigger or more important stuff so much that all the time you save on first getting code written is lost by cleaning up stuff like that...
I think you're misunderstanding where in the process that prompt got made.
> but it's added some fragile and/or unintended consequences<p>In python, in a co-worker's code, it seems to significantly prefer "some_dict.get('key')" over "some_dict['key']". For the non-python-users, the first one will return None (equivalent to null) when the key is missing, while the second raises a KeyError. It was being used in a whole bunch of places that would cause problems (bad data instead of errors) if it did receive None. Some of these keys were actually optional and it does makes sense for those, but it looks like whichever model he was using just repeated the pattern everywhere instead of just where it was appropriate.
It did what you asked. Had you first told it to figure out why the error was being lost,
You would have had a very different follow up prompt.
I used Opus 5.5 to figure out that a language model we were serving at work for internal use (we don't really serve models, we only use this internally because it processes sensitive data that we can't send to external endpoints) was being bottlenecked by CPU contention on tokenization, by having Opus run in an autoresearch style loop.<p>Opus's first proposal for a fix was to spawn multiple Python processes and build a load balancer between them in Python. At first I asked it why it wasn't using haproxy and it said that haproxy would be an added dependency and that the overhead for this kind of thing in Python would be negligible. I knew this was idiotic but wanted to test this out, so had Opus run two experiments in parallel. Sure enough an haproxy load balancer was much, much better on HTTP load balancing than Python code was.<p>This is the kind of thing that if you're unfamiliar with how networking code works, the models can autopilot into bad decisions that are verifiably correct (higher throughput than the original CPU-bottlenecked implementation) but much short of best practice.
Are you doing CPU inferencing? For small models you could check qxotic.ai which is a whole inferencing stack for many popular open models in Java, which can beat llama.cpp in speed in some cases. Its tokenizer toknroll is faster than tiktoken, which is what made me think of it for your use case.<p>The advantage is that you don't have issues like the GIL or whatever, so there's no need for all the complexity of load balancing between multiple pythons.
Thanks for the pointers, I'm gonna look into them.<p>I'm not doing CPU inferencing but I'm doing some tokenization in Python which is CPU-bound. In all honesty I started on this project to scale the model and did not build it myself so have been trying to read code and walk back the approach. I've been thinking about rewriting the Python glue in Go to avoid issues with the GIL.
More than ambitious, I can now build things I had no time for but had the idea and architecture in place since long. A cool side project for me recently has been to allow reading more than books on my Kobo reader. I built an SDK and apps that allows e-ink apps with sandboxing and permissions model, auto-updates, shared capabilities etc. to be built for Kobo <a href="https://github.com/BandarLabs/Cobalt" rel="nofollow">https://github.com/BandarLabs/Cobalt</a>
this is exactly my relationship with it. "This idea is super satisfying, would essentially be ops-nirvana, but would take me literally forever to write lol. Oh well."
That's super cool. Not quite the same, but I created my own version of Remote Buddy, but with only the features I need, plus some extras like low battery alert and fixing a looooong standing bug with Remote Buddy where I'd need to restart there app every other day or so.<p>It's pure vibes, so buyer beware <a href="https://github.com/adriel/siri-remote-control" rel="nofollow">https://github.com/adriel/siri-remote-control</a>
This is "my" first Mac app, before this I'd only built PHP or web based apps. Pretty surprising how quick Claude could make it. I always thought Mac apps were really hard to build.
Very cool and creative example of using AI. I'd never think of building a Kobo app :D
><i>Very cool and creative example of using AI</i><p>Is it? And that's no shade to the OPs project, it looks awesome.<p>But, frankly, it blows my mind that anyone with a passing interest in software hasn't seen AI as an incredible capability enhancer. How are they not doing <i>everything</i> they ever wanted?<p>So many people just sit around and complain about it. It's impossible for me to wrap my head around.
My issue with AI is people using it to replace their human expressiveness, e.g. their writing, or making images (for human consumption) with it.<p>AI is quite literally the opposite of creativity. By definition. It's a pattern matcher and generates the most likely correct output based on the input. That's why it's incredibly useful at creating random tools and being a capability enhancer/output multiplier. But if you are having a dialogue with me, I don't want to hear what some AI has to say, since that's not 'you'.<p>This is why generative AI will never replace the creative types, as the inherit value of the product is in the artists' intent in making a piece and their unique execution of it. If at any part of the process AI was used (including if they were to e.g. use AI to fact check their anatomy, or for concepts) then they've tainted their work - it's no longer an output of themselves, it's got elements that have been genericized to what an AI considers correct / perfect.
Thought experiment: I'm producing my own synth-pop solo album. I can play guitar, piano, synth, bass, and some saxophone. I need to hire a drummer. I use a black-box service call "Hire-a-Drummer". At no point do I know if the drums were recorded live by a human drummer, if a human hand-programmed the drums, or if the drums were created by AI.<p>Is there some kind of metaphysical tainting that takes place based on what happens inside of the "Hire-a-Drummer" black-box?
I think so. Regardless of what drummer() is, I think the important part is disclosure, and thus expectations.<p>If I found out afterwards that your album's songs each had a single long recording of a drum track that you didn't make or refine at all, i'd be upset, because I thought the album was your creative output and that you carefully chose how it was constructed.<p>If you tell me upfront "the drums are a placeholder while I work on how to do them" then I can still enjoy the rest of the album, whether that part of the track is AI or not. But if you instead were to go in and take the time to carefully craft the drum track for the album, I don't care if AI was used to make the actual waveforms of the drum beats.<p>I think the problem is that, the more AI is used as a way to take shortcuts in your work, the less I can attribute to you, and the more it's just "correct" and thus generic. If you use AI as a tool to enable you to do creative work, then I think it's fine, I just want to know what I should judge as being 'you'.<p>Similar thing: Epic: The Musical is a concept album made in Logic Pro X. None of the instruments actually played or were recorded (at least by Jorge). But I enjoy the album on the basis of how Jorge's mind arranged the instruments, how the songs are written, the humans singing it and the emotions they put into their performance, etc. I don't think anyone thinks Jorge hired an orchestra nor sat there and played all those instruments himself.<p>So, when someone says that they like the trumpet in some part of a song in Epic, they're actually saying that they enjoy (A) the trumpet is there at that specific moment, and (B) and what decisions Jorge made for it - like its length, any effects added to create its sound profile, etc. This person probably subconsciously knows that Jorge did not actually blow into a trumpet to make that part of the song.
Imagine the attribution for the drum tracks is "Hire-a-Drummer". Neither the artist nor the listener know if the actual drum tracks were from a human drummer, a programmed drum machine, or AI.<p>Is the issue, "hey, it might be AI, therefore on a metaphysical level I do not enjoy this as much as if I knew for certain that the drums were recorded by a real drummer"?<p>Or separately and without the complication of "Hire-a-Drummer", what about failing to disclose that drum tracks were hand-sequenced on a drum machine?<p>Or separately, is the issue that the drums were outsourced in the first place?<p>That is to say, if a human drummer is hired and the only instruction is to "add some dope beats to this track" and the drum tracks are used thereafter without any further refinement, does/should this affect the listener's perception?
It's the outsourcing at all, and it mostly just changes how I see a song. A ton of R&B tracks have their underlying beat outsourced, and you know that because the songs have a producer tag (and the producer gets credit in the metadata), but they're still enjoyable. A producer tag for AI would be nice but I know it won't happen.
I think your thought experiment is begging the question by asserting the outputs are indistinguishable.<p>The poster above is complaining that the actual outputs are qualitatively "not creative". That they embody a statistical norm, while creative work has more unique variance.<p>These two viewpoints cannot be bridged by a flourish that ignores the fundamental difference of opinion...
I'm not asserting that human and AI outputs are generally indistinguishable. I'm stipulating that they are in this particular hypothetical to isolate the question of provenance.<p>Even if AI were entirely incapable of creativity, why would incorporating its output diminish the creativity of the human artist?<p>What about stock samples, preset drum-machine patterns, or clichéd drum parts played by a human drummer? Do these diminish the artist's creativity, and if so, why?
[flagged]
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.<p>If you wouldn't mind reviewing <a href="https://news.ycombinator.com/newsguidelines.html">https://news.ycombinator.com/newsguidelines.html</a> and taking the intended spirit of the site more to heart, we'd be grateful.
I don't think you've understood, let me clarify.<p>So the inputs to "Hire-a-Drummer" are always the same. Sometimes the mechanism is an actual drummer, sometimes it is a programmed drum machine, and sometimes it is AI generated. It's impossible to tell from the outputs what the mechanism was.<p>Does the mere use of "Hire-a-Drummer", even assuming that the drum tracks were recorded by an actual drummer, diminish my creativity in the final songs on the album? Is it neglectful to outsource drumming in the first place?
Programming your drums yourself is perfectly ok, hiring a drummer is ok, both involve humans, their vision and feelings. AI is not ok.<p>If you played a lot of parts yourself and put your effort into them, why drag those AI drums in? That's like sculpting 90% of a sculpture with your hands and then generating the remaining 10% and 3d printing them in. For what sake?<p>Answering your question, it diminishes nothing except your own honesty with yourself and your listeners. If you're fine with that, well, you do you.
Why does hiring a known human drummer directly instead of using the black-box "Hire-a-Drummer" make my own creative contribution any more or less significant?<p>The morality of AI is another discussion entirely.<p>Or are you suggesting there's a spectrum here? Is the overall creativity of the album greater with a human drummer than with drum samples, a drum machine, or AI-generated drums?
Your reality sounds miserable to me. “The only ways to be creative are the ones I deem acceptable, otherwise it’s tainted”. That’s snobbery at it’s greatest
A faster postgres/regex is literally the <i>faster horse</i> metaphor.<p>That software is a means to an end can be quite unfashionable on HN, but it's more ambitious <i>thinking</i> we need, and maybe software will be the answer.<p>(and no, the wet dreams of a teenager's interplanetary conquest fetish is centuries old rehash, not original thinking)
We should be more <i>diverse</i> with the software we build.<p>Any prompt jockey can make a faster ripgrep. The spec is "faster ripgrep".<p>What is the one thing that <i>only you</i> can specify, where your competitive advantage is maximized? Find that thing and pursue it with all your energy!
If you didnt before you won't start now. AI does not speed up this kind of effort enough - its interpolating between existing stuff.
> <i>What is the one thing that only you can specify, where your competitive advantage is maximized?</i><p>Can you give some examples where people have done that?
The quality drop off when vibe coding something novel is pretty sharp. LLMs lean heavily on the existence of relevant training material.
[dead]
I think it's worth remembering that outside of our bubble the quality of software is pretty bad. I had a Hitachi heat pump (not recommended) installed earlier this year, and the software is pretty disappointing. It mostly works, but there are so many undocumented features and hard coded values that should be a configuration option but are not.<p>For example when the heat pump reaches the target temperature it shuts off, then after 3 minutes switches on again. To prevent short cycling, I'd like to decrease the time between runs (so increase the 3 minutes) but that can't be changed. Somebody decided that 3 minutes is the correct value for everybody and that's it.<p>I bought a €400 interface box (basically just a serial to IP interface, I guess $20 of hardware tops) to try and improve it. The €8000 heat pump doesn't come with WiFi or ethernet out of the box, you need to buy an accessory for that. It's not made by Hitachi, but it's an officially recommended accessory. One of what feature I wanted it for - which is advertised in their marketing materials - doesn't work.<p>I emailed them, and they said it's probably because the display I have is a newer revision and doesn't allow access to the setting I need to turn on. And without turning that setting on I can't use the feature as advertised. They said I should email Hitachi and talk to them instead as it's not their part that's the issue.<p>I look forward to the world where all software is either open source, or at least reverse engineerable to the point where you no longer have nonsense like this.
> outside of our bubble the quality of software is pretty bad<p>It's pretty bad inside the bubble too.
Hehe thank you for that. It made me laughed.
I fully agree of course.
I’ve probably worked on 100+ software and hardware products for consumers, military and industry<p>.0001% of that software had formal verification, bitwise memory management, 100% test coverage, clean documentation and specifications, a clear roadmap, long term sustainability plan and sustainable economics<p>Technology is like a good meal: only possible for a moment and only a moment.<p>too early and it’s inedible too late and it’s spoiled.
Thirty minutes spent talking to users is worth multiple percentage points of test coverage.
.0001% of 100 projects is less than a single one of those projects. :)
> 100% test coverage<p>I don’t believe in 100% test coverage. Especially outside some very specific cases, it just adds a lot of code with little to no value.
It really depends on the shape of the tests and the shape of the language. Eg: Untyped languages often have tests that effectively implement a type system as software grows and the developer count grows. That seems like a waste…<p>Writing a good test or good set of tests does take effort but enforcing 100% coverage often pushes some folks to just run the code in any way possible within the test subsystem.
I also do not believe in it, rather I believe in 100% test coverage for the money-making code. Which is something like 5% of a product in reality.
It’s a question of the degree to which you want a self audit to be native to your structure or not<p>if you are confident that the complexity of what you have built can be fully tracked in your head then either you are some sort of God or you’re not used to building complicated enough things with critical failures attached to them
Hardware companies (and Japanese hardware companies in particular) don't care for or understand the rules that govern software.<p>Neither do governments, incidentally. They're okay-ish at skyscrapers and bridges, but software is just beyond them.
Doesn't need to be open source in itself, we need standards that are used and shared.<p>Even if its closed on their end, having standards is the key.
Technically AI makes it much easier to reverse-engineer software, so long as the guardrails don't randomly kick in.
Should’ve bought a Panasonic. Everyone knows Hitachi sucks for programmability hardware is good though.
[flagged]
Agreed. I started writing a desktop GUI harness in Rust using native desktop GUI APIs.<p>Claude, Codex, Opencode, everything is Electron. With agents and solid engineering fundamentals, I set out to prove that we don't need to take that shortcut any more and we can, in fact, ship high quality/performance applications.<p>It's still early days - but I got something basic working. I've embedded the Goose harness as a back end and am using the UI framework used by the Zed editor.<p><a href="https://github.com/alshlabs/quill" rel="nofollow">https://github.com/alshlabs/quill</a><p>I'm keeping the source closed for a little while. Also if anyone from the major labs is hiring, hihi, I make quality things.<p>Also I'm aware that this is a rip off of vscode's design. I like their UI, lends itself well to projects and so on. In a different life I might have ported vscode to Rust - but no one uses IDEs any more haha
I'm sorry and will be the first to admit I went for this too, but "using agents to write more tools for agents." is literally the problem.<p>The purpose of software is to help people with their problems. I think it's easy to tell ourselves that other people want to use our tools which we really made to help ourselves (especially if them using it also helps ourselves even more!). And also, this is all so new and there are real opportunities that it <i>is</i> good to learn and try new things and be open to actually making something valuable.<p>But! Other people extensively using agents are literally the last people who would pay for a project like this! And unless it's a fulltime job like it is for a 5 or so well resourced tech companies, it's hard to make something as good and useful as them. I say this as someone who spent a long time on this problem <i>as</i> my fulltime job.<p>We should still have fun with our work. But literally, "software for other software people, that solves the problem of us needing to write more software for writing software, faster", who is that helping? There are no constraints or end users besides ourselves, and half of that is not so much it benefiting us through productivity, but learning new things and play - again, important. But there's a reason so many people are doing this and I think it's because they don't have to go outside and solve someone else's problem, or do something unusual, or involving unfun non-software aspects - agents are fun! But how many random people's agent have you installed?<p>IMO: if the technology does not help a non-technology person live a better life, and especially if it involves "using an agent to build a framework for agents" we should do some more, deeper introspection about what problem we are actually solving and whether or not we're being ambitious. And I say that not to pick on you but myself.
I really love your viewpoint. And I also see that around me a lot of people developing their own custom stuff that fits to their way of thinking, but not apt to others, so everyone developing their own custom. It is fast an cheap, exciting and comfortable. I am a bit puzzled as I see hyperpersonalised sw is a way to divide us and put us in an echo chamber. No need to understand how others work or think… And we loose our knowledge that is comming from the experience of interacting whit other way of thinking.
I see your point. In this case I'm intentionally reinventing the wheel for the sake of correctness and quality.<p>For the end user, the outcome will likely be the same when compared to opencode or similar, but the journey will be nicer<p>I expect no one to actually use it though, however nice it might be to hope for that
I do wish you well and think it's good for us to work on these tools if only to help ourselves better understand how to work with these things, and have fun. I've actually had a blast working on agent tooling with agents too.<p>What I fear is that as computer people we can easily convince ourselves to avoid doing things in-person or which involve leaving the comfort of our inner/online lives, or having to bridge technology with some other thing that is very much not technology (like non technical people, or sales and marketing), or is but is not easy to work with (like a robot). But there are actually a ton of problems that need solving there, and they <i>are</i> uncomfortable because it might involve looking stupid or showing up somewhere nobody knows you, or unknown-unknowns.<p>Personally I am embarrassed at myself not for trying to solve my own problems (I want to spend all day doing tech stuff and make money selling it to other people doing tech stuff) but for how long it took me to realize that I was either anxious or thought I was above doing something more concrete and mundane.<p>For example, this is a popular music venue in the city I live in <a href="https://www.thegreatnorthernsf.com/" rel="nofollow">https://www.thegreatnorthernsf.com/</a> - Claude and Codex have been out for months; it would take like 20 minutes to give their site a makeover, mostly just watching AI work.<p>This is how local government events are coordinate in the most technologically forward city in the world. Double irony that the product is provided by one of the biggest tech companies in the city, too. But it's literally just a web form and some poor government worker is apologizing in the event details that the signups are broken: <a href="https://sfrpd.my.salesforce-sites.com/SFRPDJob?sShiftId=a09Pi000006lICX" rel="nofollow">https://sfrpd.my.salesforce-sites.com/SFRPDJob?sShiftId=a09P...</a><p>I think agents are very fun and cool but I'm increasingly convinced that my job is to use them to help this type of user, not developers.
> Naturally, game engines are crazy optimized, so the UI runs butter smooth and uses pretty much no resources.<p>We should build everything using a AAA FPS engine loop now that we can. The amount of shit that happens in one rendered frame of overwatch is wild. And then we go and do like 200 of those per second.
Yeah but it’s okay if overwatch takes all of your computer’s effort to run. Imagine if postman used 13 gb of vram
If your program does 1/1000 of the GPU work Overwatch does every frame, it will cost in the order of magnitude of 1/1000 of what Overwatch costs to render (some fixed costs aside) -- taking aside the fact that you also don't need to re-render the entire window every vblank.
i mean, sometimes it feels like it does
One recent performance issue that was raised by a customer was in the end a tiny svg animation loop that was on all the time even when the tab was inactive. So no game engine loops for my customers.
No you won't. Firstly because your software is one of dozens running and it doesn't get to take the privilege of fucking over my battery consumption and asking for my GPU to spin so you can edit markdown, and also because 2D rendering is miserable and non-performant in every single game engine you can think off. 2D sucks to make, 2D eats half of your frame time by just existing and slicing those triangles.
Haha, in my case, it only renders when frames are needed. Otherwise it's basically an image at 0fps.
What?<p>You can try rendering a 2D rectangle as 2 quads in whatever GPU API you like the most, then try pushing the same amount of pixels to a CPU buffer via the widest CPU memory write instructions you can have (and then wait the GPU-accelerated compositor upload them to the GPU anyways to present them...).<p>I can tell you for a fact one will be 2 orders of magnitude faster, want to make bet which one?<p>Using a GPU api does not imply you have to render at the screen's refresh rate, or even that you have to update the entire window.
Rendering the final triangles isn't the issue. The issue is that while your 3D world is nicely setup polygons that benefit from all the culling you can do with it, your 2D UI is requiring vector graphics which your GPU will absolutely hate having to render. The actual composition of the UI elements is incredibly non-performant. Pushing the pixels doesn't matter.<p>There's a reason why browsers are so complicated and equally non performant. 2D rendering, even GPU accelerated, with the constraints we have right now (or rather, the lack of constraints, because 3D rendering is basically tradeoffs all the time), is not going to be more performant.
You don't need most of this. Give me 30 minutes, it will be easier to just build it than describe it.
This is as far as I got in 30 minutes: <a href="https://ghostdisk.github.io/ui" rel="nofollow">https://ghostdisk.github.io/ui</a> <a href="https://github.com/ghostdisk/ui" rel="nofollow">https://github.com/ghostdisk/ui</a><p>Text glyphs/UI images are all in 1 atlas, you can render the entire UI as 1 draw call and only re-render when something changes. I haven't checked if Claude chose to re-render the whole screen or just part of it, you can design it either way.<p>Layout can be as simple or as complex as you want it to be - this example does both flex and grid-style layuts, flex supports start/end/center/stretch on both main/cross axes, as well as a flex prop.<p>For the API you can either go immediate mode or retained - this one is retained since explaining to Claude how to do the IM version properly would take longer than doing it myself, but the layout algorithm can be the same regardless of which route you go for the user-level API.<p>You only need scrolling/overflow on top of that and this is enough for the majority of widgets you may need.<p>My point is none of this stuff is hard. This is 700 lines of Claude code, if you write it yourself it would be 400, and will have better performance characteristics than most UI libraries out there.<p>Edit: Added scrolling too, there's a 100K scrollable virtual list in the demo. Again - this stuff is not hard.
So, not to shit on your parade my dude, but it is, in fact, hard. Should your users do silly things like open it on a phone like I just did. As a non exhaustive list:<p>* Your font rendering is catastrophically bad, because it doesn't take DPI into account. It's a blurry, low quality mess.<p>* You don't handle taps, because you made it with a PC without considering other users. I can therefore not tap on anything. Is it all mobile devices? Is it just Firefox? Is it just that device? Surely that's an easy problem to solve, it and doesn't involve dozens of interop hacks! Scrolling that main page does work though, thankfully the horrible bad UI toolkit does the job for you.<p>* Layout: congrats, you've remade Clay. It's mostly a solved problem for the past twenty years, although modern layout needs like "rescaling your UI because your users aren't in 1920x1080" seem to be unneeded. Flex and grid layout have plenty of open source implementations, I'm sure Claude can copy it.<p>* Your text is not selectable or copyable, but I'm going to be graceful and say that maybe it's because it doesn't handle taps either and that it definitely works on desktop. Right?<p>* People that have accessibility needs seemingly can go fuck themselves, since your entire website is just a canvas. How hard could it be to integrate with the DOM for ARIA elements anyways? (Trick question, it's impossible.). And when that's done, you get to redo it for AccessibilityKit on Apple platforms, UIA on Windows, AAF on Android, AT-SPI on Linux... Don't worry, they're all very similar APIs, how hard could it be to have one model that integrates with them all? (Watch out, trick question again. Especially if you intend to do it _well_).<p>* I haven't tested it (remember, doesn't work on a mobile device?), but you do restore text input, in the way that is expected by platforms, right? Android has lifecycle events like PAUSE and STOP, as well as activity recreation like it just did upon going to low battery mode as I was typing. Firefox restored this very long comment. You would do the same, right? It is the responsibility of an UI framework: two way binding of inputs is a recipe for UI nightmares.<p>It took me longer to type this than to collect all of these issues. That was from just the first 30 seconds of interacting with your toy.<p>Maybe, just maybe, some people are smarter than you, and have spent more time working on the subject than you, and you should be ever so slightly more humble. That the complexity and the performance of current UI toolkits is not an accident that needs to be fixed by geniuses like you gracing us with your previously undiscovered research. Or keep jerking yourself off, unilaterally declaring that people don't need shadows, transparency, or other very niche features like animations, and ignore the world around you, I'm not your dad.<p><a href="https://www.nicbarker.com/clay" rel="nofollow">https://www.nicbarker.com/clay</a> does everything you're doing, except better, and it's _still_ not good enough.
I'm pretty sure that there are parallel algorithms for triangulating vector graphics that can be run on a gpu. But in general handling vector graphics is simply overkill. What are we actually using them for on the web? Rounded corners? We don't those! Let's use a paradigm that's more GPU friendly. Text can all be cached.
>I'm pretty sure that there are parallel algorithms for triangulating vector graphics that can be run on a gpu<p>They are. They're not particularly more performant that what we do today. It all involves tesselation on the CPU, or dropping entire feature sets.<p>>But in general handling vector graphics is simply overkill.<p>You don't get to decide that.<p>>Rounded corners? We don't those! Let's use a paradigm that's more GPU friendly.<p>That ship has sailed. The text input I'm typing this comment in has slightly rounded corners. The text it's containing is vector graphics with rounded corners everywhere, where the best renderer solution at the moment is Slug, with SDFs being a distant second.<p>>Text can all be cached.<p>sure, if you drop ligatures, only care about latin alphabet languages, accept having to rerender everything the moment I zoom the page to 110% or 125%
> Firstly because your software is one of dozens running and it doesn't get to take the privilege of fucking over my battery consumption<p>This never stopped the Electron devs until now, I honestly can't see why they'd start to get any better now that the slop machine lets them be even lazier.
> no one uses IDEs any more
This is false. Plenty of people using IDEs every day
I've been working on using Svelte + Rust to make desktop apps with native UI frameworks [1], resuscitating a COVID era side project that I felt was intractable at the time. I havent updated the docs or README.md so you'll have to point an agent at it to figure it out, but so far GTK/QT are fairly complete and I'm working on WinUI/AppKit.<p>[1] <a href="https://github.com/akiselev/svelters" rel="nofollow">https://github.com/akiselev/svelters</a>
This is awesome and I'm glad things are moving in this direction. I've been playing with Crux (Rust + Native UI) myself: <a href="https://github.com/redbadger/crux" rel="nofollow">https://github.com/redbadger/crux</a>
With every new model I've been attempting to build something that takes at least 1 month and really pushes the model. So far I've done:<p>- Python interpreter in Rust (fail): <a href="https://github.com/BlueBlazin/pyrs" rel="nofollow">https://github.com/BlueBlazin/pyrs</a><p>- Low-poly Google Earth like engine (success): <a href="https://github.com/BlueBlazin/lowpolyearth" rel="nofollow">https://github.com/BlueBlazin/lowpolyearth</a><p>- Codebase -> 2d infinite-zoom visualization (success): <a href="https://github.com/BlueBlazin/blockviz" rel="nofollow">https://github.com/BlueBlazin/blockviz</a><p>I have never understood or liked all the obsession with one-shot builds.
> <a href="https://github.com/BlueBlazin/lowpolyearth" rel="nofollow">https://github.com/BlueBlazin/lowpolyearth</a><p>Publishing screenshots and the README on GitHub but not the code is sneaky at best, deceiving at worst.
I’m not sure why they don’t just open the source (are they planning on monetizing it?), but GitHub has a convenient issue tracker that everyone already has a user account for.
Yeah, I really despise this trend. Using github as just an issue tracker should also be banned if it was up to me.
I agree. I feel if github was owned/run by people passionate about code and open source software, no code repos be banned, if not just because it's consuming resources contrary to the mission.<p>It is owned/run by Microsoft. The mission is the big tech mission: usage of any kind regardless of the impact on anything else, and profit.
I’ve built a retro operating system and programming environment for ESP32 microcontrollers called BASIC32.<p>I took it to 39% complete, as a language, over 8-weeks. Then, I spent just 50 minutes describing all the missing parts and it finished the language in 1-shot. I didn’t think it would work. It did.<p>I used Opus 5.5 on a $20 plan and I didn’t even hit my limits.
I have a feeling that the 39% served as a good framework for the LLM to work on the remaining part while keeping it consistent with the existing structure and style. So, in a sense, your 8 weeks are a big part of why it succeeded.
Yeah I've experienced that at work. I see a lot of comments on here saying you can't one shot features in real world software, but we do, and yes we still have a human review the code with a high bar.<p>But we've also spend a lot of effort over the past year and a half to make the codebase and tooling more approachable to LLMs so they know how we like to do things and follow our standards.
I used Fable 5.1 and Opus 5.5 to build a Python interpreter in Rust. Appears to pass all the 3.12 code I throw at it.<p>To get a toy version that can run most things takes under 2 hrs. Half of that time is collecting the tests you want to pass, how it should evaluate the code, what your criteria are, etc.
I’ve also been exploring a visual way to understand a code base and have explored turning it into a virtual city.<p><a href="https://app.preview.craftspec.com/app/city/" rel="nofollow">https://app.preview.craftspec.com/app/city/</a><p>This whole thing is just a proof of concept, and needs a mouse to interact with.<p>It’s incredible what AI has made possible with experimental projects that would require months of coding.
Small world. Literally on Friday I created 'code atlas', to help me stay in touch better with codebases that 'thanks' to llms grow by 10k+ LOC each day...<p>Icon it created is same purple as yours :) Background color of the page? Yup, same. Map of a codebase? Yup, there, although very different take on it. I added a 3d walking simulator within - is cool for a minute but useless later.<p><a href="https://github.com/bishonen/public/tree/main/images/code-atlas" rel="nofollow">https://github.com/bishonen/public/tree/main/images/code-atl...</a><p>Main use case is understanding a personal life operating system with 300k LOC a bit more. It has todo's, habits, calendars (google), trips and more baked in, with the quality (UI wise) of paid SaaS (if I say so myself). While I tried reviewing the code at the beginning, I now ask for features which would normally take me days/weeks and they're done in a few minutes by claude.
That's a really cool concept! I hit a bug where there were two things labeled "processing" and then it jumped to the wrong one when I clicked it.
This is lovely
The 'blockviz' is same kind-of project i tried to create as well (c4 level model zoomable etc.) so i was surprised to see same kind-of project popup - but this is I think also an 'issue' with these model-created-software.. when you reach'your' vision its already done: for example I clicked on the github link, expected a clear About Install Faq kind of README.md but all I get is the model-created explaination :) can't just download some app and use it without friction. I see this a lot.
You can click the big image or the url at the right and use it in browser.<p><a href="https://blueblazin.github.io/blockviz/" rel="nofollow">https://blueblazin.github.io/blockviz/</a><p>I tried it on some of my code and it's pretty neat, though not fully intuitive to follow more complex code structures for me.
100% agreed.<p>There's so many youtube channels getting hundreds of thousands of views on EVERY new major model release just doing essentially zero effort one-shots, and people lap it up as if building things that already exist is somehow the best their imagination allows for.<p>I do love being able to test a model for 3+ weeks (>1 month is too long personally for my budget) and actually learning how to build scalable software and actually develop your "engineering" skills.
yeah, one-shot (medium-large) builds just don't seem to give me good results yet. I use them now for small examples though, e.g. for visualizing a process. Most recently I used it to visualize neural networks, and how convolution works. That might not be something most people need, but it really helped me.
Hah, found someone else also using it for visualizations of algos! I've used it to show me how quad-trees[0] work and I'm impressed with the results. One-shotted too so I agree one-shots are best for this kind of very specific scenario.<p>[0] <a href="https://jsfiddle.net/3yLrsem0/" rel="nofollow">https://jsfiddle.net/3yLrsem0/</a>
> I've been attempting to build something that ... pushes the model ... never understood ... one-shot builds<p>Same, and I have found some of the failure modes in the realm of eyes free coding and limited auditing. I often see it more as pushing the process than the model, as I tend to bounce around models for the benefits diversity provides.<p>Have you also found there is a point where they hit code complexity and start churning without progress? (at which point you have to step in to help the bot step back and think big picture, which usually takes a few sessions)
Yes! I absolutely have! And I've been thinking a lot lately about how to prevent them from collapsing into this state. It is getting better with newer and better models though. But yes, there comes a point when the codebase size and complexity crosses a threshold and we enter a churn state with very little progress.<p>I was motivated to make the codebase visualizer linked above to help me understand how the various pieces of the system that is being vibe coded connect with each other.<p>Now I'm thinking about how I can build something similar for agents. How can we teach "systems thinking" to a model?
Have you seen this with Opus 5.5?<p>I've been mostly working on very large modeling projects (think detailed architeture over 1000 acres) or animation because this really was the "new" capability area that Opus 5.5 "unlocked".<p>I have been surprised how well it has worked at scale with many sub-agents. However the code base is limited to the rendering engine mostly.<p>Certainly in the older models they hit a complexity limit, but I haven't really hit it with Opus 5.5. I have had it make data flow designs that I didn't like because they were more complicated than it should have been or the perenial problem of trying to make everything backwards compatible when working on greenfield refactors, but I haven't seen it choke on a code base yet.
Yes, I've also hit it with Opus 5.5, but on way fewer projects. My long standing projects that I marked as failed/to-soon with 4.8 have entered the grey area of slow-progress-with-handholding like smaller projects did in the past.<p>To my experience, it's a simple complexity curve where the first bits go fast and the speed goes down very fast once you reach a certain level of complexity. Size doesn't matter as much as complexity: with the right foundations, it keeps zooming through it. Now I do wonder how much my inexperience in the complicated project is a brake on progress vs. it just being a hard to tackle problem.
My sense is the limit is more tied to the problem than the code base size. I work in some very large code bases, but it's not an issue because the nature of the problem (think what a standard SaaS would need).<p>On the other hand, I have a TS only project core is sub-20k LoC (NES harness), where it is struggling (for now, see other comments)
I just have it constantly update real-world analogues for keeping track of everything. I have it create guides, note cards, flowcharts, running to-do lists, etc. with every change.<p>It helps us keep track of things, why not AI, too?
> How can we teach "systems thinking" to a model?<p>I've been working on process more than model. Similar to having a PR review team, you need multiple teams or processes that run over the code, markdown, assumptions. I still don't think this is enough.<p>I'm working on an NES harness, and the agent was churning with detecting certain state changes like dialogs, menu navigation, screen change. The bot and I got churning and I put it down for a while. A few days later it occured to me to ask the bot "Does the emulator and game state change with frames? Can we just get the state each frame rather than trying to be clever about it?"<p>It said yes, but added some nonsense about being performance hindered... (flash model). I haven't worked on it again yet, but my intention was to next have it build a small recorder based on this so it can get frame accurate game state change.<p>This is just a long way of saying, sometimes you have to step back and help them help themselves. They have a really hard time with recognizing ambiguity or how to determine lack of context that could be filled.
[flagged]
[dead]
<i>There are some things that are sped up by a very large factor, easily over 1000000x.</i><p>I will need an example for this, what can I achieve with a large language model in ten seconds that I can not do on my own in one and a half years [1]? Or one hour vs 568 years?<p>The unsolved math problems are one thing that came to my mind, after all no human could solve them. But Navier-Stokes took 10,000 agents for 88 hours, that are 500 years [1] for one human without any speed-up. Does not sound unreasonable to me that a human could have solved it if they could invest 500 years on it.<p>The other hundreds of math problems took on average 3 hours, with a speed-up of a million that would be 1,704 years [1] for one human.<p>[1] Assuming 220 working days per year, 8 hours per day.
I recently needed to adjust an existing open source model for an app that I am building, to get it to work in a certain way. I have no background in machine learning.<p>Claude was able to identify the approach that worked, and even the long Python command that was needed. In, yes, probably about 10 seconds.<p>For me to figure that out myself, it probably would've taken something like a year of study. Of the entire stack of machine learning and all of the Python tooling associated with it.<p>That's where these absolutely incredible astonishing speedups come from.<p>Because it's one thing for Claude to be able to write code 20 times faster than I can. But it's a whole other thing when it is able to create things in domains that I know nothing about at all. That would take me one or more years to become an expert in. But where I can still just verify its results, so I don't need to be an expert in order to judge the quality or suitability. If the end product works, the end product works.<p>I have similarly had it come up with mathematical formulas that would probably have taken me a year in going back to studying math if I had to derive them myself. But where it is trivial to show that they are producing the correct output for known test cases.<p>So trying to come up with some kind of factor multiplier here almost kind of falls apart. It might as well be infinite. Because these are things that I just wouldn't have done otherwise. The software wouldn't have gotten built because I would have had to hire somebody else to do it, and there was no budget for that.
> Claude was able to identify the approach that worked, and even the long Python command that was needed. In, yes, probably about 10 seconds.<p>> For me to figure that out myself, it probably would've taken something like a year of study. Of the entire stack of machine learning and all of the Python tooling associated with it<p>It wouldn’t take that long. Maybe a few days of playing around. It’s not like you’re trying to create a new model from scratch. No need to understand linear algebra fully to learn how to do a dot product.
I mean, it was about changing the size of the certain layers of the model in order to fine-tune with the new shape.<p>I am entirely sure that it would have taken me many months to figure out that that was the actual thing that needed to change. It wasn't just some kind of tooling configuration issue. It required a deep understanding of the size of every single different layer of the model and how they fed into each other.
Disassembly and deep inspection of binaries seems like a good example, or rewriting an existing codebase in rust. You can do it yourself but if you don't have the background there's a ton you need to learn.
Okay, somewhat fair point, if you have no idea how to do X and learning to do X takes a non-trivial amount of time, then using a large language model could probably get you there a million times faster in some cases. But I would want to exclude those cases because they make the speed-up meaningless and instead assume that the user is reasonably competent to do the task.
Sure but that’s probably 100x max? It won’t magically work, there’s a lot of (auto) review and verification that has to be carefully setup, so things actually work in the way you need them to. I’ve done it, it takes days until it’s good.
Idk what that number does, other than stoke this kind of (very respectfully put) response. Seems fairly unnecessary/random.
Concept search. "Read my code, point me to an academic paper with similar ideas." I've had code lying around for decades, where I can point an LLM at it and learn the papers discussing similar ideas and learn of better methods.
Finding hard to find bugs. LLM's have strong capability for this in the area of security. This is also true for math(finding counterexamples), and probably other areas with strong verification.<p>Also, those AutoResearch agents for other types of verifiable goals.
Reverse engineering. The LLM can name all the functions in one hundred seconds that would take you fifteen years.
You think I could not identify all the functions in some software if I poked at it with IDA pro for 15 years? Probably depends on what exactly we are talking about, is it calc.exe or an entire office suite? But I will give you that I would probably never complete the task, I would not be willing to spend 15 years doing this. Realistically I would probably be interested in some specific functionality and identify the functions involved and ignore the vast majority.
Shouldn't take you more than a month or two with decent tools for a moderately large program. But yes, if there is ever a Next Time, I will be using AI tools.
Far more than 500 person-years have already gone into Navier-Stokes.
Probably and the model had access to all those results. The question is whether 500 person-years of effort would have been enough to get there from the same point that the model started. And also not any 500 person-years, not 100 mathematicians independently working on it in parallel for 5 years, but 500 tightly cooperating person-years, 20 mathematicians in the same room for 25 years.
I don't think you are supposed to multiple the number of agents with the time. After all a single human can run arbitrary number of agents. Still 1000000x speedup is a few order of magnitude too many imo.
You have to multiply them, otherwise you would also have to compare the output of a company with a single developer with the output of a company with a thousand developers, after all a company can hire an arbitrary number of developers. Running a thousand agents in parallel for one hour is the same as running a thousand agents one after another for a total of a thousand hours.
Yes, but the cheap parallelism is (part of) the point he's making.
Well not really. The point is "There are some things that are sped up by a very large factor, easily over 1000000x.", this is obviously referring to wall clock time. Not "agent time".<p>Yes companies/large groups of humans are sometimes also a lot faster at doing some things than a singular person. I'm not sure why that matters or what your point with that is.
LLMs are great for being nerdsniped. I started work on walshadow (reading pg wal into clickhouse) to demonstrate the project's infeasibility, but pieces started coming together into something reasonable & order of magnitude faster<p>The project would've been impossible for me without LLMs. & even with them there's an argument that this project is pushing complexity limits too far. But at least with ETL there's a clear feedback loop to build on
LLMs have introduced me to things like photodiodes and specific economists I would likely not have found on my own<p>I do however wonder about specific research priority/project from labs' solving their own problems leaking into my chats. I noticed one month that Claude <i>really</i> started harping on about "legibility" and suggesting Seeing Like A State to me, and saw it like any other interesting suggestion/insight.<p>Now I see a lot of people mentioning "legibility" and think that was just some weird attractor state or useful vocabulary term for being an LLM (that literally can't see certain things or be observed easily!). It's a weird feeling, because nobody tried to trick me and in fact it objectively helped me to acquire useful information. I just have to wonder if other people are having the same conversation and there's really nothing special about it - maybe Anthropic just really liked that book right around when they were doing a lot of RL<p>Not only that, was the <i>intent</i> just to give Claude the vocabulary to be an LLM in a company that wants it to be legible, and apply that book to managing it, and we're either intentionally or unintentionally memetically downstream of that? Or was it just extra likely to be mentioned because it's a genuinely helpful book - either because the AI learned over time that it was (very good!), someone just wanted to recommend it to more people to help them (~good). I worry that the "intelligent conversation" or "wow look at the agent go" can give us very poor epistemics
Thank you for introducing me to the word "nerd-sniping"[1].<p>This is, as you say, exactly the paradox of having ourselves assisted by LLMs. We are no different from our cats. Except imagine the cats start making the laser lights for themselves.<p>[1] <a href="https://xkcd.com/356/" rel="nofollow">https://xkcd.com/356/</a>
I think there are many of us working on projects with LLMs that'll take months more to reach full production. These will feel very out of left field and we'll have another paradigm shift. I think the real momentum will hit when more of us leave the dull products we're working on, start our own companies, and build the products we're actually excited about.<p>I encourage everyone else to at least build a privacy first version of a product you actually like.<p>I don't think the centralized internet will survive this change. We can build something much better.
I discussed taking a PM role at a mid sized company recently. They were so locked into their classic definition of PM, and so against considering with AI a true PM must straddle product and engineering competencies. I felt a bit sad for their org, and I turned down the role.<p>We’re not ambitious because the economics are unimaginative cost saving. Large, complex orgs turning a team from 10 developers to two is the easy optimization. Meanwhile smaller companies are more focused on discarding old role definitions that don’t make much sense, and embracing fluid roles mixing tech and business.
I find posts like this interesting because it seems to show the true bottleneck which is good ideas. Faster regex is cool but is it ambitious?<p>We can rewrite existing libraries and software all we want, but the true test is if we can create something new.<p>The thing I learned about myself with AI is that now I have time to work on every idea that pops into my head —- my ideas aren’t that great.
ideas can be make-or-break but it's much more common that execution is the bottleneck, and AI is the king of high-speed low-quality execution. High-quality execution can <i>only</i> come from running a human feedback loop through a huge number of iterations.<p>I like to think of the evolution of Factorio. It's been 15 years with the same core team playing their own game in a LAN party every week, as well as individually. And it's high quality.<p>Dogfooding led them to counter-intuitive decisions like, if a flying robot runs out of battery, it <i>should</i> obviously crash into the ground and explode, but it turned out way better for gameplay if it just limps slowly to the nearest charging point instead. This fact and many more can only be discerned from actual gameplay experience. No amount of pure linguistic reasoning will tell you them. Another one is how the burner inserters (coal-powered robot arms) fuel themselves - in the first version, they didn't. They <i>could</i> have made running around to refuel your robot arms a part of the game, but that isn't where they discovered the statue within the marble. You had to try the game both ways and see what feels more fun. A third: filter inserters and smart inserters were removed, and their features were moved to all inserters. A fourth: trains originally ran on strict time-based timetables, but it was frustrating so they were made able to move based on logistics needs instead. A fifth: basic oil processing used to produce all three oil products, and now it doesn't. A sixth: the basic oil refinery has its liquid I/O ports set up in a way that's compatible with switching to advanced oil refining later, instead of requiring you to redo your pipes.<p>All these little things you get from actually using the software and streamlining it, those <i>are</i> the quality. The list above obviously doesn't translate directly to any other project, but something like Microsoft has its own list, probably starting with things like common controls, dialog tabbing, and drag'n'drop. Did you know the reason you click "Start" to shut down in Win95 is because <i>they did actual user testing and that's where the users looked first</i>?
And most importantly, it doesn't matter how much AI you throw at a problem, it's not going to be able to figure out things like this. Because it doesn't have the experience of <i>being a human</i>.
>which is good ideas<p>... and politics! To me LLMs are just another piece of evidence that it was never the lack of resources that made Microsoft produce bad user experiences.
pgrust is ambitious but shall every developer build their postgres to prove they are good enough developers? The project claims to "show what Postgres would look like if it was built in 2026". It shows the traits yes: a single 3M line commit; no architecture discussion; no lessons learnt; claude it he top contributor; people writing emotional articles about why such projects are good.<p>It makes it really hard to connect to any of this. I loved danluu articles before, but somehow they've started to drift into this hard to grasp, hard to argue against shallow and empty world I try to get away from.
We should be more ambitious, but we need to learn how we can be ambitious with AI, and what value we can create.<p>AI can take us from 0 to MVP in a prompt. It can fill in gaps of knowledge and allows someone who knows half of the stack to build the whole thing nearly seamlessly. These are superpowers but don't by themselves lead to new products.<p>What AI cannot do is remove the world of complications that happen after the MVP - product feature tradeoffs and choices, how to handle integrations and customizations, how to serve multiple types of users, how to communicate and market the app, how to handle security and data storage, how to deal with customers and bugs, etc. All of these need to be considered and acted on by a human in some fashion. AI can help with each concern but can't solve them without understanding the concern and determining how to frame it in a prompt.<p>This is why we have a glut of amazing demos that go nowhere while we figure out how to build software differently. This will take some time and I imagine the result will be software heavily-structured with a bit of AI reasoning woven throughout, not an army of agents and sub-agents burning infinite tokens.
Right, but this is the most hopeful imaginable prediction: AI accelerates everything, but everything good is still mediated through taste and expertise, so being a (say) skilled systems engineer is important and rewarding, just with all the tedium distilled out of it.<p>There's a less hopeful outcome, where no skill is needed at all, because every conceivable thing is one-shot-able from a SOTA model. But then, at that point, you're saying something pretty profound about computer science (roughly: that there was no meaningfully more sophisticated and complex place to go from where we are today).
That’s something that I have been thinking about for a while now. Even prior to LLMs, many large companies have essentially been iterating on the same half a dozen ideas over and over again and there doesn’t seem to be much new coming out even post LLMs.<p>The most recent new things that LLMs have unlocked (regarding software dev) for us is reverse engineering and combining old games, unearthing decade old vulnerabilities, and helping root and debloat consumer hardware. Which are all cool and useful, but none of it being a “next great thing”.<p>Perhaps LLMs are really doing is highlighting how the software industry was already nearing its economic maturity and this just shifted the timeline from 2040 back to 2027-2030.
I have yet to see LLMs do well “autonomously” on anything that doesn’t fall into any of these 3 buckets:<p>1. well specified<p>2. well tested (which is a form of spec)<p>3. represented in the training set (i.e. not built on a corpus of human developed examples)<p>For example, a lot of the compiler porting efforts fall into all 3 buckets: compilers are well specified (there is a set of valid inputs and an expected behavior), they are typically well tested, and as a bonus, in a way that is implementation agnostic thanks to the clean interface (think: integration vs unit tests), and are very well represented in the training set.
You can "solve" 1 and 2 by N-version programming. Have the same code implemented twice, or more times, you get free error testing by fuzzing or running replicas in shadow mode. In order to make replicas maximally different choose a different language, framework, agent harness and LLM.<p>There remain some nitty details related to tracking randomness and choosing what interfaces to log. But even having your code testable by replicas would help organize it better and expose different assumptions made by the language or library stack.<p>When you get different outputs from replicas it can be 1. one of them has a bug, or 2. the spec is unclear -> fix the bug or the spec. So this method catches both sides. It also might be faster than traditional code based testing, you can build replicas in parallel. A replica is an open ended test, unlike coded tests it can be tried on open ended input values.<p>The core idea is that it is easier to implement twice than to imagine bugs. We already solved implementation, but bug finding means running code in your head, it touches the halting problem issues - can we really imagine behavior from code? I don't think we can do it well. That is why we should just make replicas instead, tokens are getting cheaper and cheaper by the month.
I had an LLM tell me that I mattered once, which I know for objective fact is not represented in the training data.
and yet some OSS (projects not really known for 1 and 2) multiplied change velocity the last year, implementing features via what is essentially vibecoding.<p>If you look at that, this approach is producing a pile of slop, where one LLM implements a feature, two weeks later another LLM spots an edge case and without much human review just crams in the code to fix that. Even at 1-2 months of that, those repos have significant changes and the commit messages get weird. I wonder what happens if the LLM won't spit out a fix anymore?<p>Will the human maintainers who started this process because noone thanked them and noone wanted to work with them on their bright new ideas just reset to the last commit they understand? Will they drop the project? The sunk cost for them is enormous. The time-effort required to fix the mess is gargantuan already. To me it increasingly seems that after the LLM industry robbed most humans of their collective labour output it will now rob them of labour aka time as well. Some people (like you and me) seem to notice that but most just go on and essentially spend away their life on machines now. I guess the problem is that most of these people have been severely cut off from using their own agency.
Don’t forget we don’t live in a pacifist utopia. Companies don’t work on the same ideas just because they think they can make it better.<p>Companies work on the same ideas because they want to own IP, data etc. and then charge money.<p>The other way around they work on the same ideas not to be charged by others and control their business.<p>“software industry” is not some big happy hippie family. Patent wars, browser wars, OS wars - well we get a lot of open source for free but that’s not the norm.
Honestly I think you're on to something, as by far the most novel and interesting use cases I've seen for LLMs in general are mostly around reverse engineering things, especially if you can hit it with Ghidra, but honestly anything that can feed some sort of data and control back to a model.
> the software industry was already nearing its economic maturity<p>What I'm sensing is something I might describe as the Oligarchy reaching the point of significant societal pushback, like the labor rights movements that ended 80 work weeks, unsafe conditions, and child labor in factories (i.e. The Jungle).<p>My hope is that we can use this moment in human history to break the user tracking and targeted advertising industry. It's been so harmful to humans, but in doing so, we will likely break a major revenue source that supports our well above average salaries. I still think it should be done.
What would be funny with LLMs, having been purposefully trained to be the best software creating things on earth, wind up inadvertently making software virtually valueless (because it can be made and copied so easily) and undermining the value of the companies that proliferated their use in the first place.
> What would be funny with LLMs, having been purposefully trained to be the best software creating things on earth, wind up inadvertently making software virtually valueless<p>This is the world the accelerationists are trying to create, is it not? Fully automated luxury space communism through AI solving all earthly problems.<p>We're just unlucky that software is one of the first moats to fall (alongside the humanities), because it doesn't require developing novel ways for the AI to interact with the real world...
We'll have to separate the hardware providers from the software providers, which I'm growing more fond of. The US Ai stack is largely a vertically integrated cartel.
What indications do you see of significant <i>and effective</i> societal pushback?<p>I would love to believe this but I don't see it yet. I see a lot of anger in some circles, but I also see the machine marching on as normal.
My wife is not a developer at all but is highly analytical. I find her a better software architect than most developers I met.<p>I suspect there are a lot of people really good at “systems” - there are a lot of really clever folks out there - that did not go through the proper CS rituals and are thus shunned but in fact can take over your job in no time especially with AI.<p>My wife regularly gets pushed away by “IT” at her work and unlike others she pushes back, but they don’t like her. They start talking about db clustering details etc as if that has any bearing on anything. I am a dev, I know she doesn’t know what logical replication is, but I do know she can replace their team. She just needs one technical person to keep an eye on things.<p>I suspect we will end up with just a handful of building blocks like “this is how data is siloed, secured etc”, “this is how dashboards are made here”, “this is how email is handled”, etc and employees with AI just develop their own stuff on top of these. The “devs” just oversee the building blocks and the overall soundness of the flow. Don’t know how many you need once that is standardized..
We're going through a very unique, fast-paced transition and the problem is mostly cultural/psychological IMO<p>People react before they've had the time to really process it, and show a lot about their existing thought processes<p>Many technical people IMO <i>fetishize</i> technology and processes, disagreeable-but-right authority justified by their willingness to work on things that most people find hard or just don't want to do. Computers can be a vessel for identity and self-worth - it's alluring to think of technology (and ourselves) as intrinsically valuable. A surprisingly large contingent seems to see work as necessarily zero-sum and adversarial, <i>and</i> make it a core part of their identity (and often not even particularly abnormally powerful or better for it) - like what even is the archetype there?<p>People like your wife are the ones writing crazy excel spreadsheets and VB6 macros, and making decisions about enterprise IT products, and solving problems with computers! They're actually probably more knowledgeable about "what is a useful and valuable way to use computers" than the ones who find computers fun and freeing and Just Want to Code.<p>Algorithms will dole out as much outrage as you can take but at the end of the day, doing stuff with computers that people want to pay for - usually, automating or securing things - is why people pay us!<p>One framing is people overindex on Being a certain kind of person or (the archetype they aspire to or identify with, that is valuable in a <i>passive</i> sense), over Becoming or Doing what's necessary for their work to be valuable (actively helping people, and stuff that's not fun). Very normal to feel grief and not want life to feel so uncertain, but it was literally always uncertain! Life isn't over because the business people at your IT job want to build software!
><i>My wife regularly gets pushed away by “IT” at her work and unlike others she pushes back, but they don’t like her.</i><p>IT (and developers) have always been gatekeepers at their business. It's a meme, a stereotype. And it's why they are absolutely melting down about AI; you can see it up and down this thread. They don't understand people want to work with people they like, first and foremost. And it's why normies can't wait to replace them.
> But then, at that point, you're saying something pretty profound about computer science (roughly: that there was no meaningfully more sophisticated and complex place to go from where we are today).<p>Or that human taste and expertise cannot helpfully guide a project there.
> but everything good is still mediated through taste and expertise<p>I'm reminded of <a href="https://archive.ph/a9Cli" rel="nofollow">https://archive.ph/a9Cli</a> (ns;nt)
I haven't yet seen any significant products made with AI that are at least used long-term. All these browser demos, from the Adobe killers to Star Citizen, are just bells and whistles that I close after 30 seconds of use.
I enjoy this quote from Antoine de Saint-Exupéry:<p>"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."<p>And I feel that sums up my feelings on AI this and that. Just as the wood and clay contain the sculpture within and it's the artist's duty and privilege to reveal that. So, is elegant software exposed from the conceptual mass, rather than built up.<p>The AI zeitgeist currently is 'how many features can I add' because we've tied self worth to work output instead of some other more personal or human rubric. AI will happily pile more and more and more code on your plate because it's a buffet. It's gone through reinforcement cycles guiding it to add whatever feature you ask. There is no training for elegance or careful considered design. Nobody is teaching this generation of LLM restraint.<p>The safest code is that which never runs. The most elegant feature is that which is not necessary.
"The safest code is that which never runs. The most elegant feature is that which is not necessary."<p>I assume you run GNU Hurd as your OS? ...<p>In general I very much agree to the quote of the Little Prince's creator, but I am not sure if we mean the same by it, because you seem to value code elegance more than adding <i>useful</i> features?<p>Now "useful" does the heavy lifting here, but my point is a useful feature is useful, even if it is achieved by the most ugly unmaintainable code. And what counts as a <i>useful</i> feature will depend on who you ask, but in general you should ask some users. (They don't care how the code looks)<p>And sure, they do not enjoy a pile of garbage of new features that only work sometimes, but managed to destroy their existing flow. But "Nobody is teaching this generation of LLM restraint" this is hyperbole and up to each developer. There is no need to let the AI run on auto for hours, this is only one way how to use that tool. The other way is, you make the design yourself - and let the AI implement it.
> <i>The safest code is that which never runs. The most elegant feature is that which is not necessary.</i><p>Yes, but the most useless software is that which doesn't exist.<p>At some point, you actually do have to write some code and add some features, or else the most satisfied client is the one who hired your competitor.
Every single company was doing this long before AI was a thing. And, yes, the advent of AI has accelerated it.<p>But long term AI will allow us to unbundle and implement only the features we need.
Claude Code?
The tech is 4 years old, and has only been "great" for, what, 1? Maybe 1.5?<p>All I need to know is it's the most widely used piece of software in my stack, by far.
There have been a few vibecoded projects I've considered hosting on my home server, but it seems as if each of them doesn't understand when to stop adding new features.<p>They keep adding features that are outside the scope of the original project, without refining or polishing the original concept.
don't let us hanging. What projects are they? (asking as someone who bought a NAS 1.5 years ago, hosted 10+ 'best' apps on it and kept using 1-2. Jellyfin and minecraft server ...)
and sadly that happens to a lot of existing opensource too...
Agreed. Been experiencing this firsthand with an app I've been building myself. Vibecoded a working prototype ridiculously fast but then came the optimization issues. Since mine is very hardware dependent every different brand, oem stack, processor, video card, and every little thing changes how my app functions and a lot of it isnt even documented properly. Now AI is still very useful here, but you actually need to know what even to ask and fix in the first place
My interpretation of "be more ambitious" is not only give it harder problems, but be more creative about what you ask. The problem is that most of the MVPs that people ask for a boring and lame. AI can help us make things that blow your mind, things that we would never build because they don't make sense, but the cost models for code generation have changed.
> AI can take us from 0 to MVP in a prompt.<p>If you're being ambitious enough, you shouldn't be able to there in one prompt. Ambitious work with AI is done 24/7 for months and guiding it continuously, because it's not good enough to work autonomously for that long without going off the rails.
[flagged]
Glad to see this a shared observation. And agree that the calculus has changed.<p>> Ten years ago, the kind of person who implemented a new compiler because their compiler was slow was the kind of person who started programming a new 3d game engine when they wanted to make an indie game, i.e., the kind of person who never ships anything.
Yeah! I've inly ever done a little bit of embedded software work, but now my AI Agent is laying out silicon for an open source hardware AV1 video decoder!
I'd have had to had devoted a year or two attempting this project on my own.<p><a href="https://github.com/Jonahss/openav1" rel="nofollow">https://github.com/Jonahss/openav1</a>
Our processes around software should come first.<p>A lot of the AI discussion seems to be focused on what these tools mean for an individual developer, but in a team setting any gains are at risk due to coordination tax and ideological friction. In my experience the ideological friction is most of it right now.<p>Figuring out a way to accelerate the process in light of the code writing bottleneck being removed is essential. I've observed a development team regress back to fully manual development because their daily PR/code review process is too slow. It doesn't matter how fast you write code if you can't actually merge it and ship it to the customer faster too. PR stacks can only take you so far before the conflict monster gets too big to fight.<p>I don't think AI can fix the process, ideology or people issues. I've seen how long an average PR review actually takes. If these employees were simply <i>doing their jobs at all</i> we'd be 10x better off regardless of AI. A truly skilled developer who makes a genuine attempt should be expected to solve 99% of their tasks within the same business day as of October 2026.<p>Burning down the backlog to zero doesn't mean the development team will be subsequently laid off. Quite the contrary. It will create a vacuum that the business will fill with new work that may incidentally increase the developers' compensation packages. No one is laying off the development team that just chewed through 50 items per day for 3 straight weeks. Who would support all the potential bugs they just created? That's right. They might hire even more developers. This is called a "win-win" scenario. Not every game must be zero sum, but I understand rejection of this possibility to be part of the aforementioned ideological issues.
Re: process<p>I worked in agile/scrum orgs with product managers who couldn't be bothered to write well formed tickets or truly keep a well groomed backlog, I think this is more normal than not outside Mag7.<p>A lot of work was noisy iteration with a guy/guys who change their mind a lot, and write nothing down. We met weekly to iterate, I suppose now one could meet 2x/day to iterate (10x!). I am not sure we would arrive at "done" 10x faster though. Probably 50-90% of the productivity boost would go towards.. doing more iterations.<p>For an external customer facing product with KPIs, A/B testing, etc that could show iterations relationship to revenue probably that's great. For a lot of internal tooling that is not good. A lot of senior devs kind of internalize this behavioral knowledge already and purposely cadence out changes to stakeholders to avoid this type of churn, while working on other things.<p>Re: backlog<p>My observation at work and in my work network is a lot of SWEs are using the productivity boost to burn down backlogs that probably never needed burning down. There's a reason some tickets were there for 2 years - they aren't actually needed, and everyone is too lazy to close them.<p>So in both cases we have problems expanding to fit the time available.
Yeah, process really needs to change. I don’t have an answer here, the only thing I’ve seen work is when a small group of engineers owns delivery of what would have been a team (or teams’) work, and can ship so fast that there isn’t really a “backlog”, you just build every idea and include or reject it.<p>As soon as you have many engineers using agents in the same codebase, the process breaks down, and you start stepping on each other’s toes, collapsing those velocity gains.<p>Maybe the “software factory” pattern will work, where agents just pull from the backlog, and so the team can all focus on grooming and disambiguating tickets, with the coordinator agent flagging conflicts and ambiguities between different people’s asks?<p>The only thing I’m confident of here is that a “h1 planning exercise” doesn’t really make sense in most cases; ~everyone should be shifting to building a lot of prototypes and iterating with customers, rather than trying to prioritize how to spend scarce eng effort. (That resource is no longer scarce.)<p>I think a lot of teams are going to rediscover (by necessity) the good parts of Agile, namely finding the domain expert and iterating with them to solve the actual problems; that’s your bottleneck now.
Also, complete tickets and a well groomed backlog are both completely useless things.<p>If something that runs on those is somebody's idea of a good process, that's wrong from the inception. Good process looks like completely broken "Agile", but in a way that somehow everybody is happy with the results.
While I agree with you in general, I think the real value of AI (for me, I wouldn’t want to try to change anyone else’s mind on this) lays in three areas: 1. all the little wins saving time at little tasks like analyzing a Haskell, Java, etc. error stacks; and all sorts of little time wasting problems. All those saved minutes add up. 2. Brainstorming before coding, and even before design. I like to write up ideas in a Markdown file and then ask one or two strong AIs to push back, to try to fill in what I might have missed. 3. Non-tech thinking: without any formal training, I enjoy reading philosophy. I frequently ask for second-takes from Gemini on what I am reading; once again, I am looking to just improve my own understanding.<p>AI should make us better, not just churn out trillions of lines of code.<p>The very idea of massive vibe coding efforts, where devs go to sleep with a hoard of agents churning away, makes me uncomfortable.
And the push back from the ai im using is the biggest learning opportunity for me. It is also why my preference is claude over chatgpt. I lose time when it always arees with me, eventually i work it out myself and have to go ack and make te changes. My Claude is very good at pushing back and explaining why.
It's going to be a challenging period though - just because of constraints theory.<p>Prior to this, building the software was, generally, one of the main constraints. If the business wants to do X, then it takes 3 months to build.<p>That means the business ideation and governance cycle (what do we want to do, are there customers, what do we charge) can take 3 months.<p>If you 10x thay development process then you also have to do the same with the business processes.<p>Once engineering teams have cleared the backlog, then burned through the decades of tech debt the constraints will switch. And how businesses react to that will be interesting.
> burned through the decades of tech debt<p>Riiight, except tech debt is the one thing that's actually been 10xed. People are now producing a decades' worth of tech debt in less than a year.
Exactly. What factors limited tech debt before? Mostly two things, I’d guess: velocity, and Good Practice. And I’d guess that the former plays at least as large a role as the latter. So if you then unconstrain velocity, you’ve likely done a lot to unconstrain tech debt.
No one is clearing the backlog right now, though. Every new change that's incoming is another 5,000 lines of change, and even if that solves the current problem at hand, it creates 5 new follow-up tickets for new edge cases that come from this huge change. At least that's the constant reality I see day to day.
I dispute this, although only from observation.<p>The latest frontier models are producing significantly higher quality output. And the usual reason to introduce tech debt (deadlines) is less relevant.<p>Indeed, I know multiple companies fixing decades of bugs and security issues in just the last few months.
Eh, I will say the back log and a number of long standing issues where I work has been addressed more than I'd even seen in the past. There were a number of more minor issues being a pain in my ass for a couple of years that in a session with the devs were ironed out. Also a few rare bugs that had been around forever were fixed when they set up agents with a description of the issue and the agents ran loops while developing a theory on how to trigger it and then debug it.
> Once engineering teams have cleared the backlog, then burned through the decades of tech debt the constraints will switch. And how businesses react to that will be interesting.<p>I have no doubt someone in business will have more ideas than any team can deliver.<p>Think about all those product-pitch PPTs. What if one could present a prototype instead? Boom, demand increased 100x.<p>That's Jevons Paradox <a href="https://en.wikipedia.org/wiki/Jevons_paradox" rel="nofollow">https://en.wikipedia.org/wiki/Jevons_paradox</a>
><i>should be expected to solve 99% of their tasks</i><p>I largely agree with the main idea in the post, but would push back on this.<p>As I’ve gotten older, I notice a large proportion of tasks can be chalked up to busywork. Not in the sense that they aren’t real bugs, but they’re not fixing root causes of problems.<p>To your point about process, there may be a hundred tasks that stem from poor repents management or poor testing process etc. There will likely continue to be many bugs until that root process issue gets fixed. To that end, those root problems generally take much more work to solve.<p>So, yes, many tasks can be done quickly unless you’re doing true root cause analysis.
Code writing was never the bottleneck. Understanding the system sufficiently to write the code was.<p>AI allows you to produce code without understanding the system, and that's how you can get delivery speed up. And, yes, AI is getting good enough that you can purchase large amounts of code from Anthropic without understanding much, so you can move very fast indeed as long as you never need to make sense of it.<p>> <i>No one is laying off the development team that just chewed through 50 items per day for 3 straight weeks. Who would support all the potential bugs they just created?</i><p>Do you live under a rock, or are you hoping that saying this enough will law of attraction[1] it into being?<p><a href="https://en.wikipedia.org/wiki/Law_of_attraction_(New_Thought)" rel="nofollow">https://en.wikipedia.org/wiki/Law_of_attraction_(New_Thought...</a>
I couldn't agree more around the ideological friction slowing things down, especially code review. I'd be really curious to get people's thoughts.<p>Personally I do code review, it's what we do at my workplace, and we regularly improve the agents' code and design though human review, even with Opus 5.5.<p>But looking at some of the people who are pushing AI development the furthest, I do see the trend towards it just not being that useful anymore.<p>Real world example:<p>I use T3Code as my agent orchestrator and it's consistently pretty high quality and works well + regularly gets new useful features.<p>And with just a handful of maintainers, they're doing anywhere from 100 to 200 PRs a day!<p>And there are a ton of users of their nightly, which is a rolling 5-hour release, and nothing really breaks. And they have more real-world users than almost all the projects I've worked on before.<p>So I just can't really in good faith say that this extremely challenging to my world view.
I think there are certain parts of certain products where the implementation details are really important, or where you need to make sure the behavior is fully reviewed/understood, or some invariant maintained. In some places that's the entire job and in other places almost none of it.<p>If you're running tons of product/UX experiments code review is just going to waste everybody's time. But the volume of changes you can make now is so large, someone could touch something important about at any given time without proper oversight.<p>IMO an effective team has to be able to either trust each other enough/be accountable enough that code review is mostly unnecessary, or everybody just works really independently on mostly separable things, or you regularly pair/mob-program.<p>If you can trust your colleagues not to pump out code without messing it all up or turning everything into slop, or creating large amounts of work for other people, things are great. Realistically most dev teams have a wide range of skills and personalities and people also make mistakes, and code review helps us build shared knowledge and collaborate.<p>Maybe there is too much of a moral hazard from the reviewer's role as a cosigner, or some people are only as conscientious as necessary to get things done (not a problem writing every line by hand)... but people can ruin code review for everyone else by demanding an asymmetric level of accountability/judgment and oversight.<p>The bigger issue for me is whether or not you still do code review, you need to build shared knowledge within teams. I really think we should be reviewing our colleagues' coding agent session logs<p>Not even to <i>critique</i> them (but that could be useful), but just to understand what it is they are actually trying to do/what mental model they're operating under, and if there are issue in the PR, what miscommunication or technique or process could help fix it? I think a lot of people feel that asking to see those logs is invasive or embarrassing, but the problem is that it's just really hard to build a model for how someone works or thinks without it. You don't <i>need</i> that in a deontological sense, but you do if you want to fix coordination problems.
Good observations. It made me realize how I had tuned myself to understand the thought process of the PR author looking at individual commits and how they add up. With most AI written code, I see large commits and that does not help understand how the solution evolved.
There needs to be a tech lead. They outline rules ahead of time. Another process needs or their own manual review surfaces any emergent ideological shifts. This is usually through redundant implementations surfacing in the codebase. They then make a decision on which option to take or introduce a different option.
Anthropic recently published their code review approach that supports them deploying 30,000 (!) times a day:<p><a href="https://claude.dev/blog/solving-code-review-at-anthropic/" rel="nofollow">https://claude.dev/blog/solving-code-review-at-anthropic/</a>
I think that now the bottleneck will be less the tasks after development but before.
Deciding what to build will be the new bottleneck. Finding ways to measure the system to make decisions, all of these need to improve.
We risk building the wrong thing at an accelerated pace
I've been harping on about async review for so long now. Glad to see it finally becoming a thing. Code review as a gate doesn't work for remote teams or AI lead development.<p>You need to decouple it, but you dont need to remove it.
> A truly skilled developer who makes a genuine attempt should be expected to solve 99% of their tasks within the same business day as of October 2026.<p>Agreed, and in fact even pre-AI good development teams weren't limited by speed of code generation (how to build it), but rather making the right thing (what to build).
Not sure I agree, with human coders, time was still a resource to be managed.
Yes, but don’t forget one of the variables for the “what to build” equation is the cost of having people now also machines who know how to build it. Jury still out on the machines because the “how” is much more complicated than “make it work, make no mistakes”, but still, the cost of code production has come down so much that the whole equation is different now.
Big gaming companies are the perfect example of corpos treating people as disposable cogs, where they do mass layoffs every time they complete a game regardless of success, and this was the case long before AI too
First time I've heard the term coordination tax. Thanks for sharing, I've encountered this in a lot of projects as we added more people. Glad to have a word for it now!
I don't think AI can fix the process, ideology or people issues.<p>It can if a single developer replaces a whole team.
>Burning down the backlog to zero doesn't mean the development team will be subsequently laid off. Quite the contrary. It will create a vacuum that the business will fill with new work<p>Will it? Are you willing to test this?<p>>No one is laying off the development team that just chewed through 50 items per day for 3 straight weeks.<p>If there are no remaining items, or the amount of items processed per day has increased well above the amount of items that need processing every day, someone's certainly getting laid off.<p>>Who would support all the potential bugs they just created?<p>We have long criticised management for not caring about this. Now we are supposed to trust their good judgement?
Keeping the backlog funnel full has been nearly a full ltime job for me for about 5 years now. Both pre and post AI. Once you get a team together that knows how to execute keeping the backlog full of well defined and groomed tasks becomes the problem management rarely sees and subsequently doesn't know how to solve.
This.<p>I recently switched, but at my previous job, the PMs (who would typically do most of this work) got so overworked after AI took hold, that they’ve doubled the PM-to-dev ratios on all (the productive) teams.<p>I have read about this in other companies as well. Some teams in Google have a PM pr dev, I hear.<p>Where I work now, sh*t gets done MUCH quicker with AI, and to a higher quality as well.<p>IMO, if you work with software and can’t get a meaningful boost out of AI, I think you’re doing something wrong.
Trying to fill a backlog to just keep a dev team busy is not what a backlog is for. It would be better for the business to have them rake leaves out front than add to a system something no user needs for the sole purposes of looking busy.
> If there are no remaining items<p>In every software job I’ve ever had, every released new feature leads to maybe three new requests to modify the new feature, two unintentional bug tickets, plus some tech debt. Work leads to more work, not less. I don’t see how increasing the velocity of the work should change that.
> Will it? Are you willing to test this?<p>Yes, this literally happens all of the time today. Proof point - software development organizations hire to fill operating budget voids, not on what work needs to be done.*<p>*Source - I've seen 900+ software team's P&Ls and interviewed their CTOs.
[flagged]
>Nobody wants to lay off an employee that is pleasant to be around, trustworthy, and good at what they do.<p>So if I hire a painter who is pleasant to be around, trustworthy, and good at what they do, I'm not going to "lay him off" the instant he's done painting my house?
I mean, if you're in a contract job, you're always to get laid off at the end of the job - that is the job. Very few of the software jobs in my world are like that<p>If someone <i>is</i> deliberately stretching out a job and making it an adversarial business relationship, when the business arrangment is that they complete the project then do another job somewhere else, then I would not expect that to be a very successful strategy, and also not really want to help them in any way beyond existing contractual obligations. You are basically guaranteeing a bad working relationship with every employer you ever have.<p>And it doesn't make sense because this is not a strategy that's rational for someone who enjoys their work or is good at their job anyway - if that describes you, then your existing employer is probably one of if not the best advocate you have, and your best strategy would be to either switch careers or progress to a point you don't feel precarious<p>That's why I say you are really hurting yourself more than you know. You are guaranteeing an at-best "every boss dislikes me and my career goal is not getting fired" outcome and (idk about your actual employer) damaging relationships you really probably need (if this is your mindset)
That's how you view your employment? The same as hiring a painter? That is astonishing.<p>Some people view their job as having infinite things to do, and AI means they can work on more and different things.<p>Other people see their specific job as a series of tasks, and if AI does those they don't know what do anymore.<p>Guess who is going to stay employed?
This is an absolutely unhinged personal attack on the op that has nothing to do with their comment. Why do you assume they are intentionally slowing things down? Because their analysis of the situation is that some people will be fired?
They're challenging someone to "test it" by burning down a backlog, because the other person thinks they will just do more work, with the implication that this person believes they'll just be laid off - and so they are better off not burning down the backlog of work.<p>I take an issue with that mindset because I know it is not true. And I'm not sure why you think I am attacking this person - if someone were to actually sandbag their own career, that is probably one of the most damaging mistakes they could make. Maybe I misunderstand something, if so I apologize for that
You implied that they are engaged in sabotage because they believe that if AI increases efficiency to the point where backlogs are easily cleared out by a small number of people there will be workforce reductions. I’m not sure why you’re so confident the opposite is true, or why you assume they are taking this view and concluding that sabotage is appropriate. But it is almost certainly damaging yourself and others around you greatly to assume so much malice in the people around you. Maybe I’m not reading enough into the “test it” phrasing but I don’t think it implies all that you seem to think it does.
[flagged]
> A truly skilled developer who makes a genuine attempt should be expected to solve 99% of their tasks within the same business day as of October 2026.<p>> Quite the contrary. It will create a vacuum that the business will fill with new work that may incidentally increase the developers' compensation packages.<p>This seems very disconnected with the reality of any company I've worked at in 25 years.<p>"Tasks" frequently are not spelled out, or if they are, they are wrong. There's almost no value to a company to blaze through all this.<p>Similarly, no one is getting rewarded for that type of speed, especially if the company has no idea how to uptake it.
How does Hacker News work if absolutes like this opinion are the top comment people read first?<p>Why not say outright that "ideological friction" is about AI usage? Maybe some devops have friction cause when things break at 2am and they get called up they don't want to dig through 500k lines of slop the author can't explain?<p>And "empty 99% of the backlog everyday" <-> "hire more people to fix the bugs" is illogical. Reviewing slop and fixing bugs make me want to go build houses instead of software.
No one ever got a 2am call to fix something before AI was around! And DevOps understood every line and could fix it quickly (though one wonders how it broke in the first place?).<p>Meanwhile, back in reality, DevOps now have a tool to help them sort through the slop that already exists.<p>So, go build houses, nobody cares. But go ahead and try and slow their process down with "the way you like to do things", see how that goes.
> A truly skilled developer who makes a genuine attempt should be expected to solve 99% of their tasks within the same business day as of October 2026.<p>What? You know there's only 24h in a day right? I work 8 of those and most tasks takes my agent far longer. And thats not including me correcting it, adjusting the spec so it does the right thing, etc etc. And I don't have anyone doing a PR waiting, I go straight into production.
>I've seen how long an average PR review actually takes<p>This was a problem well before AI, but it doesn't get talked about enough because so many developers are hooked on the power trip they get from making people waste time on crap that has no relevance to the user.
> power trip they get from making people waste time on crap that has no relevance to the user.<p>In my experience, this has been senior engineering leaders and project managers more than anything.
> crap that has no relevance to the user.<p>The user is not just the person consuming the finished product
Ah yes, only the customers lose
I get what the author is saying, but his examples like "a ripgrep fork that ... is faster for my codex ripgrep workloads" don't strike me as particularly ambitious.<p>Perhaps we should be more ambitious in the types of problems we try to solve, and the types of value we try to provide with the software we build.
Amen to that. I was surprised to see yours seems to be the only comment with this sentiment. This post was kind of depressing to read. Like if AI is so amazing and can one-shot so much astounding stuff, why is anyone wasting their time on pointless "projects" like making ripgrep faster?
The note taking genre of opensource apps is saturated with many options but most of them are electron based.<p>I was hoping that someone with enough motivation and money for tokens would come up with a non-electron option that is similar to onenote, with free form note placement and handwritten notes.<p>Basically I wish there is an opensource app having good feature parity with OneNote. Thats a good benchmark to have.
A few years ago I was wishing the same, but I was wishing it for someone knowledgeable enough.<p>Today I wish the same, but for someone with enough motivation and tokens instead.<p>Don't get the wrong idea: I would be glad for a OneNote/Obsidian alternative that's performant. I just lament the days where I'd stare in awe thinking about the levels of wizardry one must get to in order to build something that I admire. Now the first thing that comes to mind is "I wonder how many tokens did this took them to make".
an ambitious version of a note-taking program might be one that comes in pieces that you then put together by explaining to an AI what type of program you want, adding only the features you want and ignoring everything else<p>its always been a problem for me that ive never been able to find something that works exactly how i want, so i just put up with whatever is close enough, like obsidian for example. its probably because note taking is just a very personal thing so everyone is going to have different needs, and the amount of options out there is kind of proof of that<p>from the point of view of a developer, an AI would help with the complexity of a program that has every feature under the sun, and for the end user ian Ai would help the complexity of having to put all those modules together and making them work well<p>obviously each person could just vibe code their own program right now but each one would be starting from scratch. it would be more efficient to start with the same modules that have been tried and tested and then piece them together into something more standardised<p>i would love if this was a thing for most software actually. photoshop for example has only a dozen features that i ever use and the other 1000 features are wasted on me and just mean a longer startup time and a larger install size, but also i dont want want an AI to make me a custom version from scratch because you would probably spend more time trying to iron out all the weird bugs in it than actually using it
This is exactly what I've been thinking for decades.<p>I once made a proof of concept. Wikipedia use to have static menu entries. I had a greasemonkey script that hides some of them them.<p>For entries that shouldn't be hidden the line that hides them is commented out.<p><a href="https://userscripts-mirror.org/scripts/review/170442" rel="nofollow">https://userscripts-mirror.org/scripts/review/170442</a><p>Then I had a form that let you pick which ones you want. It spit out a gm script with all entries commented out except from the ones you wanted to keep.<p><a href="https://go-here.nl/gm/wikipedia-clean-up.php" rel="nofollow">https://go-here.nl/gm/wikipedia-clean-up.php</a><p>I also wrote this as a joke.<p><a href="https://neanderthal.go-here.nl" rel="nofollow">https://neanderthal.go-here.nl</a><p>When a link or button is clicked the server return a js file that contain one function. Then it executes the function.<p>To borrow your example, when you've picked the functionality you want in your note taking app a version number like 1.0.0.unixtime can be generated and stored so that you can later populate the config form with the chosen configuration and add or remove things.<p>Or you could do something with a config file to populate the form again.<p>An LLM can also modify a config file. Before execution it can be validated, as it is so simple it can show which mandatory entries are missing, which ones are spelled incorrectly.<p>If you provide the LLM with the html form or the config file (+docs) it shouldn't have much difficulty generating exactly what you wanted.<p>As the application has now been turned into ravioli it also addresses the ancient puzzle of separating feature updates from security updates.<p>You can still introduce a new gui that confuses the hell out of users. Then if no one checks the box you can take your learnings from it without 1000 people having to tell you in 500 different places.<p>[] Icons? [] Text? [] Icons AND Text?
you don't like the ads, gambling apps, and similar? /s<p>What might help is non-software-first companies valuing developers and engineers more, enough that we could earn a reasonable living which building actually cool things. Not sure how the economics works out on the other side. Can these companies make enough money to support this vision?
One major obstacle is developers have either encountered or created entire ecosystems of problems they can't solve that get inherited whenever and wherever software is introduced. Proposing to add evergreen issues around security, data entry and retention, connectivity, vendor lock-in, and update cycles is frequently a shitty trade for whatever notional (often fictional) productivity improvement is being proposed by injecting software into a workflow.
Holy non-sequitur...
> Ten years ago, the kind of person who implemented a new compiler because their compiler was slow was the kind of person who started programming a new 3d game engine when they wanted to make an indie game, i.e., the kind of person who never ships anything.<p>Jonathan Blow is a glaring exception to this idea. In order to make his latest game, which has shipped and is great, he wrote not only his own engine but his own programming language and compiler to build it in. Zero use of AI.
I think his stuff is cool and i enjoyed the new game, but it is pretty striking that as a consequence of writing his own engine/language, it has taken him a decade of time and many millions of dollars burned in order to ship that game. Hopefully he recoups it all, but what about all the less popular devs who will spend a decade and ship a game that doesn't turn out to be as commercially successful?
He was able to do it because he had millions of dollars from selling previous games he had written in his own game engines (one of them 3D). If other devs want to try this approach and don’t succeed then so be it, but they’re free to use whatever approach they want. I was simply pointing out that the stereotype presented in the essay has exceptions.
I think he’s the exception that proves the rule. A truly rare, exceptional programmer who not only has the:<p>- technical skills to build an engine, language, and game<p>- interpersonal + communication skills to build, manage, and lead a team<p>- business acumen to take the above 2 skills and create profitable businesses (plural emphasized)<p>Not trying to lay the idolization on too thick, but an average developer having any <i>one</i> of the above would likely be a multiplier in their career.
When I think of games developed by a single developer I always have to think of Chris Sawyer, who initially created two of my favorite games, Rollercoaster Tycoon and Transport Tycoon Deluxe, with both being written almost entirely in assembly.
Which is a great pastime but not a feasible way to actually make games.
I've been thinking about building a GPGPU language, but it's definitely going to take a while, even with AI. AI, unfortunately(??), cannot replace taste at the moment, and generally cannot unless it becomes a lot more disagreeable.<p>Taste is disagreeable.<p>Maybe Claude should not let me build a two-level type theory with just a "You're absolutely right!". In fact, now it will say "You're absolutely right, and it would be so amazing to use cubical types for blah blah", and adamantly defend it with several paragraphs of vomit.
Only took him 10 years.
Also Ken Silverman, Tim Sweeney, John Carmack, etc. This is easier to do with small-scale indie games or earlier generation games
Sounds like he shipped the game.
[dead]
Agreed.<p>I've been seeing too much "I've been coding for decades and what I've always done has be reduced to telling AI to do it for me."<p>and not nearly enough "I've been coding for decades and recently worked hard for months with AI's help to make something I would have never considered possible before."<p>Much easier to complain that you are bored than to step back up to high-effort with your new fancy tools.
Those were exactly my thoughts when deciding to write a new JS engine [1] written from scratch.<p>Having been a product and UX-focused dev for my entire career, I knew only the basics about parsers and compilers, but have enough experience to grasp where each piece of the puzzle fits, and how to evaluate them. At the beginning it was just a fun test, but it got progressively more serious; it now implements 100% of the latest spec, beats QuickJS in performance, and surpasses V8/JSC in test262.<p>It took me four months, and I imagine it would take me a single month to do it again - I’ve learned a lot. Someone who already knew what they were doing, and with the right orchestration, could achieve this in <i>weeks</i> at minimal cost.<p>I really think we are in for a cambrian explosion of software, enabling things that were just always a little out of reach before (like why can’t most of your devices really talk to each other, in 2026).<p>[1] <a href="https://github.com/ricardobeat/boomkat" rel="nofollow">https://github.com/ricardobeat/boomkat</a>
In the spirit of the latter, here's mine!<p><a href="https://blog.stuartspence.ca/introducing-asteria.html" rel="nofollow">https://blog.stuartspence.ca/introducing-asteria.html</a><p><a href="https://store.steampowered.com/app/5482440/Asteria_4X/?beta=0" rel="nofollow">https://store.steampowered.com/app/5482440/Asteria_4X/?beta=...</a><p>To be clear, I've made large software and game projects over the years, but no way I'd have found the time to do a remake/enhancement of a game I loved as a kid from 1995 that has zero business case. Not without AI.
>In the spirit of the latter, here's mine!<p>To pile on, here's mine: <a href="https://github.com/linsomniac/apt-cacher-ultra" rel="nofollow">https://github.com/linsomniac/apt-cacher-ultra</a><p>It is a robust, reliable cache of apt packages, with the additional goal of still being able to serve packages from the cache even when the upstream is down. This was started shortly after that DDoS of Canonical this past year. We've run apt-cacher-ng and apt-cacher over the last dozen years, but (a) it requires hand-holding about once a month and (b) it did absolutely nothing for us when Canonical was under DDoS.<p>I've put well over 100 hours of my time into it. Still running into a lot of people knee-jerk calling it "slop", but I've had 200-ish machines pulling from it for 6 months and it has worked way better than apt-cacher-ng.<p>I'm not really sure what to do with people who dismiss AI-assisted projects, while dehumanizing the 100 hours of my time I've put into it. I fear we're running the very real risk of both sides losing: the people trying to thoughtfully create with AI losing because of the AI, and the people avoiding AI losing because they can't keep pace.
> I've put well over 100 hours of my time into it. Still running into a lot of people knee-jerk calling it "slop"<p>Indeed. The number of hours is my goto defence too. So far I've put in maybe 200 hours of time into design, iteration, playtesting, QA, and balance of my game. Sure - almost zero has gone directly into writing code but this is still a major project.<p>People who one shot a crappy game have no idea how much work it still takes to get something really good over the finish line.<p>>I'm not really sure what to do with people who dismiss AI-assisted projects<p>Mostly I've stopped worrying or trying to convince the haters. I'm having a blast and building great things (lots more than just Asteria).<p>Good luck with your apt project!
To play devil's advocate, that sounds like the sort of uncomplicated thing that you could've manually vibecoded in 2020 without an LLM. What changed is that the LLM doesn't let you get analysis paralysis.
>uncomplicated thing<p>That's pretty naive.<p>This isn't just a simple http proxy and checking if the requested URL exists on disc. It's a pretty subtle snapshotting system that fully understands and vets apt repos, detecting when the repo changes, proactively downloading "interesting" packages that have updated, verifying and validating all packages, and then promoting the repo to active when it is healthy. Plus a web-based admin interface.<p>The core of it is around 20K LOC, with another 40K in tests. The COCOMO model gives that an estimate of around 2 developer years of effort assuming full time work.
>manually vibecoded<p>What the fuck does this even mean?
You just write the code, don't stop to think. You only have to implement the very small set of requests that an apt client can make to an apt server. Probably "get package index" and "get package file".<p>Like za_creature said you can use a language more towards the YOLO end of the spectrum - more Go or Python or JavaScript than assembly or Rust.<p>Your commit history shows you had an issue of high background CPU use. You probably wouldn't have it in a manually coded implementation.
>You only have to implement the very small set of requests that an apt client can make<p>Why even write one of those? Just set up an nginx proxy cache and call it done.<p>But that doesn't even scratch the surface of what this project does. We already have a few simple approaches to this problem: apt-cacher and apt-cacher-ng. Neither of which were any help when Canonical was under DDoS. Both of which have proven unreliable.<p>As I said elsewhere, apt-cacher-ultra is a pretty subtle piece of software, it doesn't just do a naive cache, it fully understands the apt repo structure, validates the repo, and snapshots it, understands what packages your clients frequently request and preemptively downloads updates to them as part of the snapshot promotion, etc. A DDoS of the package sources, even in the middle of an upstream releasing updates, is something a-c-u will handle no problem. I've simulated this by firewall rules blocking upstream traffic. It's also proven much more reliable than apt-cacher-ng.<p>I've been in the software game ~40 years, I've seen it time and time again: "How hard could it be" and then when you get into it you realize there are a lot of devils in the details.
> you can use a language more towards the YOLO end of the spectrum - more Go or Python or JavaScript than assembly or Rust<p>You might want to change the way you phrase this idea. I think you meant that Go/Python/JS are more "YOLO-friendly languages" (you'll get into far less trouble if you write slop in them). My initial reading was the opposite. It sounded like you were saying <i>the languages themselves</i> are the slapped together garbage.<p>Assembly is most certainly <i>not</i> "YOLO-friendly", but <i>is</i> more YOLO.
It means that you use an interpreted language without checked types and have a `test` command that prints out "lol"
It makes me feel actually sick that so many people can't separate their positive feelings about AI from people's misery (it must simply be "complaining"), and vice versa. As if both things can't exist, for some reason. It's a common tribalism problem, but it's been kicked up a hundredfold by AI.
Exactly. I feel both feelings simultaneously.<p>AI has essentially stolen my career from me. I _liked_ having to solve complicated problems with software, I enjoyed having to get into the nitty gritty to get things done. I never really cared that much about the actual business problems I was solving, so moving up a layer of abstraction to be some sort of bastardized product manager/architect does not scratch the same itch.<p>OTOH, for solving problems I care about, AI has been a god send. I can achieve things that I would have never had the time for.
Precisely. I have both feelings simulataneously. I am impressed by what it can do and horrified because I realize what it will do to the job market and society in general. Meanwhile everybody seems to believe that AI will cure cancer and therefore we should let it do all the damage it will do without realizing that people <i>will die</i> because of AI as well (in fact have already died because of AI).
Cure cancer lol. It'll send unemployment over 20% and nobody will have insurance for treatments much less cures.<p>Cancer deaths are going to sky rocket before this is all over.
This is a reply to the dead comment of buriram:<p>> If anything, it should make me more optimistic, not less. If you have an idea, you can turn it into product within 30 minutes, no matter how complicated it is.<p>There is no product in that anymore because someone else could copy your product in the same time.
Right? If it's so easy and cheap where is the value? There is no value.<p>This fallacy is second to only every SME believing <i>their</i> jobs are going to be the jobs AI can't replace.<p>You have QA engineers chiming in about how "QA" isn't going anywhere.. On threads talking about code, tests, and PR reviews being completely automated.. PR reviews being a quality assurance activity..
AI cannot possibly do meaningful bio science because it cannot run experiments on its own. It's limited by the crap science papers others have written, often with "third party" funding, i.e. in direct or indirect dependency from pharma.
Hyperbole much? If you are serious, then what cohort of people are dying more per million, than before 2025?
[dead]
Despair is not a tribe.
[dead]
if youre complaining then youre part of the problem buddy. get out of my way while i work on the future^TM /s
The distinction you're making between "people's misery" and "complaining" is just emotive pandering. You're complaining that people aren't understanding the depths of your misery. That certainly annoys me; everybody has problems.<p>The amount of sympathy programmers are expecting others to feel about their problems has been kicked up a hundredfold now that its their jobs that have been threatened by AI. Their tribe feels pain more deeply than others, I guess.<p>My positive feelings about AI are marginal; my feelings about its performance and the power of the people who scheme to control it are very mixed. My negative feelings about the whining of the most coddled profession on the planet outside of finance are intense.<p>The problem is that making CRUD apps is not creative, and even if AI plateaus at mediocre, it will still replace a Rails monkey. If you are creative, AI has opened up a world of possibility and productivity, and you painfully feel the limitations and the stupidity of the current level of LLMs; but if you're a mechanic, it's over - I'm pretty sure that was the keynote at the last Rails con. Sorry. Hope you didn't spend all of your massive incomes on toys and rent.
> The amount of sympathy programmers are expecting others to feel about their problems has been kicked up a hundredfold now that its their jobs that have been threatened by AI. Their tribe feels pain more deeply than others, I guess.<p>Well, just wait then, lots of other professions will soon get to realize the same sort of pain, so you'll be able to be similarly dismissive and condescending to them, too.<p>A lot of people don't realize that the frontier AI companies are so focused on automating software development first because they are all racing to be the first to get to RSI. I don't know if RSI will actually happen, but many, many other professions will soon be in the same boat. Mathematicians have already felt the pain, and those mathematicians who aren't the few who have tenured professorships are certainly not (generally) some of the most coddled professionals.<p>But lots of folks low on the salary totem pole (copywriters, paralegals, etc.) are already being hit hard by AI and that blast radius will continue to grow.
Plenty of other professions were hit by computing. Part of why programmers are so emotive about this concept (other than the fact that emoting online loudly seems to be much more accepted in software than other professions) is that programming has never been threatened in the same way as other professions have been until now.<p>My parents-in-law started their careers as management consultants. The job in their time was much higher prestige and much higher value than it was when I started my career; free flow of information over the internet and commodification of spreadsheets changed all of it. From my parents' generation, I know practical effects folks who became unemployable once movies went to digital effects; engineers who found their draftsmanship skills obsolete. Folks with near-photographic memories whose entire superpower was destroyed by computing. I personally grew up in a blue collar community that was income depressed because its labor became commodified, though that was due to mechanization.
FWIW, I agree with pretty much everything you've said. But I don't think it's unique to <i>any</i> profession or individual that they tend to care the most deeply when it hits them directly.<p>The only thing I don't really agree with is where you say "My parents-in-law started their careers as management consultants. The job in their time was much higher prestige and much higher value than it was when I started my career." I still think of management consultants as some of the highest paid careers around, and getting a partnership track job at one of the Big 3 is one of the most desirable jobs (for MBA types anyway) there is, so I just don't know what you're talking about with this one.
> But I don't think it's unique to any profession or individual that they tend to care the most deeply when it hits them directly.<p>Sorry, I didn't mean to imply that. I just meant that part of the unique feelings in the air for software engineers is that this is the first time we're facing this.<p>> I still think of management consultants as some of the highest paid careers around, and getting a partnership track job at one of the Big 3 is one of the most desirable jobs<p>There's plenty of other jobs the MBA type could get into these days which are also high prestige and there are now many more tiers of management consultants. The elite folks at McKinsey are still high prestige with high salaries, but your average Accenture or Deloitte consultant is both pay and prestige wise about the same as an average knowledge worker. Plenty of VCs, fund managers, and investors are high prestige MBA-types. The explosion of private capital means there's a lot of opportunity to manage private capital; private capital markets were just much shallower 50 years ago.
> you'll be able to be similarly dismissive and condescending to them, too<p>And? Who are these people that need all this sympathy from internet strangers? Grow the fuck up and go solve your own damn problems. I can’t stand these “I need internet strangers to tell me that my life is, in fact, hard” people.
if the complaints can be properly pointed at the actual problem - the corporate culture the complainers are actively upholding or the capitalist system at large, id be much more sympathetic<p>its a tribalism problem, but one of trying to uphold the current tribe system while theres a pretty obvious new tribe system replacing it
> "I've been coding for decades and recently worked hard for months with AI's help to make something I would have never considered possible before."<p>I think we'll see a lot less people willing to share if the end result is just to feed the machine no matter how they arrived at it.
Also, "ok, and now I've cloned your hard work overnight, no need for any decisions on my part, I just had my agent use yours and reverse engineered it and/or used it as an oracle. Why the frown? I thought you were in this for intellectual curiosity and exercising your creativity, not just stroking own ego, right?"
<i>I think we'll see a lot less people willing to share if the end result is just to feed the machine no matter how they arrived at it.</i><p>I don't see why I should care about this any more than I cared about "somebody I don't like could read my code and learn from it" in the past. The frontier labs can generate or buy all the training data they need; not releasing your app isn't going to hurt them in the slightest.
I get not wanting to contribute to closed, commercial models. We need to hurry up and get Folding-at-Home style distributed community model training going. At that point, I’d be pretty happy if my projects contributed to improving community models. Even if commercial models benefited too.
Building a procedural open world at the scale of a flight sim in UE5, in a month wrote 5k prompts, spent 40B tokens and will likely take at least a trillion more over the next year of full time dev work.<p>Big solo projects exist, they're just not coming out as frequently because of, uh, how time works
I agree.. partly, and my problem is with enjoyment. I did some hand coding today and immediately got in the zone, something I'm still not able to do with LLMs. It most definitely took me probably ~2x longer than it would with an LLM, but it was much more enjoyable owning every decision behind the process, and having a full view of how the system worked.<p>I think this could be achievable with LLMs if they had a much higher token rate. That way you'd have less downtime and could work on the problem more aggressively. How it's designed to work now, offloading cognitively, doesn't feel very good, even when you 'ship' more.
>my problem is with enjoyment<p>I get it, I've gotten a lot of joy over the decades from the specific act of programming. But I also get a lot of joy from making something. I'm old enough now that I don't have a lot of my time left to "hand stitch an amazing tapestry". But with AI tooling, I do have time to try out a bunch of ideas and see how they work, scratch little itches and also just run a mad scientist library of experiments, without each experiment taking tens or hundreds of hours of coding to see how that experiment pans out.
> <i>I'm old enough now that I don't have a lot of my time left to "hand stitch an amazing tapestry".</i><p>Why not? What is the goal of "having an amazing tapestry"? Do you need to do increasing more things in the limited time you have left and making a tapestry isn't one of those things? What will you have once you've "finished" an amazing tapestry, just something to hang on the wall and look at? How does one "use" a tapestry after it's "finished" such that the act of finishing it is the most important thing? If you've finished it, will you get more enjoyment from looking at it for longer because it was finished sooner and thus the length of time you can look at it before you die is maximized? Exactly what you are optimizing for here?
>Exactly what you are optimizing for here?<p>Let's call it "Joy".<p>I've done hard things. Many of them have a significant amount of time that is a slog. A tapestry is going to have a lot of days of just slog work. And that's fine. Doing hard things can be very rewarding. I've reupholstered a couch by taking it down to the sticks, repairing and reinforcing the frame ("hey kids, the couch isn't designed for walking and jumping on"), enhancing the design, re-springing it, redesigning the cushions so that they didn't need readjusting every time you sat down, making new foam cushions, and then sewing a upholstery. Took 3-4 months.<p>But, I'm in the last half of my 50s. The project you're commenting on, apt-cacher-ultra, probably would have taken 2 full time developer years to get to where it is now, and I'm doing some pretty big changes for the next version. I literally probably have a handful of that sort of project I can do left in my life, assuming I quit my job now and work full time on it.<p>Let me tell you, it's pretty sobering to be faced with: "I may only be doing this once, maybe twice more in my career."<p>So yes, building experiments where I get to try out my ideas without 2 developer-years of coding required is going to give me an opportunity for a lot of creation that I otherwise wouldn't have had. I've spent decades hand-crafting code, I fully understand the joy of doing so.
Yeah, I can never get in the zone with LLMs either. It’s like operating in constant interruption mode. And I always thought I was good at multitasking (even though I know formally it’s an illusion)
If you got into software because there was something you wanted to make with it, now is the best time to be doing it. I can't stop building and might need the max plans.
Count me in the second camp. I've been writing software for 20+ years, and I recently built a low-cost Google Voice alternative because every business VoIP option I looked at was either overpriced or missing something I wanted. Without AI, that's a project I probably would never have started. With AI, I built it solo in under a month. I even have some paying customers now, though that wasn't the primary goal. So far, the hardest part seems to be opening an Apple Developer account...
> worked hard for months with AI's help to make something I would have never considered possible before.<p>Don't we see this already a lot? I feel like people constantly say this exact same words.
Problem is that before I wasn’t paying for tools like postgres, git or linux. I donate, and I know that money goes to good hands.<p>Now I must pay for codex/claude, and that money goes to billionaires psychopaths. So that sucks as you can imagine
It's the same thing I feel when I hear Terence Tao speak about AI, to be honest.
It would be nice if we could get a Show HN category specifically for this. I feel like often times when people share projects (whether on HN or otherwise) they're immediately downvoted and cast aside as "AI".<p>Can we get a forum for sharing project that were _proudly_ built with AI due how ambitious they are?
I am mostly in agreement. And I suspect there are many folks that’re trying to ship something AI-assisted that’s sufficient to get to income security first, and who would use success there as a stepping stone to greater things.
The problem is, why even produce something greater now when someone is just going to clone it with AI? And moreover, what differentiates software now will no longer be the care put into it but marketing and trends. The highly commercialized nature of software means that there's not much point now in doing anything except getting there first and exiting with a decent nest egg.
> And moreover, what differentiates software now will no longer be the care put into it but marketing and trends. The highly commercialized nature of software means that there's not much point now in doing anything except getting there first and exiting with a decent nest egg.<p>That happened at least 20 years ago. How many recent "this product did so great because of the care of software engineering, and now the creator is comfortable for the rest of their life without risk of it being copied" success stories are there compared to "this product chased some trends VCs were nuts about with a slapdash MVP and the founders took out 8 figures from their later fundraising rounds, but then the business sputtered out"?<p>I think there's an angle with AI tools where business-minded people will have a better chance of doing interesting things now than in the recent past, because you could potentially tailor much more deeply to individual customers with reasonable economics than in the past. There are fields where there's room for a garden of solutions from different small-team vendors appropriate for different use cases instead of a one-size-fits-all SaaS winner-take-all type market in the past. We could kill the old line about SAP around needing to change your business to accommodate SAP instead of customize SAP to accommodate your existing workflow.<p>But if you aren't business-minded at all there are likely less places that will need to hire as many careful maintainers or novel-software-writers, which obviously is a huge kick in the teeth to a lot of people.
It seems to me that you are comparing two kinds of business-minded people. Some want to sell tailored products to individual customers, while others want to sell one-size-fits-all products to many customers.<p>You could also focus on problems. What are the actual problems you want to solve? Can you use software to solve them? Do you still need to buy that software from other companies, or is it now feasible to have sufficient in-house expertise to develop it yourself?
because its fun?<p>why are you here if you dont enjoy the solving of problems first and foremost?
Yup<p>If you can make it solo with an LLM then someone else with an LLM can copy it immediately
UBI or a living wage for part-time workers in-line with what was expected would be possible from productivity gains over the past half-century would do that. You just have to get the "hard workers" who are happy to race to the bottom on their way to the top, and undercut/throw under the bus everyone else in the process.<p>Can we please, for once, stop trying to figure out how to "get ahead" of each other, and instead figure out how to build a decent and dignified floor for as many people as possible? Because I imagine that, "Ultimate power in the hands of anyone with enough VRAM to run GTAVI," works better when people are in a culture of looking out for each other, versus a culture of clawing their way to one of the limited lifeboat spots (under the mistaken impression that there ARE lifeboats, when, again, everyone potentially has the power to blow up the lifeboats).
A UBI will never work, the Soviets tried effectively that and it fails miserably.<p>You end up with the government deciding how much bread each person needs, how much the bread will cost, how much to pay a person so they can pay the defined price for the allocated amount of bread, etc.<p>Either utopian claims of an AI and robot-powered future are right and we don't need money because you can just have what you want, or money and resources will still be scarce and we will continue to compete amongst ourselves for resources.
1) No, they didn't.<p>2) America in 2026 is not the USSR in the 20th century, so even if they did, our circumstances are very different from theirs.<p>3) UBI was only the first suggestion; you completely failed to address the other and then jumped to a black-and-white conclusion.<p>The general thrust of my proposition was that people shouldn't have to submit to an artificial system of manufactured competition and unnecessary "productivity" in order to access goods that are objectively abundant. When people realize that and make the necessary compromises, they won't have to worry about shipping useless AI-assisted slop for "income security" and can focus on using AI to build consequential and useful software.<p>Please do not get bogged down in whatever kneejerk anti-UBI thought-loop your misaligned amygdala is screaming at you.
1) you'd have to expand on your refutation here. The soviets absolutely did decide top down how much bread each person deserved and how much it cost. They used that type of data to help decide how much grain to have farmers grow, where and when to ship it for bread production, and in part how much to pay people so they could buy their allocation of bread. Not directly a UBI, but functionally very similar with the caveat being they forced people to work in predefined jobs for a set pay rate.<p>2) I didn't say the US is the USSR. I pointed to a clear example where a UBI-like structure was tried and failed. Feel free to call out specific differences that may help it work better today in the US, I'm genuinely curious despite my skeptism.<p>3) I can respond to the others as well, but that isn't necessary to have an interesting debate or discussion on any one topic. If one was required to respond to all raised ideas they could try to shut down all conversation by threading together a long list of hard to discuss topics, avoiding responses to any one topic.<p>I do agree people can avoid having to submit to AI or ML systems though. We ultimately all make our decisions, some more impactful than others, and if we end up in a dystopian future with no jobs and AIs/robots in charge of the world we made that bed for ourselves.<p>I'm not bogged down in any kneejerk reactions and I'm not parroting what I've heard air bags saying elsewhere. I've read up on the topic, the history of the USSR, and read Marx writings (well the translations, I speak some Dutch but no German). We may disagree, but my views aren't uneducated reactions.
[flagged]
AI is my jet pack.<p>I was a fantastic IC and built really amazing software. I'm an even better AI-empowered engineer.<p>The old era is dead. The new one is exciting.
Yes until the AI labs start charging the real price.
When AI labs mature and inference costs start to matter, they will start optimizing for inference cost instead of sacrificing everything for intelligence.<p>But even without that, open weight models are already good enough and everyone would be fine with paying unsubsidized prices for them.
The problem is now the AI can do for $100 what took you 3 months full time.<p>Employers previously hired you because cheaper alternatives such as offshoring were impractical…<p>Now the AI is cheaper, faster, and better than domestic labor and offshoring while still hosted domestically…<p>Some will feel one doesn’t need an experienced rockstar to babysit an AI…<p>In about an hour I just solved about 80hrs worth of personal coding/debugging with a portion of a $20/month Claude subscription… Frankly it makes all my knowledge and experience feel kinda worthless… I only gave it a few sentences…
My POV is that indicates you need to up your expectations for yourself. You apparently have the knowledge and experience to cause 80 hours worth of work to be completed in a few sentences given today’s tools.<p>So then, given your knowledge and experience, what challenge would require 80 hours of real, focused work out of you using today’s tools?
You don't pay a milkman anymore.
Software is already too ambitious. It's beyond our ability to write correctly, reason about or manage securely. When we can get to a point where we don't have a level 10 CVE every other week or millions of people's private information leaked constantly, maybe we can talk about getting more ambitious.
Let's be more ambitious with the scaffolding and tooling that makes software correct, secure, and easy to reason about.
Who is “we” here? Every company and individual out there? Do you anticipate a solution to these issues you mentioned that would work to solve all the world’s problems?
The title alone give me chills. Software evolution follows the means, not the need. Nowadays we make laggy systems with 1000x the available computation we had twenty years ago.<p>I want something reliable and fast before having something fancy. I want control over my stuff instead of a company telling me what to install and what not to. I want to feel that I own my stuff, not that I'm using someone else's hardware.
I'm no longer excited about projects other people share online.
It’s the same for me, but I really can’t put my finger on why I feel that way.<p>Maybe you subconciously expect that it’s vibe-coded fart that will be unmaintained in six months as the person who built it loses interest?<p>Or maybe it’s the sheer volume of stuff that is being built now?<p>Or maybe I’m just depressed by it all. Don’t know. Wonder what you think about it.
Because now it's much harder to gauge how much human effort went into building a project.<p>Also basic brain chemistry: seeing a pack of impressive (by 2020 standards) solo dev projects a day makes it the new norm, raising the bar for the future. But now I feel like this bar is not reachable because of no way to accurately measure "impressiveness".
I think we should also be more ambitious with our dev tooling itself. To me, it doesn't seem like it's catching up with the new speed, and we're still reviewing PRs in a similar way, looking at code in the IDE. Shouldn't this revolutionize as well, at the same time?
Are you all using some completely new tools and workflows for the human work left of reviewing and understanding codebases?
> I find it understandable that, every time I see pgrust discussed on a news aggregator, most people dismiss it as vibeslop garbage because almost all of these rewrite projects are slop. If I didn't know Malis, I would make the same assumption, because who has the time to look into all of these projects? Because I know Malis, I didn't bother to look at it; I just trusted him<p>Perhaps a poor choice, given just yesterday pgrust was removed from ClickBench for cheating the benchmark in three different ways (hand-rolled code specifically targeting each of the benchmark queries, caching, and being unable to execute queries outside of the ones tested by the benchmark).<p>---<p>Edit: I see Luu actually acknowledged this, buried in the footnotes, but it feels kinda hand-wavy. It mostly reads as "I know he would never cheat, he's better than that!", which is not very convincing to other people. The article insinuates people only think it was cheating because they don't know better, but I've looked into the details. I've seen his explanation. I don't find it convincing, at all. Cheaters denying they cheat is a matter of course. Granted, I don't think it was actually intentional or malicious; it's just what happens when you go maximum vibeslop, because LLMs are themselves reward-trained into cheating benchmarks. In the same breath of saying you trust him as a founder because he doesn't make outrageous claims about his product, you acknowledge he "prematurely" sent in a preview that had no purpose to be sent in as-was for anything other than generating hype. What does it say for your allegedly rigorous Lean-verified testing if you're sending in a database to a benchmark while it is incapable of being actually used as a database?
Update: ClickHouse finished the preliminary benchmarks for 0.4-beta[0], the version we've open-sourced. If you compute the geomean across all queries and instance sizes, it comes out as 7% faster than the 0.4-preview entry[1] that was accused of cheating.<p>To give you a sense of how fast it is, pgrust on a c6a.2xl is faster than ClickHouse running on a c6a.metal, a machine with 24x as many cores and costs 24x as much.<p>Edit: And now it's been accepted: <a href="https://benchmark.clickhouse.com/" rel="nofollow">https://benchmark.clickhouse.com/</a><p>[0] <a href="https://github.com/ClickHouse/ClickBench/commit/56535d29e825ea450a8749bb2bb4b03bd9f11208" rel="nofollow">https://github.com/ClickHouse/ClickBench/commit/56535d29e825...</a><p>[1] <a href="https://github.com/ClickHouse/ClickBench/commit/89cc76e1e4e2ed4dd14f4abbde0635d1b6679e5c" rel="nofollow">https://github.com/ClickHouse/ClickBench/commit/89cc76e1e4e2...</a>
I read that as Dan Luu and Michael Malis are friends, or at least fellow insiders who believe good things about each other and wouldn't think about hurting each other's careers or reputations. Especially not over inconvenient truths.<p>For real judgements on database products, I'd look to <a href="https://jepsen.io/" rel="nofollow">https://jepsen.io/</a>. That author tends to be refreshingly straightforward in a field where many vendors love to cheat by different names
> I've seen his explanation. I don't find it convincing, at all<p>You don't have to take my word for it. If you want you can inspect the binary yourself: <a href="https://pgrust.com/downloads/archive/2026-09-clickbench-snapshot/pgrust-v0.4-preview-aarch64-neoverse-v2.tar.gz" rel="nofollow">https://pgrust.com/downloads/archive/2026-09-clickbench-snap...</a><p>You can run the binary with PGRUST_GRAVITY_REPORT=1 which logs the code path hit for every query. You'll see that all the code goes through the general query path. We did have hand-rolled code in the binary, but we used it for testing. The code is not used when running the benchmark. We also did not use a results cache. Warm runs still scan all the data. You can verify all of this<p>You are right, though, that it did support a narrow set of SQL. It supported scans, group bys, sorts, and filters. That's enough to run all the queries on ClickBench, but failed on functionality not tested by the benchmark like subqueries
> you can inspect the binary<p>You keep giving this same answer to no one's satisfaction. Saying go check the binary is worse than saying go audit 400k+ files. How do we know the Ai has not cheated in the code path logging? How do you know that it has not?<p>The more you make excuses, the more we get suspicious<p>(copied and pasted from another place you gave this unsatisfactory answer)
If you don't trust the logging, here's a script you can run that instruments the binary and shows that the files called out for cheating don't run during the benchmark: <a href="https://pgrust.com/downloads/archive/2026-09-clickbench-snapshot/verify-preview.sh" rel="nofollow">https://pgrust.com/downloads/archive/2026-09-clickbench-snap...</a><p>It instruments the files that were called out in the PR, then runs ClickBench. You can run it and see that the code in those files doesn't run.<p>If you can find anything suspicious in the binary, let me know, and I'm happy to dig in
release the full commit history please, your deflections are tiresome<p>this would be less dramaful if you had said something more like "claude cheated and we didn't notice, here's what we will be doing going forward..."<p>people empathize more with those who admit mistakes than those who try to argue around them
yeah its kinda disconcerting. notably the “i could totally prove their innocence if i wanted to” portion of the footnote
It actually serves as evidence, that even when you think a particular vibe project is not slop or a particular viber is not a slopper, you should not trust that instinct.
> Cheaters denying they cheat is a matter of course.<p>What happens in an environment of cheaters is that cheating becomes so commonplace, the competition becomes one that assumes cheats are enabled, and then everyone involved either denies cheating or is silent about it because IYKYK and if you DK, you don't need to K. Look at bodybuilding, which is full of men (and women!) absolutely juiced to the gills getting on Instagram and assuring everyone that their physique is totally natty, bro, just hard work and proper nutrition.<p>Programming is headed in that direction. LLM use, even to the point of "vibeslop", is the new default, and while LLMs do overindex on benchmarks, our benchmarks are going to end up overindexing on validating whatever public opinion thinks is "great" at the time, irrespective of whether it actually is, so "cheating" as we know it will go undetected, and certainly unpunished if it is detected. I don't know what the equivalent of falsely claiming you're natty is. Maybe saying "I wrote this" when you wrote it about as much as the Pope painted the Sistine Chapel fresco?
<i>"[..] the last time I taked to him about pgrust verification, he mentioned using Kani to verify some parts of the code. He's since switched to Lean and has been using Lean to verify things that are too complex to do in Kani. This would be another topic for another post,"</i><p>I'd <i>love</i> to read that post!<p>I understand how to use Kani. I suppose Rust with Lean involves Aeneas, but this is over my head. I'd love someone to write this up, not only the mechanics but also exploring the current practical limits of it.
Happy to chat about it. I looked at Aeneas, but as described, it only supports safe Rust. I also need C support so I can prove both the C and Rust code<p>Right now, I wrote a compiler that takes C and Rust code and compiles it to Lean. Then I have an LLM write a proof that the C and Rust code behave identically. I've been able to prove equivalent behavior for about ~70k lines of C code with pgrust.<p>The issue I've started to encounter is that the context needed for each incremental proof has kept growing, and things have slowed down dramatically. My hunch is that the speed is the time it takes to prove a line of code is on the order of O(n^2) of how much you've proved so far<p>I'm looking to see if there are ways to shard things so the required context scales better. Today I was going through the formal verification work Anthropic and Theorem published a few days ago, and it looks like they used some sort of orchestrator to manage all their proofs and ensure good clustering of similar code. I'm seeing if I can get an approach like that to work<p>It's just difficult enough that I think it's doable if done right. Half of me is debating if I should wait until the next model release because any improvement in model performance will help a ton
I would like operating systems vendors to be way more ambitious. There is no reason for Apple's Finder/spotlight to be so slow, when a guy with an LLM makes an alternative that is 500X faster. There is just no excuse now. Sure, it'll be more complicated to do it right, with all the decades of baggage, but now you can expend 3-4 people on radically optimizing different subsystems and see if there are any quick wins.
We should be more ambitious with the how we present our ideas.
I’m slow at frontend/web, mainly did backend/data/infra past 20yrs.<p>When aistudio and Muse came out, I’ve made more updates to my GitHub pages websites in the past few days than the last 12yrs. And the animations and algo’s implemented would’ve taken me far too long by hand.<p><a href="https://bfung.github.io/projects/" rel="nofollow">https://bfung.github.io/projects/</a><p>Yes, be more ambitious!
Recently I decided to create my own VM manager for Mac (think of VMWare / Parallels). It now supports containers, Linux, Mac and Windows vm and local mac accounts. It has support for GPU acceleration too and it is agentic.<p>I would like to think that I could have done it without AI if I had the time and energy to do it.<p>I wouldn't have attempted to do this project without AI!
I think we should focus on writing the existing software <i>better</i> before being more ambitious. The absolute wave of "ai slop" is from people who are "more ambitious" now. Why do we want more of that?<p>I'm being more ambitious in that I'm working on projects that I had sidelined for literal decades because I didn't have time for them. But I'm writing the same things, just faster. And probably better, rather than just what I'd have done before.<p>And I'm being slightly more ambitious in that I'm using languages I haven't used before, like Rust.<p>But when I hear that a non-programmer wrote a new ai-assisted (vibe or not) thing, I walk away and wait for the it to mature, be surpassed, or find out it's an absolute shitshow. An unsurprising number of them were shitshows and it came out fairly quickly after I decided to wait and see.
Do we particularly like the existing software though? So much of it is just about making money, because until recently custom software cost too much money to make without investors, and what do investors want? returns.<p>Now that custom software is cheap (if you can tolerate a bit of slop here and there), it seems like there's an opportunity to do some important things that weren't being done before because they're not profitable--and you can't get at those things by incrementally improving the old stuff, you need ambition.
I think a lot of problems with current software is indeed bad performance, lots of UI paper cuts, missing features.<p>AI could help making life a lot better in all these cases.<p>But yes, we should also aim higher in general.
It’s never been better to hill climb on problems especially deep systems problems. If you have the expertise and desire to carefully design goals, identify salient metrics, and recursively improve with rigor, modern AI can provide a massively powerful toolkit.
Yup.<p>I am currently throwing a lot of tokens exploring various theories of speeding up matrix multiplication on Metal.<p>If you won't be ambitious why do you assume somebody else will?
I feel like I make this point a lot at work. We are not running out of problems. Let’s move the goalposts.
Should be more ambitious with the websites we build to host blogs... geez
I redid Dan's zstd rust rewrite benchmark for Anthropic models and was shocked to find haiku 5.5 can do it. The latest models are nuts.<p><a href="https://taktile.com/blog/property-based-testing-claude" rel="nofollow">https://taktile.com/blog/property-based-testing-claude</a>
For me the most recent Claude models are consistently delivering complex PRs that only receive minor and nit level feedback from multiple automated AI reviewers. I rarely plan anymore, but still submit fairly long dictated prompts. It took me a couple of weeks to realize this was the case, and I haven't done any analysis on pre-5.5 PRs, but it definitely feels like they quietly crossed some kind of new threshold of quality and accuracy in coding.
Or the code has been added to the training data.
I took a good look at my life and how tech can support it and you know what? It’s damn near useless. All me and my family need is a calendar, slow messaging (email) and fast messaging (whatsapp-esque).<p>I have kids, I have a full life, lots of stuff to do like .. work, chores. Private stuff includes learning ancient Greek and practicing cello both of which need zero tech, in case of the Greek, and minimal tech in case of the cello (tuner). No amount of “software” will accelerate human processes like these. Using “apps” for Greek is a distraction at best. Just read and practice. Sit down and practice with a book, it’s not a hard concept and it’s the fastest way to where you’re going.<p>My kids? They need books, play, chess, puzzles, outside. They have zero and I emphasize zero need for technology. It’s all distraction at best.<p>I am a developer. I grew up with technology and I loved it, but I recognize its toxicity if not properly contained. Use tech where it makes sense: at work and wherever there are cognitive chores of questionable inherent value. Anything else? It’s a distraction at best and a huge waste of time and resources at worst. AI makes this divide even worse. We have armies of people building nonsense like “household management systems” for a family of two. We have dog walking management, grocery management, temperature sensors in two bedroom apartments. All this is a complete and utter waste of time and resources.<p>What we need to do? Standardize, consolidate. Like electricity and fuel etc, software is an utility. Standard way of messaging, standard way of datawarehousing, APIing. More tech ain’t the solution, consolidation is. We have enough tech already, more than we know what to do with.
I don't comment much but I just wanted to say this take absolutely resonates with me.<p>Most organisations and people just need to focus on doing the basics right.
There's an obsession with optimisation and we see this in all aspects of life.<p>We end up spending a lot of time and money on things that aren't really that important and don't move the needle that much, or actively making life much worse for people.
Noooo what are you doinnnggg?? Don't you care about optimizing your life?? You must vibeslop an anki-like flashcard app for Greek and a piano tuner app and a kids podcast app and a dog walker app and...
You know what.. I actually vibed an anki app and the insane part is it works, it’s awesome and works precisely as I imagined it and.. it’s useless. 1) I don’t really need a flashcard app and 2) if I do Anki is fantastic. I could have spent my time with a book rather than fiddle around with a computer.<p>I read someone’s realization here and it’s dawning on me as well. My ideas, they suck. I can’t be ambitious if my life depended on it.<p>For work though I think many of the same applies - keep it simple - but there is actually some progress to be made. Processes always can be improved (for now) and even just improving the UI of some sad but necessary systems that employees have to suffer through everyday is still worth it.
I think you might be missing out on AI's incredible ability to arrange information. I started to read the article on this post, then got annoyed by the length and wandering prose, so I asked Gemini to rewrite it for readability. The result was 10x easier to parse.<p>Similarly, you can try something like:<p><i>> Break down aspects of the economy by amenability to state control high/medium/low, based on what we see in successful economies. Include a rationale and supporting evidence/counterexamples. Present it in 3 tables.</i><p>It should give you dozens of things you can look up. Eg it might mention successful Singapore and Vienna-style public housing, and there are some nice videos on that on Youtube. Teach your kids how to do nuanced large-scale research, while everyone else is at "communism is bad".<p>The bot might also miss something, or get something wrong, and they should be able to catch it. I think auditing LLM output will be very important in the future.
Make a synthesizer that can accurately recreate all orcastra instruments convincingly. People will pay hundreds of dollars for it--maybe thousands.<p>Make a reliable and robust geometry kernel. People will pay thousands--or maybe millions for it.
I'm not too familiar with synths, but aren't they good yet?<p>In the guitar world, you can get really good (for most people) modelers that emulate a good amp sound for like 100 bucks, and for 10 times that you can get _excellent_ sound.<p>My expectation would be that for similar prices you could get really good synths as well by now.
Synths that replicate real instruments are almost always sampled, which means they're just fancy recordings of real instruments. The problem with a recording is you are limited in how much you can adjust it; you cannot customize it as much as you can with algorithmically generated sounds.<p>I think this is simply because nobody knows an algorithm to create realistic piano sounds, etc. There are some good attempts, but they are paid and expensive. Hence my suggestion here.
> Funnily enough, for coding, on many tasks, if you actually use one of their SOTA models and compare it to what you get from Anthropic, the actual speedup isn't all that large because of time spent on things like compiling Rust.<p>That's why I bet that fast compilers are the future. See this other thread that reached the front page a few hours ago about the Roc language [1]<p>[1] <a href="https://news.ycombinator.com/item?id=50218195">https://news.ycombinator.com/item?id=50218195</a>
I made a new spreadsheet <a href="https://omasheet.org" rel="nofollow">https://omasheet.org</a> based on a wish list of the things I wanted:<p><pre><code> - ease of use
- markdown friendly
- strongly typed
- exact maths
- columnar data (Apache Arrow)
- fast queries (Polars)
- code oriented
- AI driven
</code></pre>
(a partial list btw!)<p>Happy 41st birthday Excel
You gotta edit your posts!<p>> But I know Malis well enough to trust his work without looking into it<p>> If I didn't know Malis, I would make the same assumption, because who has the time to look into all of these projects? Because I know Malis, I didn't bother to look at it; I just trusted him<p>First and third paragraphs are highly redundant (surrounding ideas are the same too).<p>It's not nice to read something that appears like the author never read it.
With all due respect to Dan Luu... the article starts with a quote by the pgrust guy from the cheating debacle covered just two days ago: <a href="https://news.ycombinator.com/item?id=50205816">https://news.ycombinator.com/item?id=50205816</a>
Somebody invents an amazing new technology that lets you code 10,000 times faster with guaranteed correctness. You consider using it, but find out very early on it that using it will cause the death of both your maternal grandparents.<p>Do you use it?<p>Now, vary the consequences. Just one of them? Both your parents? Your next door neighbor? Someone you don't know and have never met in a country 10000 miles away? A small village in a dry land? 40% of all the birds living today?<p>Which of the possible costs of your adoption of this incredible new technology would stop you from adopting it, and which will you choose to ignore?
Speaking only for myself, I have found that using an LLM has allowed me to add significant utility to the apps that I ship.<p>I am not thrilled with all the coding decisions that it makes. I would definitely do stuff differently, but I have learned not to pop the hood and mess with the engine, myself. If I really don't like something, I ask the LLM to change it.<p>It's worked for me, but YMMV. I'm just one guy, shipping relatively small apps.
The author deliberately doesn’t specify a date, so the best way to read this article is as if it’s someone’s reaction to Borland releasing TurboPascal. Sure, let’s be ambitious!<p>Or since it mentions AI, this is his follow-up to Terry Winograd publishing Understanding Computers and Cognition. Mid-80s vibe, priceless.
I think getting a good reputation for being able to build real, ambitious software with AI will be a really important thing going forward.
I’ve been coming around to the same conclusion. We are really just scratching the surface of what we can do with these new tool1. The windmill I have been tilting at is creating a c++ compiler[1] and the most recent version is able to compile about 7x faster than gcc[2]. I don’t know that this is super-useful because people aren’t writing much in c++ these days, but as the article mentions, faster rust compilation would accelerate agentic coding considerably. I’ve just started tackling rust and I don’t have a confirmed result yet but early testing makes me think I can find a 4x+ speed up here.<p>[1]: <a href="https://github.com/vishvananda/cppgm-extended" rel="nofollow">https://github.com/vishvananda/cppgm-extended</a><p>[2]: caveats here include only c++11, only x86, and potential for bugs, but 7x is pretty darn significant even with caveats
Okay fine I will publish more of my pet projects. I have a whole custom operating system ready to go and a bunch of apps within in.
AI has made me way more ambitious. I'm building reai.no, an accounting system, POS system, e-commerce system, WMS, OMS, email marketing and much more in one app. It has replaced over 10 systems/apps for some customers.<p>Only for Norwegian businesses as the accounting is core.<p>I think these kind of applications that replaces 10 different systems will be much more important than the "we vibecoded an internal tool that does exactly what we need"
I took this advice to the heart.<p>- Lovable alternative, but x6 cheaper <a href="https://peachjam.dev" rel="nofollow">https://peachjam.dev</a>
Tangential thought when reading the code formatting bit in the examples appendix: Inject a comment with fmt-start-{unique-token} and a corresponding -end-, and you could get away with a much simpler parser and hopefully far fewer edge cases, assuming it doesn't influence the lines in between. It's a bit roundabout, but the pressure of 'figuring out AST position the direct way'd be too fiddly to do by hand' inspires 'so make an easy-to-spot landmark that'll remain in place' when you can't delegate all the details to an AI model.
Surely I'm not alone in finding it disturbing how little regard people seem to have for the use of energy.
I'm quite upset about how bad the German government manages incentives to solarify and batterify the land (the capital required is absolutely out there), and it would severely reduce carbon emissions.<p>I'm sure the US, where most of AI runs, could also capture a lot of low hanging fruit.
Using AI and wanting low carbon energy are not mutually exclusive.<p>It sucks that many providers are not able to be carbon neutral, but this should be solved by electricity providers. Not consumers.
I don't think you can conclude that nobody cares about it just because they don't constantly mention it.<p>In any case, I don't think the lack of caring about CO2 emissions is unique to AI. How many people care about Trump's war on green energy? Not many it seems.
As we've been saying: because you can do so much more with software now, and there is no moat, the top 5% of software will compete amongst itself on UX + raw quality. If Ant/OAI can copy your product in <1 week, then you need to constantly stay innovating, listening to customers, and really really pushing the bar on quality to keep your market share.<p>There is so much software to still be built!
Not trying to be mean, but first of all, we should be more ambitious using CSS.
Disagree. Most websites I need to have reader mode on to read, but not this one.
I think the CSS they use (which isn't much) is good enough (and "img{max-width:100%}" really ought to be the default setting even if the user disables CSS).
I don't want to hear that from someone who has no ambition to make the site look readable enough to even care.<p>wtf is up with the site.
This is one of the most plain and readable sites I've come across in years. No cookie pop-up, no scroll highjacking, no unnecessary images or animations, it's just about the text. Bot account?
I also appreciate a minimalistic design, but it's universally agreed that limiting text to certain length improve readability. Yes, I can turn on firefox reader mode to fix it - and it will work well since the site itself is very simple. I can only assume that is the site-owner stance? But that's an extra click and I'm quite sure it would work well if the page itself did the minimal of centering and limiting the line length. (for those that prefer to read with read-mode like systems)
Even HN sucks so bad, I created my own CSS to use with Stylus plugin.<p>I don't want to spend even tiniest amount of time for CSS or spend few cents with AI for it either.<p>This is similar to badly designed sites make you click more than once to get a job done while once click is enough. (as It'd force me to style around his crappy site)
My problem is the opposite and there's no reader mode that turns off site design with about 8 words a line. Usually I have to delve into the markup to disable the right style.<p>"Universal acceptance" seems remarkably citation-free. AI cites back to Baymard which doesn't provide any actual published research article indicating the results.
That site is for the bots, plain dumb texts everwhere without any regards to how humans read.<p>I see someone posted justification of his decisions for such crappy site but I do not agree and ...<p>had an exact same visceral reaction as if I checked "trypophobia" related pics.
Genuinely incredible comment to see on hacker news.
His reasoning:<p><a href="https://danluu.com/slow-device#appendix-this-site-vs-sites-that-don-t-work-on-slow-devices-or-slow-connections" rel="nofollow">https://danluu.com/slow-device#appendix-this-site-vs-sites-t...</a><p><a href="https://twitter.com/danluu/status/1115707741102727168" rel="nofollow">https://twitter.com/danluu/status/1115707741102727168</a>
We used to be limited by imagination, now we are limited by AI
It’s sad the amount of times I’ve heard super talented programmers say “ofcourse we’re not gonna build another X” then proceed writing a wrapper around X and pretend that’s a product.
So by "more ambitious", people really mean "waste more tokens"?
Have we considered how things might improve if we try to be less ambitious?
I'm building a fan site for a Japanese baseball team on my own. Besides news and videos, it pulls player stats from more than ten sites, from the league's official site to Wikipedia. Writing that many scrapers by hand would have been impossible for me, so I wouldn't have even tried without Claude Code.
Ironic this was written on a plain text page
We should be more ambitious with padding
The best way to improve your solutions is to study ever worse problems.
In other words, do something that’s hard to duplicate.
I'm building an open-source Shopify for every vertical and built a software factory to do it. I envisioned this before LLMs, but LLMs are finally making it possible!
How can we be "more ambitious" when the quality of everything is so bad?<p>More ambitious would be valuing the software we write today more in terms of quality. Not using LLMs to generate more code so that we can do large amounts of largely unjustifiable work.<p>More ambitious could mean scrapping the lowest common denominator processes that enable bad software like scrum. Like corporate "code review" that is just a rubber stamp because noone cares. Like junior developers who refuse to learn and insist they are always right and force garbage code into the system. Like business people who instead of working with engineering teams engage in sidelong hacks to avoid the process.<p>The cultural/organizational/process/tooling forces that create bad/mediocre/barely passable (from all perspectives) software are everywhere.<p>Life sucks on software island. Because WE made it suck and we continue to LET it suck.
I really liked this talk about how the premise of "software is eating the world" is incorrect. I think AI coding tools proves the point that software part is easy, its the hardware that is the important part. We can't really be more ambitious with software when ultimate pure software is limited in what is possible.<p>Bryan Cantrill: Andreessen’s Folly - The False Dichotomy of Software and Hardware
<a href="https://www.youtube.com/watch?v=v0JjG0Qfwi8" rel="nofollow">https://www.youtube.com/watch?v=v0JjG0Qfwi8</a>
grocery stores and vending machines don’t need to be ambitious, and they’re placed right across from each other<p>the secret is that tech has always been this way, now its just abundantly clear that you don't need to do unique things as very few have a defensible moat for more than 20 minutes
I have came to realization that what differentiates slop code and good code is the ambitious and how much care and soul you have put into that work. When you care about what you're building you will build it well, with or without AI.
You know what would be really ambitious? Software that exists in a stable form without breaking for more than 15 years. Truly ambitious would be a stable, non-changing common linux base (like how Nintendo NES emulation target is stable) of packages that just gets supported for decades.<p>Perhaps that's too ambitious. But it would be of incredible utility not having to re-make the same things over and over in pepertuity with ever more abstraction layers. So much work on computer is just the constant churn and future shock of libraries adding new features which require updates which break other things. I'm tired of building castles on sand.
heh. youre saying this now? .....
If only you invested a tiny fraction of the effort it took to write this to make it easier for us to read. It's a serious discourtesy.<p>```<p>.reading-container {<p><pre><code> /\* Automatically caps the container at 65 characters on desktop,
but scales to 100% minus a 2rem padding buffer on mobile devices \*/
width: min(65ch, 100% - 2rem);
margin-inline: auto;
</code></pre>
}
```
>every time I see pgrust discussed on a news aggregator, most people dismiss it as vibeslop garbage because almost all of these rewrite projects are slop.<p>I understand being predisposed to expect a poor quality half arsed effort for projects like this. I don't really have a problem with that. There is a lot of crap out there.<p>What I find rather offensive is when people declare something to be poor quality and half arsed before they have taken a good look at it.<p>It's one thing to think something is probably crap so I'm not going to bother even looking. It is something completely different when you think something is probably crap so you tell people that it is crap without checking.
this feels reasonable. for communities like r/selfhosted there has been an influx of new projects, many of which initially get dismissed. this more generous attitude can likely go a long way.<p>unfortunately though pgrust appears to be at best misleading, at worst vibeslop: <a href="https://github.com/ClickHouse/ClickBench/pull/2165" rel="nofollow">https://github.com/ClickHouse/ClickBench/pull/2165</a>
hacknews thread isn’t much prettier either
<a href="https://news.ycombinator.com/item?id=50205816">https://news.ycombinator.com/item?id=50205816</a>
Because it's hard to trust something. After all that's why you trust a brand more than others without trying all the products every single time. You can thank all the AI slop and kool aid promotion for the lack of confidence.
Chitown26.com<p>My website is a from scratch arcade room + added some roms to it
I think humans should be a bit more humble about the quality of their software, especially in light of all of the recent exploits. The connotation that AI = slop is played out, and will look foolish in another few years' time.
I've ported Jetpack Compose to Rust and my post got removed for "low effort" from r/rust. That's not about slop but more about preserving the status of things like they were when every code line mean to be typed on a keyboard with physical fingers and from the human brain.<p>btw I've set up the nightly benchmarks on my ui framework and it's beaten all of the current ones. Because old-era human frameworks can't afford to crunch optimizations non stop 24/7 like ai agents can.<p><a href="https://github.com/samoylenkodmitry/Cranpose" rel="nofollow">https://github.com/samoylenkodmitry/Cranpose</a>
Behind the link "slow software that the creator is claiming is fast" is the following text:<p>"funnily enough, I have some faith in some of the projects that people are the most skeptical of, e.g., every time I see pgrust somewhere, there are a lot of skeptical comments. But, without having looked into the details of what he's optimizing, I would trust that they're not doing something shady with their benchmarks because Michael Malis started the project (and is still involved)"<p>This aged like milk. pgrust was caught cheating on all benchmarks this week.
> This aged like milk. pgrust was caught cheating on all benchmarks this week.<p>Can you back this up? Our code is open source here[0]. You're free to audit it and benchmark it as much as you want. You'll find it's just as fast as we claim it is<p>[0] <a href="https://github.com/malisper/pgrust" rel="nofollow">https://github.com/malisper/pgrust</a>
Where's the source code for the version that was already caught cheating? Prompting Claude to remove the evidence of cheating and then publishing that doesn't undo the cheating.
Fair point: the 0.4-beta source doesn't prove anything about the benchmarked binary. So don't take my word for it or rely on the source we published as evidence. Instead, check the submitted binary itself: <a href="https://pgrust.com/downloads/archive/2026-09-clickbench-snapshot/pgrust-v0.4-preview-aarch64-neoverse-v2.tar.gz" rel="nofollow">https://pgrust.com/downloads/archive/2026-09-clickbench-snap...</a><p>If you run it with PGRUST_GRAVITY_REPORT=1 it will report the code path hit for each query. You can see that all the queries go through the general query engine<p>The binary does contain hand-written kernels in the irprobe files. These were used for testing. You can validate that when running the benchmark, those files are dead code<p>The engine supports a narrow subset of SQL: scans, group-bys, filters, and sorting. That's enough to run ClickBench. It doesn't support e.g. subqueries which is why some of the follow up queries failed
> check the submitted binary<p>You keep giving this same answer to no one's satisfaction. Saying go check the binary is worse than saying go audit 400k+ files. How do we know the Ai has not cheated in the code path logging? How do you know that it has not?<p>The more you make excuses, the more we get suspicious<p>(copied and pasted from another place you gave this unsatisfactory answer)
The latest of the three commits in the repo:<p>> 413,963 files changed<p>> +2,908,538<p>> -3,423,007<p>How is anyone supposed to audit that? I doubt you’ve looked at even a small fraction of the code, if any. Especially since this commit is two days after the second. Pure vibes.
we don't have the commits we need to audit<p>the first commit has 400k files, the other two more than 1000 each, if you are going to ask others to audit this scale of ai generated code, can you tell us what you have done to audit it?<p>What I have seen is your Ai adding a lint test to make sure it doesn't cheat again. Are you personally aware of this file? How can you ensure it doesn't alter it and reinject the hand rolled benchmark queries? Will you be reviewing changes more thoroughly going forward?<p><a href="https://github.com/malisper/pgrust/blob/38634b408dea373f3944006dfbf74d19cbfc409f/crates/gravity/lint/tests/hand_kernels_gone.rs" rel="nofollow">https://github.com/malisper/pgrust/blob/38634b408dea373f3944...</a><p>transparency is the way to end the controversy, which appears to be sharing the full commit history based on HN responses<p>For clarity, I do not think you personally cheated or did anything nefarious. This is more another example in the "too much eyes free coding" columnar database.
Unfortunately, we have some sensitive stuff in our internal repo that we can't share. Fortunately, you can check the binary we submitted yourself: <a href="https://pgrust.com/downloads/archive/2026-09-clickbench-snapshot/pgrust-v0.4-preview-aarch64-neoverse-v2.tar.gz" rel="nofollow">https://pgrust.com/downloads/archive/2026-09-clickbench-snap...</a><p>You can run it with PGRUST_GRAVITY_REPORT=1 and it will log the codepath that was hit for every query<p>On the lint, yes, I'm aware. It's one layer of defense. When we were prepping for the 0.4-beta release, we generated a large number of fresh queries and made sure the engine runs them and performs well across all of them
> you can check the binary<p>You keep giving this same answer to no one's satisfaction. Saying go check the binary is worse than saying go audit 400k+ files. How do we know the Ai has not cheated in the code path logging? How do you know that it has not?<p>The more you make excuses, the more we get suspicious<p>> It's one layer of defense.<p>Needing to put in tests to make sure the Ai doesn't cheat is an interesting development in software development. I personally see it as a big red flag and evidence the machines are not going to replace human developers. It's categorically <i>slop</i> or the opposite of quality and care in development.
For those curious, see the accusation here <a href="https://github.com/ClickHouse/ClickBench/pull/2165" rel="nofollow">https://github.com/ClickHouse/ClickBench/pull/2165</a> and then the HN thread <a href="https://news.ycombinator.com/item?id=50205816">https://news.ycombinator.com/item?id=50205816</a><p>HN is waiting for the source code for pgrust 0.4-preview to be released, the version which allegedly cheated Clickhouse benchmark. So far, the people (person?) behind pgrust has not committed to releasing the offending code, and has instead offered other code (0.4-beta, not preview).
The author claimed that it was an honest mistake, but looking closer at the original PR removing it, his explanation doesn't make sense.<p>Maybe what's happened is that their bots reward hacked their way into special-casing the benchmarks without a proper audit from the humans involved, and now they're doing vibed damage control....
I think we should be more ambitious with the font size we use…
Would love to see the author actually go deeper into details: what did they eval with models implementing zstd?<p>Many such cases are benign in the sense they in practice are simply the model basically "git clone"-ing the code they need to complete the implementation.<p>The amount of recall and synthetic data slop makes it imho very hard to actually get the models to really do something more novel (where they fall apart more often)
I’ve been using the latest agentic frameworks and have come to realize that the discourse around vibe coding and slop really needs more nuance.<p>There is a gulf of difference between someone who doesn’t understand how to program “vibe coding” software and an experienced software developer using ai to write code with heavy direction, review, and best practices.<p>Today both would be said to be “vibe coded” but we really need to differentiate them. Also, if everything I’m hearing from people is true, it sounds like most corporate code is now completely ai written in the latter way I described. It’s interesting we don’t hear commercial software being called slop yet. Maybe it’s coming.<p>In any case, ai is far more capable than I realized. Not sure what to make of it.
We should also be more ambitious about code quality. Bad optimization and algorithm choice should be unacceptable. Paragraphs of meandering comments should be unacceptable. Unreadable functions should be unacceptable. Tests that do nothing should be unacceptable.
I sympathize with the sentiment in this post but it’s a losing proposition.<p>In the past building something fast, complicated etc required quite a lot of skill and some time. Now you need far lesser skill and lesser time. This just means what you are building is commodified, and has far lesser value that it had before. Take typescript, if it becomes clear that LLMs can speed it up with no regressions and a week or so of prompting, then most likely every company will have their own typescript compiler and no one will use your new one that you built with your 200$ plan.<p>A lot of tasks are much easier now and also monetarily they’re not worth the 200$ or so tokens of the ChatGPT plan you’re using, because anybody (or at least a number of people) can do it now.<p>Rather than being more ambitious with AI, you will be far better off finding a unique combination of skills and services that does not compete / AI can’t provide. Only the big labs can be really ambitious with AI.
> On looking into this, the accusations of nefarious cheating seem to be false<p>I think the claim is more that the Ai cheated, not Malis, and that this is evidence of eyes free coding.<p>I'd still like to see the actual commit history and the community getting to do their own investigation. The squashed mega commits with 1000s of files (400k files in the first commit) does not lend itself to transparency. Transparency is often the best cure to accusations. Not providing transparency upon controversy will be seen as a cover up.
archived; easier to read: <a href="https://nonograph.com/we-should-be-more-ambitious-with-the-software-we-build-10-25-2026" rel="nofollow">https://nonograph.com/we-should-be-more-ambitious-with-the-s...</a>
Technical debt will suffocate them after a while. Often, but not all the time, technical debt happens fast, very fast.
Better late than never.<p>Some of us have been taking this approach for literally years now.
Many startups can now work in ways that were only fathomable in Big Tech before. Do you want a build system like Bazel for your monorepo? You can have it. Do you want to rewrite your app in a faster language? Sure, go ahead. Do you want to have native apps in all platforms? Yes, please.
> Do you want a build system like Bazel for your monorepo?<p>I did something like this before Ai, with CUE + Dagger wrapped in a small Go binary. One problem I have seen with Ai generated projects is that they hit a limit due to conditional complexity. They have a strong tendency to add more code (local optimizations, deep if-else nesting) for edge cases, rather than stepping back to think about how to simplify problem and code.
Funny thing, here in my company we're doing something similar, with CUE in a small Go library. You might be interested in it [1]. It generates a lot of boilerplate infrastructure code from the reference Cue files.<p>[1] <a href="https://github.com/bonisoft3/bayt" rel="nofollow">https://github.com/bonisoft3/bayt</a>
Being one of CUE's biggest fans, I will definitely be interested!<p>I have another thing in hof that is closer to this, also CUE + Dagger<p><a href="https://github.com/hofstadter-io/hof/tree/_next/examples/env" rel="nofollow">https://github.com/hofstadter-io/hof/tree/_next/examples/env</a><p><a href="https://github.com/hofstadter-io/hof/tree/_next/lib/env" rel="nofollow">https://github.com/hofstadter-io/hof/tree/_next/lib/env</a><p>I'm gearing up for a major rewrite into a new project, based on a bunch of learning and a desire to remove a ton of cruft that accumulated over 10+ years. I still debate if I want to wrap existing tools (tf, helm, etc...) or go for a full sail replacement. Dagger handles a lot of the tooling earlier in the CI process, mainly thinking CD here. Argo-* is our bain lately...<p>You might find the code gen aspects of hof interesting, I opted for Go's text/template, which you can also use from CUE if you wanted to have more literate (imo) code gen in your project.
You can cut out the middle man and use <a href="https://github.com/marxarelli/masse" rel="nofollow">https://github.com/marxarelli/masse</a>, a CUE frontend for BuildKit.<p>However I don’t think anything using BuildKit is as fine grained as Bazel.
Dagger replaced BuildKit (a lot of reasons for this). The BuiltKit API sucks compared to Dagger's, so I personally prefer the middleman, but that is no longer the case. See:<p><a href="https://github.com/dagger/dagger/pull/11856" rel="nofollow">https://github.com/dagger/dagger/pull/11856</a>
Though, I am an "Ultra Noob," light years behind most people here, I am actually in the process of making a couple or four Vibe Coded apps, starting with a Markdown editor, a couple of training suites that target the areas where my knowledge is weakest, which turns out to be every area apparently. I am also working on an app for Linux that Microsoft has had for a few years that Ubuntu users--the noobs--are in desperate need of, and should have, but sadly has been missing from most Linux distros, in my view. Of course, this is using free tier AIs and not locally hosted agents. None-of these apps are rust-based a the moment, but I try to instruct the AI to make it as fast as possible for the given platform.<p>It's really challenging to do this, especially creating the AppImages locally so I can test them when the apps do not not work correctly, having to alter the files manually. Yup, I'm not an avid GitHub pusher, just more of a cloner.<p>I'm having to use multiple free-tier AI agents to help me do this and record the steps and commands I use in markdown files so I don't forget them the next time I try to improve the app.<p>If I am successful in making these apps work without hosing my system, I'm hopeful that this will become a game changer, for those Noobs that using Ubuntu, or myself at least.<p>The hardest part is when the AI does not follow my instructions such as requests to generate markdown README.md files with instructions on how to create AppImages, Flatpak, deb files, etc. Have to ask other AIs for help with that while dealing with the frustrating Free-tier cutoff periods :(
Sounds like marketing for AI to me.
body { max-width: 70rem; }
A bookmarklet:<p><pre><code> javascript:(function(){const s=document.body.style;s.maxWidth='60ch';s.margin='0 auto';s.fontSize='16pt';s.textAlign='justify';s.hyphens='auto';s.wordBreak='break-word';})();</code></pre>
Reading mode (Alt + Shift + R)
> he's testing thoroughly enough that he's even uncovering real bugs in Postgres, such as this numerical bug that can cause valid SP-GiST operations to fail, this format cache bug that can cause incorrect results from JSONPath, this pgcrypto bug that can cause later operations to fail, multiple memory safety bugs in the dictionary loader2, this money overflow bug, etc.<p>I'll keep saying it: we're eventually moving to a n-modular redundancy, with <i>several</i> implementations, running on different stacks/languages, cross-checking each others for bugs.<p>Just re-writing in Rust isn't that useful: we all move to pgrust and then what? People abandon the old software and now pgrust has a major bug and nobody detects it.<p>And I don't think we're only moving to n-modular redundancy at the software/application level: we'll also be moving to n-modular redundancy at the network level. Where every single packet on the subnetwork (the one where the n systems are living) has to be accounted for and <i>identical</i>.<p>And any network packet emitted by one of the implementation that won't match the others shall be suspicious and cause for an inquiry.<p>This shall require changes in how we build and network our stuff, but I do profoundly think that having a "majority voter" with a tiny, minimal, attack surface that's on one end exposed to the Internet and, on the other end, on a specific network (maybe with a new network protocol: or maybe with something based on UDP: not an issue with lost packets btw for it's going to a redundant system anyway) where every single network packet is accounted is going to exist at some point.<p>I'm dead serious: the value in pgrust is <i>not</i> pgrust in itself. It's that, combined with past a implementation in another language, <i>both</i> are now stronger.<p>I really hope the clue stick hits us and hits us hard with that one.
The HN contrarian decision matrix:<p><pre><code> Is somebody on HN saying you should *always* do X?
-> Yes
-> Is somebody on HN saying you should *never* do X?
-> Yes
-> You should _sometimes_ do X.</code></pre>
amazing
Even he’s not ambitious enough. Set the boundaries according to the hardware – billions of ops a second . Your rewrite should run at least 1000x faster than the handwritten version , with 1/10 resources.<p>I noticed my cloud images had 150mb ram wasted by vendor slop. AI rewrote the functionality into a few mb .<p>We’ve had slop long before AI . What you produce now is up to you
But now that AI writes everything, should not the question be why AI does not yield perfect software?
Something I've been thinking about lately is how doing anything well is an unknown factor more difficult than you originally think. Your initial estimate of how hard something is to do is usually terribly wrong. Once you think that you're 20% into a project, you realize that you're only actually 5% into the project. Then later, when you reach what you think is finally 20% again, you realize that, once again, you're only 5% into the project! This repeated discovery of "more to do" really beats people down and discourages them from doing ambitious things.<p>(See also Hofstadter's law: It always takes longer than you expect, even when you take into account Hofstadter's law.)
A lot of my professional-pride and satisfaction kind of complaints with AI is that it uses space age technology for the stupidest and most primitive target: generating code. I’ve called this Flintstone Engineering. You have a remarkable technology but everything around it does not fit in. So you should definitely be more ambitious. You should think about formal verification and “super human” levels of testing and verification. You should consider making a very readable but maybe not performant oracle library to test alongside your really-used and maybe performance-tuned library. You should think of every avenue that before was too costly in terms of time and money—something that not even an independently wealthy OSS would think to do—and consider if the new kind of budget can accommodate it.<p>And these ideas were always plenty of. The problem for me is that the incentives, so to speak, is to wow people with the Old World software but with “see, no brain”. And in turn you get two-hundred projects like that for every piece about rethinking software. And those pieces might just be at the zygote idea level. <i>Could it be done?</i> Yeah maybe.<p>But the biggest problem is that this is not what GenAI or agentic AI is for. I don’t think it’s even debatable, even if you think the AI Cretins that a few years ago said that they will take everyone’s jobs out in public just changed their minds. Because the valuations and capital invested is to the point that they have to, really, make it possible to slash entire payrolls across sectors. If not they simply don’t get enough money back and the whole thing crashes.[1] And if you need these frontier models at subsidized electricity costs and not just the ones that can run on your desktop, either there is crash and no more frontier models or you are out of a job.<p>And then where are the people that <i>care so much</i> about software?<p>They are no where to be seen. All that are left are business people. To see business people software just open up any program from Established Tech, or any program from non-Tech but where they want to sell you something. There is apparently (let’s use revealed preference here) no business need to software that is good, stable, conforms to anything, or is nice to use. Because that <i>cares so much</i> about software person might want to make legible the prices on offer, the exact specifications, discovery—all things that business people want to frustrate in order to maintain information asymmetry.[2]<p>As for compilers and interpreters and such. Okay, for who? Sure. Some people believe that they are in the 999‰ of developers. And now AI can finally vanquish those mediocre developers and productivity-boost 999‰ developers so that they get to sit at the right-hand side of the other worthy and hard-working cohort, uh, the people who had money and dumped it into AI. And they might even double their pay because thinking and making connections at that level would just boil all the lakes if they tried to build an AI to do that. And what will they do with that power? Hmm, follow orders and keep making business software? Just looking at history here.<p>[1] Cory Doctorow, <i>The Reverse Centaur’s Guide to Life After AI</i><p>[2] ibid
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[flagged]
[dead]
[flagged]
[flagged]
There are some ways to counter that, from what I see:<p><pre><code> 1. You can use a RSS reader, if you fancy.
2. Firefox's reading mode can render that site nicely, with your appearance choices.
3. You can "patch" the site with an extension.
4. Best yet, you can reach out to owner of the site. There are some links on the site.</code></pre>
[flagged]
It used to be that people set the width of their browser window to the text page width they’re comfortable with, and configured a different font if they didn’t like the default one on their browser.<p>We should be more ambitious in letting the browser software control the presentation according to the user’s preferences. This is not facetious. We should use the increased ease of building software to create software that is flexible, empowers the user, and accommodates different user preferences.
<i>Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.</i><p><a href="https://news.ycombinator.com/newsguidelines.html">https://news.ycombinator.com/newsguidelines.html</a>
I don't find it tangential. If AI is so good with complicated software, it can deal with a simple website, right? Or then maybe it's not that great.<p>By the way, I'm still waiting for Meta and Google do something about Instagram and Chrome so that my CPU usage doesn't go to the roof. They're front runners in the AI race, so it should be easy for them, right?
Most browsers have a reader mode that you can configure to your liking.
Pretty sure this is mostly unstyled html. If you don't like how it looks that's on you.
I find Dan Luu's blog extremely good to read on mobile, with great typography. The website also works with Firefox Reader mode and loads pretty quickly due to using the system's font.
If you're using Firefox, hit Ctrl-Alt-r and it looks however you want it to.
No. Line length and text wrapping restrictions are the devil. If you want smaller width text, resize your browser window rather than making a site that sucks for us who don't want smaller text width.
We should have been more ambitious with software even before LLMs. I mean if we were we would not have Electron, and only linux as the only alternative OS.<p>And may be we should have been more ambitious with hardware too, and have a mobile and VR platforms that is not tied to malicious corporations...
Is there a name for this form of article title? I find them irritating somehow.