Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I can support the "End of Programming" thesis from the standpoint that no one is still doing punch cards in binary against the CPU.
Higher level languages are great, but we all owe RSM a debt of gratitude for the FSF and keeping the source code within public view.
These closed AI models are akin to compiler vendors, in my view.
It doesn't take much economic analysis to realize that we disdain living on the vendors' various plantations.
That is, the "AI is just a tool" argument is subordinate to the need to keep freedom free.
End of rant.
by smitty1e - Rewriting something from one language to another is not really the height of software development.
When you have an extensive testing suite, I would claim it's the ideal scenario for LLM's, next to crunching out small tools and MVP's.
Let's first see how it handles the architecture in a 1 year old project of 3 developers, before we make such claims as "the end of programming".
I love LLM's, they save me a lot of time and effort. But their autonomy degrades quickly when you keep adding context and complexity, which a medium codebase clearly has.
by koonsolo - 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.
- 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
by AJRF - > Claude told them
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.
by mechazawa - 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.
by przemub - Really didn't see programming going the way of blacksmithing in my lifetime, let alone early in my lifetime.by broodbucket
- Why not?
It's a highly paid, in demand career path where formal education is optional.
They came for the sysadmins first because they had more power, but they were always coming for you.
Even if "Agentic Coding" doesn't solve programming, there is an aligned incentive not to care, I've heard directly from the executives at large companies that they despise the amount of leverage software programmers have... and now they have an excuse to end it on a unified front.
That is sufficed to say that many people in our profession don't actually care about software development or programming, they just saw a lucrative career path.
My personal and somewhat bitter opinion is that the profession will be more enjoyable for me once all the people who are only in it for money leave. I can live a blue collar salary life working in tech and still enjoy it. Maybe I'll have less scrum masters and shit. Thank god.
by dijit - Hm. I'm someone who stills prefers to code by hand, and one of my hobbies is to go do some work in my blacksmith shop down in my barn. While my wife enjoys making our own clothes by hand and quilting.
OK, I think I'm going to bow out of these discussions. Clearly I'm not as into tech as I though I was.
by codingdave - > Broader, cheaper access to frontier intelligence at incredible speeds is coming.
OP's entire argument rests on this presumption, and while it certainly sounds like the industry is headed in this direction, it's definitely way too early to equate the success of building proofs of concept with success at maintaining mission-critical production systems across industry verticals, as OP attempts to:
> The prototype is working software. And the improvement and testing of that prototype is further enabled by more improvement loops with the AI. It gets better with more testing and verification, not through human code review, but through usage and testing.
Who drives usage and testing today? Who takes user feedback from the "usage and testing" and translate it into something that The Machine can use for improvements? Humans do. There is no agentic harness for managing at the level of the product itself, and I'm not convinced that there ever will be, because it's a fundamentally political concern. And not the low-stakes intra-team kind like tabs vs. spaces - the high-stakes, do-we-close-the-deal-or-not kind. Even if agents hypothetically could handle that level of stakes - they simply lack the context to do so, and will continue to lack the context to do so, at least until we get AGI in a humanoid robotic form factor.
Software engineering isn't dead. As a separate field with a dedicated job title, it's arguably dying in a world where it becomes a table-stakes skillset for Product roles. It is simply cheaper to employ 2x Product Engineers at $300k/year each, armed with $200k/year each in tokens, than it is to staff out a team of eight Software Engineers at $150k/year each. And this is before a hypothetical crash in API token pricing, or agility benefits from aligning fewer humans.
It's happening slowly in smaller companies, and hasn't happened yet at scale because, while you can teach Product skills to most Software Engineers and can't teach Software skills to most Product folk, most big-cap executives haven't gotten this memo yet. But the economic pressures are there.
by solatic - 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.
[1] http://www.softwarepreservation.org/projects/FORTRAN/BackusE...
by mpweiher - 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...by zoig_nk
- So you are suggesting we will soon drop the "vibe" from "vibe coding"?by cubefox
- 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.
by Gareth321 - The time has long passed since the “inevitable” things should have come into existence, for example universal basic housing. What happened instead of the advent of it is something to behold: somehow instead of supply being provisioned in response to demand, we simply changed the excess demand into an externality. Now there’s been a lot of “rage” about this, but it hasn’t been effectual. We still have plenty of homelessness right now and no particular mechanism to control it. We may not be ready for this change, but that doesn’t mean we will accept the change instead of simply pretending the problem never existed and should never exist, if everyone just behaved right.by ironmagma
- 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.
by simonw - 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.
[0] https://github.com/oven-sh/bun/blob/fc865b398e51de8a95ddde4b...
[1] https://haskellforall.com/2026/03/a-sufficiently-detailed-sp...
[2] https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...
- > 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
by rdedev - 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.
by taurath - 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 released 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 obsess over while failing to provide value to non-developers. 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.
- Simon - I hope this is not a rude question, but do you work with other engineers?by AJRF
- 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.
It's hard not to extrapolate...
by cafebabbe - 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)by mastermage
- 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.by dogcomplex
- I guess in most industries speed was always the primary concern. Things like architecture and principles were there only to prevent things slowing down to a crawl. A way to protect that speedby k3nt0456
- 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.
by kodoman - 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. come up with the idea 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.
by znnajdla - 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.
by devy - Source code transpilers were a thing since forever.
We'd guess that LLMs probably make them cheaper, but there's no real world data on this.
- Yes but those are all semantic tasks which can be done and understood in time by the next iteration of models training at that meta-level of architectural analysis.
AI deeply understands what Bun, Zig and Rust are, how they work, can conceive of the before and after architecture (probably the hard step here), can conceive of the goal of the rewrite, and can verify (using Lean and machine-checked proofs of the before and after expected states) the final result.
They just needed us to ask. Build a sufficiently general research program that can find and iterate on ideas, and it will do the asking itself.
by dogcomplex