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.
Yeah when ever I have been worried about AI completely removing the need for any kind of programming skill I think about how much I had to guide it and stop it doing dumb things (even when using Sol or Fable).
I also tried to vibe code a machine learning thing and it got to a level where I was lost and I tried to move ahead without understanding the problem and let the agent figure it out. And despite using Fable it was a mess and I realized that I had to teach my self more before I can continue. Even worse it felt like it was working for a bit until It become clear it was trash. I would Imagine that kind of experience would annoy a lot of non-developers and they would not want to try again.
It feels like this narrative of programming and computer sciences skills being irrelevant is pushed by many groups (not just AI companies) who want to reduce the value of human skill and talent both financially and socially. It's quite insidious when you think about it, A gleeful sort of tone is detectable where the person is happy that nothing require mental effort or skill. Not that this is that article and that it seems to be saying that AI has changed everything (which I agree some what though I think people will still write some code by hand, Their are still things I code entirely by hand usually certain scripts or things I really need to understand and my intuition of them is important)
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.
Sure, maybe step 2 can eventually be replaced by AI. But step 1? Why would the AI even conceive of the idea of doing a rewrite in the first place?
And rewriting is just an example. There are tons of architectural decisions that need to be made every day in the building of advanced software. This is no "correct" way to do it that the AI can know in advance, it's a technical decision to be made by an engineer.
Maybe it sees a bunch of segfaults in the Zig codebase and decides a memory safe language is better, just as the human did in Bun's rewrite. I'm not sure why you think it wouldn't have been able to conceive a rewrite.
Such an AI would be unusable in production because there is no bound on the work that can be created and external side effects that could happen. All projects have real world constraints and side effects, budget, customer requirements, etc. Imagine a non-technical person prompting the AI "make the app faster and fix all the bugs" and the AI autonomously decides to rewrite the whole production app and all its dependencies in Rust that is live and serving thousands of users. Doing a full rewrite would take days to execute, and have all sorts of side effects on the actual users during deployment (even if it was done 100% correctly, work has to be paused, affairs need to be coordinated with real customers, etc.). Even if the AI has that capability (and I do believe it is possible, even with today's models), that's not what a business owner wants. You don't want to use an AI which, if you gave it a 3 word prompt, it could suddenly decide on its own to rewrite your whole entire business. An AI that had that much autonomy could just decide on its own to pivot your whole startup and sell something else. A business owner wouldn't even want to use such an AI which could have such large unbounded side effects.
I feel like leaving it to decide everything would not produce a good end product. It feels like just having it decide how GC should work, how the function call stack should work or any of these rather simple but actually requiring lots of decision and thinking how things fit together (and pick a good solution out of many seemingly good solutions that can come back to bite you), couple this with the tendency for AI agents to tend towards adding new code and building over features I don't think you end up with a good solution.
On formal verification having done it only in an academic sense and looked over at projects like seL4 and quite interested in that project. It feels like actually proving useful properties of programs for real programs even ones with well defined domains and easier to model such as interpreters or compilers it seems that it will just prove theorems about properties that hardly matter or don't even matter at all. See how bad it still tends to be when trying to get it to write tests.
I would be interested to know if their has been an agent that has actually utilized formal methods such as Lean or Coq or Isabella to prove properties of programs in an automated way as you suggest, I have only seen it proving mathematics and or searching for counter examples, not writing Curry-Howard style proofs.
More precisely, a "perfect solution" doesn't exist. It's all tradeoffs given your goals. Someone needs to make the decision: 1. which tradeoffs are worth given your goals 2. which goals are worth defining or redefining. And do that effectively, you need to understand the problem, which goes back to engineering.
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 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.
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.
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.
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 speed
No, it was to build things that were good enough. I am watching initiative after initiative fail after a rapid PoC phase, the more in depth the LLM dependence the quicker the codebase becomes unmanageable.
And who will fix the slop? Not Silicon Valley programs being paid $200K or whatever. We stand on the verge of a golden age of outsourcing in software which will make all previous phases of outsourcing look like trial runs.
I live in what's probably the outsourcing capital of the world (though I thankfully don't work in those body shops).
I don't think there's going to be a rush to outsource. In fact, I suspect that it's quite the opposite scenario going to play out.
Primarily because now that the cost to produce the boring/mundane stuff that is the stuff of outsourcing (internal tooling, dashboards, ERP, integrations, QA etc.), it will likely be much more cost effective to hire 3 devs in the US and give them hefty token budgets and have much easier coordination and communication loops than outsourcing to a Bangalore body shop that will try and bill you 15 engineers for the same work.
In fact, word on the street here is that there's a significant correction in the Bangalore realty market for the first time in history thanks to the IT salaries drying up. [1]
I suspect LLMs are going to have a global worldwide deflationary effect what with white collar salaries at risk. The only counter acting force might be the distortions caused by recent wars and tariff shenanigans of the US government.
But even having said all of that I am hopeful for the eventual benefits human beings can reap from the advent of LLMS. The only thing that keeps me up at night is my lack of faith in the aging gerontocracy (worldwode phenomenon) that all our futures are in the hands of that seems to be ill equipped to handle this period of what is most likely massive upheaval and uncertainty.
I come to conclusion that software source code will be kind of ephemeral output, like binaries are today. If you are not happy about slop accumulation, you take still valid functional requirements, docs, API contracts, test cases, some selection of still valid prompt history, and let better agent rewrite everything from scratch. Even if the session costs $200K one time - that is very cheap even for SMEs.
I really worry about "regressions" in that model. If you regenerate everything all the time. Do you keep issues fixed or constantly end up introducing new issues. Well it might work with absolute total test coverage. Which seems to be very high bar to reach.
Won't this mean that a lot of developers in Silicon Valley will find themselves out of a job? If the competition (AI operators) can sit 8000 miles away and be paid peanuts.
The whole point is that we’re TikToking the software industry and no one will know what to tell the ai to get the software written in a way that works. It’s in principle the same as idiocracy where no one knows how to make burrito covers anymore because shit won’t grow
Probably the other way around. The idea behind outsourcing is that you move the generic labor abroad and keep coordination and control onshore. AI can now do the generic labor for even less, so you'll likely see small onshore teams using AI instead.
AI won't end silicon valley, but could still shrink it significantly.
Unless, of course, new opportunities arise and the economy grows. This is not even unlikely as we've seen amazing growth the last 25 years, even.
In which case your sentiment is probably correct. And now that I think of it, this is potentially very bad news for the outsourcing companies in countries like India. They also have less money to spend on tokens.
it does not have to be patching over the existing system. Of course you need someone experience in the loop, but it is not that someone needs to manually refactor everything by typing every line. One approach that works quite well is like this.
"give me all the specs in a list" -> "which architectural changes would simplify the implementation based of these specs" -> delete everything -> "implement the new specs"
Which speed in which industry? Speed of having the idea, speed of creating a early mockup, speed of creating the prototype, speed of proof, speed of creating the process to replicate at scale, speed of mass production, speed of maintenance and evolution tasks, speed of support, speed of dismantlement, speed of keeping track of all the damn conflicting priorities between all speeds?
In building/construction industry, certainly one might expect delivery speed to matter, and humanity have literally millennia of experience in the domain, and yet it’s notoriously known to go through the roof all the time.
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 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)
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.
I see a lot of enthusiasm from people who work alone or who have total control over a project and nothing but abject misery from people who work in a professional setting with a group of people using coding models.
It's a learning curve, but it can work, you just need to be comfortable with large (and likely quite negative) reviews for the inevitable large MRs that will get generated.
The important things to get right are the same as they were before though. Work from well refined stories that are not too broad in scope. Ensure you have enough good acceptance criteria that will help prove that the code works as intended.
Yeah so unverified PR's is super annoying, but people using LLMs to answer things incorrectly they could look at themselves is a big issue too.
I often hear this get dismissed along the lines of "oh you didn't context engineer hard enough" - but the default state of the model is to very confidently state a thing to be true when it hasn't searched correctly.
That is a trait of a very junior engineer - one who, if they never learned to fix this behaviour would be fired.
It seems objectively _worse_ than what we had before - trained engineers who gained wisdom over a long time horizon and had a reputation they'd lose if they kept incorrectly stating things.
I think he is saying this in reference to this:
"If you can reduce a problem to a clearly verifiable end state, provide the necessary context [...]"
Which for reference i am not an engineer but a Physicist is literally one of the things we make jokes about for engineers. Not that we are much better in that regard as a verfiable end state in Physics is like realy realy dificult to get so is the necessary context.
I don't mean to imply that was easy! I think it's hard, and a skill that needs active investment. It's one of the reasons I'm not afraid for my career.
> 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.
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.
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.
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 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.
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 here as "coding" 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...
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.
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.
If I thought this would happen I would've done something else with my life. There's still some fun to be had, and I'll probably stay in the industry because it pays well and I have history here, but the magic has largely died.
I essentially have the opposite opinion, you're going to lose people who had a lot of passion and be left with people who are content writing prompts for money.
My personal take is that the AI era will be a rough brush that will help shed all the accumulated cruft in this profession.
I think highly technical, knowledgable people will remain, and thrive in a few years, and all the rest will move on to the next fad, or whatever pays the most.
The reason a segment of the current market will remain is because LLMs still need steering, we are not at a point where an abstract idea can go from Tweet to product, and we are many many leagues away from that. Of course, this has been noted to oblivion before, so I'm not really providing shocker value at all here.
> 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.
I would love it if it was that simple :-) Agents can one-shot this prototype and that feels like they are "almost done". The hard part starts when we try to make it production-grade.
I'm not saying that it's not possible, but it requires more effort than productionizing a PoC that we used to create "by hand". We start to discover shortcuts taken by the coding agent and we spend 80% of the time on getting the last 20% right (but to be clear, it's still less time than writing it by hand).
It looks like the author may not have hit this reality check yet:
> Of course, neither of these things is currently shipped, or supported and isn’t what I’d call production ready software. So you could say what many say about AI, which is that it helps you ship the prototype faster. But that isn’t really giving enough credit here.
For AI-generated code, finding "the last 20% rough edges" is much, much harder than creating PoC. Often the rough edges are buried in the code that we don't know. Fixing those problems requires big refactors that, for wrongly architected code, can break other things.
Tests help, but that's not enough for models to autonomously fix them. If they make one error, it compounds over multiple iterations.
It's especially true for problems where we don't have a clear oracle. It's impressive that models can brute-force problems with a clear oracle. But many problems where a clear oracle doesn't exist (a lot of business software that I know) will still require a lot of product engineering.
Maybe it will improve? I'm not sure if it can happen with hallucinations around (from what I see, they are still a big deal for domains that agents are not trained on).
> 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.
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 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.
Programming with AIs requires new architectural structures designed around the all-too-small context windows of the AIs themselves. Highly modular, highly semantic, highly traceable, good at deleting and refactoring/removing things they no longer need, good at identifying the core truths/principles/designs they need to uphold, good at recognizing what is mere interface from architecture from data.
This is the great orchestrator game. It might be the last game. I dont think it lands precisely in our previous "best practices" though, and I don't think it's trivial to solve for. I also don't think it's going to be a human-centric design. I think we're generally better off rethinking fundamentals and designing from the ground up on this one. I think it's also a lot of fun to start thinking in these new ways.
There will always be programming, just like there will always be oil painters and historians. But this is about to get industrialized into stable emerging factory forms, and there's a lot of ways to design those right now. And after that us artisans will either need to find new unfinished aspects of programming-like design or retire. At least take solace that the rest of the world will basically simultaneously be doing so too.
First, the "all too small context window" reminds me of GetRight, mp3pro and a lot of other artifacts we invented in the 80s and 90s to deal with the limited internet bandwidth of then. We created artifacts to "achieve things" with the limited technology at hand. In 2026, ive got a 500 mbps simetric home connection. The same way, RAGs and all related stuff are artifacts to help us deal with today's tech limitations. In 10 years, it will be a non issue.
Second, I agree on the architectural patterns. Building (commercial) software will become a real Engineering career. Engineers will define the blueprints of the functionality of software, as well as the "materials" (technology, practices to use, measurement limits, ranges, etc) of tge software to be built, the same way Architects and Civil Engineers do when designing a Skyscraper or a bridge to be built.
As you very well put it, there will still be the "artisan" programmer, who builds whatever code by hand. But that will be as a hobby or some personal project.
When i look around my programming coworkers i feel this shift poses a problem to many of them. Not so much because AI now does all programming but more because they are so used to working through tasks someone else creates for them.
Skeptical whether author has financial gain from echoing and underwriting this already prominent statement, spread by BigAI. Not that I disagree with what’s written, I do see irreversible changes in our industry, but there’s the flip side that he doesn’t seem interested to write about. Makes the whole article read like a sponsored Anthropic ad.
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.
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.
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.
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 mostly 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.
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 spend more time writing tests than writing code. Saying "You don't need to write code any more, only think, design, and write 'verification'" is interesting of course, but compacts a smaller percentage of the total time to make a feature than listeners might think.
However my recent years have been in Python, which perhaps is high level enough to require a large amount of code writing. Maybe in C++ it's a bigger gain?
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.
Bob Martin spent about half his life talking about an eventual coding error that will kill 10000 of people, and how we must be responsible with our code because of this.
When it eventually happens and it is AI generated... who gets the stick?
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)
It may be the end of programming (the act of writing code by hand) but not the end of software engineering (making sure that code works and can be extended)
> 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 label on technical debt, which is interesting in itself, and a perverse incentive for AI companies.
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.
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.
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.
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.
if you tell it to do a thing it'll try it's best to make you think that it was done. I rarely get good refactors from AI unless I tell it specifically what to do.
Its not the end of programming, its the change from how we program.
Do we still write code in Assembly? No, we moved over to a form of programming that allowed more people, to easier program.
Did it mean that the assembly guys lost their jobs? No, their knowledge allowed them to still program better then the rest, in the new paradigm world.
Did the creation of visual programming UIs like Delphi, VB, etc result in the end of programming because the entry level was lowered even more? No ...
But people who have no programming experience are now programming. So?
My dad who has at most basic PC knowledge ended up making a few simple programs 20+ years ago, because he had a need for it. He did it with a combination of easy programming language + visual interface like VB, and googling... That did not make him turn it into a job.
My old boss who had no programming knowledge (bank/sales guy) used Microsoft Access to make a ticket system to monitor the employees. With cost calculation, hour tracking etc.
It did not remove the need for programmers, people with actual experience. We also used those new tools like visual UI, or easier programming language (compared to assembly) to work faster, create bigger programs, ...
AI baaed programming is just the same. I have seen non programmers create impressive programs, just like i have seen non-programmers create impressive programs in Visual Basic.
BUT ...
When issues are found, this is where experience actually matters. Even if we do not program anymore in the old way by writing every word, its that experience of understanding how something works, that makes the difference.
Just like the guys that has gone from 100% asm, to maybe 1% transitioned, so are we all transitioning.
No matter how good a transcompiler is (yes, they existed before AI), you always need to fix issues and that requires domain knowledge.
No matter how many programs your transcompile, it means nothing without actually supporting those programs. Making software is the easy part, keeping it supported, bug fixed, etc matters. People may be crapping out tons of programs with AI, most of them are abandonware because creating is sexy, maintaining is not. Guess what the real job of most programmers is? Yea ... the boring part.
AI is a tool, just like how we moved from low level programming language, to compile helper, debuggers, syntax highlighters, to visual interfaces, ... and all of those tools are their to make our work faster, easier, .. to be more productive and squeezer more out of person.
We harvested grains manually, then the first simply tools came. It did not remove farmers. The arrival of the tractor that made harvesting even easier. It did not remove farmers. We now have combines that run on GPS and can harvest themselves and do the work in a hour, that will have taken 1000 people in a day. And yet, farmers still exist. What happened is that people can do more, vs them doing it manually.
Its not the end of programming, programming simply changed in the way its done. And some people have a hard time accepting changes. Its not the end, it never is, its simply the changeover how its done.
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 they think "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 old expedition picked up an oar and splits the bounty during the trip.
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) tells us that human programming is going to become a niche activity in the near future.
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.
Yeah when ever I have been worried about AI completely removing the need for any kind of programming skill I think about how much I had to guide it and stop it doing dumb things (even when using Sol or Fable).
I also tried to vibe code a machine learning thing and it got to a level where I was lost and I tried to move ahead without understanding the problem and let the agent figure it out. And despite using Fable it was a mess and I realized that I had to teach my self more before I can continue. Even worse it felt like it was working for a bit until It become clear it was trash. I would Imagine that kind of experience would annoy a lot of non-developers and they would not want to try again.
It feels like this narrative of programming and computer sciences skills being irrelevant is pushed by many groups (not just AI companies) who want to reduce the value of human skill and talent both financially and socially. It's quite insidious when you think about it, A gleeful sort of tone is detectable where the person is happy that nothing require mental effort or skill. Not that this is that article and that it seems to be saying that AI has changed everything (which I agree some what though I think people will still write some code by hand, Their are still things I code entirely by hand usually certain scripts or things I really need to understand and my intuition of them is important)
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.
Sure, maybe step 2 can eventually be replaced by AI. But step 1? Why would the AI even conceive of the idea of doing a rewrite in the first place?
And rewriting is just an example. There are tons of architectural decisions that need to be made every day in the building of advanced software. This is no "correct" way to do it that the AI can know in advance, it's a technical decision to be made by an engineer.
Maybe it sees a bunch of segfaults in the Zig codebase and decides a memory safe language is better, just as the human did in Bun's rewrite. I'm not sure why you think it wouldn't have been able to conceive a rewrite.
Such an AI would be unusable in production because there is no bound on the work that can be created and external side effects that could happen. All projects have real world constraints and side effects, budget, customer requirements, etc. Imagine a non-technical person prompting the AI "make the app faster and fix all the bugs" and the AI autonomously decides to rewrite the whole production app and all its dependencies in Rust that is live and serving thousands of users. Doing a full rewrite would take days to execute, and have all sorts of side effects on the actual users during deployment (even if it was done 100% correctly, work has to be paused, affairs need to be coordinated with real customers, etc.). Even if the AI has that capability (and I do believe it is possible, even with today's models), that's not what a business owner wants. You don't want to use an AI which, if you gave it a 3 word prompt, it could suddenly decide on its own to rewrite your whole entire business. An AI that had that much autonomy could just decide on its own to pivot your whole startup and sell something else. A business owner wouldn't even want to use such an AI which could have such large unbounded side effects.
I feel like leaving it to decide everything would not produce a good end product. It feels like just having it decide how GC should work, how the function call stack should work or any of these rather simple but actually requiring lots of decision and thinking how things fit together (and pick a good solution out of many seemingly good solutions that can come back to bite you), couple this with the tendency for AI agents to tend towards adding new code and building over features I don't think you end up with a good solution.
On formal verification having done it only in an academic sense and looked over at projects like seL4 and quite interested in that project. It feels like actually proving useful properties of programs for real programs even ones with well defined domains and easier to model such as interpreters or compilers it seems that it will just prove theorems about properties that hardly matter or don't even matter at all. See how bad it still tends to be when trying to get it to write tests.
I would be interested to know if their has been an agent that has actually utilized formal methods such as Lean or Coq or Isabella to prove properties of programs in an automated way as you suggest, I have only seen it proving mathematics and or searching for counter examples, not writing Curry-Howard style proofs.
> I don't think you end up with a good solution
More precisely, a "perfect solution" doesn't exist. It's all tradeoffs given your goals. Someone needs to make the decision: 1. which tradeoffs are worth given your goals 2. which goals are worth defining or redefining. And do that effectively, you need to understand the problem, which goes back to engineering.
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.
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...
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.
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.
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.
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 speed
It is about functionality.
Functionality iterations or adaptations are just faster with good architecture and principles.
No, it was to build things that were good enough. I am watching initiative after initiative fail after a rapid PoC phase, the more in depth the LLM dependence the quicker the codebase becomes unmanageable.
And who will fix the slop? Not Silicon Valley programs being paid $200K or whatever. We stand on the verge of a golden age of outsourcing in software which will make all previous phases of outsourcing look like trial runs.
I live in what's probably the outsourcing capital of the world (though I thankfully don't work in those body shops).
I don't think there's going to be a rush to outsource. In fact, I suspect that it's quite the opposite scenario going to play out.
Primarily because now that the cost to produce the boring/mundane stuff that is the stuff of outsourcing (internal tooling, dashboards, ERP, integrations, QA etc.), it will likely be much more cost effective to hire 3 devs in the US and give them hefty token budgets and have much easier coordination and communication loops than outsourcing to a Bangalore body shop that will try and bill you 15 engineers for the same work.
In fact, word on the street here is that there's a significant correction in the Bangalore realty market for the first time in history thanks to the IT salaries drying up. [1]
I suspect LLMs are going to have a global worldwide deflationary effect what with white collar salaries at risk. The only counter acting force might be the distortions caused by recent wars and tariff shenanigans of the US government.
But even having said all of that I am hopeful for the eventual benefits human beings can reap from the advent of LLMS. The only thing that keeps me up at night is my lack of faith in the aging gerontocracy (worldwode phenomenon) that all our futures are in the hands of that seems to be ill equipped to handle this period of what is most likely massive upheaval and uncertainty.
[1] https://timesofindia.indiatimes.com/real-estate/news/housing...
Project "Death by a thousand cuts"
I come to conclusion that software source code will be kind of ephemeral output, like binaries are today. If you are not happy about slop accumulation, you take still valid functional requirements, docs, API contracts, test cases, some selection of still valid prompt history, and let better agent rewrite everything from scratch. Even if the session costs $200K one time - that is very cheap even for SMEs.
I really worry about "regressions" in that model. If you regenerate everything all the time. Do you keep issues fixed or constantly end up introducing new issues. Well it might work with absolute total test coverage. Which seems to be very high bar to reach.
Won't this mean that a lot of developers in Silicon Valley will find themselves out of a job? If the competition (AI operators) can sit 8000 miles away and be paid peanuts.
The whole point is that we’re TikToking the software industry and no one will know what to tell the ai to get the software written in a way that works. It’s in principle the same as idiocracy where no one knows how to make burrito covers anymore because shit won’t grow
Maybe a super smart AI will take over the part of telling the smaller AI's what to do.
Humanity can then relax in floating chairs drinking soft drinks and consuming AI generated entertainment.
Maybe we need to start cryofreezing some of our best engineers as a precaution. Or even just a bunch of average ones.
Probably the other way around. The idea behind outsourcing is that you move the generic labor abroad and keep coordination and control onshore. AI can now do the generic labor for even less, so you'll likely see small onshore teams using AI instead.
AI won't end silicon valley, but could still shrink it significantly.
Unless, of course, new opportunities arise and the economy grows. This is not even unlikely as we've seen amazing growth the last 25 years, even.
In which case your sentiment is probably correct. And now that I think of it, this is potentially very bad news for the outsourcing companies in countries like India. They also have less money to spend on tokens.
This is cope. There is no going back to artisan programming. Any issues will also be fixed by ai agents.
Sufficiently complex software is something agents still struggle a lot with
Patching over the architectural nightmares LLMs pour out is I think the opposite of artisan programming.
it does not have to be patching over the existing system. Of course you need someone experience in the loop, but it is not that someone needs to manually refactor everything by typing every line. One approach that works quite well is like this.
"give me all the specs in a list" -> "which architectural changes would simplify the implementation based of these specs" -> delete everything -> "implement the new specs"
Which speed in which industry? Speed of having the idea, speed of creating a early mockup, speed of creating the prototype, speed of proof, speed of creating the process to replicate at scale, speed of mass production, speed of maintenance and evolution tasks, speed of support, speed of dismantlement, speed of keeping track of all the damn conflicting priorities between all speeds?
In building/construction industry, certainly one might expect delivery speed to matter, and humanity have literally millennia of experience in the domain, and yet it’s notoriously known to go through the roof all the time.
There's zero evidence to support the notion that LLMs help deliver software quicker.
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 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)
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.
Simon - I hope this is not a rude question, but do you work with other engineers?
Yes, why do you ask?
I see a lot of enthusiasm from people who work alone or who have total control over a project and nothing but abject misery from people who work in a professional setting with a group of people using coding models.
I'm just building some data points.
It's a learning curve, but it can work, you just need to be comfortable with large (and likely quite negative) reviews for the inevitable large MRs that will get generated.
The important things to get right are the same as they were before though. Work from well refined stories that are not too broad in scope. Ensure you have enough good acceptance criteria that will help prove that the code works as intended.
I don't work with a large team, so I don't personally experience the hell of coworkers dumping thousands of lines of unreviewed slop on me.
(I get a bit of exposure to that from my open source projects but it's much easier to close or ignore those.)
Thanks for answering in good faith.
Yeah so unverified PR's is super annoying, but people using LLMs to answer things incorrectly they could look at themselves is a big issue too.
I often hear this get dismissed along the lines of "oh you didn't context engineer hard enough" - but the default state of the model is to very confidently state a thing to be true when it hasn't searched correctly.
That is a trait of a very junior engineer - one who, if they never learned to fix this behaviour would be fired.
It seems objectively _worse_ than what we had before - trained engineers who gained wisdom over a long time horizon and had a reputation they'd lose if they kept incorrectly stating things.
I think he is saying this in reference to this: "If you can reduce a problem to a clearly verifiable end state, provide the necessary context [...]"
Which for reference i am not an engineer but a Physicist is literally one of the things we make jokes about for engineers. Not that we are much better in that regard as a verfiable end state in Physics is like realy realy dificult to get so is the necessary context.
I don't mean to imply that was easy! I think it's hard, and a skill that needs active investment. It's one of the reasons I'm not afraid for my career.
> 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.
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.
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.
> That's called programming. The Bun tests and oracle are the result of years of programming.
I completely agree. That's why I warned about getting distracted by the headline.
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 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.
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...
So you are suggesting we will soon drop the "vibe" from "vibe 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 here as "coding" 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...
Really didn't see programming going the way of blacksmithing in my lifetime, let alone early in my lifetime.
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.
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.
If I thought this would happen I would've done something else with my life. There's still some fun to be had, and I'll probably stay in the industry because it pays well and I have history here, but the magic has largely died.
I essentially have the opposite opinion, you're going to lose people who had a lot of passion and be left with people who are content writing prompts for money.
I agree with you.
My personal take is that the AI era will be a rough brush that will help shed all the accumulated cruft in this profession.
I think highly technical, knowledgable people will remain, and thrive in a few years, and all the rest will move on to the next fad, or whatever pays the most.
The reason a segment of the current market will remain is because LLMs still need steering, we are not at a point where an abstract idea can go from Tweet to product, and we are many many leagues away from that. Of course, this has been noted to oblivion before, so I'm not really providing shocker value at all here.
> 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.
I would love it if it was that simple :-) Agents can one-shot this prototype and that feels like they are "almost done". The hard part starts when we try to make it production-grade.
I'm not saying that it's not possible, but it requires more effort than productionizing a PoC that we used to create "by hand". We start to discover shortcuts taken by the coding agent and we spend 80% of the time on getting the last 20% right (but to be clear, it's still less time than writing it by hand).
It looks like the author may not have hit this reality check yet:
> Of course, neither of these things is currently shipped, or supported and isn’t what I’d call production ready software. So you could say what many say about AI, which is that it helps you ship the prototype faster. But that isn’t really giving enough credit here.
For AI-generated code, finding "the last 20% rough edges" is much, much harder than creating PoC. Often the rough edges are buried in the code that we don't know. Fixing those problems requires big refactors that, for wrongly architected code, can break other things.
Tests help, but that's not enough for models to autonomously fix them. If they make one error, it compounds over multiple iterations.
It's especially true for problems where we don't have a clear oracle. It's impressive that models can brute-force problems with a clear oracle. But many problems where a clear oracle doesn't exist (a lot of business software that I know) will still require a lot of product engineering.
Maybe it will improve? I'm not sure if it can happen with hallucinations around (from what I see, they are still a big deal for domains that agents are not trained on).
> 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.
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
> 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.
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.
Programming with AIs requires new architectural structures designed around the all-too-small context windows of the AIs themselves. Highly modular, highly semantic, highly traceable, good at deleting and refactoring/removing things they no longer need, good at identifying the core truths/principles/designs they need to uphold, good at recognizing what is mere interface from architecture from data.
This is the great orchestrator game. It might be the last game. I dont think it lands precisely in our previous "best practices" though, and I don't think it's trivial to solve for. I also don't think it's going to be a human-centric design. I think we're generally better off rethinking fundamentals and designing from the ground up on this one. I think it's also a lot of fun to start thinking in these new ways.
There will always be programming, just like there will always be oil painters and historians. But this is about to get industrialized into stable emerging factory forms, and there's a lot of ways to design those right now. And after that us artisans will either need to find new unfinished aspects of programming-like design or retire. At least take solace that the rest of the world will basically simultaneously be doing so too.
Great take, two things come to mind:
First, the "all too small context window" reminds me of GetRight, mp3pro and a lot of other artifacts we invented in the 80s and 90s to deal with the limited internet bandwidth of then. We created artifacts to "achieve things" with the limited technology at hand. In 2026, ive got a 500 mbps simetric home connection. The same way, RAGs and all related stuff are artifacts to help us deal with today's tech limitations. In 10 years, it will be a non issue.
Second, I agree on the architectural patterns. Building (commercial) software will become a real Engineering career. Engineers will define the blueprints of the functionality of software, as well as the "materials" (technology, practices to use, measurement limits, ranges, etc) of tge software to be built, the same way Architects and Civil Engineers do when designing a Skyscraper or a bridge to be built.
As you very well put it, there will still be the "artisan" programmer, who builds whatever code by hand. But that will be as a hobby or some personal project.
When i look around my programming coworkers i feel this shift poses a problem to many of them. Not so much because AI now does all programming but more because they are so used to working through tasks someone else creates for them.
Skeptical whether author has financial gain from echoing and underwriting this already prominent statement, spread by BigAI. Not that I disagree with what’s written, I do see irreversible changes in our industry, but there’s the flip side that he doesn’t seem interested to write about. Makes the whole article read like a sponsored Anthropic ad.
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.
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.
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.
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 mostly 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.
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 spend more time writing tests than writing code. Saying "You don't need to write code any more, only think, design, and write 'verification'" is interesting of course, but compacts a smaller percentage of the total time to make a feature than listeners might think.
However my recent years have been in Python, which perhaps is high level enough to require a large amount of code writing. Maybe in C++ it's a bigger gain?
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.
Bob Martin spent about half his life talking about an eventual coding error that will kill 10000 of people, and how we must be responsible with our code because of this.
When it eventually happens and it is AI generated... who gets the stick?
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)
It may be the end of programming (the act of writing code by hand) but not the end of software engineering (making sure that code works and can be extended)
What happens to the last AI agent written project with the web browser?
McDonald's code gives you something to show but it's no bridge to stand on..
> 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 label on technical debt, which is interesting in itself, and a perverse incentive for AI companies.
I think I’m on the right track by building a feature flag service for AI coding agents. It will serve coding agents rather than human users.
The Bun from Zig into Rust move is at best doing a "burn out on the main street"
Loud with lots of smoke, but didn't go anywhere!
Related:
It's Not the End of Programming
https://news.ycombinator.com/item?id=49446597
Or is it a transition to truly declarative programming?
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.
I don't think we'll be fucked as a profession. That's just SV hype from people living far away from reality
What are you switching to?
Switching jobs, not profession. I am currently very underpaid.
What to?
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.
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 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.
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.
You can often just tell it to refactor though. That's like a scheduled harness thing, not a game changer.
Perhaps, but you need to tell it how to refactor or you’ll get more gibberish and helper functions. Hence, programming.
if you tell it to do a thing it'll try it's best to make you think that it was done. I rarely get good refactors from AI unless I tell it specifically what to do.
Its not the end of programming, its the change from how we program.
Do we still write code in Assembly? No, we moved over to a form of programming that allowed more people, to easier program.
Did it mean that the assembly guys lost their jobs? No, their knowledge allowed them to still program better then the rest, in the new paradigm world.
Did the creation of visual programming UIs like Delphi, VB, etc result in the end of programming because the entry level was lowered even more? No ...
But people who have no programming experience are now programming. So?
My dad who has at most basic PC knowledge ended up making a few simple programs 20+ years ago, because he had a need for it. He did it with a combination of easy programming language + visual interface like VB, and googling... That did not make him turn it into a job.
My old boss who had no programming knowledge (bank/sales guy) used Microsoft Access to make a ticket system to monitor the employees. With cost calculation, hour tracking etc.
It did not remove the need for programmers, people with actual experience. We also used those new tools like visual UI, or easier programming language (compared to assembly) to work faster, create bigger programs, ...
AI baaed programming is just the same. I have seen non programmers create impressive programs, just like i have seen non-programmers create impressive programs in Visual Basic.
BUT ...
When issues are found, this is where experience actually matters. Even if we do not program anymore in the old way by writing every word, its that experience of understanding how something works, that makes the difference.
Just like the guys that has gone from 100% asm, to maybe 1% transitioned, so are we all transitioning.
No matter how good a transcompiler is (yes, they existed before AI), you always need to fix issues and that requires domain knowledge.
No matter how many programs your transcompile, it means nothing without actually supporting those programs. Making software is the easy part, keeping it supported, bug fixed, etc matters. People may be crapping out tons of programs with AI, most of them are abandonware because creating is sexy, maintaining is not. Guess what the real job of most programmers is? Yea ... the boring part.
AI is a tool, just like how we moved from low level programming language, to compile helper, debuggers, syntax highlighters, to visual interfaces, ... and all of those tools are their to make our work faster, easier, .. to be more productive and squeezer more out of person.
We harvested grains manually, then the first simply tools came. It did not remove farmers. The arrival of the tractor that made harvesting even easier. It did not remove farmers. We now have combines that run on GPS and can harvest themselves and do the work in a hour, that will have taken 1000 people in a day. And yet, farmers still exist. What happened is that people can do more, vs them doing it manually.
Its not the end of programming, programming simply changed in the way its done. And some people have a hard time accepting changes. Its not the end, it never is, its simply the changeover how its done.
Wow another hot take - agents can write a lot of code!!!
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 they think "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 old expedition picked up an oar and splits the bounty during the trip.
Clickbait title for a story about a bot translating a program from one language to another. Some people get hyped over the most trivial things.
Controversial title just to stir the engagement. Congrats, you're on top of HN!
The title accurately reflects what is in the post. Therefore your assessment of the title is unfair.
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) tells us that human programming is going to become a niche activity in the near future.