> We are 4 years into this ‘revolution’ and the industry has almost nothing to show for it. Software has not improved in quality,
Apple, Mozillia, and Firefox just released a record number of bug fixes because of AI. So this assertion that Software as not improved in quality is arguably if not provably false. There are 1000s of other examples. I have my own. Personal projects that were stopped because of dependency rot, having 100s of bugs fixed, nearly all dependencies removed, and lots of tests added just by asking. I know tons of others with similar experiences
> I do not feel like I’m falling behind by not using them
Obviously you are correct about "how you feel". But, this argument to me is more like a horse owner claming they don't feel like they're failling behind to trucks that can carry 10x, 100x, 1000x more than their horse. Sure, maybe the horse can go places the truck can't. For most uses the truck is better than the horse.
> The LLM-generated PRs I get are still rubbish.
I can't argue with that. I haven't seed the LLM-generated PRs "you" get. I can say though the LLM-generated bug reports I've seen are 1000x better than human ones. Human bug report "your software breaks, fix it!". LLM bug report "There is a bug in this specfic part of the code for these specific reasons and here's a repo I wrote to demonstrate the bug. Here's instructions on how to run the repo. There's the code to fix the bug. And, here's a test to show the bug is fixed."
Is it perfect? No, sometimes the bug isn't real because the code can only be reached in situtations that can never happen. But still, 7 of 8 times it's a real bug and the bug report are the best I've ever received.
>For most uses the truck is better than the horse.
I think you're talking past the author here, who says:
>By not leaning into LLMs I’ve given myself the room to specialise in a smaller set of skills. So far that conscious decision is working out well, and I remain confident about my job security.
"Most uses" might mean boilerplate and simple frontend work that LLMs can do easily because it's formulaic and doesn't require much creativity. OP is simply not doing that type of work.
I don't think anyone sane is really claiming 100x or 1000x speedups anymore. Most people I talk to who use LLMs are closer to 1.5 or 2. Because their job is not mostly boilerplate, there is simply not that much room to be improved.
It’s not about speed-ups, it’s the fact that I’ll attempt a project far more ambitious than I would have in the past.
Over the past two months I’ve built out a very complex web app for a client. Without the aid of AI it would be far smaller, simpler and less capable. And honestly I probably wouldn’t have agreed to take on the job in the first place.
>Apple, Mozillia, and Firefox just released a record number of bug fixes because of AI.
A hidden metric here is the number of new bugs created by these fixes. If an LLM creates 10x bugs but create 5x more new bugs, then it is not really an improvement. Because that is 5x more bugs that the user has to observe and report (unless it is a security vulnerability, which the LLMs might detect) before it can be fixed.
This is effectively a claim that Mozillia, Apple, Google's developers are idiots and irresponsible and just accepted the fixes without checking them. That's a pretty strong claim which I think you'd have a hard time proving or even finding any evidence for
LLMs are very helpful as a debugging aid, yes, but in large part because the fixes tend to be small and verifiable. That this does not carry over to many other use cases is the crux of the problem.
I myself use them to accelerate programming tasks, so I'm not anywhere near as pessimistic as the author, but the claimed multiples of productivity definitely haven't materialized for me.
I gave the 1000x example because a single semi-truck can generally carry 240x what a horse can carry. A horse can carry 150-200lbs. A semi-truck can carry 42,000 to 48,000 pounds. The largest truck carries 2.2 million pounds or 11000x the horse.
To see an example of this 1000x, all we have to do is look at the flood of bug reports and fixes to browsers and OSes. Does it do 1000x for every project? No, and neither does a pickup truck do 1000x what a horse does. But, even a small pickup truck does more than a horse for most use cases (carrying people or stuff) and similarly, LLMs do more for most use cases.
I recently experienced some cognitive decline due to chronic health issues. This is unfortunate timing because I am shipping a game with online multiplayer for the first time. So "brain works properly" is kind of a basic job requirement! But you work with what you got...
Some day I have the energy to do programming "manually", but on many days, the difference between "tasks get done" and "I am just staring at the screen reading the same code over and over again" is "ask the LLM to do it."
So I have had to shift my identity from "the guy who does the thing" to "the guy who ensures the thing has been done."
That being said, I do check the diffs carefully. (I tried a more hands-off approach a few months ago, and that was a pretty bad idea.) And I've learned to make the diffs as small as possible: more digestible for me, and less room for the AI to go off the rails.
Nice bonus to small, well defined changes is that small, fast, cheap models can handle them. (Having a great time with Luna lately, even on Low reasoning effort, which I wasn't expecting at all.)
By checking the diffs carefully, you're showing how to use an LLM to add value instead of creating a 17000-line PR that nobody with any sense will read.
LLMs are really good at making it harder to ignore ignorant people, and you've demonstrated that you're NOT part of the problem.
>The not-so-quiet goal of the LLM push by big tech was to homogenise intellectual labour such that it can be made fungible. When labour is fungible you can swap it out whenever you like for an alternative, decreasing the bargaining power of workers. Software development was one of the last ‘guild fields’ and now we are seeing its industrialisation occur.
I think that the industrialization of software development already happened decades ago. The common professional software development methodologies, both waterfall and sprint-based, ARE the industrialization of software development. Isn't modern "agile", sprint-based software development methodology directly influenced by Japanese manufacturing methods? I don't know when software development actually was a guild field, and my personal experience doesn't reach back this far, but based on what I've read at least, it seems to me that even back in the 1990s it was already not a guild field.
A "guild field" is not a well-defined matter, but I think it's still the easiest engineering field to sit at home on your personal gear and learn skills that can get you hired in a real job with a future without attending any professional school for the field.
In fact the four-year degree you'll get from school is getting increasingly distant from the skills I actually want out of a new grad. It's not impossible to bridge the gap or anything but my transition into the commercial realm in the early 2000s was a cakewalk compared to the sheer number of things I'm asking a new grad to learn as soon as they're settled in at their desk... source control, CI/CD, bug trackers, devops, and that's just the beginning of that list not the end.
> In fact the four-year degree you'll get from school is getting increasingly distant from the skills I actually want out of a new grad
Those skills are easily taught. But in every run of the mill project I’ve been on, I’ve been really happy about all the maths and other science stuff I’ve been taught at college. It’s easier to grasp the web DOM, React, and git when you already know about trees and the related algorithms. Easier to learn SQL after opening some books on relational theory (basically the first chapter on database theory) and learning about projections. And definitely easier to learn the nature of distributed systems.
Learning how to use Bash and Ansible is a walk in the park after that.
I personally look at react-foo and see something thats the opposite of how I want to work as a software craftsman [ small code, lispy / function flavored style, opinionated, few dependencies ]
For similar aesthetic reasons, have only dabbled with code-gen LLMs. Im happy to vibe code css and html but not, well actual code. I'm aware of my own double standard, Im fine with median-reverting banal css and html.
I do worry about some aspects of LLMs :
- google giving AI code snippets so easily, prevents traffic to sites like stack-overflow, where discussion happens
- vibe coding means less people hit the actual hard parts of coding, which result in learning to think as a developer. Thence where the next generation of developers who understand code ?
- code will become a magical, inscrutable black box where no-one understands how it works. DNNs and LLMs have this feature already. At least with LLM discovered math, the proof in lean exists, which is independent at how it was arrived at / searched for.
- if I write a novel, and the DNN AI detects it as AI slop with 68% probability, then what recourse do I have to prove its human written ?
- circular training : subsequent rounds of LLMs trained not on human input, but on LLM slop of the previous generation [ the %ge of which increases ]
- you will own nothing : fortunately it looks like self-hosted open weight LLMS will remain a thing, but the massive spend by hyperscaler companies on Datacenters/GPUs/RAM has driven down supply and driven up prices of CPU, GPU, RAM for enthusiasts / gamers / home AI nerds / garage startups .. which might stifle innovation.
The last bullet point is the most important. The industry is most hyped about AI so that they can pay software developers $70k instead of paying them $200k.
I don’t really agree that AI can’t make development faster, though. What the author describes as the negative AI outcome is blind vibecoding. There are many other ways to use it, and even the basic “enhanced autocomplete” is a net benefit, especially since that functionality is dirt cheap or free.
Not really. The other bullet points are the reality. The last one is the MBA wet dream.
We have been programmed to believe that MBA wet dreams are inevitable because "$x hundreds of billions invested can't be wrong" but they very often are.
To the author’s point about there not being enough evidence to support pro-AI claims — Additionally, there are studies and articles coming out showing those people are wrong and AI only makes people barely more efficient. Not the 10x tech CEOs are claiming while slashing thousands of jobs
I'm definitely able to spew out more code than I used to. Good code. Maybe not great code, but good code.
But I spent a lot of time in the second half of this week dealing with friction with a team that is very annoyed that I'm moving fast and using an agile methodology so I can't tell them the exact, precise REST calls that I'm going to have for them in six months designed to a tee and signed off in triplicate before they start development against it. Manifesting that increase in code production as real value to the business is going to take more from me than just spewing the code out more quickly.
AI isn't creating this problem. I would have had this problem anyhow even if I were writing all the code by hand again. I know, because I've been there before. But the increased velocity is manifesting in increased organizational stress and not just increased velocity.
AI is perhaps even helping solve it to some degree, though far from totally. I have written before about how people eventually learned not to play the "oh well we can't do this until we have documentation" card on me [1]. This week they played the "well, I see you have docs but they aren't in our precise format". Guess what AI can do in about 15 minutes really well? You may recall the term "style transfer" getting tossed about a lot 3-4 years ago, and it is still something AI is extremely good at, and "take these docs in this format and convert them to that format" is just a style-transfer problem. AI really does chew at the "oh but we need docs" old-school card... and they can't even complain about the quality of the AI docs because in order to do that, they'd have to actually read them, and that is not the point of the "but we need docs" card, you see....
Yeah, as you said, this isn't an AI problem. The interface between an agile team and the non-agile part of the company was a problem over 20 years ago. (At least, that was when it bit me.)
You can think of it as an impedance mismatch, or as a translation problem. But no matter how you think about it, it's real, and it's a problem - especially if upper management lives on the non-agile side of the fence.
All AI hallucinates, and therefore is unpredictable and unreliable. 1.5 trillion dollars to prove the obvious. It has no place in production use. IMHO at least. They want so badly to get rid of all of us, and replace us with something that doesn't complain, doesn't have kids, or outside lives or want ick, vacations. Most of you are paycheck to paycheck, statistically speaking, so you have a vested interest in how this all turns out.
edit: I get it, it's not a popular opinion.
But am I wrong?
If the problem of hallucination in AI has been solved, maybe I missed it?
I have a similar experience that I expected several competitors to popup in my app niche, and so far only one has come up, and after some digging, they already had 8+ apps in another niche that had some overlap, so they would be able to complete the competing one without AI.
> The not-so-quiet goal of the LLM push by big tech was to homogenise intellectual labour such that it can be made fungible. When labour is fungible you can swap it out whenever you like for an alternative, decreasing the bargaining power of workers. Software development was one of the last ‘guild fields’ and now we are seeing its industrialisation occur.
This is really well said. I had not put my finger on it before. Maybe this is a next move in the saga to avoid labor unions in engineering.
I have started using AI a bit, but I'm still trying to be careful in that if I ever lose access I can still perform my job at pre-AI ability. My understanding is that tokens are still heavily subsidized, and when that well runs dry I don't want it to be some nightmare to go back to the way I was doing my work in like 2022.
From my reading on the topic, the tokens are subsidized when considering average cost, but are profitable at marginal cost. Basically, they're super expensive when considering the training cost, but aren't super expensive when doing inference. Since AGI is quite unlikely now, my guess is that we'll see consolidation and will see frontier models released at a slower clip, such that they can pay for training for from the profits from prediction tokens themselves. There may be slight increases in token prices, but there's sufficient competition between Google, Anthropic, OpenAI and X alongside the open weights providers that I don't see huge price increases happening. Even if OpenAI is absorbed into one of the others (which I think is most likely), that would still make token price collusion difficult.
that'd only be true if you have a lot of trust that people care about quality. It's wrong to think of industrialization as only affecting producers. Fast fashion is a good example of this. There's studies on the quality of for example jeans and they've declined over decades. Mid 20th century cotton denim was a lot better than what you can buy now. Animation is another one as many people have noticed, you have movies that have somehow managed to decline in quality but nobody cares because you can churn out ten times as many. The nutritional quality of food has declined for 60 years as ultra-processed and industrially produced foods have taken over.
The worst scenario isn't actually that machines are intelligent and you lose your job, it's that they're stupid and you lose your job because in our quantitative glutton culture qualitative judgement is entirely gone to begin with
>The not-so-quiet goal of the LLM push by big tech was to homogenise intellectual labour such that it can be made fungible. When labour is fungible you can swap it out whenever you like for an alternative, decreasing the bargaining power of workers.
Especially if you replace people with robots that don't need days off and have the people train their replacements.
idk. I get more stuff done, faster, that I wouldn’t have been able to. You have to use it judiciously and with supervision - I can see how letting it get out of control would negate the benefits. But with good use, its undeniable.
It takes some time to learn how to get these systems to work well, and learn what they’re good for. I think people who don’t see the benefits either haven’t dug in enough or haven’t used them for things they’re good at.
Do coding agents help me with highly technical work where it’s some deep thought and discussion with coworkers and eventually I change five lines of code? Not really.
But I can debug a weird kernel panic or optimizer bug from a standing start in an hour when it would have taken me all day without these tools.
I’m in the final prep for ship phase of a project that started February. It’s a bottom-to-top rewrite of a project that’s been shipping for two years, and took two years to write, initially.
I’m deliberately doing it all with the $20/month ChatGPT sub. After it ships, I’ll move to the $100/month sub; but I want to be able to say that the entire project was done on a low-tier LLM subscription.
your perception is that you get more stuff done faster, and that seems to be the conclusion that most using LLM's come to (including myself): but there are no productivity gains that are externally observable to show for it (yet).
That might be because of some lag, but another explanation might be that the tools are really effective at increasing someone's perception of their productivity while net productivity gains measured over long time windows are low or zero. Another explanation might be that the incompetent/negligent users are causing enough harm to nearly neutralize the gains brought by proficient / effective users. I don't know what the explanation is, but there is a mystery in the divergence between users' perceptions of their own productivity, and the observed productivity gains in the economy.
It would be a weird coincidence if a pretty different way of working turned out to be exactly as productive as the old way, no more and no less. I’m skeptical of these claims. Measuring programmer productivity is notoriously difficult.
It might be weird, but it might be the result of forces in equilibrium:
e.g. one explanation might be that time spent prompting is time spent not improving, or learning, so it would not be surprising then that the productivity gains might be similar in scale to the productivity lost from learning / improvement that never happens.
another explanation might be that prompting just delays work that will have to be done later when fixing errors. When encountering an error that the LLM doesn't fix on the first attempt the human-in-the-loop doesn't understand the problem very well: they will either pull the slot machine for a while until they hit lucky, or grit their teeth and sit down to understand what the code is doing in the excruciating and boring detail required to find and solve bugs, which is exactly the work that they had offloaded onto the LLM earlier.
the decision i have to make dozens if not hundreds times a day: do i actually look at this crap or trust it blindly and let it slide? I'm honestly reading maybe 20% tops of what "I" produce (and what other people post for my review) I think you do lose skills and understanding that way. Sure, you can always ask the robot to do the tldr for you, but.... yeah, something is still lost, not in a good way.
>We should all know by now that code is an input to the software development process and not an output: yet even the most forward-looking organisations still tactitly treat lines of code as a productivity metric
What exactly is this referring to? My thinking here is "code is a hypothesis", and you don't know if it's solid or not until it contacts the real world. (And ideally tests, and maybe a proof or two.) And what we're seeing lately is that the hypotheses often get disproven decades later (longstanding kernel bugs etc.)
Maybe because the actual work is done by the process, which may not even be the code itself, just its compiled form. In this code the code is both a communication tool (between humans) and the input that leads to the process. It's like a group of musicians collaborating on a music sheet. The final valuable form is a concert. The audience won't care about the music sheet.
The comments here gush about how they can write more code, but they don't say anything about the quality of the software being built and if they have improved on some points with it (cheaper maintenance, faster reaction to feedback, less bugs overall). Very much like a musician clamoring how he can write a lot more music sheets, but there's no concert in sight to listen to his music.
I agreed right upto the last quote. That made the post political, similar to the ones being written by the AI evangelists.
The thing about complex systems is that they are not predictable. Right now the answer is whatever you think is right, and a lot of scenarios seem plausible.
It is a fun intellectual moment trying to make sense, but maybe only time will tell how the dynamics work out.
I think the fundamental rebuttal to this is merely that, we’re still so early, the $1.5 trillion number is irrelevant for developing technologies in the same way two women can’t birth a baby in 4.5 months
The $1.5 trillion number is extremely relevant because it makes the revenue numbers the industry has to hit higher and there's an expectation to see progress sooner before funding starts getting pulled back.
>...it makes the revenue numbers the industry has to hit higher...
Yes. But.
Industry can miss its revenue targets, Oracle can go bankrupt (looking more and more likely) OpenAI, Anthropic and SpaceX might find "true value" at about 10% of current valuations (that feels right to me), all that can happen with the associated economic chaos... and still out of it comes world shaping new technology
Certainly, but a flop of $1.5 trillion would create a deep and long trough. I think in that situation OpenAI and Anthropic probably don't survive as independent companies (where is the revenue? who would want to put more money in at that point?). In that situation there would definitely be a fire sale in the prices of licensing models (open weights are already pushing this way the hell down), semiconductors, data centers, and compute in general. And like in that situation, who knows what products come out of that dividend of cheap stranded assets? It might not even be AI related. You can do a lot of things with a lot of cheap GPU power. This boom-bust cycle is nothing new, especially to the tech industry. This deep crash outcome is the risk that a bet of $1.5 trillion makes. And it makes the current paradigm of coding agents and chatbots less likely because it is so volatile.
Oracle has bet the house on AI. Free cash flow is deeply negative with tons more capex guidance on the books. They are currently the largest non-financial corporate issuer of new debt in the corporate bond market. They are literally cutting their headcount to the bone to help fund this build out. If their compute deals do not pan out because their customers have liquidity issues or revenue stalls, they are in dire straits.
Given the advances since 2022 why would funding get pulled back? The endgame is replacing all office workers globally and so you get 10% of that market that's that's easily $1 trillion. A competent AI employee replaces a human the same way the car replaced the horse. Businesses will pay more for an AI employee that doesn't get sick or come in hung over over a human one and never goes to sleep. If OpenAI manages to crack that, and capture even 10% of the market globally, that's trillions.
Total addressable market doesn't pay interest expenses. Even if this technology really did have the potential to be as revolutionary as the move from the horse to the car, if you can't get there with what the world economy's liquidity can provide then you can't get there. Free cash flow is drying up and data centers depreciate. This creates a limit and if that limit is hit before the profit starts coming in it doesn't matter what the potential could be. Paying back interest is financial gravity and it exists today. And this isn't an appeal to Wall Street's short term profit motive, there just is an economic limit to what the capital markets can spend on a bet this big and this risky.
Yes, that's going on optimism. It's also possible that we're 80% there and the rest will take forever, while the loans and investments were taken out now.
This is equally as biased as those who claim AI can just code all night autonomously for you. You don't have to use it to generate "fully LLM-generated PRs". It's true GitHub is flooded with poor-quality LLM slop, but that is not the only way to use it.
It's ironic the author links to Naur's paper because I use LLMs to dig through code faster, question my assumptions, review my drafts, or generate drafts for my review. It's not because I am bad at it, I used to be very proud of being able to do this better than others. Anyway, this does not lead to more "lines of code" as the author suggests and instead it can lead to higher quality code.
FWIW, I also don't believe you can let LLMs make critical judgement by somehow stringing together more LLMs. And I am also not making a claim on whether the $1.5T investment is proportional to its benefits. But to say "industry has nothing to show for it", or to bring up strawmen like "LLM-generated PRs" and "lines of code", makes me question whether the author has tried studying the applications of LLMs.
the way i see, LLM's in their current shape are neither good enough to replace software engineers but they have become a necessary part of everyone tool kit. ergo, actual companies themselves aren't getting much benefit because their competitors are using the same tools and they can't fire their human labor either just it's just an extra cost. At my org, i see good engineers use LLM's in wise ways and bad engineers just let it write slop for them. What gets to me is the verbosity and noise though, i consider brevity, and curation to be hallmarks of intelligence but most people at work just spit out so many words in their design docs or code comment these days.
The reality is new technology that works, will get used for what it best works for.
There are things that LLMs remain uniquely suited for, while the echo chambers go for everything.
There's no requirement to use new technology. Maybe what you do, or how you do it is just fine, and that's OK.
Skepticism today can remind me of someone who went into a cave for 3-4 years with a dated take of LLMs on day 1 and not remember software improves, and LLMs are software.
There are no shortage of uniquely working solutions with LLMs if sone seeks to find them, and also the self-validating echo chamber that says that it doesn't if that's desired. Which parts of software development, or how software development may better happen differently with the involvement of AI remains to be seen.
AI skeptics hate him. Here's how he doubled his productivity using AI with one simple trick.
You have to stop thinking like an employee or a worker bee, and start thinking like a boss.
Guess what, the work you give your boss isn't 100% gold either. And sometimes you are preoccupied, or tired, so what you deliver isn't the best of all possible deliverables. Sometimes you hallucinate, i.e. you are dead wrong when you think you are dead right.
This is the job of a boss: take fallible employees and turn what they produce into something actually valuable. The boss lets the grunts do the grunt work, and then they combine the output together, and do the due diligence, etc etc.
It's an entirely new skillset. But learning the new skillset isn't the real blocker--the real blocker is that you've got to stop thinking like a grunt and start thinking like an executive.
WHAT is it that you really want to do? Frame that question as clearly and as concretely as you can. Then farm out thee work to human or AI grunts, and be prepared to do your due diligence on the result.
... theres a lot of anecdotal evidence executives aren't good thinkers.
Why not replace all mid-execs with LLMs trained on every MBA textbook and linked-in blog post ? why stop at grunt coders, graphic designers and phone marketeers ?
Can we reduce the role of CEO to the following prompt : "make money, by any legal means"
>> We are 4 years into this ‘revolution’ and the industry has almost nothing to show for it.
If you actually used LLMs instead of preaching against them from the sidelines with no real experience, you'd know such statements are wrong.
This is the real problem with many of the anti LLM folks - they tell us about LLMs and also tell us they don't use them.
"That thing cannot do the stuff you say it can. And there is no way I will ever try it. But I know for sure I am right."
> We are 4 years into this ‘revolution’ and the industry has almost nothing to show for it. Software has not improved in quality,
Apple, Mozillia, and Firefox just released a record number of bug fixes because of AI. So this assertion that Software as not improved in quality is arguably if not provably false. There are 1000s of other examples. I have my own. Personal projects that were stopped because of dependency rot, having 100s of bugs fixed, nearly all dependencies removed, and lots of tests added just by asking. I know tons of others with similar experiences
> I do not feel like I’m falling behind by not using them
Obviously you are correct about "how you feel". But, this argument to me is more like a horse owner claming they don't feel like they're failling behind to trucks that can carry 10x, 100x, 1000x more than their horse. Sure, maybe the horse can go places the truck can't. For most uses the truck is better than the horse.
> The LLM-generated PRs I get are still rubbish.
I can't argue with that. I haven't seed the LLM-generated PRs "you" get. I can say though the LLM-generated bug reports I've seen are 1000x better than human ones. Human bug report "your software breaks, fix it!". LLM bug report "There is a bug in this specfic part of the code for these specific reasons and here's a repo I wrote to demonstrate the bug. Here's instructions on how to run the repo. There's the code to fix the bug. And, here's a test to show the bug is fixed."
Is it perfect? No, sometimes the bug isn't real because the code can only be reached in situtations that can never happen. But still, 7 of 8 times it's a real bug and the bug report are the best I've ever received.
you can go through this list: https://www.firefox.com/en-US/firefox/150.0/releasenotes/ and for those very few issues not still blocked you can read the examples
>For most uses the truck is better than the horse.
I think you're talking past the author here, who says:
>By not leaning into LLMs I’ve given myself the room to specialise in a smaller set of skills. So far that conscious decision is working out well, and I remain confident about my job security.
"Most uses" might mean boilerplate and simple frontend work that LLMs can do easily because it's formulaic and doesn't require much creativity. OP is simply not doing that type of work.
I don't think anyone sane is really claiming 100x or 1000x speedups anymore. Most people I talk to who use LLMs are closer to 1.5 or 2. Because their job is not mostly boilerplate, there is simply not that much room to be improved.
It’s not about speed-ups, it’s the fact that I’ll attempt a project far more ambitious than I would have in the past.
Over the past two months I’ve built out a very complex web app for a client. Without the aid of AI it would be far smaller, simpler and less capable. And honestly I probably wouldn’t have agreed to take on the job in the first place.
>Apple, Mozillia, and Firefox just released a record number of bug fixes because of AI.
A hidden metric here is the number of new bugs created by these fixes. If an LLM creates 10x bugs but create 5x more new bugs, then it is not really an improvement. Because that is 5x more bugs that the user has to observe and report (unless it is a security vulnerability, which the LLMs might detect) before it can be fixed.
This is effectively a claim that Mozillia, Apple, Google's developers are idiots and irresponsible and just accepted the fixes without checking them. That's a pretty strong claim which I think you'd have a hard time proving or even finding any evidence for
Also there's the "let's make time to work on those bugs by using this new tool". Time that wouldn't have been allocated otherwise.
LLMs are very helpful as a debugging aid, yes, but in large part because the fixes tend to be small and verifiable. That this does not carry over to many other use cases is the crux of the problem.
I myself use them to accelerate programming tasks, so I'm not anywhere near as pessimistic as the author, but the claimed multiples of productivity definitely haven't materialized for me.
Not the 1000x more productive numbers again please. Is this a meme or something? If you said +17% I might have taken you seriously.
I gave the 1000x example because a single semi-truck can generally carry 240x what a horse can carry. A horse can carry 150-200lbs. A semi-truck can carry 42,000 to 48,000 pounds. The largest truck carries 2.2 million pounds or 11000x the horse.
To see an example of this 1000x, all we have to do is look at the flood of bug reports and fixes to browsers and OSes. Does it do 1000x for every project? No, and neither does a pickup truck do 1000x what a horse does. But, even a small pickup truck does more than a horse for most use cases (carrying people or stuff) and similarly, LLMs do more for most use cases.
>productivity
I recently experienced some cognitive decline due to chronic health issues. This is unfortunate timing because I am shipping a game with online multiplayer for the first time. So "brain works properly" is kind of a basic job requirement! But you work with what you got...
Some day I have the energy to do programming "manually", but on many days, the difference between "tasks get done" and "I am just staring at the screen reading the same code over and over again" is "ask the LLM to do it."
So I have had to shift my identity from "the guy who does the thing" to "the guy who ensures the thing has been done."
That being said, I do check the diffs carefully. (I tried a more hands-off approach a few months ago, and that was a pretty bad idea.) And I've learned to make the diffs as small as possible: more digestible for me, and less room for the AI to go off the rails.
Nice bonus to small, well defined changes is that small, fast, cheap models can handle them. (Having a great time with Luna lately, even on Low reasoning effort, which I wasn't expecting at all.)
By checking the diffs carefully, you're showing how to use an LLM to add value instead of creating a 17000-line PR that nobody with any sense will read.
LLMs are really good at making it harder to ignore ignorant people, and you've demonstrated that you're NOT part of the problem.
>The not-so-quiet goal of the LLM push by big tech was to homogenise intellectual labour such that it can be made fungible. When labour is fungible you can swap it out whenever you like for an alternative, decreasing the bargaining power of workers. Software development was one of the last ‘guild fields’ and now we are seeing its industrialisation occur.
I think that the industrialization of software development already happened decades ago. The common professional software development methodologies, both waterfall and sprint-based, ARE the industrialization of software development. Isn't modern "agile", sprint-based software development methodology directly influenced by Japanese manufacturing methods? I don't know when software development actually was a guild field, and my personal experience doesn't reach back this far, but based on what I've read at least, it seems to me that even back in the 1990s it was already not a guild field.
A "guild field" is not a well-defined matter, but I think it's still the easiest engineering field to sit at home on your personal gear and learn skills that can get you hired in a real job with a future without attending any professional school for the field.
In fact the four-year degree you'll get from school is getting increasingly distant from the skills I actually want out of a new grad. It's not impossible to bridge the gap or anything but my transition into the commercial realm in the early 2000s was a cakewalk compared to the sheer number of things I'm asking a new grad to learn as soon as they're settled in at their desk... source control, CI/CD, bug trackers, devops, and that's just the beginning of that list not the end.
New grads have learnt git and issue trackers as part of standard coursework. Not sure about CI or devops.
> In fact the four-year degree you'll get from school is getting increasingly distant from the skills I actually want out of a new grad
Those skills are easily taught. But in every run of the mill project I’ve been on, I’ve been really happy about all the maths and other science stuff I’ve been taught at college. It’s easier to grasp the web DOM, React, and git when you already know about trees and the related algorithms. Easier to learn SQL after opening some books on relational theory (basically the first chapter on database theory) and learning about projections. And definitely easier to learn the nature of distributed systems.
Learning how to use Bash and Ansible is a walk in the park after that.
There's a big difference between understanding the underlying concepts vs being proficient with a tool.
I personally look at react-foo and see something thats the opposite of how I want to work as a software craftsman [ small code, lispy / function flavored style, opinionated, few dependencies ]
For similar aesthetic reasons, have only dabbled with code-gen LLMs. Im happy to vibe code css and html but not, well actual code. I'm aware of my own double standard, Im fine with median-reverting banal css and html.
I do worry about some aspects of LLMs :
- google giving AI code snippets so easily, prevents traffic to sites like stack-overflow, where discussion happens
- vibe coding means less people hit the actual hard parts of coding, which result in learning to think as a developer. Thence where the next generation of developers who understand code ?
- code will become a magical, inscrutable black box where no-one understands how it works. DNNs and LLMs have this feature already. At least with LLM discovered math, the proof in lean exists, which is independent at how it was arrived at / searched for.
- if I write a novel, and the DNN AI detects it as AI slop with 68% probability, then what recourse do I have to prove its human written ?
- circular training : subsequent rounds of LLMs trained not on human input, but on LLM slop of the previous generation [ the %ge of which increases ]
- you will own nothing : fortunately it looks like self-hosted open weight LLMS will remain a thing, but the massive spend by hyperscaler companies on Datacenters/GPUs/RAM has driven down supply and driven up prices of CPU, GPU, RAM for enthusiasts / gamers / home AI nerds / garage startups .. which might stifle innovation.
The last bullet point is the most important. The industry is most hyped about AI so that they can pay software developers $70k instead of paying them $200k.
I don’t really agree that AI can’t make development faster, though. What the author describes as the negative AI outcome is blind vibecoding. There are many other ways to use it, and even the basic “enhanced autocomplete” is a net benefit, especially since that functionality is dirt cheap or free.
Not really. The other bullet points are the reality. The last one is the MBA wet dream.
We have been programmed to believe that MBA wet dreams are inevitable because "$x hundreds of billions invested can't be wrong" but they very often are.
To the author’s point about there not being enough evidence to support pro-AI claims — Additionally, there are studies and articles coming out showing those people are wrong and AI only makes people barely more efficient. Not the 10x tech CEOs are claiming while slashing thousands of jobs
https://getdx.com/blog/ai-productivity-gains-are-10-percent-...
The problem is that LLMs improve so fast, your article may very well be out of date by now.
I'm definitely able to spew out more code than I used to. Good code. Maybe not great code, but good code.
But I spent a lot of time in the second half of this week dealing with friction with a team that is very annoyed that I'm moving fast and using an agile methodology so I can't tell them the exact, precise REST calls that I'm going to have for them in six months designed to a tee and signed off in triplicate before they start development against it. Manifesting that increase in code production as real value to the business is going to take more from me than just spewing the code out more quickly.
AI isn't creating this problem. I would have had this problem anyhow even if I were writing all the code by hand again. I know, because I've been there before. But the increased velocity is manifesting in increased organizational stress and not just increased velocity.
AI is perhaps even helping solve it to some degree, though far from totally. I have written before about how people eventually learned not to play the "oh well we can't do this until we have documentation" card on me [1]. This week they played the "well, I see you have docs but they aren't in our precise format". Guess what AI can do in about 15 minutes really well? You may recall the term "style transfer" getting tossed about a lot 3-4 years ago, and it is still something AI is extremely good at, and "take these docs in this format and convert them to that format" is just a style-transfer problem. AI really does chew at the "oh but we need docs" old-school card... and they can't even complain about the quality of the AI docs because in order to do that, they'd have to actually read them, and that is not the point of the "but we need docs" card, you see....
[1]: https://news.ycombinator.com/item?id=48412349
Yeah, as you said, this isn't an AI problem. The interface between an agile team and the non-agile part of the company was a problem over 20 years ago. (At least, that was when it bit me.)
You can think of it as an impedance mismatch, or as a translation problem. But no matter how you think about it, it's real, and it's a problem - especially if upper management lives on the non-agile side of the fence.
(March 2026)
All AI hallucinates, and therefore is unpredictable and unreliable. 1.5 trillion dollars to prove the obvious. It has no place in production use. IMHO at least. They want so badly to get rid of all of us, and replace us with something that doesn't complain, doesn't have kids, or outside lives or want ick, vacations. Most of you are paycheck to paycheck, statistically speaking, so you have a vested interest in how this all turns out.
edit: I get it, it's not a popular opinion.
But am I wrong?
If the problem of hallucination in AI has been solved, maybe I missed it?
I have a similar experience that I expected several competitors to popup in my app niche, and so far only one has come up, and after some digging, they already had 8+ apps in another niche that had some overlap, so they would be able to complete the competing one without AI.
My apps are also not super complicated.
> The not-so-quiet goal of the LLM push by big tech was to homogenise intellectual labour such that it can be made fungible. When labour is fungible you can swap it out whenever you like for an alternative, decreasing the bargaining power of workers. Software development was one of the last ‘guild fields’ and now we are seeing its industrialisation occur.
This is really well said. I had not put my finger on it before. Maybe this is a next move in the saga to avoid labor unions in engineering.
I have started using AI a bit, but I'm still trying to be careful in that if I ever lose access I can still perform my job at pre-AI ability. My understanding is that tokens are still heavily subsidized, and when that well runs dry I don't want it to be some nightmare to go back to the way I was doing my work in like 2022.
From my reading on the topic, the tokens are subsidized when considering average cost, but are profitable at marginal cost. Basically, they're super expensive when considering the training cost, but aren't super expensive when doing inference. Since AGI is quite unlikely now, my guess is that we'll see consolidation and will see frontier models released at a slower clip, such that they can pay for training for from the profits from prediction tokens themselves. There may be slight increases in token prices, but there's sufficient competition between Google, Anthropic, OpenAI and X alongside the open weights providers that I don't see huge price increases happening. Even if OpenAI is absorbed into one of the others (which I think is most likely), that would still make token price collusion difficult.
People keep saying that, but there are no real confirmed numbers. And an incredibly high incentive to lie.
> Software development was one of the last ‘guild fields’ and now we are seeing its industrialisation occur.
Doesn’t really support the rest of the argument. If you’re a skeptic and think it’s all hype, there’s nothing to worry about.
that'd only be true if you have a lot of trust that people care about quality. It's wrong to think of industrialization as only affecting producers. Fast fashion is a good example of this. There's studies on the quality of for example jeans and they've declined over decades. Mid 20th century cotton denim was a lot better than what you can buy now. Animation is another one as many people have noticed, you have movies that have somehow managed to decline in quality but nobody cares because you can churn out ten times as many. The nutritional quality of food has declined for 60 years as ultra-processed and industrially produced foods have taken over.
The worst scenario isn't actually that machines are intelligent and you lose your job, it's that they're stupid and you lose your job because in our quantitative glutton culture qualitative judgement is entirely gone to begin with
>The not-so-quiet goal of the LLM push by big tech was to homogenise intellectual labour such that it can be made fungible. When labour is fungible you can swap it out whenever you like for an alternative, decreasing the bargaining power of workers.
Especially if you replace people with robots that don't need days off and have the people train their replacements.
idk. I get more stuff done, faster, that I wouldn’t have been able to. You have to use it judiciously and with supervision - I can see how letting it get out of control would negate the benefits. But with good use, its undeniable.
It takes some time to learn how to get these systems to work well, and learn what they’re good for. I think people who don’t see the benefits either haven’t dug in enough or haven’t used them for things they’re good at.
Do coding agents help me with highly technical work where it’s some deep thought and discussion with coworkers and eventually I change five lines of code? Not really.
But I can debug a weird kernel panic or optimizer bug from a standing start in an hour when it would have taken me all day without these tools.
That’s been my experience, too.
I’m in the final prep for ship phase of a project that started February. It’s a bottom-to-top rewrite of a project that’s been shipping for two years, and took two years to write, initially.
I’m deliberately doing it all with the $20/month ChatGPT sub. After it ships, I’ll move to the $100/month sub; but I want to be able to say that the entire project was done on a low-tier LLM subscription.
your perception is that you get more stuff done faster, and that seems to be the conclusion that most using LLM's come to (including myself): but there are no productivity gains that are externally observable to show for it (yet).
That might be because of some lag, but another explanation might be that the tools are really effective at increasing someone's perception of their productivity while net productivity gains measured over long time windows are low or zero. Another explanation might be that the incompetent/negligent users are causing enough harm to nearly neutralize the gains brought by proficient / effective users. I don't know what the explanation is, but there is a mystery in the divergence between users' perceptions of their own productivity, and the observed productivity gains in the economy.
It would be a weird coincidence if a pretty different way of working turned out to be exactly as productive as the old way, no more and no less. I’m skeptical of these claims. Measuring programmer productivity is notoriously difficult.
It might be weird, but it might be the result of forces in equilibrium:
e.g. one explanation might be that time spent prompting is time spent not improving, or learning, so it would not be surprising then that the productivity gains might be similar in scale to the productivity lost from learning / improvement that never happens.
another explanation might be that prompting just delays work that will have to be done later when fixing errors. When encountering an error that the LLM doesn't fix on the first attempt the human-in-the-loop doesn't understand the problem very well: they will either pull the slot machine for a while until they hit lucky, or grit their teeth and sit down to understand what the code is doing in the excruciating and boring detail required to find and solve bugs, which is exactly the work that they had offloaded onto the LLM earlier.
the decision i have to make dozens if not hundreds times a day: do i actually look at this crap or trust it blindly and let it slide? I'm honestly reading maybe 20% tops of what "I" produce (and what other people post for my review) I think you do lose skills and understanding that way. Sure, you can always ask the robot to do the tldr for you, but.... yeah, something is still lost, not in a good way.
>We should all know by now that code is an input to the software development process and not an output: yet even the most forward-looking organisations still tactitly treat lines of code as a productivity metric
What exactly is this referring to? My thinking here is "code is a hypothesis", and you don't know if it's solid or not until it contacts the real world. (And ideally tests, and maybe a proof or two.) And what we're seeing lately is that the hypotheses often get disproven decades later (longstanding kernel bugs etc.)
Maybe because the actual work is done by the process, which may not even be the code itself, just its compiled form. In this code the code is both a communication tool (between humans) and the input that leads to the process. It's like a group of musicians collaborating on a music sheet. The final valuable form is a concert. The audience won't care about the music sheet.
The comments here gush about how they can write more code, but they don't say anything about the quality of the software being built and if they have improved on some points with it (cheaper maintenance, faster reaction to feedback, less bugs overall). Very much like a musician clamoring how he can write a lot more music sheets, but there's no concert in sight to listen to his music.
I agreed right upto the last quote. That made the post political, similar to the ones being written by the AI evangelists.
The thing about complex systems is that they are not predictable. Right now the answer is whatever you think is right, and a lot of scenarios seem plausible.
It is a fun intellectual moment trying to make sense, but maybe only time will tell how the dynamics work out.
it is a political issue though
The author claims that software has become no more secure - despite the avalanche of security fixes appearing for all software everywhere.
Never mind the more subtle issues.
I think the fundamental rebuttal to this is merely that, we’re still so early, the $1.5 trillion number is irrelevant for developing technologies in the same way two women can’t birth a baby in 4.5 months
The $1.5 trillion number is extremely relevant because it makes the revenue numbers the industry has to hit higher and there's an expectation to see progress sooner before funding starts getting pulled back.
>...it makes the revenue numbers the industry has to hit higher...
Yes. But.
Industry can miss its revenue targets, Oracle can go bankrupt (looking more and more likely) OpenAI, Anthropic and SpaceX might find "true value" at about 10% of current valuations (that feels right to me), all that can happen with the associated economic chaos... and still out of it comes world shaping new technology
Both things can be true
Certainly, but a flop of $1.5 trillion would create a deep and long trough. I think in that situation OpenAI and Anthropic probably don't survive as independent companies (where is the revenue? who would want to put more money in at that point?). In that situation there would definitely be a fire sale in the prices of licensing models (open weights are already pushing this way the hell down), semiconductors, data centers, and compute in general. And like in that situation, who knows what products come out of that dividend of cheap stranded assets? It might not even be AI related. You can do a lot of things with a lot of cheap GPU power. This boom-bust cycle is nothing new, especially to the tech industry. This deep crash outcome is the risk that a bet of $1.5 trillion makes. And it makes the current paradigm of coding agents and chatbots less likely because it is so volatile.
Oracle can go bankrupt? Oracle was a license to print money for decades. If they go bankrupt, that is one insanely bad bet they made.
Oracle has bet the house on AI. Free cash flow is deeply negative with tons more capex guidance on the books. They are currently the largest non-financial corporate issuer of new debt in the corporate bond market. They are literally cutting their headcount to the bone to help fund this build out. If their compute deals do not pan out because their customers have liquidity issues or revenue stalls, they are in dire straits.
Given the advances since 2022 why would funding get pulled back? The endgame is replacing all office workers globally and so you get 10% of that market that's that's easily $1 trillion. A competent AI employee replaces a human the same way the car replaced the horse. Businesses will pay more for an AI employee that doesn't get sick or come in hung over over a human one and never goes to sleep. If OpenAI manages to crack that, and capture even 10% of the market globally, that's trillions.
Total addressable market doesn't pay interest expenses. Even if this technology really did have the potential to be as revolutionary as the move from the horse to the car, if you can't get there with what the world economy's liquidity can provide then you can't get there. Free cash flow is drying up and data centers depreciate. This creates a limit and if that limit is hit before the profit starts coming in it doesn't matter what the potential could be. Paying back interest is financial gravity and it exists today. And this isn't an appeal to Wall Street's short term profit motive, there just is an economic limit to what the capital markets can spend on a bet this big and this risky.
Yes, that's going on optimism. It's also possible that we're 80% there and the rest will take forever, while the loans and investments were taken out now.
I think an argument can be made that some software has gotten more secure.
I don’t think it can be denied that the models do show an ability to find security vulnerabilities that may have otherwise been missed
This is equally as biased as those who claim AI can just code all night autonomously for you. You don't have to use it to generate "fully LLM-generated PRs". It's true GitHub is flooded with poor-quality LLM slop, but that is not the only way to use it.
It's ironic the author links to Naur's paper because I use LLMs to dig through code faster, question my assumptions, review my drafts, or generate drafts for my review. It's not because I am bad at it, I used to be very proud of being able to do this better than others. Anyway, this does not lead to more "lines of code" as the author suggests and instead it can lead to higher quality code.
FWIW, I also don't believe you can let LLMs make critical judgement by somehow stringing together more LLMs. And I am also not making a claim on whether the $1.5T investment is proportional to its benefits. But to say "industry has nothing to show for it", or to bring up strawmen like "LLM-generated PRs" and "lines of code", makes me question whether the author has tried studying the applications of LLMs.
are open ai, anthropic, zai, deepseek, cursor etc not new players? that benchmark seems like one defined to never be good enough
the way i see, LLM's in their current shape are neither good enough to replace software engineers but they have become a necessary part of everyone tool kit. ergo, actual companies themselves aren't getting much benefit because their competitors are using the same tools and they can't fire their human labor either just it's just an extra cost. At my org, i see good engineers use LLM's in wise ways and bad engineers just let it write slop for them. What gets to me is the verbosity and noise though, i consider brevity, and curation to be hallmarks of intelligence but most people at work just spit out so many words in their design docs or code comment these days.
The reality is new technology that works, will get used for what it best works for.
There are things that LLMs remain uniquely suited for, while the echo chambers go for everything.
There's no requirement to use new technology. Maybe what you do, or how you do it is just fine, and that's OK.
Skepticism today can remind me of someone who went into a cave for 3-4 years with a dated take of LLMs on day 1 and not remember software improves, and LLMs are software.
There are no shortage of uniquely working solutions with LLMs if sone seeks to find them, and also the self-validating echo chamber that says that it doesn't if that's desired. Which parts of software development, or how software development may better happen differently with the involvement of AI remains to be seen.
it's not as good as the hype, but it's definitely revolutionary. i am still blown away at what I can achieve in 20 minutes with a couple of agents
"Well, actually, vim doesn't make you faster"
AI skeptics hate him. Here's how he doubled his productivity using AI with one simple trick.
You have to stop thinking like an employee or a worker bee, and start thinking like a boss.
Guess what, the work you give your boss isn't 100% gold either. And sometimes you are preoccupied, or tired, so what you deliver isn't the best of all possible deliverables. Sometimes you hallucinate, i.e. you are dead wrong when you think you are dead right.
This is the job of a boss: take fallible employees and turn what they produce into something actually valuable. The boss lets the grunts do the grunt work, and then they combine the output together, and do the due diligence, etc etc.
It's an entirely new skillset. But learning the new skillset isn't the real blocker--the real blocker is that you've got to stop thinking like a grunt and start thinking like an executive.
WHAT is it that you really want to do? Frame that question as clearly and as concretely as you can. Then farm out thee work to human or AI grunts, and be prepared to do your due diligence on the result.
... theres a lot of anecdotal evidence executives aren't good thinkers.
Why not replace all mid-execs with LLMs trained on every MBA textbook and linked-in blog post ? why stop at grunt coders, graphic designers and phone marketeers ?
Can we reduce the role of CEO to the following prompt : "make money, by any legal means"