> Code has always been expensive. Producing a few hundred lines of clean, tested code takes most software developers a full day or more. Many of our engineering habits, at both the macro and micro level, are built around this core constraint.
> ...
> Writing good code remains significantly more expensive
I think this is a bad argument. Code was expensive because you were trying to write the expensive good code in the first place.
When you drop your standards, then writing generated code is quick, easy and cheap. Unless you're willing to change your standard, getting it back to "good code" is still an equivalent effort.
There are alternative ways to define the argument for agentic coding, this is just a really really bad argument to kick it off.
In my experience, it’s even more effort to get good code with an agent-when writing by hand, I fully understand the rationale for each line I write. With ai, I have to assess every clause and think about why it’s there. Even when code reviewing juniors, there’s a level of trust that they had a reason for including each line (assuming they’re not using ai too for a moment); that’s not at all my experience with Codex.
Last month I did the majority of my work through an agent, and while I did review its work, I’m now finding edge cases and bugs of the kind that I’d never have expected a human to introduce. Obviously it’s on me to better review its output, but the perceived gains of just throwing a quick bug ticket at the ai quickly disappear when you want to have a scalable project.
There is demand for non scalable, not committed to be maintained code where smaller issues can tolerated. This demand is currently underserved as coding is somewhat expensive and focused on critical functions.
We have a somewhat complicated OpenSearch reindexing logic and we had some issue where it happened more regularly than it should. I vibecoded a dashboard visualizing in a graph exactly which index gets reindexed when and into what. Code works, a little rough around the edges. But it serves the purpose and saved me a ton of time
Another example, in an internal project we made a recent change where we need to send specific headers depending on the environment. Mostly GET endpoint where my workflow is checking the API through browser. The list of headers is long, but predetermined. I vibecoded an extension that lets you pick the header and allows me to work with my regular workflow, rather than Postman or cURL or whatever. A little buggy UI, but good enough. The whole team uses it
I'm not a frontend developer and either of these would take me a lot of time to do by hand
I've been in these situations before. If there's a known bug in an internal tool that would take the development team a day to investigate and fix - aka $10,000s - it's often smarter to send around an email saying "don't click the Froople button more than once, and if you do tell Benjamin and he'll fix it in the database for you".
Of course LLMs change that equation now because the fix might take a few minutes instead.
> If there's a known bug in an internal tool that would take the development team a day to investigate and fix - aka $10,000s - it's often smarter to send around an email saying "don't click the Froople button more than once, and if you do tell Benjamin and he'll fix it in the database for you".
How much will Benjamin's time responding to those calls cost in the long run?
Hopefully none, because your staff will read the email and not click the button more than once.
Or one of them will do it, Benjamin will glare at them and they'll learn not to do it again and warn their coworkers about it.
Or... Benjamin will spend a ton of time on this and use that to successfully argue for the bug to get fixed.
(Or your organization is dysfunctional and ends up wasting a ton of money on time that could have been saved if the development team had fixed the bug.)
Large companies are often very bad at organizing work, to the tune of increasing the cost of everything by a large multiple over what you'd think it should be. Most of that cost wouldn't be productive developer time.
You are setting up to say "I wouldn't tolerate that" for any example given, but if you look at the market and what makes people actually leave, instead of what makes people complain, then basically anything that isn't life-and-death, safety critical, big-money-losing, or data corrupting is tolerable. There's plenty of complaints about Microsoft, Apple, Gmail, Android, and all kinds of 3rd party niche business systems.
All the decades people tolerated blue-screens on Windows. All the software which regularly segfaulted years ago. The permeation of "have you tried turning it off and on again" into everyday life. The "ship sooner, patch later" culture. The refusal to use garbage collected or memory managed languages or formal verification over C/C++/etc because some bugs are more tolerable than the cost/effort/performance costs to change. Display and formatting bugs, e.g. glitches in video games. When error conditions aren't handled - code that crashes if you enter blank parameters. Bugs in utility code that doesn't run often like the installer.
One software I installed yesterday told me to disable some Windows services before the install, then the installer tried to start the services at the end of the install and couldn't, so it failed and finished without finishing installing everything. This reminded me that I knew about that, because that buggy behaviour has been there for years and I've tripped over it before; at least two major versions.
Another one I regularly update tells me to close its running processes before proceding with the install, but after it's got to that state, it won't let me procede and it has no way to refresh or rescan to detect the running process has finished. That's been there for years and several major versions as well.
One more famous example is """I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you’re leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.""" - Rasmus Lerdorf, creator of PHP. I've a feeling that was admitted about 37 Signals and Basecamp, it was common to restart Ruby-on-Rails code frequently, but I can't find a source to back that up.
You need to have the AI write an increasingly detailed design and plan about what to code, assess the plan and revise it incrementally, then have it write code as planned and assess the code. You're essentially guiding the "Thinking" the AI would have to perform anyway. Yes, it takes more time and effort (though you could stop at a high-level plan and still do better than not planning at all), but it's way better than one-shotted vibe code.
It shouldn't be any longer than the actual code, just have it write "easy pseudocode" and it's still something that you can audit and have it translate into actual coding.
TDD is a great way to start the plan, stubbing things it needs to achieve with E2E tests being the most important. You still need to read through them so it won't cheat, but the codebase will be much better off with them than without them.
We'd just be overloading "lessons" as well, and even more so because it takes more work to ground the concept, given its larger semantic distance from what we're describing.
> Even when code reviewing juniors, there’s a level of trust that they had a reason for including each line (assuming they’re not using ai too for a moment)
Even my seniors are just copy pasting out whatever Claude says. People are naturally lazy, even if they know what they’re doing they don’t want to expend the effort.
I hear you, but it seems quicker to predict whether the agent's solution is correct/sound before running it than to compose and "start" coding yourself. Understanding something that's already there seems like less effort. But I guess it highly depends on what you are doing and its level of complexity and how much you're offloading your authority and judgment.
I was careful to say "Good code still has a cost" and "delivering good code remains significantly more expensive than [free]" rather than the more aesthetically pleasing "Good code is expensive.
I chose this words because I don't think good code is nearly as expensive with coding agents as it was without them.
You still have to actively work to get good code, but it takes so much less time when you have a coding agent who can do the fine-grained edits on your behalf.
I firmly believe that agentic engineering should produce better code. If you are moving faster but getting worse results it's worth stopping and examining if there are processes you could fix.
Totally agreed. I’ve been reverse engineering Altium’s file format to enable agents to vibe-engineer electronics and though I’m on my third from scratch rewrite in as many weeks, each iteration improves significantly in quality as the previous version helps me to explore the problem space and instruct the agent on how to do red/green development [1]. Each iteration is tens of thousands of lines of code which would have been impossible to write so fast before so it’s been quite a change in perspective, treating so much code as throw away experimentation.
I’m using a combination of 100s of megabytes of Ghidra decompiled delphi DLLs and millions of lines of decompiled C# code to do this reverse engineering. I can’t imagine even trying such a large project for LLMs so while a good implementation is still taking a lot of time, it’s definitely a lot cheaper than before.
[1] I saw your red/green TDD article/book chapter and I don’t think you go far enough. Since we have agents, you can generalize red/green development to a lot of things that would be impractical to implement in tests. For example I have agents analyze binary diffs of the file format to figure out where my implementation is incorrect without being bogged down by irrelevant details like the order or encoding of parameters. This guides the agent loop instead of tests.
> I was careful to say "Good code still has a cost" and "delivering good code remains significantly more expensive than [free]" rather than the more aesthetically pleasing "Good code is expensive.
Which is nuance that will get overlooked or waved away by upper management who see the cost of hiring developers, know that developers "write code", and can compare the developer salary with a Claude/Codex/whatever subscription. If the correction comes, it will be late and at the expense of rank and file, as usual. (And don't be naive: if an LLM subscription can let you employ fewer developers, that subscription plus offshore developers will enable even more cost saving. The name of the game is cost saving, and has been for a long time.)
Sure, but clueless leadership is not a new thing. While big companies with structural moats can shamble along with a surprising amount of dysfunction (which is why they tolerate so many muppets in middle management), even they rely on some baseline of system integrity that will erode pretty quickly if they let go of the people who know how things work.
Don’t get me wrong, I think SWE headcounts will reduce over time, but the mechanism will be teams that know how to leverage AI effectively will dominate ones who don’t. This takes more market cycles though, and it’s even hard to nail down the specifics of these skills with the speed agentic coding tools are currently evolving. My advice is make yourself part of the second group, and worry less about bad management decisions that are inevitable.
> I chose this words because I don't think good code is nearly as expensive with coding agents as it was without them.
Still navigating this territory, but I think a lot of people are getting caught up on the idea that producing code is simply a matter of typing it at the keyboard.
One of the benefits of something like Claude Code isn't just the code it produces, but the ability to quickly try out ideas, get some feedback, AND THEN write the good code.
> than the more aesthetically pleasing
Agreed. What even is "good" code? So much of the bad code I write isn't necessarily that it's ugly, it's bad because it misses the mark. Because I made too many assumptions and didn't take the time to actual learn the domain. If I can eek out even a few more hours a week to actually build worthwhile solutions because I was able to focus a bit more, it's a win to me. My users in particular have a really difficult time imagining features without actually seeing them. They have a hard to articulating what's wrong/right without something tangible in front of them. It would be hard to argue that having the ability to quickly prototype and demo features to people is a bad thing.
This was the single worthwhile point behind “agile” development: getting new code in front of users as quickly as possible to know whether or not you’re building the right thing.
With agile that meant delivering something to evaluate every two weeks instead of 6 months or a year. Now with AIs maybe it should be a new version every day? Are current processes outside of writing the code capable of supporting that cadence? Do users even want to try new versions that often?
> I was careful to say "Good code still has a cost" ...
Misleading headline, with the qualifier buried six paragraphs deep. You have a wide enough readership (and well deserved too). Clickbait tactics feel a little out of place on your blog.
This is the chapter title for a sort-of book I'm working on, and it's the central philosophy I'm building the book around.
I'm not going to change a good chapter title (and I do think it's a good chapter title) just because people on Hacker News won't read a few paragraphs of content.
A dishonest title would be "Code is cheap now" or "Programming is cheap
now". I picked "Writing code is cheap now" to capture that specifically the bit where you type code into a computer is the thing that's cheap.
Fairly esoteric and self-serving definition of "writing code" if it represents just the typing part. I wouldn't call it a dishonest title, but perhaps not a fully honest one either.
Code is cheaper. Simple code is cheap. More complex code may not be cheaper.
The reason you pay attention to details is because complexity compounds and the cheapest cleanup is when you write something, not when it breaks.
This last part is still not fully fleshed out.
For now. Is there any reason to not expect things to improve further?
Regardless, a lot of code is cheap now and building products is fun regardless, but I doubt this will translate into more than very short-term benefits. When you lower the bar you get 10x more stuff, 10x more noise, etc. You lower it more you get 100x and so on.
I really like the idea of Ousterhout's tactical vs strategic programming. Where we either create a new feature as fast as possible vs focusing on architecture and keeping complexity in check.
I truly believe that LLMs are replacing tactical programming. Focusing on implementing features as fast as possible with not much regards to the overall complexity of a system.
Its more important then ever to focus on keeping complexity low at a system level.
I 'love' that folks are seemingly inching slowly towards more acceptance of crappy llm code. Because it costs marginally less to produce to production if you just pass some smoke tests? Have we not learned anything about technical debt and how it bites back hard? Its not even seniority question, rather just sane rational approach to our craft unless one wants to jump companies every few months like a toxic useless apple (not sure who would hire such person but world is big and managers often clueless).
There are of course various use cases, for few this is an acceptable tradeoff but most software ain't written once and never touched (significantly) again, in contrary.
> Have we not learned anything about technical debt and how it bites back hard?
I think LLMs are changing the nature of technical debt in weird ways, with trends that are hard to predict.
I've found LLMs surprisingly useful in 'research mode', taking an old and badly-documented codebase and answering questions like "where does this variable come from, and what are its ultimate consumers?" Its answers won't be as natural as a true expert's, but its answers are nonetheless useful. Poor documentation is a classic example of technical debt, and LLMs make it easier to manage.
They're also useful at making quick-and-dirty code more robust. I'm as guilty as anyone else of writing personal-use bash scripts that make all kinds of unjustified assumptions and accrete features haphazardly, but even in "chat mode" LLMs are capable of reasonable rewrites for these small problems.
More systematically, we also see now-routine examples of LLMs being useful at code de-obfuscation and even decompilation. These forward processes maximize technical debt compared to the original systems, yet LLMs can still extract meaning.
Of course, we're not now immune to technical debt. Vibe coding will have its own hard-to-manage technical debt, but I'm not quite sure that we have the countours well defined. Anecdotally, LLMs seem to have their biggest problem in the design space, missing the forest of architecture for the trees of implementation such that they don't make the conceptual cuts between units in the best place. I would not be so confident as to call this problem inherent or structural rather than transitory.
After the LLM helps untangle the mess, if you leave the mess in place, you will have to ask the LLM untangle it for you every time you need to make a change.
Better to work with the LLM to untangle the technical debt then and there and commit the changes, so neither you nor the LLM have to work so hard in the future.
I’ve even seen anecdotal evidence that code that’s easier for humans to work with is easier for LLMs to work with as well.
> taking an old and badly-documented codebase and answering questions like "where does this variable come from, and what are its ultimate consumers?"
Why do you even need an LLM for this? Code is formal notation, it’s not magic. Unless the code is obfuscated, even bad code is pretty clean on what they’re doing and how various symbols are created and used. What is not clear is “why” and the answer is often a business or a technical decision.
Once you are dealing with legacy codebase older than you, with very little comments and confusing documentation, you'd understand that LLM is god send for untangling the mess and troubleshooting issues.
The inching-towards-acceptance of crappy processes is quite influencer-driven as well, with said influencers if not directly incentivised by LLM providers, then at least indirectly incentivised by the popularity of outrageous exhortations.
There's definitely a chunk of the developer population that's not going to trade the high-craft aspects of the process for output-goes-brrr. A Faustian bargain if ever I saw one. If some are satisfied by what comes down to vibe-testing and vibe-testing, I guess we wish them well from afar.
I wouldn't say acceptance of crappy code. I think the issue is the acceptance of LLM plans with just a glance and the acceptance of code without any code review by the author at all because if the author would waste any more time it wouldn't be worth it anymore.
People aren't interested in long-term thinking when companies are doing layoffs for bullshit reasons and making vague threats about how most of us will have to go find a new career which causes a heck of a lot of stress and financial costs. That isn't being petty, it's having self-respect. They get the quality when the companies treat the craftspeople with respect.
I don't just have LLMs spit out code. I have them spit out code and then I try that code out myself - sometimes via reviewing it and automated tests, sometimes just by using it and confirming it does the right thing.
That upgrades the code to a status of generated and verified. That's a lot more valuable than code that's just generated but hasn't been verified.
If I throw it all away every time I want to make a change I'm also discarding that valuable verification work. I'd rather keep code that I know works!
I suspect that is where we will be going next - automated verification. At least to the point where we can pass it over the wall for user acceptance testing.
Is it possible to write Cucumber specs (for example) of sufficient clarity that allows an LLM agent team to generate code in any number of code languages that delivers the same outcome, and do that repeatedly?
Then we're at the point where we know the specs work. And is getting to the point where we know the specs work less effort than just coding directly?
I think the nuanced take on Joel's rant is this: it was good advice for 26 years. It became slightly less good advice a few months ago. This is a good time to warn overenthuastic people that it’s still good advice in 2026, and to start a discussion about which of its assumptions remain to be true in 2027 and later.
We're not writing code in a computer language any more, we're writing specs in structured English of sufficient clarity that they can be generated from.
> writing specs in structured English of sufficient clarity
What does "sufficient clarity" mean? And is it english expressive enough and free of ambiguities? And who is going to review this process, another LLM, with the same biases and shortcomings?
I code for a living, and so far I'm OK with using LLMs to aid in my day to day job. But I wouldn't trust any LLM to produce code of sufficient quality that I would be comfortable deploying it in production without human review and supervision. And most definitely wouldn't task a LLM to just go and rewrite large parts of a product because of a change of specs.
You'll get the same software in outcome terms. Which is what we want.
Tokens are cheaper than getting an individual to modify the code, and likely the tokens will get cheaper - in the same way compilation has (which used to be batched once a day overnight in the mainframe era).
Non-determinism is how the whole LLM system works. All we're doing with agents is adding another layer of reinforcement learning that gets it to converge on the correct output.
That's also how routing protocols like OSPF work. There's no guarantee when those multicast packets will turn up, yet the routes converge and networks stay stable.
I think this fear of non-determinism needs to pass, but it will only pass if evidence of success arises.
The problem is to know what to write. I spent a whole day yesterday to understand what the problem was with a PDF file we were failing to process. Once I understood the cause it took one line of code to fix it and another dozen of lines for a unit test. A LLM helped me to write the code to explore several possible candidate problems but it did not find the problem by itself.
So code is both cheaper (what the LLM wrote for me much faster than I could have typed it) and is also expensive (the only line that we deployed to production today.)
I think the cost and work remains the same. What has change is efficiency. Previously people had to manually program byte after byte. Then came C and streamlined it, allowing faster development.
With python I can write a simple debugging UI server with a few lines.
There are frameworks that allow me to complete certain tasks in hours.
You do not need to program everything from scratch.
The more code, the faster everything gets, since the job is mostly done.
We are accelerating, but we still work 9 to 5 jobs.
C, Python, and frameworks don't generate all-new code for every task: you're taking advantage of stuff that's thoroughly tested. That simple debugging UI server is probably using some well-tested libraries, which you can reasonably trust to be bug-free (and which can be updated later to fix any bugs, without breaking your code that relies on them). With AI-generated code, this isn't the case.
Depends on what you think with AI-generated code. Do you mean vibe-coded? If yes, then I agree, but there are also other scenarios of AI-generated code.
I use regularly AI in my hobby projects, it provides me feedback, proposed other libraries to use, or other solutions. It generates some classes for which I write tests. I also need to understand the code it generates. If I don't I don't use it. It does speed up my process of creation of code.
If other people also are accelerated lets say 30% then, everything is sped up, cheaper. I think many people use it AI like that. It is just a tool, like a hammer, with which you can harm yourself if you do not know how to use it.
> I think the cost and work remains the same. What has change is efficiency. Previously people had to manually program byte after byte. Then came C and streamlined it, allowing faster development.
I think you got your history wrong. People didn’t program bit by bit. They programmed on paper (flowcharts, pseudo-code, diagrams,…), then encoded that afterwards. There was a lot of programming languages before C like Lisp and APL (which are high-level, btw). Why would they waste precious computer time, when you could plan out procedures on a notepad or a whiteboard.
Yeah, I have to agree. Worth noting that deterministic "code-generation" systems have existed for quite some time. It's just that once you saw something like that being useful for your system, that gave pause to critique the existing system design.
Boilerplate is boilerplate, whether filling it in is purely mechanical or benefits from an LLM's fuzzy logic.
Yeah people going on and on about peerless human generated code reminds me of that scene in iRobot when the cop asks sonny “can a robot create a work of art?” And the robot replies “can you?”. In 30 years in this industry I’ve yet seen what I would describe as perfect and maintainable code. It’s an aspirational dream not SOP.
Definitely the market incentives for "good code" have never been worse, but I'm wouldn't be so sure the cost of migrating decent pieces of generated code to good code is worse than writing good code from whole cloth.
I find that implementing a sound solution from scratch is generally lower effort than taking something that already exists and making it sound.
The former: 1) understand the problem, 2) solve the problem.
The latter: 1) understand the problem, 2) solve the problem, 3) understand how somebody or something else understood & solved the problem, 4) diff those two, 5) plan a transition from that solution to this solution, 6) implement that transition (ideally without unplanned downtime and/or catastrophic loss of data).
This is also why I’m not a fan of code reviews. Code review is basically steps 1–4 from the second approach, plus having to verbally explain the diff, every time.
That's specious reasoning. Code reviews are a safeguard against cowboy coding, and a tool to enforce shared code ownership. You might believe you know better than most of your team members, but odds are a fresh pair of eyes can easily catch issues you snuck in your code that you couldn't catch due to things like PR tunnel vision.
And if your PR is sound, you certainly don't have a problem explaining what you did and why you did it.
Code reviews have their place. I just personally don’t like being the reviewer, because it’s more effort on your part than just writing the damn thing from scratch while someone else gets the credit for the result[0]. Of course, having multiple pairs of eyes on the code and multiple people who understand it is crucial.
[0] Reviews are OK if I enjoy working with the person whose work I’m reviewing and I feel like I’m helping them grow.
> ...
> Writing good code remains significantly more expensive
I think this is a bad argument. Code was expensive because you were trying to write the expensive good code in the first place.
When you drop your standards, then writing generated code is quick, easy and cheap. Unless you're willing to change your standard, getting it back to "good code" is still an equivalent effort.
There are alternative ways to define the argument for agentic coding, this is just a really really bad argument to kick it off.