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.
Compilers were first called automatic coders.
The word compiling referred to something more like linking: producing an image containing multiple library routines. In other words, similar to compiling an anthology of works into a book.
After compilers, the word coding to changed to writing program code in any language.
Because the tooling for automatic coding also compiled the bits of code into a larger image, the term compiler/compiling came to be used for the coding part also.
While the terms reshuffled, the concrete reality was simply that people worked less in assembly language, not that fewer people worked or that programming ended.
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.
In [1]: def f(x: int) -> float:
...: return f"the input was {x}"
In [2]: f(b'deadbeef')
Out[2]: "the input was b'deadbeef'"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
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.
People tend to overestimate change in short term, and underestimate it in long term. AI hasn't replaced programmers yet, but I believe it will replace most white collar workers in 20 years.
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.
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 to deal 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.
I also want to take the opportunity to point out the concept of notation as a tool of thought, coined a quarter century later by IBM fellow Iverson in his Turing Award lecture: https://www.recurse.com/blog/58-paper-of-the-week-notation-a...
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
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.
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.
float constant(void) {
return 3.1f;
}
Option 1 (loading high 16 bits and low 16 bits, then moving to fp register):
movw r3, #26214
movt r3, 16454
vmov s15, r3
vmov.f32 s0, s15
ldr r3, .L3
mov r0, r3
.L3:
.word 1078355558
vldr.32 s0, .L3
.L3:
.word 10783555581) that LLMs can do existing white collar work well once some (possibly significant amount of) work is done to fully plug them in and get specifications settled.
2) That all white collar workers will be replaced by LLMs.
Perhaps a typo, but I don't think (1) implies (2).
In my ~20 year career in software, I've never once gotten adequate specifications. I honestly don't feel threatened.
I think the latter would not occur under the current state of AI/LLMs, but the rapid pace of growth gives me pause.
Opus 5.5 produces code far better than 95% of professional devs, and it only stands to get “worse” from here on out.
Quite where this leaves any of the people in these information processing jobs is anyone’s guess.
I would agree that it still does, but much less often than it did in the past. Compare what it produces today vs what it produced one year ago and the improvement is staggering.
(I'm talking across the whole LLM spectrum here, not really Opus in particular).
And AI doesn't have to replace literally 100% of the workforce to have a catastrophic economic impact.
If AI takes 50% of the jobs instead of 100% the economic destruction is roughly the same in the sense that you will already hit calamitous society-level tipping points long before you replace literally everyone.
For context the Great Depression was "only" 25% unemployment.
It still requires a lot of work and care to leverage correctly and it's a moving target.
But it's quite impressive
It absolutely does in some ways, but how confident are you that this will continue to be the case indefinitely?
What has filled me with a low-key but growing existential dread over the past year isn't the snapshot of where LLMs are right now, but the continual rate of improvement, particularly since approximately November 2025 to now.
Treat it like it’s got an inspired brilliant side, talk to it as if it has, and it will show it. If you talk to these things like they’re idiots they act like them - this is one of the most unfortunate aspects of the whole development.
I am seriously seeing it churn out well structured clean code solving problems that saying 95% of devs couldn’t do is being generous, to the humans.
I use all the latest and greatest Anthropic (and OpenAI) models, and interact with them probably on average 10h a day. I experiment with changing effort levels, with different ways of prompting and guardrailing, etc. Giving more instructions, giving less instructions. Doing heavy planning, just giving vague ideas.
I've done everything from fully vibe coding massive projects, to using LLMs regularly in my day job and reviewing every single line they produce.
Unless you are *really* on top of your agents, they inevitably end up writing an absolute mess. Not only does the code become impossible for humans to reason about very quickly, it actually becomes difficult for agents to reason about it. It turns into a total garbage in = garbage out situation.
Have you honestly reviewed a vibe coded project after it has been going for a while, even one written by current SOTA models, and thought "yep, this is great code"?
There is clearly a trick to coaxing these results, and a major factor is to treat the model like it is something you fully expect to get it right because it knows how to do it, not you micromanaging it into compliance.
when is it going to happen already? OpenAI says Astra is AGI. why hasn't your prediction already come to pass? it's not early, it's late, these companies owe $1.5T. It's time for your side to start explaining why exactly GPT 3 or 4 or 5 or Astra hasn't already caused this in the way it's been predicted over and over by the labs
Employers typically want their employees to do what’s expected from them. ;)
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.
i cannot type "make me an exploit based on whatever these diffs fixed" into a compiler and get usable output. and i cannot type "make me a budget, here is 6 months of credit card receipts" into a compiler and get a budget. etc.
Here are some suggestions,
Workato, Boomi, Sitecore AI, Optimizely Opal, Workfront AI...
You will naturally have to split the budget calculation in a few agentic nodes, and maybe a couple of tools.
i thought we were talking about compilers vs. llms.
Agentic programming tools are nothing other than the old ideas from UML code generation in a new package.
Better accept that in a few more model iterations, the code being generated is a matter of changing a markdown file.
This sentence from the article really stuck out to me.
> and you write the rule down so clearly that nobody (human or otherwise) has to guess again.
Writing rules, or steps, unambiguously in a high level language and having those statements translated to lower level languages, that ultimately get executed by a machine, is what compilers do.
All observable and defined side effects should be identical otherwise you have a compiler bug. Optimizations that are not generically semantics preserving may be used, but should only be used where the program is semantically identical for your use case otherwise you have incorrectly used the options available in your compiler.
Newer languages consider this to be a misfeature, and have taken pains to define far more of the language semantics outright, even if the definition is simply "This is a compile error" or "This is a panic." It's interesting that we're now going back the opposite way with LLMs, with their ability to generate code that does something for any natural-language prompt being a major selling point.
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.
start with opening up codex or whatever you use. type "make me a calculator app". get your calculator app in an hour or whatever.
it's fair to describe this process as taking an idea and getting a program.
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.
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 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).
jmclnx•55m ago
Interesting Read.
margalabargala•52m ago