The End of Programming

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.

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...

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 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).

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.

“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...

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.

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

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.

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.

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.

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?

When it eventually happens and it is AI generated... who gets the stick?

McDonald's code gives you something to show but it's no bridge to stand on..

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.

Loud with lots of smoke, but didn't go anywhere!

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.

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.

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.

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.

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.