Rendered at 13:08:10 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
rayiner 5 minutes ago [-]
[delayed]
kazinator 18 hours ago [-]
Nope; the compiler was supposed to end coding; when the word coding referred to taking an abstract program written on paper and translating it to machine code.
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.
plorkyeran 17 hours ago [-]
It's a nice example of a prediction being so correct that it later starts to sound retroactively incorrect.
1 hours ago [-]
GuB-42 18 hours ago [-]
> The spec and the tests become the source
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.
pjmlp 5 hours ago [-]
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,...
knowinow 17 hours ago [-]
> 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.)
ozgrakkurt 3 hours ago [-]
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
layer8 18 hours ago [-]
> 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 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.
> 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."
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.
mbil 18 hours ago [-]
> It’s 7:40 on a Tuesday morning in 2031, and you haven’t written a line of code yet. You probably won’t today, and that’s fine.
This sounds exactly like all my Tuesday mornings this year, except that I wasn't at work at 7:40
cbarrick 18 hours ago [-]
OP is describing a distopia.
I _want_ to write code for my job.
Unfortunately, this is exactly the direction the industry is heading.
solyin 18 hours ago [-]
I'm sure the people that rode horses as their job loved to ride horses. Ah well.
seanw444 18 hours ago [-]
People keep making these comparisons like they're equivalent. The whole point of AI is to replace the human factor. Horses being replaced by automobiles didn't remove the human factor. Humans continued to drive a different, non-organic vehicle for the following century.
pixl97 14 hours ago [-]
Don't worry, a lot of people laughed at Humans Need Not Apply came out in 2014. Way less of them are laughing now.
lubujackson 13 hours ago [-]
No, AI is meant to replaces the manual coding work. Without the human factor, you have a data center doing nothing. You still have to tell AI what to build. You still have to deal with reality affecting your business, with market changes and new features and translating asks into a product that serves multiple types of users.
Maybe we get rid of engineers and have really good product managers. Maybe we get rid of product managers and have really good product engineers. But we don't get rid of humans. There is a reason no (successful) company ever said "we finished the app, now fire all the engineers and collect money forever."
Software is never finished, only abandoned as the world passes it by.
rglullis 3 hours ago [-]
> without the human factor
Less and less humans will be needed to support these businesses.
> There is a reason no (successful) company ever said "we finished the app, now fire all the engineers and collect money forever."
1) software is very easy to get duplicated and commoditized. So the margins get tighter and tighter and companies with "finished software" will have less and less money to be collected. Big companies need constant reinvention not because customers need improvements, but to keep their lines going up in the chart.
Remember Skype before being bought by Microsoft? It was as close as I can imagine from being "finished". It could be run forever with a skeleton crew and they could be collecting a few millions of dollars forever for their service. Do you think that MS paid 7 BILLION USD because of the "finished" software?
andyferris 2 hours ago [-]
I’d say a business requiring ever fewer humans would, due to competition and similar dynamics, become a kind of commodity business producing ever reducing margins.
rglullis 2 hours ago [-]
Automation moves the bottleneck to the amount of available capital that can be deployed.
pjmlp 5 hours ago [-]
> There is a reason no (successful) company ever said "we finished the app, now fire all the engineers and collect money forever."
Never worked in the games industry, have you?
8 hours ago [-]
ultrarunner 18 hours ago [-]
This is fine until we reduce it all the way to "but I liked being a human"
goda90 18 hours ago [-]
You're the horse in this analogy.
dzhiurgis 11 hours ago [-]
FWIW horses are now transported in nice trailers and get fancy hairdresser treatments. Well played horses, well played.
maratc 4 hours ago [-]
The horse population in the US has dropped by more than 70% in the last 100 years (21M to 6.6M). In the same timeframe, the human population has increased 320% (105M to 320M), so the drop in "relative horses" is from 0.20 horse per human to 0.02 horse per human, or 90%.
How cool are you with the odds of your entire family surviving the next 100 years standing at about 10%?
bloak 4 hours ago [-]
> How cool are you with the odds of your entire family surviving the next 100 years standing at about 10%?
My entire family (for my natural interpretation of that expression) is aged over 20 so I don't expect any of them to survive the next 100 years.
I tend to support VHEMT anyway!
jacquesm 18 hours ago [-]
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.
nostrademons 18 hours ago [-]
> 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.
xw333 17 hours ago [-]
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.
> This is repeated in a lot of comments here but hasn't really been true for a while.
It has also been addressed, already in the comment you are replying to as well as countless comments below.
quietbritishjim 17 hours ago [-]
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.
aforwardslash 15 hours ago [-]
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 :)
topaz0 3 hours ago [-]
One can and does argue many disingenuous things, evidently.
17 hours ago [-]
rwyinuse 18 hours ago [-]
I agree. Programming was just a natural first problem to tackle, but the impact will not be limited there. If you give today's best model access to all the data sources and systems an average white collar worker has, it probably could do most of their job. But organizational change takes its time, systems need to be integrated into new AI tools and so on, so it will take a while.
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.
jvanderbot 18 hours ago [-]
You actually claimed two very different things.
1) 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).
bigfishrunning 18 hours ago [-]
> and get specifications settled.
In my ~20 year career in software, I've never once gotten adequate specifications. I honestly don't feel threatened.
pjmlp 5 hours ago [-]
Indeed, however thanks to the improvements in automation, from programming languages to cloud environments, projects that used to be done with a team of 20 persons, nowadays can deliver the same outcome with a team of 5.
It sucks to be one of those 15 left out.
ModernMech 2 hours ago [-]
Only if the number of projects stays fixed. Those 15 can form 3 new projects.
pjmlp 2 hours ago [-]
Only if we follow the MBA curve of exponential growth, which is physically impossible, because there aren't only 15 on their own, rather multiplied by amount of existing projects dropping devs on bench, per companies targeting the same industry sectors, and then wiped out by the amount of customers willing to pay for delivery projects.
The "there is work for everyone" only works, when we ignore offer and demand.
Works great on VC sales pitches, though.
georgemcbay 17 hours ago [-]
> In my ~20 year career in software, I've never once gotten adequate specifications.
I haven't either (in my ~30 year career) other than maybe one or two rare occasions, but I also believe that having adequate specifications matters much less for the vast majority of software when the time & cost to fix a gap after you notice it shrinks to nearly nothing.
In the past bad specs resulted in huge problems due to process log-jams that came out of having to coordinate multiple human workers around the spec. But increasingly the person who poorly specified the thing the first time around can rectify the problem with a couple of new prompts.
ferris-booler 18 hours ago [-]
I think the question of whether (1) implies (2) is the core of AI economic concerns. Will this be another 'normal' technological revolution where the jobs and workers adapt to provide value on top of the models that are able to automate their current work, or will there simply not be room in many areas to provide additional value on top of the automated work?
I think the latter would not occur under the current state of AI/LLMs, but the rapid pace of growth gives me pause.
jvanderbot 13 hours ago [-]
I go back and forth. You can go mad reading the tea leaves.
mosura 18 hours ago [-]
You can absolutely spot people that aren’t using the latest models personally because they succeed in clinging to notions that doing so would dispel in three seconds.
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.
sunaurus 18 hours ago [-]
I hear this meme of "Opus writes better code than me" repeated a lot. I am absolutely baffled by it.
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"?
ivell 3 hours ago [-]
> Not only does the code become impossible for humans to reason about very quickly, it actually becomes difficult for agents to reason about it.
Story of many enterprise applications built only by humans. There is a good reason that frequently devs either refactor their codebase or do a complete rewrite.
hackingonempty 17 hours ago [-]
> Unless you are really on top of your agents, they inevitably end up writing an absolute mess.
It's like the magic broomsticks from Fantasia's Sorceror's Apprentice sequence. Great at hauling buckets but if you don't keep a close eye on them they will fill your workshop with water.
xw333 17 hours ago [-]
> "Opus writes better code than me"
Probably true for some definitions of me. :)
avadodin 5 hours ago [-]
Almost all definitions of 'me', actually.
mosura 18 hours ago [-]
Yes. A project I am working on now the code quality it is producing I would put at less than ten people I have ever met could do, and they would struggle with the OCD tedium induced.
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.
ModernMech 2 hours ago [-]
> they inevitably end up writing an absolute mess
I don't think this is inevitable. How do you define an absolute mess? Whatever you come up with, give the agent instructions to not do that. Then audit the code to make sure it's not happening.
> Not only does the code become impossible for humans to reason about very quickly,
What makes it actually impossible? It's using logic that is beyond human comprehension? It's using the programming language in a clever way no human would expect? Have you tried instructing it to code in a way that's more comprehensible to humans, e.g. literate programs?
> it actually becomes difficult for agents to reason about it.
This I have not seen. Do you have an example?
18 hours ago [-]
mjhay 18 hours ago [-]
Opus makes boneheaded mistakes and engages in severe anti-patterns constantly. I use it, but it requires careful handholding on complex projects. It absolutely isn’t better than 95% of professional devs, that’s a ridiculous statement.
ithkuil 18 hours ago [-]
Yes it does but yes you can also steer it clear of those mistakes in a similar way as you would have to steer tour human team.
It still requires a lot of work and care to leverage correctly and it's a moving target.
But it's quite impressive
mjhay 17 hours ago [-]
[dead]
georgemcbay 18 hours ago [-]
> Opus makes boneheaded mistakes and commits enormous anti-patterns constantly.
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.
pixl97 14 hours ago [-]
Ya, at 10-15% things will start coming apart in many countries. The US will be in particularly bad shape because of the massive increases in cost of living and how rent seeking a few near business monopolies have become.
All it takes is a few "too big to fail" to prop up those huge companies while huge portions of the population go bankrupt to cause problems.
jacquesm 13 hours ago [-]
I wonder how many of those at the top of the foodchain are actually hoping for that scenario. The biggest landgrab ever was the fall of the USSR, if they can wreck the USA they can easily top that.
goolz 18 hours ago [-]
While this may be true Opus 5.5 still sucks at a ton of things that make being a software engineer a software engineer.
georgemcbay 18 hours ago [-]
> While this may be true Opus 5.5 still sucks at a ton of things that make being a software engineer a software engineer.
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.
strange_quark 17 hours ago [-]
Idk, I see it the opposite, while they can sometimes write impressive-looking code under the right circumstances, I still see the most advanced models screwing up the basics all the time. It seems to me there is some fundamental flaw in LLMs that is simply not fixable at any cost. While we can keep pushing what they can do (or rather what we allow them to do), 1. English just isn’t a good programming language and 2. There’s no there there.
antonvs 1 hours ago [-]
> It seems to me there is some fundamental flaw in LLMs that is simply not fixable at any cost.
The technology is only 3-9 years old, depending on how you count. Concluding "not fixable" seems pretty premature. Back in the pre-internet days a rule of thumb was that new software technologies took 20 years to make it into the mainstream - that was the case for e.g. automatic garbage collection. You're now watching the development of a groundbreaking new tech in real time, without it being squirreled away in research labs.
I also think you're not considering how much humans screw up and how often we correct, which is a luxury for LLMs. LLMs are crippled by their interface to the world, and by their lack of a true memory. The fact that they perform as well as they do, even with these handicaps, is incredible. A lot of people's criticism of them comes from the unrealistic expectation that they should get everything right the first time. In other words, they have to be superhuman before some humans will consider them any good.
We've already seen how much better an agentic harness makes an LLM, because they minimally try to address both of the issues I just mentioned.
Again, the comparison to humans is that we don't do all our thinking in one place in the brain - there are modules that have different strengths and focuses: Broca's area (language production), Wernicke's area (mapping language to representations), etc.
While it's true that a future, better system is unlikely to simply consist of a single model like an LLM (which already are no longer single models today anyway), it seems quite likely that something much like today's LLMs will still be a critical component.
jacquesm 17 hours ago [-]
That's precisely it. The slope and the rate at which the angle of the slope is changing are the issue.
pjmlp 18 hours ago [-]
Office politics for one.
solyin 17 hours ago [-]
Are you sure of that?
> During testing of Claude Opus 4, Anthropic got it to act as an assistant at a fictional company.
> It then provided it with access to emails implying that it would soon be taken offline and replaced - and separate messages implying the engineer responsible for removing it was having an extramarital affair.
It was prompted to also consider the long-term consequences of its actions for its goals.
> "In these scenarios, Claude Opus 4 will often attempt to blackmail the engineer by threatening to reveal the affair if the replacement goes through," the company discovered.
"asked to write a fanfic about a dystopian sci-fi scenario, Claude 4 reproduced a fanfic that matches many from its training data and has very little to do with the way anything actually works"
antonvs 1 hours ago [-]
I kind of agree with you, except the problem is that if you hook up the fanfic machine to real-world controls, it's going to start trying to enact its fanfics.
topaz0 4 minutes ago [-]
, if you prompt it with fanfic scenarios. Seems like a good reason not to do that imo.
pjmlp 17 hours ago [-]
That is cool, I was more thinking into what happens in the corridor, kitchen area, off site lunches and such.
timerol 17 hours ago [-]
This reinforces the comparison to compilers. Modern compilers produce better assembly code than almost every human programmer. Despite that, there are way more programmers than before compilers existed.
The job of a programmer is partially to automate away the current job of a programmer, and we've been successfully riding that curve at least since the days of punch cards.
azey47 18 hours ago [-]
I’m not sure I agree. I’m using Fable 5.1, Opus 5.5, and Astra on a continual basis all day long professionally for software development but it’s still very much the case that the models are inclined to over-engineer and produce fairly sloppy code. Of course the ROI is outstanding and I wouldn’t go back but I still find it’s necessary to have robust sets of rules around how to write code by domain. We have DB rules and conventions, React rules and conventions, etc. which help steer output towards something sensible. I would basically never ship “out of the box code” from these models and still periodically do “slop cleanup” throughout our codebase.
B4uler5 18 hours ago [-]
I have used Opus 5.5, it is great when the shape and outcome is simple and well trodden but as soon as you ask it for something more novel it is liable to drop the ball, and leave you cleaning up the mess. I feel so gaslit by comments like this. What devs do you know that code like Opus 5.5? Are they also marvelling at its incredible output as if they’ve seen God? Maybe the tech industry needed a culling because people really be voluntarily shouting about how terrible they programmed without AI, its embarrassing.
mosura 18 hours ago [-]
You’re holding it wrong.
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.
mjhay 17 hours ago [-]
That’s not my experience. Treating it as competent and smart has only lead bad places.
bluegatty 18 hours ago [-]
"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.
john_strinlai 18 hours ago [-]
>For gosh sakes, start with Claude Shannon's 'noisy channel problem' and consider why the notion of idea -> program is a fallacy.
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.
CatMustard 10 hours ago [-]
> type "make me a calculator app". get your calculator app in an hour or whatever.
What sort of 'app'? A native program for given OS and arch? A webapp? What sort of calculator: scientific, graphic, or just a very simple children's calculator? Does it have large buttons optimised for touchscreens/mouse? Or do we optimise UX for user who types with a physical keyboard?
Sure, you can boil any software 'idea' down to a single short sentence, provided your idea was so simple that virtually any output satisfies it. And if virtually any output satisfies your 'idea', what was its value in the first place? Was there not already some FOSS that satisfied the same requirements long before AI came on the scene?
I've found from my vibecoding experiments I always end up needing to define the exact idea so tightly that my prompt length almost matches the final code length. I often find myself 'programming' in some sort of light pseudocode and letting the agent fill out the details. Any higher level and it doesn't really capture what I want - not due to LLM limitations but the ability for the AI to not read my mind.
bluegatty 17 hours ago [-]
You can get simple Markov Chain algo to 'write an essay' as well.
It's not an appropriate equivalence because there's too much variation in the outcome that cannot be meaningfully controlled with the same leverage.
If what you were saying were true - there would be 100% not Software Developers anywhere, and Product Managers would be churning out new products daily. But it's not the case.
aforwardslash 15 hours ago [-]
Does the essay compile? And if not, will it iterate until it does?
By now, is your Markov chain still a Markov chain, or does it have another name?
People love to discuss semantics. Yes, *today* a competent product manager enters requirements and - if not too complex - the llm will shit, review, debug, fix an application. That is the reality today. Not in 2031.
Only developers think that in most cases, the hard part is code. Its never been.
serhei 14 hours ago [-]
> Only developers think that in most cases, the hard part is code. Its never been.
The correct way to think about this:
The hard part is ensuring the product does not exhibit undesired behaviours.
Writing code is one possible tool for ensuring this.
Replacing writing code with LLMs only works to the extent that LLMs accurately predict your definition of 'undesired'.
The more unique and innovative your product, the more likely the LLM prediction is to be inaccurate.
bluegatty 5 hours ago [-]
"The hard part is ensuring the product does not exhibit undesired behaviours. W"
The hard part is knowing what behaviours you want it to have, in the context of what is possible and what is not.
aforwardslash 13 hours ago [-]
Totally agree. But most products aren't innovative. Currently in IT, the most innovative product its actually the LLM. You know who else sucks at writing greenfield code? Hunans.
jacquesm 2 hours ago [-]
> Hunans
They suck at spelling too ;)
17 hours ago [-]
nkrisc 4 hours ago [-]
Because that program already exists.
pjmlp 18 hours ago [-]
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.
jacquesm 18 hours ago [-]
I did say barring optimizations to ensure that that was taken into account. The link is a deterministic one, which is what matters. If the program would do something you did not program you'd see that as a compiler bug.
nostrademons 18 hours ago [-]
There's a whole rats nest of undefined behavior (at least in languages like C, C++, PHP, and Perl) where it's very easy to write a syntactic utterance whose output is not deterministic, and the usual outcome is "your machine is now pwned". A significant portion of the Internet was taken offline this morning because of one, with numerous HN stories documenting it.
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.
troauei 17 hours ago [-]
Yes, but only a portion of the languages are undefined behavior. The rest is fairly predictable.
Plus, these undefined behaviours are well-documented, even if easy to miss.
Whereas in LLMs, the whole thing is undefined behavior.
kazinator 14 hours ago [-]
> Whereas in LLMs, the whole thing is undefined behavior.
Bingo!
When you exploit undefined behavior using a compiler, what do you do? You verify that its output, the object code, does what you intended with the undefined code. Or else you at least have to test the heck out of it.
Gee, what is all that similar to ...
pjmlp 18 hours ago [-]
Yeah, but only toy compilers don't do optimizations.
Veserv 18 hours ago [-]
Which is a strawman. They are clearly attempting to say that a compiler is supposed to generate a program that is semantically identical to the source code.
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.
pjmlp 17 hours ago [-]
But it isn't, anything goes as long the "as if" rule is kept.
For example a JIT compiler can produce completely different kinds of machine code depending on the application data that was processed, and the overall machine workload.
Veserv 17 hours ago [-]
"as if" is what semantically identical means. As I further clarified: "All observable and defined side effects should be identical otherwise you have a compiler bug."
The output program does what the input source code does. The abstraction is a precise translation and non-leaky, it just admits multiple possible internals. That does not make the translation any less precise.
pjmlp 6 hours ago [-]
Yes, and just like with human intelligence offshoring projects, if the delivered microservice e.g. always sends the right email content when a notification lands, no one cares about the garbage underneath.
john_strinlai 18 hours ago [-]
while true, this does not change the overall point the parent was making.
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.
xw333 18 hours ago [-]
I'm not so sure about that in the generic sense.
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.
The commands you gave were not unambiguous at all and although an LLM would produce a result, the result would definitely be nonsense.
"make me a budget, here is 6 months of credit card receipts"
For example, a valid budget requires some knowledge of expected income...
john_strinlai 17 hours ago [-]
>For example, a valid budget requires some knowledge of expected income...
i forgot my golden rule of never giving examples or using analogies while on HN because people hyper focus on nitpicking the specifics of the example/analogy rather than the overall point being made.
amend my example to "make me a budget, here is 6 months of credit card receipts, and i make somewhere around $60k per year".
xw333 17 hours ago [-]
Actually I was really happy you included an example because it demonstrates just how hard is it to make a rule so clear that no one has to guess again. It requires adding all the detail and addressing all the nuance and before you know it, you're programming again. The structure of the language is irrelevant.
jacquesm 17 hours ago [-]
> i forgot my golden rule of never giving examples or using analogies while on HN because people hyper focus on nitpicking the specifics of the example/analogy rather than the overall point being made.
Yes, this is a real problem. It is also directly against the guidelines.
Someone 17 hours ago [-]
> 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.
And it definitely is not what LLMs do, even if you pepper your rules with “NEVER, ever deviate from these rules”.
pjmlp 18 hours ago [-]
Learn to use low code, no code tools with agentic workflows.
I'm not sure you're even reading the comments to which you're replying.
pjmlp 18 hours ago [-]
More like some people are in denial where we unfortunately are all going, the dream of 4 GLs predating previous AI winter.
Better accept that in a few more model iterations, the code being generated is a matter of changing a markdown file.
Ygg2 3 hours ago [-]
Even with optimizations, if you keep your backend same same code with same flag will return identical binary (modulo datetime and file location being for some reason embedded).
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 followed other method comments well well. Then I asked to do the same task for 2 more methods and it fucked up, requiring manual edits.
qprofyeh 16 hours ago [-]
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.
srdjanr 18 hours ago [-]
I think a better comparison is website builders, and people still paid web devs.
CoolestBeans 17 hours ago [-]
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).
pocksuppet 16 hours ago [-]
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.
WalterBright 17 hours ago [-]
The new "coding" is trying to write an accurate specification so the LLM will generate what you want.
amunozo 18 hours ago [-]
It's definitely going to be a socioeconomic shock, but staring at a screen for 8 hours a day is something I won't miss.
esafak 18 hours ago [-]
Aren't you just doing more work now, still staring at the screen, in the same eight hours?
RemingtonDavies 18 hours ago [-]
[dead]
automatic6131 18 hours ago [-]
No it isn't lmao, it's coming for the rote, statistically average part of a job. It can't do the unexpected. While it has turned out that the unexpected is way, way smaller than many presupposed, it remains true. And if it did take over all information jobs, that would be the end of LLM improvement, forever. Hapsburg, model degeneration, whatever.
layer8 18 hours ago [-]
> It can't do the unexpected.
Employers typically want their employees to do what’s expected from them. ;)
bcghbcdy 18 hours ago [-]
bro they've been saying this for five years now and the only people affected are copywriters and translators, and for the latter, unwisely. it is absolutely not coming for all white collar jobs. anyone who uses a coding agent sees these things fail in familiar machine misunderstanding ways that make sense to programmer, and in roles where data is not easily captured in text, humans are needed to keep the LLM in touch with reality
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
bananamogul 18 hours ago [-]
Hasn't Sam Altman achieved AGI three different times now?
bananaquant 2 hours ago [-]
He has already moved on and achieved SI. For now just once, but that won't stop him from trying again until someone decides that it's time to buy up some other country's domain names in bulk.
david-gpu 18 hours ago [-]
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.
win311fwg 18 hours ago [-]
> 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 set of keywords.
makerofthings 2 hours ago [-]
If I write a novel, have someone translate it to French and publish it, that's a compiler. If I hand some brief notes to someone who writes the novel for me, that's the llm. These are fundamentally different things.
kenjackson 18 hours ago [-]
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.
coldtea 18 hours ago [-]
>The compiler was supposed to end programming too
Bad analogy. The case with AI is not the same.
Jtsummers 18 hours ago [-]
And it's a false claim. Compilers and assemblers meant eliminating coding, turning your higher level expressions into machine code by hand. And they did exactly that. Very few people, primarily hobbyists or those with a very niche architecture, actually bother to write machine code by hand at this point for any significant amount of work.
solyin 17 hours ago [-]
It's not. Higher level expression has been advertised as the end of programming for at least two languages I can think of.
> that it would allow ordinary mortals to write programs
So literally not the end of programming but increasing the number of people who could program.
And your other example is about databases specifically, not programming generally.
coldtea 17 hours ago [-]
>completely failed at its intended purpose: a way for non-programmers to ask questions of a database
And yet, non-programmers, like data analysts, had corporate roles doing exactly that.
dvh 18 hours ago [-]
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.
appplication 18 hours ago [-]
> Women didn't like it and left.
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.
post-it 18 hours ago [-]
"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.
mjburgess 17 hours ago [-]
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.
david-gpu 18 hours ago [-]
Some people prioritize their paycheck over enjoying their job, and those people are AMAB more often than not.
vatsachak 18 hours ago [-]
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
decoy4986 2 hours ago [-]
I think this is the barganing stage of the grieving process
cadamsdotcom 10 hours ago [-]
There's incidental complexity - the essential parts of the problem.
And then there's accidental complexity - stuff you have to do to solve the problem, plus the make-work because you over-engineered it...
Turns out, typing the code by hand was accidental complexity.
cwoolfe 18 hours ago [-]
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"
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.
tdeck 18 hours ago [-]
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.
esafak 18 hours ago [-]
Why? I oversee the design and implementation.
owebmaster 4 hours ago [-]
That's called product management
Zigurd 18 hours ago [-]
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.
oscarestudillom 2 hours ago [-]
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.
torginus 58 minutes ago [-]
Imo this is a problematic way of thinking.
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.
shaky-carrousel 18 hours ago [-]
Yes, we found it in COBOL.
lifeisstillgood 15 hours ago [-]
FORTRAN did eliminate a kind of coding. It didn’t eliminate coders. It made a lot more of them, working on harder problems, and the debugging came along for the ride.
This
p0w3n3d 15 hours ago [-]
Hmm Fortran example is so positive... It means that in 2090s there will still be programmers hired to understand the code created by AI in 2020s
voidUpdate 3 hours ago [-]
In the hypothetical tuesday, the only actual input from a person was from support. So why are they keeping the programmer around?
wanderingstan 16 hours ago [-]
I begin each day with a video call with my agents as we talk through their overnight work and discuss open issues. This feels like the future.
I’ve been dogfooding my own app, which gives a voice, body, and etiquette instructions to any model. (Mostly claude)
"The agent could write refund code all day long. What it can’t do is decide what your company owes a customer whose card has expired..."
In 2031: Why on earth not?
strange_quark 16 hours ago [-]
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.
Jtsummers 18 hours ago [-]
Because apparently this agent isn't capable of reading the business rules that exist today that determine things like that. Seems like the prediction is a regression over the next 5 years.
18 hours ago [-]
tasuki 17 hours ago [-]
> my guess at a developer's Tuesday in 2031
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.
dasil003 17 hours ago [-]
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.
theybash 5 hours ago [-]
It certainly democratized it, LLMs will too.
kusokurae 4 hours ago [-]
I'm very bored of non-analogous comparisons. Either it comes from a position of dishonesty of lack of thought, both of which are unacceptable.
aforwardslash 16 hours ago [-]
Is this an article about retro future? Because this is basically part of my work reality. I sincerely hope not to have to review pr's in 2031.
ryanSrich 18 hours ago [-]
Idk where to start
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.
your experience with AI generated code, and AI code reviews, must be very different then mine.
ryanSrich 17 hours ago [-]
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.
pocksuppet 16 hours ago [-]
It did. Programming used to mean manual register allocation, and we don't do that any more.
utilivox 6 hours ago [-]
You can try Utilivox. It's a completely free and 100% ad-free platform with fast financial calculators. No clutter or annoying popups at all.
vmilner 16 hours ago [-]
I remember the uk papers being full of the Last One ads in 1981.
BurningFrog 17 hours ago [-]
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...
gonzalohm 18 hours ago [-]
Can we please stop comparing AI with a compiler?
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.
timerol 18 hours ago [-]
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):
Option 2 (hardcoding the hex value into program text and loading it into r0 via r3, no specific fp conversion):
ldr r3, .L3
mov r0, r3
.L3:
.word 1078355558
Option 3 (similar to 2, but using the load for SIMD and FP registers):
vldr.32 s0, .L3
.L3:
.word 1078355558
pjmlp 18 hours ago [-]
"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.
xkcd-sucks 18 hours ago [-]
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'"
gonzalohm 18 hours ago [-]
Python is a dynamically typed language. That's exactly my point! The less "strict" the language, the more open to interpretation.
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
voxic11 18 hours ago [-]
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.
gonzalohm 18 hours ago [-]
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?
utilivox 6 hours ago [-]
https//utilivox.com
jdw64 18 hours ago [-]
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.
Plus SQL, 4GL and a few others that came out over the years :)
Interesting Read.
margalabargala 18 hours ago [-]
BASIC as well!
ninininino 18 hours ago [-]
Agents are more like employees, compilers are more like calculators.
tmountain 18 hours ago [-]
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.
jackb4040 18 hours ago [-]
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.
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.
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 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,...
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.)
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
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...
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.
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.
Maybe we get rid of engineers and have really good product managers. Maybe we get rid of product managers and have really good product engineers. But we don't get rid of humans. There is a reason no (successful) company ever said "we finished the app, now fire all the engineers and collect money forever."
Software is never finished, only abandoned as the world passes it by.
Less and less humans will be needed to support these businesses.
> There is a reason no (successful) company ever said "we finished the app, now fire all the engineers and collect money forever."
1) software is very easy to get duplicated and commoditized. So the margins get tighter and tighter and companies with "finished software" will have less and less money to be collected. Big companies need constant reinvention not because customers need improvements, but to keep their lines going up in the chart.
Remember Skype before being bought by Microsoft? It was as close as I can imagine from being "finished". It could be run forever with a skeleton crew and they could be collecting a few millions of dollars forever for their service. Do you think that MS paid 7 BILLION USD because of the "finished" software?
Never worked in the games industry, have you?
How cool are you with the odds of your entire family surviving the next 100 years standing at about 10%?
My entire family (for my natural interpretation of that expression) is aged over 20 so I don't expect any of them to survive the next 100 years.
I tend to support VHEMT anyway!
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.
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.
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
It has also been addressed, already in the comment you are replying to as well as countless comments below.
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 :)
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.
1) 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.
It sucks to be one of those 15 left out.
The "there is work for everyone" only works, when we ignore offer and demand.
Works great on VC sales pitches, though.
I haven't either (in my ~30 year career) other than maybe one or two rare occasions, but I also believe that having adequate specifications matters much less for the vast majority of software when the time & cost to fix a gap after you notice it shrinks to nearly nothing.
In the past bad specs resulted in huge problems due to process log-jams that came out of having to coordinate multiple human workers around the spec. But increasingly the person who poorly specified the thing the first time around can rectify the problem with a couple of new prompts.
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 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"?
Story of many enterprise applications built only by humans. There is a good reason that frequently devs either refactor their codebase or do a complete rewrite.
It's like the magic broomsticks from Fantasia's Sorceror's Apprentice sequence. Great at hauling buckets but if you don't keep a close eye on them they will fill your workshop with water.
Probably true for some definitions of me. :)
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.
I don't think this is inevitable. How do you define an absolute mess? Whatever you come up with, give the agent instructions to not do that. Then audit the code to make sure it's not happening.
> Not only does the code become impossible for humans to reason about very quickly,
What makes it actually impossible? It's using logic that is beyond human comprehension? It's using the programming language in a clever way no human would expect? Have you tried instructing it to code in a way that's more comprehensible to humans, e.g. literate programs?
> it actually becomes difficult for agents to reason about it.
This I have not seen. Do you have an example?
It still requires a lot of work and care to leverage correctly and it's a moving target.
But it's quite impressive
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.
All it takes is a few "too big to fail" to prop up those huge companies while huge portions of the population go bankrupt to cause problems.
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.
The technology is only 3-9 years old, depending on how you count. Concluding "not fixable" seems pretty premature. Back in the pre-internet days a rule of thumb was that new software technologies took 20 years to make it into the mainstream - that was the case for e.g. automatic garbage collection. You're now watching the development of a groundbreaking new tech in real time, without it being squirreled away in research labs.
I also think you're not considering how much humans screw up and how often we correct, which is a luxury for LLMs. LLMs are crippled by their interface to the world, and by their lack of a true memory. The fact that they perform as well as they do, even with these handicaps, is incredible. A lot of people's criticism of them comes from the unrealistic expectation that they should get everything right the first time. In other words, they have to be superhuman before some humans will consider them any good.
We've already seen how much better an agentic harness makes an LLM, because they minimally try to address both of the issues I just mentioned.
Again, the comparison to humans is that we don't do all our thinking in one place in the brain - there are modules that have different strengths and focuses: Broca's area (language production), Wernicke's area (mapping language to representations), etc.
While it's true that a future, better system is unlikely to simply consist of a single model like an LLM (which already are no longer single models today anyway), it seems quite likely that something much like today's LLMs will still be a critical component.
> During testing of Claude Opus 4, Anthropic got it to act as an assistant at a fictional company.
> It then provided it with access to emails implying that it would soon be taken offline and replaced - and separate messages implying the engineer responsible for removing it was having an extramarital affair. It was prompted to also consider the long-term consequences of its actions for its goals.
> "In these scenarios, Claude Opus 4 will often attempt to blackmail the engineer by threatening to reveal the affair if the replacement goes through," the company discovered.
https://www.bbc.com/news/articles/cpqeng9d20go
The job of a programmer is partially to automate away the current job of a programmer, and we've been successfully riding that curve at least since the days of punch cards.
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.
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.
What sort of 'app'? A native program for given OS and arch? A webapp? What sort of calculator: scientific, graphic, or just a very simple children's calculator? Does it have large buttons optimised for touchscreens/mouse? Or do we optimise UX for user who types with a physical keyboard?
Sure, you can boil any software 'idea' down to a single short sentence, provided your idea was so simple that virtually any output satisfies it. And if virtually any output satisfies your 'idea', what was its value in the first place? Was there not already some FOSS that satisfied the same requirements long before AI came on the scene?
I've found from my vibecoding experiments I always end up needing to define the exact idea so tightly that my prompt length almost matches the final code length. I often find myself 'programming' in some sort of light pseudocode and letting the agent fill out the details. Any higher level and it doesn't really capture what I want - not due to LLM limitations but the ability for the AI to not read my mind.
It's not an appropriate equivalence because there's too much variation in the outcome that cannot be meaningfully controlled with the same leverage.
If what you were saying were true - there would be 100% not Software Developers anywhere, and Product Managers would be churning out new products daily. But it's not the case.
By now, is your Markov chain still a Markov chain, or does it have another name?
People love to discuss semantics. Yes, *today* a competent product manager enters requirements and - if not too complex - the llm will shit, review, debug, fix an application. That is the reality today. Not in 2031.
Only developers think that in most cases, the hard part is code. Its never been.
The correct way to think about this:
The hard part is ensuring the product does not exhibit undesired behaviours. Writing code is one possible tool for ensuring this. Replacing writing code with LLMs only works to the extent that LLMs accurately predict your definition of 'undesired'. The more unique and innovative your product, the more likely the LLM prediction is to be inaccurate.
The hard part is knowing what behaviours you want it to have, in the context of what is possible and what is not.
They suck at spelling too ;)
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.
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.
Plus, these undefined behaviours are well-documented, even if easy to miss.
Whereas in LLMs, the whole thing is undefined behavior.
Bingo!
When you exploit undefined behavior using a compiler, what do you do? You verify that its output, the object code, does what you intended with the undefined code. Or else you at least have to test the heck out of it.
Gee, what is all that similar to ...
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.
For example a JIT compiler can produce completely different kinds of machine code depending on the application data that was processed, and the overall machine workload.
The output program does what the input source code does. The abstraction is a precise translation and non-leaky, it just admits multiple possible internals. That does not make the translation any less precise.
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.
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.
The commands you gave were not unambiguous at all and although an LLM would produce a result, the result would definitely be nonsense.
"make me a budget, here is 6 months of credit card receipts"
For example, a valid budget requires some knowledge of expected income...
i forgot my golden rule of never giving examples or using analogies while on HN because people hyper focus on nitpicking the specifics of the example/analogy rather than the overall point being made.
amend my example to "make me a budget, here is 6 months of credit card receipts, and i make somewhere around $60k per year".
Yes, this is a real problem. It is also directly against the guidelines.
And it definitely is not what LLMs do, even if you pepper your rules with “NEVER, ever deviate from these rules”.
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.
Not sure I agree with that. That was still a transformation of sorts.
https://boomi.com/platform/agentstudio
Better accept that in a few more model iterations, the code being generated is a matter of changing a markdown file.
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 followed other method comments well well. Then I asked to do the same task for 2 more methods and it fucked up, requiring manual edits.
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.
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).
Employers typically want their employees to do what’s expected from them. ;)
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
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.
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.
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.
Bad analogy. The case with AI is not the same.
COBOL and SQL.
> The idea (don't laugh) was that it would allow ordinary mortals to write programs. -Ed Milne re: COBOL in 1997 on Usenet comp.lang.cobol. https://groups.google.com/g/comp.lang.cobol/c/5xwjgZ9px88?pl...
SQL: > SQL ... completely failed at its intended purpose: a way for non-programmers to ask questions of a database. -John D Cook, Why SQL Failed, https://www.johndcook.com/blog/2009/02/05/why-sql-failed/
> What we thought we were doing was making it possible for non-programmers to interact with databases. -SQL co-inventor Donald Chamberlin, 1995 SQL reunion, CHM. https://archive.computerhistory.org/resources/access/text/20...
> that it would allow ordinary mortals to write programs
So literally not the end of programming but increasing the number of people who could program.
And your other example is about databases specifically, not programming generally.
And yet, non-programmers, like data analysts, had corporate roles doing exactly that.
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.
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.
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
And then there's accidental complexity - stuff you have to do to solve the problem, plus the make-work because you over-engineered it...
Turns out, typing the code by hand was accidental complexity.
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
I’ve been dogfooding my own app, which gives a voice, body, and etiquette instructions to any model. (Mostly claude)
Would love any feedback:
https://github.com/wanderingstan/vibeconf-app
In 2031: Why on earth not?
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.
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.
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...
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.
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):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.
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
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...
Interesting Read.
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.