Yes exactly. LLM-assisted coding is just the next layer of abstraction. This has been happening to computer programming for decades. We've always been in search of a way to program in "natural language"
It's also an abstraction to hire a software engineer and tell them what kind of app you want, but I don't think we can call it "programming" at that point.
Which company do you work for that the product managers are opining on the software architecture, data structures, algorithms, and variable names? And what are your software engineers doing while the product managers are doing the aforementioned tasks? Did your company expand the scope of the engineers to subsume product management? Because a person without a technical background can not reliably take on these tasks. But if the engineers are doing all this, who's talking to the customers?
> Which company do you work for that the product managers are opining on the software architecture, data structures, algorithms, and variable names
We are talking about the separation of these roles going away. If you disagree or can't see that happening, that's fine. Nobody gonna waste their time convincing you.
It's not worth arguing with the troll. Obviously opining about a task is not the same job as doing the task. Everyone understands this. It's like saying "my cooking got better when I delegated the implementation to a private chef".
AI generation isn't an abstraction because you have to wrestle with the nitty-grittys of the output.
And that output is what you retain.
You can't clone someone's repository of nothing but prompts and rebuild from scratch.
Abstraction means that I trust the toolchains so much that I think of the source code as the software, and in the right kind of environment/ecosystem such as open source distros, I can actually ship that to the downstream users as my product.
Abstractions are based on very detailed and rigid logical contracts.
Conversely, the reason agent assisted coding works so well is that all the tooling meant to keep human coders out of trouble, like lint, leak detectors, profiling tools, test harnesses, etc. prevent agents from making errors.
This is in contrast with general purpose agents like Meta Muse that make some amusing and horrifying errors. These kinds of agents don't have the interfaces and guardrails that were built for human coders. They use a lot of ad hoc screen scraping and guessing at what APIs do.
That's also why Apple and Google haven't shipped fully general purpose agents that use their new app tool calling interfaces yet. For example Google only released their Gemini agent that uses AppFunctions to enterprise customers. Presumably because MDM tools can be used to monitor agents' actions.
I feel linters are not that useful now, AI tend to not do that mistakes already. However there are some other issues like how do you architect, if a helper is needed or not, that no linter can flag. Other AI review tools are doing great imo to improve what is already amazing about coding agent.
I've been doing a lot of devops lately, writing tons of templates, configs, scripts in like 3 programming languages, wrestling with 'cloud-based' constructs - with LLMs ofc.
LLMs make all this work easy, otherwise it'd be borderline impossible.
It's all BS. Hosting a CRUD app should be an executable for the server (written in boring lang/lib of my choice) + an SQLite db. Of course it's a bit more than that, but not by much.
There are wonderful IDEs and tools out there which help humans do the task, and good design keeps the complexity under control.
LLMs on the other hand both are sources of the mess and solutions to it. Without good tooling you'll be much more inclined to reach for an LLM.
> LLMs make all this work easy, otherwise it'd be borderline impossible.
This is exactly it. We all know and envy that guy who can bang out a script on demand that makes any task simple, and we also know we'll never be that guy.
LLMs are superhuman knowledge remixers. And that's exactly what we need to deal with a lot of software development tasks.
This is similar disruption that terminals brought. Before terminals, programming was done in the computer room, it was social gathering, many programmers were women, people were debugging printouts on the floor, punching cards together. Then terminals came and everybody crawled into their dark solitary offices, staring at green or yellow phosphor screens of their terminals. Women didn't like it and left.
"Women didn't like it and left" is certainly an interesting interpretation of the systemic exclusion of women from a field when it transitions from low-prestige manual work to high-prestige intellectual work.
Keypunch operators were overwhelmingly women, but skilled programming was never substantially female. The obsolescence of "secretarial programming" (ie., retyping, keypunching, etc.) is the principle cause of the gender shift. Gender ratio in "formal programming" has always been ~4:1 M:F, including today.
Given now ~two decades of affirmative action for women getting into technology, and many high-status "professional industries" now dominated by women, the idea that the best explanation of this ratio is 70s/80s culture is implausible.
What we have seen, instead, is that as women are more free to choose professions the percentage of women's involvement drops.
I appreciate the rose-tinted, high-agency historical take, but I think the factors that led to computer science/programming becoming male-dominated were largely external to and independent of the preferences of women themselves.
Has only one translation into assembly. The programming language is well defined (or it should be). If you try to do
float x = '3.1'; you will get an error
However, the human language is not a programming language. It's open to interpretation
"create a variable x and assign it 3.1" is not a well defined programming instruction.
Is x a number or a string? If it's a number, what's the precision. Etc.
might a compiler turn "float x = 3.1;" into no instructions at all in some situations? So it has at least 2 possible translations into assembly depending on the context.
And "code a to-do app" has infinite possible compilations. That's exactly my point. If C instructions already have multiple compilations that could end up in bugs, why make it even more complex?
After all programming is not that complicated, are we really getting enough benefits by going up in the abstraction layer?
"Please send an email with subject XYZ to recipient ABC@somehere with this body AAA"
You can enter this as is on an Workato or Boomi agentic workflow.
For plenty of people this is how programming looks like in 2026.
Also your example has multiple translations into Assembly, depending on the optimizations levels, and where the statement happens to be located, it might even be part of auto vectorisation, or completely thrown away.
Loading a float value of 3.1 does not have only one translation into assembly. On Godbolt, flipping through various ARM 32-bit compilers, I define a function that returns 3.1 as a float:
float constant(void) {
return 3.1f;
}
And can get a handful of different results. I trimmed the function setup and teardown to simplify things.
Option 1 (loading high 16 bits and low 16 bits, then moving to fp register):
Except, the lived experience today is that I don’t need to program to do my job anymore, and I say this as an engineer with almost 30 years of experience.
If you can't see the difference between a compiler and an LLM then that's on you.
LLMs are a game changer in a completely different way than compilers. With compilers there is a (roughly, barring optimizations) 1:1 correspondence between input and output. With LLMs you take an idea and it will drive the whole thing from the beginning all the way to the end.
This is unlike anything that we've done so far. It's also strange to focus on programming: LLMs are coming for all information related jobs. If your job is somehow described as 'staring at a screen' then that job is on the line, if not sooner, than later.
Only for those not up to date with modern compilers and language runtimes.
The 1:1 is long gone, that is the UNIX K&R C days.
Modern compilers are full of heuristics, PGO driven optimizations, machine learning compiler passes, JIT compilers, and various kinds of GC implementations, the time of 1:1 mappings is long gone.
Even with optimizations, if you keep your backend same same code with same flag will return identical binary.
Same query to same AI, at different times of day will might not return the same answer. For example I wrote some docs for a class that had 14 methods. So I asked for autocomplete docs in 2 methods, and it copied other methods well. Then I asked to do the same task for 2 more methods and it fucked up, requiring manual edits.
"With LLMs you take an idea and it will drive the whole thing from the beginning all the way to the end."
Well if you think that's what it's doing - that's on you.
For gosh sakes, start with Claude Shannon's 'noisy channel problem' and consider why the notion of idea -> program is a fallacy.
That's for the Wix, Lovable and Shopify - wherein AI is only a component, and where the conditions are highly constrained.
To manage the output in detail, we need abstractions ... which do not exist.
Code -> Machine Instructions is not a noisy channel - it's deterministic.
Idea -> Code is theoretically not possible at any scale in a stable scenario because it's not deterministic, it won't make 'what you want' - then you have to spend a Million Mythical Man Hours to get it to do what you want.
Given that only a small portion of a developers job was ever 'writing code' in the first place - and that we write on average a fairly small number of 'usable lines of code' per day, the 'coding' was never it.
Research, prototypes, corners cases, help, bug fixes, ideation - so many ways it's powerful ... but not like a compiler.
Ignoring AI is like ignoring the industrial revolution, but AI is something very different than.
Also while some jobs are going to go - software hiring is up, not down - that should be a clue.
> With compilers there is a (roughly, barring optimizations) 1:1 correspondence between input and output.
This is repeated in a lot of comments here but hasn't really been true for a while. I remember, c. 2010, Kenton Varda complaining to Google's internal compiler team about how it generated some particularly non-intuitive assembly code out of the protobuf generated code, and the response was "Yeah everything is adaptive optimization now. Benchmark it and give us a profile and we'll put it in the compiler test suite. Trying to reason about what the compiler is doing and micro-optimize accordingly hasn't worked since the mid-90s."
I do think that LLMs are a step change in how we program computers, but the main step change is that the source language is now English, which opens up programming to a wider market accordingly. And this'll come with all the downsides of English: the ambiguity, lack of precision, multiple meanings, and so on. If you try to recover that control over what the computer generates, you end up reinventing computer science. (Which isn't that far off from how I use LLMs to program: anything that has widely accepted "best practices", I'll just let the LLM do, but if there's anything novel or requiring high-precision, I'll tell it "leave that function body blank; here are the inputs and outputs to the rest of the program; I will fill in the algorithm details myself.")
I also think that people are underselling the extent to which compilers were a step change to previous practices of programming. For someone accustomed to C, try doing register allocation or inlining yourself; you will suck at it, and it will take up the vast majority of your head space that could be spent on better things. For someone accustomed to a garbage-collected language like Python, try doing manual memory allocation and object ownership yourself; you will suck at it, and it will take up the vast majority of your head space that could be spent on better things.
Doesn't 1:1 correspondence between input and output just mean the compiler output is deterministic. There is no requirement that the output is machine code. For example cfront [1] was a complier whose output was C.
To me that points to the real the step change in LLMs. They are not deterministic and they always give a result to any query. Even if the query is invalid, missing data, or has no possible logically correct answer, you still get a result.
That totally misses the point. No matter how surprising the output of the compiler's adaptive optimiser, its observable behaviour (except speed) will be the same. That is clearly not true of LLMs.
That totally misses the point. No matter how surprising the output of the compiler's adaptive optimiser, the observable behaviour (except speed) of the program, when run, will be the same. That is clearly not true of LLM output.
Thats actually exactly on point; thing is, are programs deterministic? It depends; one can argue that any speculative execution pipeline cannot be truely deterministic from a timing perspective; its not an issue for a compiler, but it is for many applications. Gcc optimization flags were notorious to expose both compiler defects and non-deterministic code.
An LLM is a stochacstic system. With enough rounds, its undistinguishable from an emulated deterministic one, if you consider a delta greater than zero. Oh and each implementation/iteration give you the same determinism guarantees :)
> With compilers there is a (roughly, barring optimizations) 1:1 correspondence between input and output.
Maybe if you are using a compiler to provider a portable assembler (i.e. C) where ~1:1 mapping is the whole point. But in that case you'd be actually be using assembler instead in a world where all CPUs were the same.
That is very narrow view, though. Often — and I'd say most often — people use compilers so they can think in higher levels of abstraction, like SQL. Taking SQL and adding millions or billions of additional keywords doesn't really change anything with respect to the concept. Its still the same thing at the end of the day, even of those millions/billions of additional keywords are much more powerful than a small, restricted set of keywords.
Whenever I read these arguments, it seems to me like folks are talking past each other because programmers tend to fall into two camps.
Those who spend time thinking about a problem, then writing design notes, specifications, and test plans, and focus on the implementation last. For these people, AI agents primarily act like an extension to their existing toolchain, and thus like the analogy of "AI as the new compiler".
The other side are people who don't like writing specifications and such, and rather prefer to sit down figure things out as they start coding. For them, an agent feels radically different from a compiler.
In both instances the AI agent is still the same tool, with the same real-world capabilities and limitations. It is not like one camp is blind, they just have very different workflows.
It also seems to me like many in the "sit down and code" camp then slowly figure out that doing some planning ahead of time helps them get better results, and they see this as another AI-led paradigm shift, when in reality it is how many other programmers have worked for decades.
Everyone in this thread is being pedantic about what optimization is but missing the point that code is a precise description of some virtual machine that is realized with near perfect accuracy by the compiler. Yeah you don't know exactly what the silicon is doing with a modern compiler but you do know that the final result of the program for any input will be defined by whatever the correct interpretation of the program is, as if the structure the programming language implies actually existed.
LLMs are not this, and they cannot be this because it is their ability to operate on vague instructions that make them as powerful as they are. They can take an imprecise natural language description of a process and realize it as a process in a programming language. The problem is that understanding and manipulating the precise problem description is your job as a software engineer. The LLM can and will make its best attempt based on what exists in its training data, but it cannot know what is the precise behavior that actually fulfills goals and I think, contrary to the parent article, it cannot determine where the edges are to ask you with enough certainty that you will be able to take your hands completely off the wheel.
I think the nature of LLMs also explains why it is good at the verticals it is good at. Porting is an extremely well defined, replicate the behavior on another platform. There are far fewer vagueries in that. Game dev is not extremely well defined, but the consequences of imprecision do not have a lot on the line. Furthermore, games are pretty self-contained, so there's not a lot of guessing about what could happen or what the behavior of a counterparty system could be. With some pretty big exceptions, it is all there for the LLM to see in C++ (or whatever).
Not true, never was true. You can't write real code for either Linux or Windows without venturing into what C calls undefined behaviour, but Linux and Windows don't.
So true. I believe the programming harness is only the first of many many harnesses that will soon displace all knowledge workers. The LLMs already contain all the weights and facts. They just need loops to get results out.
It’s basically moving from chat (conversational copiloting) to result driven agent harnesses, exactly what happened with code. To us.
The reason it happened so fast with code is because:
- anthropic is a software company and scratching their own itch
- open source codebases in training input
- vast amount of books and docs too
- real-time linters and tests provide confident feedback for closing the loop quickly
Other occupations will want to limit their public knowledge sharing (sadly) and avoid formal specification / standardization of their unique workflows. And definitely avoid equivalents of realtime linters and tests.
We do pretty much just use compilers now though. The last time I read dissassembly to fix an issue was at least a decade ago. Even bytecode I rarely look at.
So you're saying that we'll still be coding, but it will be through talking to our agents and only occasionally we will look at generated source? That seems like a pretty big change still.
Yes, it's a huge change. For me, it has already happened, and I like it. Since the end of September, agents have made about 960 commits to a project of mine, and I haven't written or read a line of its code.
About 6 months ago, I mostly stopped reading the code. And since a few weeks, I also stopped testing the changes manually. Before, it felt like I was the agents' QA department. Now, each agent shows me its change running in the app, in a short narrated screen recording. A fix takes me 30 seconds to watch. When something is off, I say what, and the agent goes another round.
I have a pretty negative opinion about LLM's coding abilities (and predictions about how they will improve). But I don't get a lot out of this type of argument. Compilers created a perfect, deterministic, provable abstraction so that we could have 99% of developers no longer know how assembly works and not suffer any consequences. Humans don't have to give up any control or make any quality compromises to deploy them as widely as possible.
If the author is contending that AI models will improve to a point that they actually make no mistakes while coding, and have that same level of reliability, then they're on exactly the same side as AI doom trolls just wearing a different costume.
> In 1954, IBM said FORTRAN would virtually eliminate coding and debugging.
Only because Fortran was viewed as transcribing mathematical notation, which wasn’t considered coding. Coding originally referred to having to work with numeric machine codes. Programming languages like Fortran removed the need for having to deal with how to encode the program for a specific machine, and with human errors in that encoding process (debugging). It didn’t mean abandoning formal specifications that you can reason about with a high degree of precision.
> the concept of notation as a tool of thought, coined a quarter century later by IBM fellow Iverson
Precedence for "the concept of notation as a tool of thought" would have to go to Leibniz, 300 years earlier, in The Method of Mathematics:
> "Whence it is manifest that if we could find characters or signs appropriate for expressing all our thoughts as definitely and as exactly as arithmetic expresses numbers or geometric analysis expresses lines, we could in all subjects in so far as they are amenable to reasoning accomplish what is done in Arithmetic and Geometry.
> "For all inquiries which depend on reasoning would be performed by the transposition of characters and by a kind of calculus, which would immediately facilitate the discovery of beautiful results. For we should not have to break our heads as much as is necessary today, and yet we should be sure of accomplishing everything the given facts allow.
> "Moreover, we should be able to convince the world what we should have found or concluded, since it would be easy to verify the calculation either by doing it over or by trying tests similar to that of casting out nines in arithmetic. And if someone would doubt my results, I should say to him: "Let us calculate, Sir," and thus by taking to pen and ink, we should soon settle the question."
First, it's a bad comparison. Compilers and LLMs/Agents are not remotely comparable.
Second, the example used for 2031 is already outdated in 2026. There is almost no reason to even use PRs anymore [1, 2], and the example question should be easily answered by an agent that has enough context and planning.
Must be different from the rest of the market as well, since most software companies report that LLMs generate 80-95% of their code (including frontier model providers who are reporting > 90% of the code they produce being generated by LLMs).
I do think most of this is a skill issue. I don't mean your personal skills; I mean the misuse or non-use of agentic skills. The majority of issues with code synthesis and review can be repaired by giving the agent enough guardrails, context and skills to use.
Yeah, after some thinking I am starting to realize that Linus' take of AI being like compilers is kind of true.
Vibecoding maintainable code requires providing the LLM a specification. It's still coding, but you now have the liberty of just providing the spec as opposed to worrying about syntax. Since they are non deterministic and love to cheat you still need to review though
I also looked into the history of software[1] thought a while ago, and the fact is that, setting aside the determinism of compilers, ultimately no matter what tool comes out, programmers will keep arguing about how software should be built
Looking at history, I think LLMs will settle down too. Because, in fact, if you look at the history of software thought, there were actually many people who would have welcomed LLMs.
The thing I find least compelling about these “AI is a compiler” arguments is that they require dissonance or magical thinking where somehow the AI is good enough to write and review all the code to the point where you don’t even need to look at it, but at the same time the LLM needs an experienced software engineer to feed it the prompts.
Sufficiently precise spec is called code. It is the compiler story all over again.
Notably absent from the timeline is visual programming, or Rapid Application Development, think Visual Basic. It was all the rage in the 90s, and for some reason, we don't hear much about it today. We used to make fun of Visual Basic and the people using it back in the days, but the reality is that people with little skill could do something useful. Reminds you of something?
Honestly, I don't really understand why we write so much code today when a lot of use cases can be taken care of using templates and moving boxes into place, "low code" and "no code" never really seem to have taken off as much as they could have. That reliance on code was a boon for LLMs by the way, as text is the thing they have the easiest time working with.
My theory is that every project is unique in some way. As in, my CRUD has a little something that makes it different from other CRUD, and that's why it is valuable. You can't use an off the shelf component because no suitable component exists, and you want code because with code, you can express what you want with precision.
But it is also what limits AI. AI is very good at doing what other people did, but you don't want to do like everyone else, so you have to be very precise in what you are asking, and the most precise way of asking things is to write code.
However, when you really want what others did, then AI is really effective: rewrites, ports, decomp, etc... But this is not really programming, it is at best a translation job, and it will never be as good as the original. To make it better, you need to inject something unique, and for that, the best way to do it is with code. Like the translator of a novel who injects elements of his own culture that go beyond the work of the original author, to make up for what can't be literally translated.
> But it is also what limits AI. AI is very good at doing what other people did, but you don't want to do like everyone else, so you have to be very precise in what you are asking, and the most precise way of asking things is to write code.
I think Entertainment creatives have a similar field to software developers. The average exceptional creative could express something completely unique precisely but will actually have a tough to impossible time reaching anyone given the levers a creative that uses remixes at the edge of fair use has to hold the audience attention. It is like asking someone to give up multiple addictions at once (and while concentrating more than they are used to.)
In HN circles you don't hear about it, yet it is all over the place in enterprise.
You also don't hear much about VB specifically, because of evolution, nowadays the modern equivalent of Visual Basic and Delphi, are OutSystems, Power Platform, Workato, Boomi, Sitecore AI, Optimizely Opal,...
It comes from the mentality and quality of the people in the industry imo.
If you go to squarespace domain management website you will see it is utter garbage in terms of experience. It doesn’t have to be like this but the people that make it just aren’t good enough or don’t care.
Unfortunately it is same with blockchain and LLMs soon.
Blockchain can be super useful but there are hard problems that need to be solved and people that vacuum the investment up just aren’t interested in solving problems.
I see the same problem with LLMs because big companies want to pump horror stories and vibe coding instead of code review or security review or cost stabilization/profitability etc.
The people that behave this was just don’t have a chance of long term success imo.
These technologies could have been so much better if they were developed by different people
In 2031 you single-handedly maintain 173 million lines of code making up a simple crud app. You're a good programmer, but the previous guy wasn't, and now there's too much code to make it any smaller. Not even your vastly superhuman LLM feels confident to delete any of the code. So the two of you slog along, keeping the thing alive.
I'm really not worried about this scenario at all. I mean yes, it will be possible for bad programmers to build 173 million line monstrosities held together with duct tape and bailing wire, and certainly these things will exist. And it's also possible that good programmers will be paid by idiots to maintain said monstrosities with no agency to actually fix the root cause. Both of those things will happen.
But a good programmer given agency to solve the higher order problem will always have a path to rewrite, because any "simple CRUD app" exists to serve human purposes, and in order to meet those needs the human interface need to be legible, and to be legible there have to be tight enough inputs and outputs that you can create a parallel implementation without the incidental complexity.
Now you might say this won't be the case for large multi-party distributed systems, and that is true, but that is also true today where all manner of insane cruft and non-sensical logic and workflows exist. But even where things appear totally intractable due to legacy requirements and conflicting logic, there still is a human backstop where if the pain is big enough, any process can be fixed. In practice competing interests may prevent such fixes for a long time, but that is political problem not a technical problem, and it's not inevitable as things can flip very quickly due to the dynamics of human attention and power.
When I went into software engineering in the early 1980s, several people told me that had no future, since programmers would soon be automated away.
I ignored that, in part because I had no other skill I wanted to do 5 days a week, and it's of course been incredibly rewarding.
This time it definitely is different, and maybe the profession moves into a new and very different era. If SWEs will hit harder times and job losses, I don't think we have much standing to complain, given how many professions we have automated away during the last 50 years...
103 comments
[ 2.4 ms ] story [ 26.3 ms ] threadInteresting Read.
We are talking about the separation of these roles going away. If you disagree or can't see that happening, that's fine. Nobody gonna waste their time convincing you.
AI generation isn't an abstraction because you have to wrestle with the nitty-grittys of the output.
And that output is what you retain.
You can't clone someone's repository of nothing but prompts and rebuild from scratch.
Abstraction means that I trust the toolchains so much that I think of the source code as the software, and in the right kind of environment/ecosystem such as open source distros, I can actually ship that to the downstream users as my product.
Abstractions are based on very detailed and rigid logical contracts.
This is in contrast with general purpose agents like Meta Muse that make some amusing and horrifying errors. These kinds of agents don't have the interfaces and guardrails that were built for human coders. They use a lot of ad hoc screen scraping and guessing at what APIs do.
That's also why Apple and Google haven't shipped fully general purpose agents that use their new app tool calling interfaces yet. For example Google only released their Gemini agent that uses AppFunctions to enterprise customers. Presumably because MDM tools can be used to monitor agents' actions.
I've been doing a lot of devops lately, writing tons of templates, configs, scripts in like 3 programming languages, wrestling with 'cloud-based' constructs - with LLMs ofc.
LLMs make all this work easy, otherwise it'd be borderline impossible.
It's all BS. Hosting a CRUD app should be an executable for the server (written in boring lang/lib of my choice) + an SQLite db. Of course it's a bit more than that, but not by much.
There are wonderful IDEs and tools out there which help humans do the task, and good design keeps the complexity under control.
LLMs on the other hand both are sources of the mess and solutions to it. Without good tooling you'll be much more inclined to reach for an LLM.
This is exactly it. We all know and envy that guy who can bang out a script on demand that makes any task simple, and we also know we'll never be that guy.
LLMs are superhuman knowledge remixers. And that's exactly what we need to deal with a lot of software development tasks.
Given now ~two decades of affirmative action for women getting into technology, and many high-status "professional industries" now dominated by women, the idea that the best explanation of this ratio is 70s/80s culture is implausible.
What we have seen, instead, is that as women are more free to choose professions the percentage of women's involvement drops.
I appreciate the rose-tinted, high-agency historical take, but I think the factors that led to computer science/programming becoming male-dominated were largely external to and independent of the preferences of women themselves.
This sounds exactly like all my Tuesday mornings this year, except that I wasn't at work at 7:40
I _want_ to write code for my job.
Unfortunately, this is exactly the direction the industry is heading.
A compiler takes a programming language as input
float x = 3.1;
Has only one translation into assembly. The programming language is well defined (or it should be). If you try to do
float x = '3.1'; you will get an error
However, the human language is not a programming language. It's open to interpretation "create a variable x and assign it 3.1" is not a well defined programming instruction. Is x a number or a string? If it's a number, what's the precision. Etc.
It is not bad per se, but it comes with huge downsides. And the more abstract the language the messier it gets.
I just don't think that the gains in coding speed we get from using AI + human language as outweigh the downsides of having poorly defined programs
Your point, by your own words:
> However, the human language is not a programming language. It's open to interpretation
Is that a language is not a programming language if it is open to interpretation. It is a point that is demonstrably wrong.
You can enter this as is on an Workato or Boomi agentic workflow.
For plenty of people this is how programming looks like in 2026.
Also your example has multiple translations into Assembly, depending on the optimizations levels, and where the statement happens to be located, it might even be part of auto vectorisation, or completely thrown away.
Option 1 (loading high 16 bits and low 16 bits, then moving to fp register):
Option 2 (hardcoding the hex value into program text and loading it into r0 via r3, no specific fp conversion): Option 3 (similar to 2, but using the load for SIMD and FP registers):Bad analogy. The case with AI is not the same.
LLMs are a game changer in a completely different way than compilers. With compilers there is a (roughly, barring optimizations) 1:1 correspondence between input and output. With LLMs you take an idea and it will drive the whole thing from the beginning all the way to the end.
This is unlike anything that we've done so far. It's also strange to focus on programming: LLMs are coming for all information related jobs. If your job is somehow described as 'staring at a screen' then that job is on the line, if not sooner, than later.
The 1:1 is long gone, that is the UNIX K&R C days.
Modern compilers are full of heuristics, PGO driven optimizations, machine learning compiler passes, JIT compilers, and various kinds of GC implementations, the time of 1:1 mappings is long gone.
Same query to same AI, at different times of day will might not return the same answer. For example I wrote some docs for a class that had 14 methods. So I asked for autocomplete docs in 2 methods, and it copied other methods well. Then I asked to do the same task for 2 more methods and it fucked up, requiring manual edits.
Well if you think that's what it's doing - that's on you.
For gosh sakes, start with Claude Shannon's 'noisy channel problem' and consider why the notion of idea -> program is a fallacy.
That's for the Wix, Lovable and Shopify - wherein AI is only a component, and where the conditions are highly constrained.
To manage the output in detail, we need abstractions ... which do not exist.
Code -> Machine Instructions is not a noisy channel - it's deterministic.
Idea -> Code is theoretically not possible at any scale in a stable scenario because it's not deterministic, it won't make 'what you want' - then you have to spend a Million Mythical Man Hours to get it to do what you want.
Given that only a small portion of a developers job was ever 'writing code' in the first place - and that we write on average a fairly small number of 'usable lines of code' per day, the 'coding' was never it.
Research, prototypes, corners cases, help, bug fixes, ideation - so many ways it's powerful ... but not like a compiler.
Ignoring AI is like ignoring the industrial revolution, but AI is something very different than.
Also while some jobs are going to go - software hiring is up, not down - that should be a clue.
This is repeated in a lot of comments here but hasn't really been true for a while. I remember, c. 2010, Kenton Varda complaining to Google's internal compiler team about how it generated some particularly non-intuitive assembly code out of the protobuf generated code, and the response was "Yeah everything is adaptive optimization now. Benchmark it and give us a profile and we'll put it in the compiler test suite. Trying to reason about what the compiler is doing and micro-optimize accordingly hasn't worked since the mid-90s."
I do think that LLMs are a step change in how we program computers, but the main step change is that the source language is now English, which opens up programming to a wider market accordingly. And this'll come with all the downsides of English: the ambiguity, lack of precision, multiple meanings, and so on. If you try to recover that control over what the computer generates, you end up reinventing computer science. (Which isn't that far off from how I use LLMs to program: anything that has widely accepted "best practices", I'll just let the LLM do, but if there's anything novel or requiring high-precision, I'll tell it "leave that function body blank; here are the inputs and outputs to the rest of the program; I will fill in the algorithm details myself.")
I also think that people are underselling the extent to which compilers were a step change to previous practices of programming. For someone accustomed to C, try doing register allocation or inlining yourself; you will suck at it, and it will take up the vast majority of your head space that could be spent on better things. For someone accustomed to a garbage-collected language like Python, try doing manual memory allocation and object ownership yourself; you will suck at it, and it will take up the vast majority of your head space that could be spent on better things.
It has also been addressed, already in the comment you are replying to as well as countless comments below.
To me that points to the real the step change in LLMs. They are not deterministic and they always give a result to any query. Even if the query is invalid, missing data, or has no possible logically correct answer, you still get a result.
[1] https://en.wikipedia.org/wiki/Cfront
An LLM is a stochacstic system. With enough rounds, its undistinguishable from an emulated deterministic one, if you consider a delta greater than zero. Oh and each implementation/iteration give you the same determinism guarantees :)
Maybe if you are using a compiler to provider a portable assembler (i.e. C) where ~1:1 mapping is the whole point. But in that case you'd be actually be using assembler instead in a world where all CPUs were the same.
That is very narrow view, though. Often — and I'd say most often — people use compilers so they can think in higher levels of abstraction, like SQL. Taking SQL and adding millions or billions of additional keywords doesn't really change anything with respect to the concept. Its still the same thing at the end of the day, even of those millions/billions of additional keywords are much more powerful than a small, restricted set of keywords.
Those who spend time thinking about a problem, then writing design notes, specifications, and test plans, and focus on the implementation last. For these people, AI agents primarily act like an extension to their existing toolchain, and thus like the analogy of "AI as the new compiler".
The other side are people who don't like writing specifications and such, and rather prefer to sit down figure things out as they start coding. For them, an agent feels radically different from a compiler.
In both instances the AI agent is still the same tool, with the same real-world capabilities and limitations. It is not like one camp is blind, they just have very different workflows.
It also seems to me like many in the "sit down and code" camp then slowly figure out that doing some planning ahead of time helps them get better results, and they see this as another AI-led paradigm shift, when in reality it is how many other programmers have worked for decades.
LLMs are not this, and they cannot be this because it is their ability to operate on vague instructions that make them as powerful as they are. They can take an imprecise natural language description of a process and realize it as a process in a programming language. The problem is that understanding and manipulating the precise problem description is your job as a software engineer. The LLM can and will make its best attempt based on what exists in its training data, but it cannot know what is the precise behavior that actually fulfills goals and I think, contrary to the parent article, it cannot determine where the edges are to ask you with enough certainty that you will be able to take your hands completely off the wheel.
I think the nature of LLMs also explains why it is good at the verticals it is good at. Porting is an extremely well defined, replicate the behavior on another platform. There are far fewer vagueries in that. Game dev is not extremely well defined, but the consequences of imprecision do not have a lot on the line. Furthermore, games are pretty self-contained, so there's not a lot of guessing about what could happen or what the behavior of a counterparty system could be. With some pretty big exceptions, it is all there for the LLM to see in C++ (or whatever).
It’s basically moving from chat (conversational copiloting) to result driven agent harnesses, exactly what happened with code. To us.
The reason it happened so fast with code is because: - anthropic is a software company and scratching their own itch - open source codebases in training input - vast amount of books and docs too - real-time linters and tests provide confident feedback for closing the loop quickly
Other occupations will want to limit their public knowledge sharing (sadly) and avoid formal specification / standardization of their unique workflows. And definitely avoid equivalents of realtime linters and tests.
So you're saying that we'll still be coding, but it will be through talking to our agents and only occasionally we will look at generated source? That seems like a pretty big change still.
About 6 months ago, I mostly stopped reading the code. And since a few weeks, I also stopped testing the changes manually. Before, it felt like I was the agents' QA department. Now, each agent shows me its change running in the app, in a short narrated screen recording. A fix takes me 30 seconds to watch. When something is off, I say what, and the agent goes another round.
If the author is contending that AI models will improve to a point that they actually make no mistakes while coding, and have that same level of reliability, then they're on exactly the same side as AI doom trolls just wearing a different costume.
Only because Fortran was viewed as transcribing mathematical notation, which wasn’t considered coding. Coding originally referred to having to work with numeric machine codes. Programming languages like Fortran removed the need for having to deal with how to encode the program for a specific machine, and with human errors in that encoding process (debugging). It didn’t mean abandoning formal specifications that you can reason about with a high degree of precision.
Precedence for "the concept of notation as a tool of thought" would have to go to Leibniz, 300 years earlier, in The Method of Mathematics:
> "Whence it is manifest that if we could find characters or signs appropriate for expressing all our thoughts as definitely and as exactly as arithmetic expresses numbers or geometric analysis expresses lines, we could in all subjects in so far as they are amenable to reasoning accomplish what is done in Arithmetic and Geometry.
> "For all inquiries which depend on reasoning would be performed by the transposition of characters and by a kind of calculus, which would immediately facilitate the discovery of beautiful results. For we should not have to break our heads as much as is necessary today, and yet we should be sure of accomplishing everything the given facts allow.
> "Moreover, we should be able to convince the world what we should have found or concluded, since it would be easy to verify the calculation either by doing it over or by trying tests similar to that of casting out nines in arithmetic. And if someone would doubt my results, I should say to him: "Let us calculate, Sir," and thus by taking to pen and ink, we should soon settle the question."
-- https://www.rbjones.com/rbjpub/philos/classics/leibniz/meth_...
Keep in mind that Leibniz invented the notation we still use for calculus today (as well as calculus itself), so this wasn't purely abstract for him.
First, it's a bad comparison. Compilers and LLMs/Agents are not remotely comparable.
Second, the example used for 2031 is already outdated in 2026. There is almost no reason to even use PRs anymore [1, 2], and the example question should be easily answered by an agent that has enough context and planning.
1. https://r.rich/blog/ai-native-change-management 2. https://ampcode.com/notes/thats-not-soc-2-compliant
I do think most of this is a skill issue. I don't mean your personal skills; I mean the misuse or non-use of agentic skills. The majority of issues with code synthesis and review can be repaired by giving the agent enough guardrails, context and skills to use.
Vibecoding maintainable code requires providing the LLM a specification. It's still coding, but you now have the liberty of just providing the spec as opposed to worrying about syntax. Since they are non deterministic and love to cheat you still need to review though
Looking at history, I think LLMs will settle down too. Because, in fact, if you look at the history of software thought, there were actually many people who would have welcomed LLMs.
[1]https://www.makonea.com/en-US/blog/people-who-build-things-t...
In 2031: Why on earth not?
Sufficiently precise spec is called code. It is the compiler story all over again.
Notably absent from the timeline is visual programming, or Rapid Application Development, think Visual Basic. It was all the rage in the 90s, and for some reason, we don't hear much about it today. We used to make fun of Visual Basic and the people using it back in the days, but the reality is that people with little skill could do something useful. Reminds you of something?
Honestly, I don't really understand why we write so much code today when a lot of use cases can be taken care of using templates and moving boxes into place, "low code" and "no code" never really seem to have taken off as much as they could have. That reliance on code was a boon for LLMs by the way, as text is the thing they have the easiest time working with.
My theory is that every project is unique in some way. As in, my CRUD has a little something that makes it different from other CRUD, and that's why it is valuable. You can't use an off the shelf component because no suitable component exists, and you want code because with code, you can express what you want with precision.
But it is also what limits AI. AI is very good at doing what other people did, but you don't want to do like everyone else, so you have to be very precise in what you are asking, and the most precise way of asking things is to write code.
However, when you really want what others did, then AI is really effective: rewrites, ports, decomp, etc... But this is not really programming, it is at best a translation job, and it will never be as good as the original. To make it better, you need to inject something unique, and for that, the best way to do it is with code. Like the translator of a novel who injects elements of his own culture that go beyond the work of the original author, to make up for what can't be literally translated.
I think Entertainment creatives have a similar field to software developers. The average exceptional creative could express something completely unique precisely but will actually have a tough to impossible time reaching anyone given the levers a creative that uses remixes at the edge of fair use has to hold the audience attention. It is like asking someone to give up multiple addictions at once (and while concentrating more than they are used to.)
You also don't hear much about VB specifically, because of evolution, nowadays the modern equivalent of Visual Basic and Delphi, are OutSystems, Power Platform, Workato, Boomi, Sitecore AI, Optimizely Opal,...
If you go to squarespace domain management website you will see it is utter garbage in terms of experience. It doesn’t have to be like this but the people that make it just aren’t good enough or don’t care.
Unfortunately it is same with blockchain and LLMs soon.
Blockchain can be super useful but there are hard problems that need to be solved and people that vacuum the investment up just aren’t interested in solving problems.
I see the same problem with LLMs because big companies want to pump horror stories and vibe coding instead of code review or security review or cost stabilization/profitability etc.
The people that behave this was just don’t have a chance of long term success imo.
These technologies could have been so much better if they were developed by different people
Hey that was about my last Tuesday.
--
In 2031 you single-handedly maintain 173 million lines of code making up a simple crud app. You're a good programmer, but the previous guy wasn't, and now there's too much code to make it any smaller. Not even your vastly superhuman LLM feels confident to delete any of the code. So the two of you slog along, keeping the thing alive.
But a good programmer given agency to solve the higher order problem will always have a path to rewrite, because any "simple CRUD app" exists to serve human purposes, and in order to meet those needs the human interface need to be legible, and to be legible there have to be tight enough inputs and outputs that you can create a parallel implementation without the incidental complexity.
Now you might say this won't be the case for large multi-party distributed systems, and that is true, but that is also true today where all manner of insane cruft and non-sensical logic and workflows exist. But even where things appear totally intractable due to legacy requirements and conflicting logic, there still is a human backstop where if the pain is big enough, any process can be fixed. In practice competing interests may prevent such fixes for a long time, but that is political problem not a technical problem, and it's not inevitable as things can flip very quickly due to the dynamics of human attention and power.
I ignored that, in part because I had no other skill I wanted to do 5 days a week, and it's of course been incredibly rewarding.
This time it definitely is different, and maybe the profession moves into a new and very different era. If SWEs will hit harder times and job losses, I don't think we have much standing to complain, given how many professions we have automated away during the last 50 years...