I don't know if this is the end of programming, but i can clearly observe the gradual end of expertise in my company - people slowly forgetting architecture, principles, and how stuff works in general, in favor of code delivery speed.
And without expertise you end up asking stupid things to a token producer machine, however godlike it can be.
I do see this as good... for my personal future career. Currently AI has caused a massive hiring stop in Consulting which is the area I want to go into. However the more terrible AI decisions there are in the future the more need for a human that can scrutinize those decision there is again. Aka Consulting will boom in a few years. (Is my hope)
If you care about architecture and principles, the AI is excellent in architecting around that goal too and/or helping you articulate your own intuitions. You just need to be willing to sacrifice code delivery speed. It's far from an either/or.
I have found different, often even when doing something like coming up with a database schema, the solution it chooses is not the best and and can be even terrible sometimes. It could be I suck at prompting.
I really do think that people who rely on AI to make architectural dissensions will simply have a bad time later down the road when it turns out that the AI made a stupid decision.
I have noticed myself a 3 months or so ago sometimes asking AI questions for things that I knew the answer to (but had to think about) and my solution would have been better. Once I realized it I realized how despite always telling my self to think about the result I was still allowing myself to hand over some of my thinking to the AI.
What I have started doing is still doing lots of things without AI and trying to not lose those skills because I think they are still needed but AI can lull you into handing over your prefrontal cortex, which is scary.
Same mental state i'm now, back from holidays. AI-free diet for a while. Nothing scarier than realizing that "smart" laziness was simply hiding the beginning of incompetence.
Also, handing over the work to AI robs you of learning and understanding. Let’s say you write a ticket for a feature and that description is good enough that an AI agent can implement it from start to finish. The AI will then discover things while implementing the feature, and will use those learning to make the feature work. That learning will then be discarded once the AI is done. No one will be able to partake or share the knowledge with others. Sure, some of it can be saved in form of comments, but not everything.
He is right. The GitHub graphs show that most code is already no longer written by humans, and the shape of the graphs (as well as the recent pace of LLM progress as measured by various benchmarks) tell us that human programming is going to become a niche activity in the near future.
Nope. Not yet. The frontier still produces slop and never refactors. Your code base will grow with the square of your features and grind to a halt. God speed to folks that work at this shop.
This is a strong article with a distracting headline. Challenge for commenters: can you discuss the content without getting caught up in the headline?
My favorite paragraph:
> The fact that AI wrote 1M LOC and then refined it over the course of the next couple of months to produce a reliable piece of software that is currently running on millions of developer machines is absolutely mind blowing. And you can say, “well it’s not that impressive because they had an oracle to compare against, so it was simple to go from one language to another”, but I think that’s selling this entire thing short. If you can build a verification system and give proper direction, AI can produce a highly complex, highly sophisticated piece of software and it can continue to refine it until it just works.
For me, this captures what's special about the Claude Fable 5 and GPT-5.6 Sol class of models. If you can reduce a problem to a clearly verifiable end state, provide the necessary context, and equip a model with the necessary tools it can usually get to a good solution.
Reducing problems to that state and designing that environment remains a skill, and one that I expect we will be paid handsomely for.
This is a terrible, shallow article, that is about what you'd come to expect.
> If you can build a verification system and give proper direction,
That's called programming. The Bun tests and oracle are the result of years of programming. If you have to spend years programming an oracle before, programming is not ended. This is not just the headline claim. They are also making the claim in the article. `What I mean by this is that I think the act of writing code manually and having other humans review it to create useful, working software is headed for extinction.`
I'd also note the $165,000 figure is cited for the 11 day sprint, but this has only been merged months later with both employees and agents hammering away at it. The true cost of this rewrite is likely in the millions.
There's also the quality angle. It's taken as a given that because Claude Code is using it in production, it must be quality software. This couldn't be further from the truth. Claude Code is absolute dogshit software that nobody in their right mind would even consider using if Claude didn't gatekeep their subscription subsidy token rates behind it. It is the absolute worst of any possible harness that anybody uses seriously.
Don't get me wrong, this is impressive in some degree. It is a genuine feat of software engineering to have written a class of programs that can generate other programs of this scale. I use LLMs daily for various classes of tasks because they are helpful tools. But the claims of its relevance and impact are wildly, wildly overstated. Note also the exponential growth in Github commits, and yet there is not a single piece of non-LLM related, LLM-generated software that I use, or existing software that I have felt has improved as a result of adopting full LLM-based workflows. There is no massively popular new software that regular end consumers are using, just a bunch of .md file wrappers for certain types of developers to wank over. To the contrary, software in general appears to be degrading even more rapidly than it already was, with major Windows issues, Github issues, outrageous security breaches [as a result of woefully incompetent security practices rather than amazingly competent offensive practices], etc. becoming more and more common.
To me it’s a purpose fit solution that does actually show what LLMs are capable of. Just in the best case, with the most well defined constraints one will be able to work with.
It proves that with a sufficient spec, it can do a lot of work. The spec is always the problem though - to make the spec correct enough, one has to go thru the same process as coding it. Will LLMs surface the right tradeoffs, let alone make them? Working w frontier models all day, I can say resoundingly no, and not for a long while I think. Always looking for examples of things going well though if folks have some to share.
> Reducing problems to that state and designing that environment remains a skill, and one that I expect we will be paid handsomely for.
This seems to be what AI these days seems almost super humanly good at. See coding or math I guess.
But it does beg the question, why would a programmer using AI as a tool be worse than a programmer building the harness and environment and asking AI to go hogwild? The latter is definitely faster but if it's the former, atleast I will have an understanding how the system works. Weather that is valuable is an open question as far as I am concerned
I think the understanding is the most important piece here.
I've seen this called "cognitive debt".
If you don't understand the system you are building - if the AI gets too far ahead of you - then you lose the ability to reason about the system and make confident decisions about what to do next.
Reasoning about the system and making confident decisions is the job.
I think that the bun rewrite actually supports the oppposite conclusion in a lot of ways:
1. The resulting code was of pretty low quality. Others that bothered to put it through Miri and the like found many soundness issues, but my personal favorite example is this example which is trivially and locally (meaning that someone who has the most basic understanding of unsafe in rust can see it's obviously wrong just by looking at the specific function) incorrect example [0]. This particular example was removed in an apparently unrelated refactor after spending well over a month in the code base without any of the bun maintainers or their agents detecting it, and a quick grep found hundreds of potential similar issues (although many of those are false positives).
2. More generally, it's not clear to me that there was any technical benefit to the rewrite in the first place. The stated reason was for memory safety, but replacing Zig with unsafe rust doesn't actually get you memory safety, and removing the unsafe blocks often requires more extensive refactors to fit within rust's model.
> If you can reduce a problem to a clearly verifiable end state, provide the necessary context, and equip a model with the necessary tools it can usually get to a good solution.
As others have pointed out (and you acknowledge), "reducing a problem to a clearly verifiable end state" is just "programming". What you don't seem to understand is that actually doing that is made harder by using AI, not easier. A sufficiently detailed spec is called "code" [1], the question is what language/notation is best to write it in. The answer is almost never "whatever is closest to what the computer actually executes", as assemblers and later compilers and interpreters demonstrated. But it also isn't several of the things that AI proponents have suggested to replace the latter with.
Take natural language, for example. As Dijkstra pointed out, we've been through this already with math. It used to be that all math was expressed in a way closer to what we'd now call "word problems", but this turned out to be bad. The specialized language of e.g. algebra isn't something mathematicians use to gate-keep, it's way easier to reason in the domain that way than it is in English (or other natural languages). The same is true for programming, once you actually specify what you want to do with enough rigor. It's generally easier to read and reason about code than to do so with natural language specifications.
Another proposal is to use tests and similar automatic verification to specify the program. I suspect that anyone with much experience can already tell whether it's preferable to specify a program through code or through tests, but thankfully we have empirical evidence on this for anyone who has any doubts in the form of e.g. sqlite. Sqlite is probably one of if not the closest any piece of software comes to being fully specified by it's tests. To do that takes almost 600 times as much test code as there is "regular" code. Dr. Hipp even personally weighed in on the implications this has on AI recently [3] . The reason to do testing is that it provides a second independent check for correctness, if you're using it as the *only* check that advantage disappears.
The announcement also makes it very clear that 1.4 isn't just a rust port of 1.3. Rust is my favorite language and it can be a bit faster than other systems languages in the right circumstances (because the compiler can make optimizations based on assumptions that wouldn't hold without the borrow checker), but numbers like those seem far more likely to be the result of other changes than the language shift.
Just saw this now. The two aren't remotely in conflict. The _rewrite_ (from zig to rust) almost certainly didn't result in the performance improvements they're claiming, because rust and Zig are roughly equivalent in that regard. We know that they included other changes with the 1.4 release (in other words, 1.4 is not just 1.3, but in rust this time), so it's far more likely that those changes are responsible, not the rewrite.
Considering the direction that InfluxDB has taken over the years, making insanely terrible product and tech decisions, chasing shiny new things, breaking the Open Source edition further and further while not being able to offer a competent sales process for the commercial one, I think it's fair to take the opinions of the author with a mountain of salt.
From TFA: "What I mean by this is that I think the act of writing code manually and having other humans review it to create useful, working software is headed for extinction."
“Since FORTRAN should virtually eliminate coding and debugging…” -- FORTRAN report, 1954 [1]
And the FORTRAN report was both right and wrong. What was meant by "coding" back then, carefully crafting machine instructions from higher level specifications, was almost entirely eliminated. It was replaced by something else, which we now call coding.
I think we have been doing that for a while already. Seems like almost every major company is using LLMs for coding internally and people dont consider that vibe coding.
Culturally, it feels like we've already speedran the pipeline of "vibe coding is using LLMs without reading the code" to "vibe coding is using LLMs for code" to "using LLMs is just a tool for coding". LLMs seems to now be mostly accepted for coding (on HN at least), the discussion has shifted to how useful and in what ways.
Yeah, but the semantic question is whether LLMs being accepted to use for coding means that the software engineer who merely instructs the LLM is thereby also "coding" (similar to how someone who merely writes Fortran, rather than machine code, is nowadays also described as "coding") or whether the only entity that is described as "coding" here is the LLM.
Big difference is that now C level management really tries to push this narrative down to our throats.
People who are writing and claiming thing like this should be held accountable for it. It is easy to try to scare developers that their job is going away. Especially for gaining attention. Currently I don't see difference between these claims and conspiracy theories...
The main reason that I'm in the process of switching jobs is to get more money, in case we are fucked as a profession later on. So yeah, even if I don't necessarily believe this is the future, I am certainly making sure that if it is the future I will be more comfortable.
LLMs are scarily good at translation, whether between natural or between programming languages. Also very good at re-implementing the stuff that has been provably done before. And, arguably, 90-95% of writing code is exactly that.
In my experience they still struggle a lot though. They're great at 1 to 1 translations but they will fight the target language to get there tho. A lot of the rust rewrites I've seen done by AI contain a lot of patterns that any rust dev worth it's salt will scoff at.
Yes -- the bigger the difference between languages the worse they perform. However I'm not really expecting e.g. Claude to be able to port sync.Map from Go to Rust, because sync.Map relies on GC to do the hard work of cleaning up references to values no longer used by any goroutine :).
But in porting, e.g. from PHP to Go they're crazy good at, doing a much better job than any simplistic machine translation ever could
I'm no expert, but it feels like this exact thing is how it ends up eating itself. For two reasons.
- Eventually the universe of "provably done before" is now all LLM genned code. So the training data quality starts a slow decline.
- That it's "good enough" now for 90+% of the work kills the pipeline for any new human software experts. So they never gain the experience and insight to be able to steer the AI to produce ok-ish code. Existing experts age out. This cycles with the bullet above over time. And at some point we're stalled, all code is now mediocre at best and while output is high, innovation/evolution is low. Or whatever innovation we have is coming from a very small circle without much natural competition.
IMO that's precisely why software engineering is going to become even harder than it is right now -- all the "easy" stuff is semi-automated, so now you have to spend even more time and energy "drawing the rest of an owl" so to speak, doing the hard 10% yourself. And unless anything drastic happens in LLM development this last 10% isn't going to be automated away any time soon.
The article gives the example of Bun's successful Zig to Rust of why this is the end of programming. I think that rewrite is a perfect example of why it's NOT the end of software engineering. A non-programmer could not have prompted AI to do that rewrite, and in fact a non-programmer would not have even conceived of the idea of doing that rewrite in the first place. Somebody is still needed to 1. understand that a Zig-to-Rust rewrite is necessary to achieve certain technical goals 2. prompt the AI to do the rewrite, clearly describing the before-and-after architecture, the goal of the rewrite, and technically verifying the result.
Neither 1 nor 2 can be done by someone who doesn't even know what Bun, Zig, or Rust is, let alone deeply understand how those work. In fact, even I as a programmer with decades of experience in PHP/Python/JS but without specific experience in Zig and Rust probably couldn't do a proper rewrite for a project the size of Bun.
Don't conflate the existing SOTA and the future SOTA.
When OpenAI released ChatGPT 3.5 in late 2022 as free a research preview as the SOTA at the time, the model wasn't good and with a ton of hallucinations. There was no harness, context windows was small and token speed is slow. Plenty of folks said what a joke, no one can do serious work with it.
4 year later now looking back, can you imagine what AI capabilities are now? Can you imagine what AI would be capable another 4 years from today?
Keep in mind, AI improvement is not stagnant as everyone is working on Recursive Self-Improvement and trillions of dollars pouring into it. If you are betting the future on the current understanding the AI capability, I bet you will lose.
Such a big disconnect in the coverage of coding models and the output they produce.
If you discard coding purity questions like style, architecture, cleanliness - the stuff they come out with is buggy & error prone.
The problems seems architectural - in that context windows are limited and you need more compute to increase them, married with the fact the models are really over confident. But if you do increase them it causes mode collapse. Yann LeCun has a really good graphic in his slides of a circle (all possible answers) and a red line coming from the centre depicting the one correct path. How do you actually stop the model going into the subsequence of wrong paths? I don't think it's possible.
I've had so many times in my day job someone has told me (Claude told them) there is a bug in my code, I look at it and nope - it just didn't look up the right file. Then you push back on it and it completely crumbles and says sorry.
I wouldn't keep an employee hired who did that over and over again and never learned
People acting like meat proxies add no value. Claude is also very eager to make conclusions without digging deeper. It has no inherent curiosity or prior knowledge about the codebase asside from what it can see.
I agree with the thesis. Development is moving towards intent and alignment and clear understanding of needs. These have always been important but in a future where code is almost free, customers will be more demanding about having their needs met, fast.
Our SaaS company is making plans to move towards bespoke development, which until now has been far too costly for most customers to accept. It also violates the multi-tenant cost/business model, so we're scrambling to figure out what hosting and ops and support agreements look like in a bespoke future.
The implications here go well beyond development. I'm seeing pretty massive changes happening in finance, consulting, HR, accounting, law, design, architecture, health, and everything else. When the value of intelligence is effectively zero, how are humans supposed to market and sell themselves in the job market? Some white collar people might try to move into physical jobs for job security, but it will only take a fraction of white collar workers to migrate to crater wages there too.
We're not ready for this. Socially, economically, and politically. Look at how we treated middle Americans who lost their manufacturing jobs when they were offshored to China. Hillary Clinton famously laughed at them and told them to "learn to code." We'll watch jobs and industries disappear while clinging to our own and praying that it's not us today.
UBI is going to be inevitable soon, but it's also woefully insufficient. Giving a developer who used to earn $100k $20k per year UBI isn't going to placate their white hot rage at the social contract being broken. We're going to need universal high income, and paying for that is going to be such a radical social change that I worry voters won't accept it until things are dire.
The end of programming and the birth of metaprogramming. The art of writing programs that write programs, which itself is significantly harder than writing programs themselves. In fact I'm glad to see this happening because at most shops the use of metaprogramming is minimal to non-existant. (see Linux/Chromium/Firefox/Android)
I think the best glimpse into the future is the bugginess and engineering laziness of Claude Code itself.
New versions ship daily and I seem to hit brand new issues every day. They disappear after a few more updates, but it's damn annoying to keep up instead of doing work, and the direction of changes is lacking at best. The underlying technology otherwise seems nothing short of a miracle, but the contrast is eye-opening.
In industries where this is acceptable, that's the future. In ones that can't tolerate it, it isn't. I hadn't expected software engineering itself to be one of the former but it's kinda obvious in retrospective.
LLMs will accelerate the proliferation and searchability of ideas. Many times I've been using an LLM and it'll suggest ideas I would have never come across naturally that have been beneficial to whatever I happened to be implementing. For learning in general, it's been the most delightful tool I've ever used.
On the other hand, if you're working in an industry where you and your coworkers are developing novel solutions that aren't widely known, chances are you'll still be doing that by hand with some light LLM automation. There are industries with a lot of gatekept secrets where LLMs will be less useful. What I will say on that matter is this: if you weren't surprised frontier labs stole copyrighted work for training data, you'd do well to mind what you push through their systems.
In our shop, we are understanding that the art of "designing and implementing algorithms, step-by-step specifications of procedures, by writing code in one or more programming languages" (Source: wikipedia) shifted to LLMs does not mean that programming has ended, but that expectations around what and how humans do programming has changed and will continue to change. We still need humans who understand how databases should work and should be designed/evolved because these humans are the consumers of the programs. The prompters (programmers) are the consumers. LLMs are not consumers. Without programmers, LLMs don't do any work.
It's just another tool. Programming is/can be fun. People still hand turn wood, and make their own furniture, even though Ikea exists.
Or maybe 'code' just gets pushed down a level like assembly did when C was invented, for example. As a percentage very few people look at assembly in comparison to the 1960s-80s.
I'm going to separate this from the title, versus the contents on the post
on the bun rewrite, this matches my experience
it's always been worth completely ignoring people that had a negative experience with AI-assisted coding, because others of us have been entirely functional. the slow trickle of examples has always been because it was counterproductive to tell anyone that your project or service was AI-assisted in coding or entirely vibe coded.
but now, with bun being an Anthropic project and their whole thing is showing examples that would speed up everyone else, the truth is out there. good move by them.
bun is a fast runtime and will save millions of projects time and compute costs in CI/CD and redeployments
on the title, I disagree, but with a twist. manually coding is just not necessary, but the ability to get results, and use available compute resources efficiently and at low cost are still disciplines. I don't just mean "architecture", I mean a more specific part of architecture like knowing that your postgres instance can already be an event based architecture and you don't need the cloud provider's pub/sub arrangement at all.
right now, AI isn't going to do that for you. but regarding the discipline, I don't have pride over that, I think that's a major point for people, a level of gatekeeping and pride. this isn't what we need, this isn't what companies need, everyone always needed results.
people in this career are concerned about the billable rate when people with less familiarity with the discipline can deliver results, and thats where I also see a different outcome: delivering results in software still has some unique attributes compared to almost every role in an organization.
A, it just has to be done. B, it's still one of the only roles where your workers can compete directly against you whenever they feel content enough to do so, or discontent with how you are paying them.
Software engineers have little to no overhead costs of running their own thing, they have no licenses and hence no geographic limitation compared to your accountants and lawyers, and they also have enough money to cover the little overhead costs they do incur, something even your sales team doesn't have before getting caught in a lead trading ponzi scheme. The major markets for software engineers (California) nullifies any non-compete you were relying on. It doesn't matter who is doing the software, whether it was someone that was previously doing HR, or someone that built an identity around coding, it just has to be done.
But this should translate into hiring, right now, the importance and cost reinforces teams to want to interview for something that "should" be gatekept. multi week, multi month, hiring processes to prove someone has a cognitive ability. but this isn't necessary, people should be able to come into the effort, the same way someone can pick up a broom. the same way a sailor on an expedition picks up an oar and splits the bounty during the trip.
> And you can say, “well it’s not that impressive because they had an oracle to compare against, so it was simple to go from one language to another”, but I think that’s selling this entire thing short.
It's not. If you give it a reference implementation, and unless the LLM/agent cheats, you'd get the migration minus undocumented/untested behavior. I've done that with different domain, migrating existing numerical code from Fortran to Rust. When working on the same codebase, agents routinely shit the bed unless given increasingly specific and concrete specs.
It's simply a spectrum between "make an airbnb for ants, make no mistakes" and providing an actual specification (and I consider an implementation to be such). What you don't provide and account for from the beginning will be paid in tokens later. That puts a price on technical debt, which is interesting in itself.
I’m still looking out for the end of programming for the human eye: these models are still pretty bad at any kind of UI that isn’t some React dashboard or single page report. For example, iOS / SwiftUI design. Sure, they can write the code just fine, but I’ve had a hard time just letting them vibe out a basic View with Sections that doesn’t look slopped out.
73 comments
[ 1.5 ms ] story [ 107 ms ] threadAnd without expertise you end up asking stupid things to a token producer machine, however godlike it can be.
It's hard not to extrapolate...
I have noticed myself a 3 months or so ago sometimes asking AI questions for things that I knew the answer to (but had to think about) and my solution would have been better. Once I realized it I realized how despite always telling my self to think about the result I was still allowing myself to hand over some of my thinking to the AI.
What I have started doing is still doing lots of things without AI and trying to not lose those skills because I think they are still needed but AI can lull you into handing over your prefrontal cortex, which is scary.
My favorite paragraph:
> The fact that AI wrote 1M LOC and then refined it over the course of the next couple of months to produce a reliable piece of software that is currently running on millions of developer machines is absolutely mind blowing. And you can say, “well it’s not that impressive because they had an oracle to compare against, so it was simple to go from one language to another”, but I think that’s selling this entire thing short. If you can build a verification system and give proper direction, AI can produce a highly complex, highly sophisticated piece of software and it can continue to refine it until it just works.
For me, this captures what's special about the Claude Fable 5 and GPT-5.6 Sol class of models. If you can reduce a problem to a clearly verifiable end state, provide the necessary context, and equip a model with the necessary tools it can usually get to a good solution.
Reducing problems to that state and designing that environment remains a skill, and one that I expect we will be paid handsomely for.
> If you can build a verification system and give proper direction,
That's called programming. The Bun tests and oracle are the result of years of programming. If you have to spend years programming an oracle before, programming is not ended. This is not just the headline claim. They are also making the claim in the article. `What I mean by this is that I think the act of writing code manually and having other humans review it to create useful, working software is headed for extinction.`
I'd also note the $165,000 figure is cited for the 11 day sprint, but this has only been merged months later with both employees and agents hammering away at it. The true cost of this rewrite is likely in the millions.
There's also the quality angle. It's taken as a given that because Claude Code is using it in production, it must be quality software. This couldn't be further from the truth. Claude Code is absolute dogshit software that nobody in their right mind would even consider using if Claude didn't gatekeep their subscription subsidy token rates behind it. It is the absolute worst of any possible harness that anybody uses seriously.
Don't get me wrong, this is impressive in some degree. It is a genuine feat of software engineering to have written a class of programs that can generate other programs of this scale. I use LLMs daily for various classes of tasks because they are helpful tools. But the claims of its relevance and impact are wildly, wildly overstated. Note also the exponential growth in Github commits, and yet there is not a single piece of non-LLM related, LLM-generated software that I use, or existing software that I have felt has improved as a result of adopting full LLM-based workflows. There is no massively popular new software that regular end consumers are using, just a bunch of .md file wrappers for certain types of developers to wank over. To the contrary, software in general appears to be degrading even more rapidly than it already was, with major Windows issues, Github issues, outrageous security breaches [as a result of woefully incompetent security practices rather than amazingly competent offensive practices], etc. becoming more and more common.
It proves that with a sufficient spec, it can do a lot of work. The spec is always the problem though - to make the spec correct enough, one has to go thru the same process as coding it. Will LLMs surface the right tradeoffs, let alone make them? Working w frontier models all day, I can say resoundingly no, and not for a long while I think. Always looking for examples of things going well though if folks have some to share.
This seems to be what AI these days seems almost super humanly good at. See coding or math I guess.
But it does beg the question, why would a programmer using AI as a tool be worse than a programmer building the harness and environment and asking AI to go hogwild? The latter is definitely faster but if it's the former, atleast I will have an understanding how the system works. Weather that is valuable is an open question as far as I am concerned
I've seen this called "cognitive debt".
If you don't understand the system you are building - if the AI gets too far ahead of you - then you lose the ability to reason about the system and make confident decisions about what to do next.
Reasoning about the system and making confident decisions is the job.
1. The resulting code was of pretty low quality. Others that bothered to put it through Miri and the like found many soundness issues, but my personal favorite example is this example which is trivially and locally (meaning that someone who has the most basic understanding of unsafe in rust can see it's obviously wrong just by looking at the specific function) incorrect example [0]. This particular example was removed in an apparently unrelated refactor after spending well over a month in the code base without any of the bun maintainers or their agents detecting it, and a quick grep found hundreds of potential similar issues (although many of those are false positives).
2. More generally, it's not clear to me that there was any technical benefit to the rewrite in the first place. The stated reason was for memory safety, but replacing Zig with unsafe rust doesn't actually get you memory safety, and removing the unsafe blocks often requires more extensive refactors to fit within rust's model.
> If you can reduce a problem to a clearly verifiable end state, provide the necessary context, and equip a model with the necessary tools it can usually get to a good solution.
As others have pointed out (and you acknowledge), "reducing a problem to a clearly verifiable end state" is just "programming". What you don't seem to understand is that actually doing that is made harder by using AI, not easier. A sufficiently detailed spec is called "code" [1], the question is what language/notation is best to write it in. The answer is almost never "whatever is closest to what the computer actually executes", as assemblers and later compilers and interpreters demonstrated. But it also isn't several of the things that AI proponents have suggested to replace the latter with.
Take natural language, for example. As Dijkstra pointed out, we've been through this already with math. It used to be that all math was expressed in a way closer to what we'd now call "word problems", but this turned out to be bad. The specialized language of e.g. algebra isn't something mathematicians use to gate-keep, it's way easier to reason in the domain that way than it is in English (or other natural languages). The same is true for programming, once you actually specify what you want to do with enough rigor. It's generally easier to read and reason about code than to do so with natural language specifications.
Another proposal is to use tests and similar automatic verification to specify the program. I suspect that anyone with much experience can already tell whether it's preferable to specify a program through code or through tests, but thankfully we have empirical evidence on this for anyone who has any doubts in the form of e.g. sqlite. Sqlite is probably one of if not the closest any piece of software comes to being fully specified by it's tests. To do that takes almost 600 times as much test code as there is "regular" code. Dr. Hipp even personally weighed in on the implications this has on AI recently [3] . The reason to do testing is that it provides a second independent check for correctness, if you're using it as the *only* check that advantage disappears.
[0] https://github.com/oven-sh/bun/blob/fc865b398e51de8a95ddde4b...
[1] https://haskellforall.com/2026/03/a-sufficiently-detailed-sp...
[2] simonw ↗ > More generally, it's not clear to me that there was any technical benefit to the rewrite in the first place. lunar_mycroft ↗ The announcement also makes it very clear that 1.4 isn't just a rust port of 1.3. Rust is my favorite language and it can be a bit faster than other systems languages in the right circumstances (because the compiler can make optimizations based on assumptions that wouldn't hold without the borrow checker), but numbers like those seem far more likely to be the result of other changes than the language shift. simianwords ↗ > More generally, it's not clear to me that there was any technical benefit to the rewrite in the first place lunar_mycroft ↗ Just saw this now. The two aren't remotely in conflict. The _rewrite_ (from zig to rust) almost certainly didn't result in the performance improvements they're claiming, because rust and Zig are roughly equivalent in that regard. We know that they included other changes with the 1.4 release (in other words, 1.4 is not just 1.3, but in rust this time), so it's far more likely that those changes are responsible, not the rewrite.
The Bun 1.4 announcement claims: https://bun.com/blog/bun-v1.4
> It reduces idle CPU usage by 5x, reduces memory usage by up to 35%, and starts 50% faster on Linux.
> but numbers like those seem far more likely to be the result of other changes than the language shift.
Which one is it?
“Since FORTRAN should virtually eliminate coding and debugging…” -- FORTRAN report, 1954 [1]
And the FORTRAN report was both right and wrong. What was meant by "coding" back then, carefully crafting machine instructions from higher level specifications, was almost entirely eliminated. It was replaced by something else, which we now call coding.
[1] http://www.softwarepreservation.org/projects/FORTRAN/BackusE...
Culturally, it feels like we've already speedran the pipeline of "vibe coding is using LLMs without reading the code" to "vibe coding is using LLMs for code" to "using LLMs is just a tool for coding". LLMs seems to now be mostly accepted for coding (on HN at least), the discussion has shifted to how useful and in what ways.
But in porting, e.g. from PHP to Go they're crazy good at, doing a much better job than any simplistic machine translation ever could
- Eventually the universe of "provably done before" is now all LLM genned code. So the training data quality starts a slow decline.
- That it's "good enough" now for 90+% of the work kills the pipeline for any new human software experts. So they never gain the experience and insight to be able to steer the AI to produce ok-ish code. Existing experts age out. This cycles with the bullet above over time. And at some point we're stalled, all code is now mediocre at best and while output is high, innovation/evolution is low. Or whatever innovation we have is coming from a very small circle without much natural competition.
Loud with lots of smoke, but didn't go anywhere!
Neither 1 nor 2 can be done by someone who doesn't even know what Bun, Zig, or Rust is, let alone deeply understand how those work. In fact, even I as a programmer with decades of experience in PHP/Python/JS but without specific experience in Zig and Rust probably couldn't do a proper rewrite for a project the size of Bun.
When OpenAI released ChatGPT 3.5 in late 2022 as free a research preview as the SOTA at the time, the model wasn't good and with a ton of hallucinations. There was no harness, context windows was small and token speed is slow. Plenty of folks said what a joke, no one can do serious work with it.
4 year later now looking back, can you imagine what AI capabilities are now? Can you imagine what AI would be capable another 4 years from today?
Keep in mind, AI improvement is not stagnant as everyone is working on Recursive Self-Improvement and trillions of dollars pouring into it. If you are betting the future on the current understanding the AI capability, I bet you will lose.
If you discard coding purity questions like style, architecture, cleanliness - the stuff they come out with is buggy & error prone.
The problems seems architectural - in that context windows are limited and you need more compute to increase them, married with the fact the models are really over confident. But if you do increase them it causes mode collapse. Yann LeCun has a really good graphic in his slides of a circle (all possible answers) and a red line coming from the centre depicting the one correct path. How do you actually stop the model going into the subsequence of wrong paths? I don't think it's possible.
I've had so many times in my day job someone has told me (Claude told them) there is a bug in my code, I look at it and nope - it just didn't look up the right file. Then you push back on it and it completely crumbles and says sorry.
I wouldn't keep an employee hired who did that over and over again and never learned
People acting like meat proxies add no value. Claude is also very eager to make conclusions without digging deeper. It has no inherent curiosity or prior knowledge about the codebase asside from what it can see.
Our SaaS company is making plans to move towards bespoke development, which until now has been far too costly for most customers to accept. It also violates the multi-tenant cost/business model, so we're scrambling to figure out what hosting and ops and support agreements look like in a bespoke future.
The implications here go well beyond development. I'm seeing pretty massive changes happening in finance, consulting, HR, accounting, law, design, architecture, health, and everything else. When the value of intelligence is effectively zero, how are humans supposed to market and sell themselves in the job market? Some white collar people might try to move into physical jobs for job security, but it will only take a fraction of white collar workers to migrate to crater wages there too.
We're not ready for this. Socially, economically, and politically. Look at how we treated middle Americans who lost their manufacturing jobs when they were offshored to China. Hillary Clinton famously laughed at them and told them to "learn to code." We'll watch jobs and industries disappear while clinging to our own and praying that it's not us today.
UBI is going to be inevitable soon, but it's also woefully insufficient. Giving a developer who used to earn $100k $20k per year UBI isn't going to placate their white hot rage at the social contract being broken. We're going to need universal high income, and paying for that is going to be such a radical social change that I worry voters won't accept it until things are dire.
New versions ship daily and I seem to hit brand new issues every day. They disappear after a few more updates, but it's damn annoying to keep up instead of doing work, and the direction of changes is lacking at best. The underlying technology otherwise seems nothing short of a miracle, but the contrast is eye-opening.
In industries where this is acceptable, that's the future. In ones that can't tolerate it, it isn't. I hadn't expected software engineering itself to be one of the former but it's kinda obvious in retrospective.
On the other hand, if you're working in an industry where you and your coworkers are developing novel solutions that aren't widely known, chances are you'll still be doing that by hand with some light LLM automation. There are industries with a lot of gatekept secrets where LLMs will be less useful. What I will say on that matter is this: if you weren't surprised frontier labs stole copyrighted work for training data, you'd do well to mind what you push through their systems.
Or maybe 'code' just gets pushed down a level like assembly did when C was invented, for example. As a percentage very few people look at assembly in comparison to the 1960s-80s.
on the bun rewrite, this matches my experience
it's always been worth completely ignoring people that had a negative experience with AI-assisted coding, because others of us have been entirely functional. the slow trickle of examples has always been because it was counterproductive to tell anyone that your project or service was AI-assisted in coding or entirely vibe coded.
but now, with bun being an Anthropic project and their whole thing is showing examples that would speed up everyone else, the truth is out there. good move by them.
bun is a fast runtime and will save millions of projects time and compute costs in CI/CD and redeployments
on the title, I disagree, but with a twist. manually coding is just not necessary, but the ability to get results, and use available compute resources efficiently and at low cost are still disciplines. I don't just mean "architecture", I mean a more specific part of architecture like knowing that your postgres instance can already be an event based architecture and you don't need the cloud provider's pub/sub arrangement at all.
right now, AI isn't going to do that for you. but regarding the discipline, I don't have pride over that, I think that's a major point for people, a level of gatekeeping and pride. this isn't what we need, this isn't what companies need, everyone always needed results.
people in this career are concerned about the billable rate when people with less familiarity with the discipline can deliver results, and thats where I also see a different outcome: delivering results in software still has some unique attributes compared to almost every role in an organization.
A, it just has to be done. B, it's still one of the only roles where your workers can compete directly against you whenever they feel content enough to do so, or discontent with how you are paying them.
Software engineers have little to no overhead costs of running their own thing, they have no licenses and hence no geographic limitation compared to your accountants and lawyers, and they also have enough money to cover the little overhead costs they do incur, something even your sales team doesn't have before getting caught in a lead trading ponzi scheme. The major markets for software engineers (California) nullifies any non-compete you were relying on. It doesn't matter who is doing the software, whether it was someone that was previously doing HR, or someone that built an identity around coding, it just has to be done.
But this should translate into hiring, right now, the importance and cost reinforces teams to want to interview for something that "should" be gatekept. multi week, multi month, hiring processes to prove someone has a cognitive ability. but this isn't necessary, people should be able to come into the effort, the same way someone can pick up a broom. the same way a sailor on an expedition picks up an oar and splits the bounty during the trip.
It's not. If you give it a reference implementation, and unless the LLM/agent cheats, you'd get the migration minus undocumented/untested behavior. I've done that with different domain, migrating existing numerical code from Fortran to Rust. When working on the same codebase, agents routinely shit the bed unless given increasingly specific and concrete specs.
It's simply a spectrum between "make an airbnb for ants, make no mistakes" and providing an actual specification (and I consider an implementation to be such). What you don't provide and account for from the beginning will be paid in tokens later. That puts a price on technical debt, which is interesting in itself.