I basically fully agree with this. I am not sure how to handle the ramifications of this in my day to day work yet. But at least one habit I have been forming is sometimes I find that even though the cost of writing code is immensely cheap, reviewing and validating that it works in certain code bases (like the millions of line mono repo I work in at my job) is extremely high. I try to think through, and improve, our testability such that a few hundred line of code change that modifies the DB really can be a couple of hours of work.
Also, I do want to note that these little "Here is how I see the world of SWE given current model capabilities and tooling" posts are MUCH appreciated, given how much you follow the landscape. When a major hype wave is happening and I feel like I am getting drowned on twitter, I tend to wonder "What would Simon say about this?"
> 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.
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.
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.
Computer programming is cheap. Software engineering is expensive.
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 the final step of verbally explaining the diff.
> This is also why I’m not a fan of code reviews.
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.
Spaghetti code was always a thing though
Code generation is cheap in the same way talk is cheap.
Every human can string words together, but there's a world of difference between words that raise $100M and words that get you slapped in the face.
The raw material was always cheap. The skill is turning it into something useful. Agentic engineering is just the latest version of that. The new skill is mastering the craft of directing cheap inputs toward valuable outcomes.
> The new skill is mastering the craft of directing cheap inputs toward valuable outcomes.
Strongly agree with this. It took me awhile to realize that "agentic engineering" wasn't about writing software it was about being able to very quickly iterate on bespoke tools for solving a very specific problem you have.
However, as soon as you start unblocking yourself from the real problem you want to solve, the agentic engineering part is no longer interesting. It's great to be solving a problem and then realize you could improve it very quickly with a quick request to an agent, but you should largely be focused on solving the problem.
Yet I see so many people talking about running multiple agents and just building something without much effort spent using that thing, as though the agentic code itself is where the value lies. I suspect this is a hangover from decades where software was valuable (we still have plenty of highly valued, unprofitable software companies as a testament to this).
I'm reminded a bit of Alan Watts' famous quote in regards to psychedelics:
> If you get the message, hang up the phone.
If you're really leveraging AI to do something unique and potentially quite disruptive, very quickly the "AI" part should become fairly uninteresting and not the focus of your attention.
It's funny that so many people are using AI and still hasn't really shown up in productivity numbers or product quality yet. I'm going to be really confused if this is still the case at the end of the year. A whole year of access to these latest agentic models has to produce visible economic changes or something is wrong.
My intuition from talking to people across different parts of the industry, is that adoption at bigger companies is really limited or slow, or totally banned. Additionally some developers are not seeing it help their specific roles all that much anyway. This is hard to level with success other people are having, but software is a super broad discipline which I think explains a lot of the mixed success stories.
It seems to depend a lot on the industry and niche you're in, working at an agency I get experience across many different projects and industries and sometimes you are just at the edge of AIs training and it can get very unhelpful. Noting many if not most companies are working on proprietary code in donain specific problems, that isn't all that surprising either.
I used to think this was a sign that AI code isn't really useful, but I've changed my tune (also I believe these numbers have changed in the last few months).
As an example: One of my most promising projects I was discussing with a friend and we realized together we could potentially use these tools to build a two person agency with no need to hire anyone ever. If this were to work, could theoretically make nice revenue and it shouldn't show up in any metric anywhere.
Additionally I've heard of countless teams cancelling their contracts with outsourced engineers because cheap but bad coders in India are worse that an LLM and still cost more. I'm not sure if there's a number around this activity, but again, these type of changes don't show up in the usual places.
My current belief is not that AI will replace traditional software engineering it will replace a good chunk of the entire model of software.
> If this were to work, could theoretically make nice revenue and it shouldn't show up in any metric anywhere.
Except production GDP, the standard measure of economic activity.
Correct me, but if two people create a SAAS that can replace a 50 people SAAS, compete on price and the competitor is forced out of the market, wouldn’t this show up as an reduction in GDP? Efficiency (GDP/time_worked) should be up though, and AFAIK it isn’t.
2 people are now producing what took 50 people previously.
What are the 48 other people doing now? Presumably some other economic activity.
>One of my most promising projects I was discussing with a friend and we realized together we could potentially use these tools to build a two person agency with no need to hire anyone ever. If this were to work, could theoretically make nice revenue and it shouldn't show up in any metric anywhere.
potentially...if this were to work...theoretically
shouldn't show up? I would worry that something with so many variables wouldn't show up.
>One of my most promising projects I was discussing with a friend and we realized together we could potentially use these tools to build a two person agency with no need to hire anyone ever...My current belief is not that AI will replace traditional software engineering it will replace a good chunk of the entire model of software
You're not following your last line to its logical conclusion regarding your own prospects: no one is going to buy the vibeslop your two person agency is selling because they'd rather create and maintain their own vibeslop instead of dealing with yours.
If you follow some of your thoughts to their logical conclusion you'll realize the parent is right: there will be limited productivity that ends up fueling the economy when nobody is buying each other's vibeslop.
We're not selling vibe slop, the "vibe slop" tools which work for one person enable of automation of tasks for the services we sell. Whether or not we use AI behind the scenes is entirely irrelevant to the service we're providing other than that it allows our margins to be higher and our speed of implementation to be faster.
I absolutely agree that it's not logical to think "oh we'll sell our AI stuff", that's the old model (which is just a variation on SaaS). I suspect a lot of HNers can't imagine a "product" that isn't code, but that's not at all what I'm describing.
The products that most people on HN have traditionally built are used by other companies to make money by allowing those processes to be scaled. AI, in many new cases, eliminates the need for a 'software' middle man. The case I'm describing is "I know how to make money doing X if only I could scale it up with out hiring people" and my offering is "I can scale it up without hiring people".
This is increasingly where I think the future of work is headed, and it's more than fine if you aren't convinced.
> it allows our margins to be higher and our speed of implementation to be faster
Faster than what? You will be faster than your previous self, just like all of your competitors. Where’s the net gain here? Even if you somehow managed to capture more value for yourself, you’ve stopped providing value to 5-10x that many employees who are no longer employed.
When costs approach zero on a large scale, margins do not increase. Low costs = you’re not paying anyone = your competitors aren’t paying anyone = your customers no longer have money = your revenue follows your costs straight to zero.
Companies that provide physical services can’t scale without hiring. A one-man “crew” isn’t putting a roof on a data center.
I want to be wrong. Tell me why you think any of this is wrong.
>funny that so many people are using AI and still hasn't really shown up in productivity numbers or product quality yet.
That's because the threat is now not other businesses, but your own users who decide to vibe-code their own "Claw" product instead of using your company's vibeslop, so there are no buyers for your single-week product. All these new harness developers are engaging in resume-driven development to save their own asses. The only ones that are not naked when the tide recedes are the ones that are able to jump to the next layer of abstraction on the infinite staircase, until the next tide comes five seconds later.
This is actually an old syndrome with technology. It takes a longt ime for the effect to be reliably measured. Famously, it took many years for the internet itself to show up in significant productivity gains (if the internet is actually useful why don't the numbers show that? - a common comment in the 1990s and 2000s). So it seems to me we're just the usual dynamic here. Productivity in trillion-dollar economies do not turn on a dime
I think if you're doing front-end development AI is good. If you are reading a db and sending a json to said webpage AI is decent, if you are doing literally anything else AI is next to useless.
At least, in my own experience.
I wouldn't say it hasn't shown up. The number of ShowHN's per weekend has definitely gone up, and while that isn't rigorous scientific proof, I'd consider is a leading edge indicator of something. Unfortunately, we as an industry have yet to agree on anything approaching a scientific measure of productivity, other than to collectively agree that Lines of Code is universally agree that LoC is terrible. Thus even if someone was able to quantify that, say, they're having days where they generate 5000 LoC when previously they were getting O(500) LoC, that's not something we could agree upon as improved productivity.
So then the question is, lis there anything other than feels to say productive has or has not gone up? What would we accept as actual evidence one way or another? Commits-per-day is similarly not a good measure either. Jira tickets and tshirts sizes? We don't have a good measure, so while ShowHN's per weekend is equally dumb, it's also equally good in the bag of lies, damn lies, and statistics.
There was a post a few days ago about how the quality of SnowHN had gone down with people asking how they could block this category of submissions - so I wouldn't be too quick to equate an increase in ShowHN with anything positive.
That's a great insight about iterating on bespoke tools. I have seen the most speed up when diving into new tools, or making new tools as AI can make the initial jump quite painless, and I can get straight to the problem solving. But I get barely any speedup using it on legacy projects in tools I know well. Often enough it slows me down so net benefit is nil or worse.
Another commentor said it makes the easy part easy, and the hard part harder, which I resonate with at the moment.
I am pretty excited by being able to jump deep into real problems without code being the biggest bottleneck. I love coding but I love solving problems more, and coding for fun is very different to coding for outcomes.
Or another way of looking at it: just because digging a ditch became cheap and fast with the backhoe doesn't mean you can just dig a bunch of ditches and become rich.
Yeah but there were a lot less ditch diggers in the world after the invention of the backhoe
If true, only because people knew where to dig and did it with purpose.
Indeed: The act of actually typing the code into an editor was never the hard or valuable part of software engineering. The value comes from being able to design applications that work well, with reasonable performance and security properties.
It wasn't the hard or valuable part of software engineering, but it was a very time-consuming part. That's what's interesting about this new era - the time-consuming-but-easy bit has suddenly stopped being time-consuming.
Agreed, often see cope from managers along the line of “writing the code was never the bottleneck”. Well, sure felt like it.
For most people who can type with more than 2 fingers, thinking what to type is slower than typing it.
Then why did most software fail to do that even before the advent of LLMs?
Because designing systems that work well is difficult. It takes years of experience to develop the muscle memory behind quality systems architecture. Writing the code is an implementation detail (albeit a large one).
Are we sure it's not failing anymore after the advent of LLMs?
Because coding bootcamps and CS programs were churning out squillions of people who could type the code but had poor design and analytical skills, because there was a time where being able to implement Dijkstra on a whiteboard would get you 400k at a FAANG.
And you think these people will now produce better results with the assistance of an LLM that was trained on their work?
No, that's the opposite of what I think.
Bootcamp grads are basically obsolete now. The real skill has always been the ability to make good design decisions and that's still the case in the LLM era.
Raising $100M doesn’t even mean you have a good idea or an idea people like or an idea you can even make money on.
It’s probably a better indicator of a good business idea than if you get slapped in the face…
I mean, juicero got the money instead of the slaps in the face it deserved. And there's thousands of startup like that. I think VCs are terrible at picking and a dice would probably do a better job.
And yet, who would you trust more - a CEO that raised 100M on their "vision" or someone who got slapped in the face?
A raise is random noise, not signal, based a confidence game within the VC ecosystem. LP capital call->GP gamble based on waves arms around considering VC underperforms as an asset [1] [2] class even when accounting for the grand slam returns. It's 0DTE options gambling dressed up as skill and an art. But, you know [3] [4] [5], lottery still pays out sometimes.
TLDR A raise is not robust signal in this regard.
[1] https://news.ycombinator.com/item?id=7260137
[2] https://www.linkedin.com/posts/peterjameswalker_most-venture...
[3] https://en.wikipedia.org/wiki/There%27s_a_sucker_born_every_...
I think we’re falling into a trap of overestimating the value of incrementally directing it. The output is all coming from the same brain so what stops someone just getting lucky with a prompt and generation that one-shots the whole thing you spent time breaking down and thinking about. The code quality will be the same, and unless you’re directing it to the point where you may as well be coding the old way, the decision-making is the same too.
The cost of code never lived in the typing — it lived in the intent, the constraints, and the reasoning that shaped it. LLMs make the typing cheap, but they don’t make the reasoning cheap. So the economics shift, but the bottleneck doesn’t disappear.
For most non-hobby project, the cost of code was in breaking a working system (whether by a bona fide bug, or a change in some unspecified implicit assumption). That made changes to code incredibly expensive - often much more than the original implementation.
It sounds harsh, but over the lifetime of a project, 10-lines/person/day is often a high estimate of the number of lines produced. It’s not because humans type so slow - it is because after a while, it’s all about changing previously written lines in ways that don’t break things.
LLMs are much better at that than humans, if the constraints and tests are reasonably well specified.
> if the constraints and tests are reasonably well specified.
if they are, then why would a human be so slow? You're not comparing the same situation.
> LLMs make the typing cheap, but they don’t make the reasoning cheap.
LLMs lower the cost of copy/pasting code around, or troubleshooting issues using standard error messages.
Instead of going through Stack Overflow to find how to use a framework to do some specific thing, you prompt a model. You don't even need to know a thing about the language you are using to leverage a feedback loop.
LLMs lower the cost of a multitude of drudge work in developing software, such as having to read the docs to learn how a framework should be used to achieve a goal. You still need to know what you are doing, but you don't need to reinvent the wheel.
I'm going to shill my own writing here [1] but I think it addresses this post in a different way. Because we can now write code so much faster and quicker, everything downstream from that is just not ready for it. Right now we might have to slow down, but medium and long term we need to figure out how to build systems in a way that it can keep up with this increased influx of code.
> The challenge is to develop new personal and organizational habits that respond to the affordances and opportunities of agentic engineering.
I don't think it's the habits that need to change, it's everything. From how accountability works, to how code needs to be structured, to how languages should work. If we want to keep shipping at this speed, no stone can be left unturned.
[1]: https://lucumr.pocoo.org/2026/2/13/the-final-bottleneck/
I don’t think we can expect all workers at all companies to just adopt a new way of working. That’s not how competition works.
If agentic AI is a good idea and if it increases productivity we should expect to see some startup blowing everyone out of the water. I think we should be seeing it now if it makes you say ten times more productive. A lot of startups have had a year of agentic AI now to help them beat their competitors.
We're already seeing eye-watering, blistering growth from the new hot applied AI startups and labs
Imo the wave of top down 'AI mandates' from incumbent companies is a direct result of the competitive pressure, although it probably wont work as well as the execs think it will
that being said even Dario claims a 5-20% speedup from coding agents, 10x productivity only exists in microcosm prototypes, or if someone was so unskilled oneshotting a localhost web app is a 10x for them
"eye-watering, blistering growth from the new hot applied AI startups and labs"
Could you give us a few examples?
Claude Cowork was apparently built in less than two weeks using Claude Code, and appears to be getting significant usage already.
Only a personal anecdote, but the humans I know that have used it are all aware of how buggy it is. It feels like it was made in 2 weeks.
Which gets back to the outsourcing argument: it’s always been cheap to make buggy code. If we were able to solve this, outsourcing would have been ubiquitous. Maybe LLMs change the calculus here too?
That's certainly a good example of a tool developed quickly thanks to AI assistance.
But coding assistance tools must themselves be evaluated by what they produce. We won't see significant economic growth through using AI tools to build other AI tools recursively unless the there are companies using these tools to make enough money to justify the whole stack.
I believe there are teams out there producing software that people are willing to pay for faster than they did before. But if we were on the verge of rapid economic growth, I would expect HN commenters to be able to rattle these off by the dozen.
claude code 1B+ arr
ant 10xing ARR, oai
harvey legora sierra decagon 11labs glean(ish) base10(infra) modal(infra) gamma mercor(ish) parloa cognition
regulated industries giving these companies 7/8-fig contracts less than 2 years from incorporation
AI has been a lifesaver for my low performing coworkers. They’re still heavily reliant on reviews, but their output is up. One of the lowest output guys I ever worked with is a massive LinkedIn LLM promoter.
Not sure how long it’ll last though. With the time I spend on reviews I could have done it myself, so if they don’t start learning…
> With the time I spend on reviews I could have done it myself, so if they don’t start learning…
Then? Your job is still to review their code. If they are your coworker, you can not fire them.
Then just start rubber-stamping their code. Say you "vibe" read it.
OpenClaw went from first commit in late November to Super Bowl commercial (it's meant to be the tech behind that AI.com vaporware thing) in February.
(Whether you think OpenClaw is good software is kind of beside the point.)
OpenClaw is not going to be a thing in 6 months. The core idea might exist but that codebase is built on a house of cards and is being replicated in 10% of the code.
I don’t think anyone is arguing against code agents being good at prototypes, which is a great feat, but most SWE work is built on maintaining code over time.
It’s very much not beside the point. Productivity is measured in how much value you get out from the hours your workers put in.
But that only gets you to a philosophical argument about what "value" is. Many would argue that being able to get your thing into a Super Bowl commercial is extremely valuable. I definitely have never built anything that did.
It's very much imperfect, but the only consistently agreed upon and useful definition of "value" we have in the West is monetary value, and in that sense, we have at least a few major examples of AI generating value rapidly.
OK but that also means VR was a success, and web 3, and NFTs.
Well, yes, these were definitely a success for some. And I personally still believe that VR will be a success in the longer-term.
In any case, I agree with the grandparent post about the distinction between being successful and good.
One of the most interesting aspects is when LLMs are cheap and small enough so that apps can ship with a builtin one so that it can adjust code for each user based on input/usage patterns.
The clear intent is to stop allowing regular people to be able to compute...anything. Instead, you'll be given a screen that only connects to $LLM_SERVER and the only interface will be voice/text in which you ask it to do things. It then does those things non-deterministically, and slower than they would be done right now. But at least you won't have control over how it works!
Weather or not the intent is as nefarious as you suggest, that type of UI is going to be a boon for a lot of people. Most people on the planet are incredibly computer illiterate.
If this could ever happen, there will be no point in GUI apps anymore, your AI assistant or what have you will just interact with everything on your behalf and/or present you with some kind of master interface for everything.
I don't see a bunch of small agents in the future, instead just one per device or user. Maybe there will be a fleeting moment for GUI/local apps to tie into some local, OS LLM library (or some kind of WebLLM spec) to leverage this local agent in your app.
>If this could ever happen, there will be no point in GUI apps anymore, your AI assistant or what have you will just interact with everything on your behalf and/or present you with some kind of master interface for everything.
sort of how the hammer is the most useful tool ever and all we have to do is to make every thing that needs doing look like a nail.
Agents will still have to communicate with each other, the communication protocols, how data is stored, presented and queried will be important for us to decide?
Will we stop using web browsers as we understand them today in the next few decades in favor of only interacting with agents? Maybe.
I've heard this referenced multiple times and I have yet to hear the value be clearly articulated. Are you saying that every user would eventually be using a different app? Wouldn't it eventually get to the point that negates the need for the app developer anyways since you would eventually be unable to offer any kind of support, or are we just talking design changing while the actual functionality stays the same? How would something like this actually behave in reality?
I don't know!
These are valid points, taken to the extreme we will have apps that cannot be supported.
In short term, we already have SQL/reports being automated. Lovable etc is experimenting with generating user interfaces from prompts, soon we will have complete working apps from a prompt. Why not have one core that you can expand via a prompt?
I am currently studying and depending heavily on Anki, its been amazing to use Claude Code to add new functionality on the fly. Its a holy mess of inconsistent/broken UX but it so clearly gives me value over the core version. Sometimes it breaks, but CC can usually fix it within a prompt or two.
> I've heard this referenced multiple times and I have yet to hear the value be clearly articulated.
Me too, and I see this as _incredibly_ wasteful.
LISP returns!
>but medium and long term we need to figure out how to build systems in a way that it can keep up with this increased influx of code.
Why? Why do we need to "write code so much faster and quicker" to the point we saturate systems downstream? I understand that we can, but just because we can, does'nt mean we should.
> to the point we saturate systems downstream
But that's point of TFA, no? Now that writing code is no longer the bottleneck, the upstream and downstream processes have become the new bottlenecks, and we need to figure out how to widen them.
As I see it, the end goal for all of this is generating software at the speed of thought, or at least at the speed of speech. I want the digital butler to whom I could just say - "I'm not happy with the way things happened to day, please change it so that from here on, it'll be like x" - and it'll just respond with "As you wish", and I'll have confidence that it knows me well enough and is capable enough to have actually implemented the best possible interpretation of what I asked for, and that the few miscommunications that do occur would be easy to fix.
We're obviously not close that yet, but why shouldn't we build towards it?
> Now that writing code is no longer the bottleneck
I think it’s contestable that writing the code was ever the main bottleneck.
> As I see it, the end goal for all of this is generating software at the speed of thought, or at least at the speed of speech.
The question is what distinguishes that from having AGI, and if the answer is “nothing”, then that will change the whole game entirely again.
Oh, absolutely, my vision depends on AGI (and maybe even ASI), and I definitely agree that it'll be a whole new ball game.
If we want to continue to ship at that speed we will have to. I’m not sure if we should, but seemingly we are. And it causes a lot of problems right now downstream.
We were already rushing and churning products and code of inferior quality before AI (let's e.g. consider the sorry state of macOS and Windows in the past decade).
Using AI to ship more and more code faster, instead of to make code more mature, will make this worse.
I want to use AI to ship more and more code faster and better. If AI means our product quality goes down we should figure out better ways to use it.
Shouldn't you want to ship less code that does more? Since when was LoC the relevant benchmark for engineering?
Less code isn't as important as it used to be, because the cost of maintaining (simple) code has gone down as well.
With coding agent projects I find that investing in DRY doesn't really help very much. Needing to apply the same fix in two places is a waste of time as a human. An agent will spot both places with grep and update them almost as fast as if there was just one.
It's another case where my existing programming instincts appear to not hold as well as I would expect them to.
When you talk about maintaining code, do you mean having the LLM do it and you maintain a write-only codebase? Because if you're reading the code yourself and you have a bloated tangled codebase it would make things much harder right?
Is the goal basically a codebase where your interactions are mediated through an LLM?
I'm betting on it meaning the product quality going down - and technical debt increasing, which will be dealt with more AI in a downward spiral. Meanwhile college CS majors wont ever bother learning the basics (as AI will handle their coursework, and even their hobby work). Then future AI will train on previous AI output, with the degredation that brings...
I was having this conversation at work, where if the promise of AI coding becomes true and we see it in delivery speed, we would need to significantly increase the throughput of all other aspects of the business.
Totally agree - that's what I was trying to get at with "organizational habits". The way we plan, organize and deliver software projects is going to radically change.
I'm not ready to write about how radically though because I don't know myself!
> If we want to keep shipping at this speed
Do we? Spewing features like explosive diarrhea is not something I want.
The linked article is worth reading alongside this one.
The thing I'd add from running agents in actual production (not demos, but workflows executing unattended for weeks): the hard part isn't code volume or token cost. It's state continuity.
Agents hallucinate their own history. Past ~50-60 turns in a long-running loop, even with large context windows, they start underweighting earlier information and re-solving already-solved problems. File-based memory with explicit retrieval ends up being more reliable than in-context stuffing - less elegant but more predictable across longer runs.
Second hard part: failure isolation. If an agent workflow errors at step 7 of 12, you want to resume from step 6, not restart from zero. Most frameworks treat this as an afterthought. Checkpoint-and-resume with idempotent steps is dramatically more operationally stable.
Agree it's not just habits - the infrastructure mental model has to change too. You're not writing programs so much as engineering reliability scaffolding around code that gets regenerated anyway.
The cost has always been the sum of:
1. The time spent to think and iteratively understand what you want to build 2. The time spent to spell out how you want to build it
The cost for #2 is nearly zero now. The cost for #1 too is slashed substantially because instead of thinking in abstract terms or writing tests you can build a version of the thing and then ground your reasoning in that implementation and iterate until you attain the right functionality.
However, once that thing is complex enough you still need to burn time on identifying the boundaries of the various components and their interplay. There is no gain from building "a browser" and then iterating on the whole thing until it becomes "the browser". You'll be up against combinatorial complexity. You can perhaps deal with that complexity if you have a way to validate every tiny detail, which some are doing very well in porting software for example.
AI agents is like outsourcing to a bad team offshore - yeah they can build and maybe cheap but requires lots of hand holding.
I don't agree that the code is cheap. It doesn't require a pipeline of people to be trained and that is huge, but it's not cheap.
Tokens are expensive. We don't know what the actual cost is yet. We have startups, who aren't turning a profit, buying up all the capacity of the supply chain. There are so many impacts here that we don't have the data on.
Writing code is cheaper than ever. Maintaining it is exactly the same as ever and it scales with the LOC.
Code is still liability but it's undeniable that going from thought to running code is very cheap today.
You completely ignored the post you're replying to.
To recap, the author disagrees that writing code is cheap, because we've collectively invested trillions of dollars and redirected entire supply chains into automating code generation. The externalities will be paid for generations to come by all of humanity; it's just not reflected in your Claude subscription.
GP is not totally ignoring the post he replied to: we have models that are basically 6-months behind closed SOTA models and that we can run in the cloud and we fully know how much these costs to run.
The cat is out of the bag: compute shall keep getting cheaper as it's always been since 60 years or something.
It's always been maintenance that's been the killer and GP is totally right about that.
And if we look at a company like Cloudflare who basically didn't have any serious outage for five years then had five serious outages in six months since they drank the AI kool-aid, we kinda have a first data point on how amazing AI is from a maintenance point of view.
We all know we're generating more lines of underperforming, insecure, probably buggy, code than ever before.
We're in for a wild ride.
Maintaining it is becoming more costly. The increasing burden of review on FOSS maintainers is one example. AWS going down because an agent decided to re-write a piece of critical infrastructure is another. We are rapidly creating new kinds of liability.
This burden of review will go down as FOSS maintainers involve AI more.
unlikely, FOSS is mostly driven by zero-cost maintenance but AI tools needs money to burn. So only few FOSS project will receive sponsored tools and some definitely reject to use by ideological reasons (for example it could be considered as poison pill from copyright perspective).
> We don't know what the actual cost is yet.
We kind of do? Local models (thought no state of the art) set a floor on this.
Even if prices are subsidized now (they are) that doesn't mean they will be more expensive later. e.g. if there's some bubble deflation then hardware, electricity, and talent could all get cheaper.
> Here's what I mean by "good code":
> [...]
> - It’s simple and minimal - it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future.
But do the humans need to actually understand the code? A "yes" means the bottleneck is understanding (code review, code inspection). A "no" means you can go faster, but at some risk.
> But do the humans need to actually understand the code? A "yes" means the bottleneck is understanding (code review, code inspection). A "no" means you can go faster, but at some risk.
I always thought of things like code reviews as semi pseudo-science in most cases. I've sat through meetings where developers obviously understand the code that they are reviewing, but where they didn't understand anything about the system as a whole. If your perfect function pulls on 800 external dependencies that you trust. Trust because it's too much of a hazzle to go through them. I'd argue that in this situation you don't understand your code at all. I don't think it matters and I certainly don't think I'm better than anyone else in this regard. I only know how things work when it matters.
If anything, I think AI will increase human understanding without the need to write computer unfriendly code like "Clean Code", "DRY" and so on.
Writing code has been cheap for a while now.
Writing good software is still expensive.
It's going to take everybody a while to figure that out (just like with outsourcing)
Dollars to donuts that at some point someone is going to discover that senior engineers spend just as much time reviewing, fixing, and dealing with blowups caused by, shitty AI-generated code produced by more junior coders....as they did providing various forms of mentoring of said junior coders, except those junior coders become better developers in the latter case, whereas the AI generates the same shitty results or even worse, inconsistent quality code.
Yeah, it’s odd watching the outsourcing debate play out again. The results are gonna be the same.
Which is a shame, cause I think LLMs have a lot more use for software dev than writing code. And that’s really what’s going to shift the industry - not just the part willing to cut on quality.
The interesting thing nobody's talking about here is that cheap code generation actually makes throwaway prototypes viable. Before, you'd agonize over architecture because rewriting was expensive. Now you can build three different approaches in a day and pick the one that works.
The real cost was never the code itself. It was the decision-making around what to build. That hasn't gotten cheaper at all.
This feels to me like peak sfba mentality on par with "move fast and break things". Outside of trying to create a unicorn, is this really how people create things?
It seems to me that in order to obtain the ability to build things that other people like, you need to go through the process of creating things they won't. Like a painter needs to paint a bunch of crappy paintings to learn how to create a good painting. If you have the LLM create these throwaway prototypes, how will you even know when you come across a good idea and how will you be able to build it.
This is how successful things are created. By iterating on less successful things until they become successful.
The cost of iterating (with software) dropped by a few orders of magnitude in the last few months.
But you need to actually be the one doing the iterating, you can't outsource it. The entire point to doing the iteration is the process, not the artefacts.
I'm finding I can iterate significantly faster if the coding agent is doing the typing for me, and learn at a faster rate as a result.
Hmm interesting, I didn't realise people were using it as a typing replacement instead of having it work agentically. Does that mean when you want to change a line of code somewhere, you just prompt the LLM to replace line 334 with your changes etc? So do you not use the LLM autonomously at all then? Sounds like it since you're still doing the iteration yourself.
the real shift is that throwaway code became viable for production workflows. i used to spend days writing reusable utility libraries. now i generate single-purpose scripts, run them once, and delete them. the economics of code reuse have fundamentally changed when generation is cheaper than comprehension.
the downstream bottleneck is real though. built a video production pipeline recently - generating the python glue code took maybe 10% of total project time. the other 90% was testing edge cases, tuning ffmpeg parameters, and figuring out why API responses were subtly different between providers. cheap code just means you hit the hard problems faster.
It's like the allegory of the retired consultant's $5000 invoice (hitting the thing with a hammer: $5, knowing where to hit it: $4995).
Yeah, coding is cheaper now, but knowing what to code has always been the more expensive piece. I think AI will be able to help there eventually, but it's not as far along on that vector yet.
Possibly even more important than knowing where to hit it (what to code), is knowing where not to hit it (what not to code). Hitting the thing in the wrong place can lead to catastrophe. Making a code change you don't need can blow up production or paint your architecture into a corner.
AIs so far seem to prefer addition by addition, not addition by subtraction or addition by saying "are you sure?".
This doesn't mean that "code is cheap" is bad. Rather, it means that soon our primary role will be to guide AIs to produce a high proportion of "code that was cheap", while being able to quickly distinguish, prevent, and reject "cheap code".
Code is cheap is the same as saying "Buying on credit is easy". Code is a liability, not an asset.
Code you can’t just throw away is a liability because you have to keep supporting it / servicing it. Claude Code and friends also change that part of the cost equation:
You might not get gcc/llvm level optimization from a newly built compiler - but if you had a home-built one, which took $15,000/month engineer to support (for years!) you can now get a new one for $20,000 every 3 months, for a 50% cost saving, each time changing your requirements (which you couldn’t do before).
Code used to be a liability, like a car or an apartment for the average person. Now it’s a liability, like a car or apartment for Bill Gates.
I would normally agree, but I think the "code is a liability" quote assumes that humans are reading and modifying the code. If AI tools are also reading and modifying their own code, is that still true?
What happens when there’s a service outage and you cannot debug code without an agent?
Like any service outage out of their control, people will find other things to do until it’s over.
You have to be able to express the change you want in natural language. This is not always possible due to ambiguity.
Next to that, eventually you run into the same issue that we humans run into: no more context windows.
But we as software engineers have learned to abstract away components, to reduce the cognitive load when writing code. E.g., when you write file you don't deal with syscalls anymore.
This is different with AI. It doesn't abstract away things, which means you requesting a change might make the AI make a LOT of changes to the same pattern, but this can cause behavior to change in ways you haven't anticipated, haven't tested, or haven't seen yet.
And because it's so much code to review, it doesn't get the same scrutiny.
>Code is a liability, not an asset
Then "AI" code is even more of a liability.
I think you mean to say, "code you don't understand is a liability, not an asset"
But please correct me if I'm wrong.
No I said what I meant. Code is a liability, though to your point, code you don't understand is an even bigger liability.
Even if I understand all my code, when I go to make changes, if it's 100k lines of code vs 2k lines of code, it's going to take more time and be more error prone.
Even if I understand all my code, the intern I hired last week won't and I'll have to teach it to them.
Even if I understand all my code, I don't remember everything all the time and I can forget about an edge case handed in thousands of lines of code.
Even if I understand all my code, I don't understand my co-workers code, and they don't understand mine.
Even if I understand all my code, I might not want to work for this company the rest of my life.
I've worked at so many places in my career that "not understanding code" is not an excuse. It is a skill to be able to read and follow code and get up to speed quickly, even on shit codebases. But "AI" generated code makes that so much more difficult, and the "AI" isn't going to walk you through it, and neither will your new coworkers. We aren't in a race to the bottom with "AI", we're in a speedrun to the bottom, and I don't think it's going to end up going too well for whatever developers are left in a few years.
This fact is opening the floodgates of low-end products, which are somehow better than nothing, but are embarrassing to use.
True, however as these products have been designed and coded by LLMs from the ground up in 2025+, they are generally using modern (typed even) languages, the latest version of third party libraries, usually have documentation of sorts... sometimes they even have test suites.
As such, they can often be improved as easily as one can prompt, which is much faster and easier than before. Notably in the FOSS world where one had to ask the maintainer, get ghosted for a year and have them go back with a "close: wontfix (too tedious)".
I've tried very earnestly to use opus 4.5 to get rid of some backlog tasks that were too tedious to do manually. It turns out that they're still extremely tedious because I have to make every single non trivial decision for the model, unless I don't care one iota about the long term sustainability of the code base. And by long term, I mean more than a week. They're good for saving keystrokes or doing fuzzy searches for me. "Design"? No, that is an anthropomorphism.
Better languages do not necessarily mean better architectural decisions, or even better performance, unless the humans pressure for that and burn tokens on that. With no engineer in the room, more technical issues will be left unnoticed and unaddressed.
Compare it to visual arts. With a guidance form an artist, AI tools can help create wonderful pictures. Without such guidance, or at least expert prompting, a typical one-shot image from Gemini is... well, at best recognizable as such.
I think there's a good parallel with AI images - generating pictures has gotten ridiculously easy and simple, yet producing art that is meaningful or wanted by anyone has gotten only mildly easier.
Despire the explosion of AI art, the amount of meaningful art in the world is increased only by a tiny amount.
But the amount of pleasing useful art has gone up x1000; If I had a blog, I would now have access to art that would be a perfect fit for my words, whereas 5 years ago, I would have to do with a my own (talent-lacking) doodles.
Would some people prefer no art/illustration to AI generated art? Sure. But even more would prefer no art to my doodles.
Software is rarely an end unto itself.
Thus, "Code" is a liability; Producing excess liabilities 'cheaply' is still a loss.
You only ever want to have just enough code to accomplish the task at hand.
LLMs may help you get to just enough faster, but you'll only know that you are there after doing the second 90%.
Writing code is cheap.
Owning code is getting more and more expensive.
SWEs sacrificed their jobs so that SREs could have unlimited job security.
I'm very curious to see how this will affect the job market. All the recent CS grads, all the coding bootcamp graduates - where would they end up in? And then there's medium/senior engineers that would have to switch how they work to oversee the hordes of AI agents that all the hype evangelists are pushing on the industry.
Not an employee market, that's for sure.
>> oversee the hordes of AI agents
This is the thing I don't really get. I enjoy tinkering with AI and seeing what it comes up with to solve problems. But when I need to write working code that does anything beyond simple CRUD, it's faster for me to write the code than it is to (1) describe the problem in English with sufficient detail and working theory, then (2) check the AI's work, understand what it's written, de-duplicate and dry it out.
I guess if I skipped step 2, it might save time, but it would be completely irresponsible to put it into production, so that's not an option in any world where I maintain code quality and the trust of my clients.
Plus, having AI code mixed into my projects also leaves me with an uneasy sense of being less able to diagnose future bugs. Yes, I still know where everything is, but I don't know it as well as if I'd written it myself. So I find myself going back and re-reviewing AI-written code, re-familiarizing myself with it, in order to be sure I still have a full handle on everything.
To the extent that it may save me time as an engineer, I don't mind using it. But the degree to which the evangelists can peddle it to the management of a company as a replacement for human coders seems highly correlated with whether that company's management understood the value of safe code in the first place. If they didn't, then their infrastructure may have already been garbage, but it will now become increasingly unusable garbage. At some point, I think there will be a backlash when the results in reality can no longer be denied, and engineers who can come in and clean up the mess will be in high demand. But maybe that's just wishful thinking.
I'm in the same boat. Too often for me it feels easier to write code that I want to see by myself instead of opening some AI tool where I would have to describe what I need in plain English. After which I'd still have to review the code to make sure it does do what was requested.
Perhaps you have to be certain type of person or work in a peculiar company where second step (review) can be ignored as long as AI says that it does. Hardcore YOLO life.
the top % of talent is still extremely hard to get, perhaps moreso
saw an article recently where every sector is seeing a reduction in IT/devs except for tech and ai companies
if your company is in a sector where eng is a cost-center and the product is not directly tied to your engineers / your company is pushing for efficiency it's an employer's market
> 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.
> At the macro level we spend a great deal of time designing, estimating and planning out projects, to ensure that our expensive coding time is spent as efficiently as possible. Product feature ideas are evaluated in terms of how much value they can provide in exchange for that time - a feature needs to earn its development costs many times over to be worthwhile!
Maybe I am spending my life working at the wrong corporations (not FAANG/direct tech related), but that doesn't match at all my experience. The `design` phase was reduced to something more akin to a sketch in order to get faster iterating products. Obviously that now, as you create and debate over more iterations, the time for writing code is increased (as you built more stuff that is discarded). What is that discarded time used for? Well, it's the way new people learn the system/business domain. It's how we build the knowledge to support the product in production. It's how the business learns what are the limits/features, why they are there, what they can offer, what they must ask the regulators etc.
Realistically, if you only count the time required to develop the feature as described, is basically nothing. Most of the time is spent on edge-cases that are not written anywhere. You start coding something and 15m in you discover 5-10 cases not handled in any way. You ask business people, they ask other people. You start checking regulation docs/examples, etc. etc. Maybe there are no docs available, so you just push a version, and test if you assumptions are correct (most likely not...so go again and again). At the end of this process everyone gains a better understanding on how the business works, why, and what you can further improve.
Can AI speedrun this? Sure, but then how will all the people around gain the knowledge required to advance things? We learn through trial and error. Previously this was a shared experience for everyone in the business, now it becomes more and more a solitary experience of just speaking with AI.
Yes writing code is easier than ever, my problem is that understanding it still costs the same if not more [0]. I get that when people use agents, understanding code is not the concern because it's not exactly catering to people, it's for other agents. But when maintaining applications that have been running for years now, I still believe we need to fully understand code before we commit.
[0]: https://idiallo.com/blog/writing-code-is-easy-reading-is-har...
If coding is so cheap, I hope people start vibing Rust. If the machine can do the work, please have it output in a performant language. I do not need more JS/Python utilities that require embarrassing amounts of RAM.
It's already happening, particularly with "Ladybird Browser adopts Rust" [0] being at the top of HN today. It's now feasible to quickly iterate on a system's design with a dynamic language like Python, and then, once you're happy with the design, have AI rewrite it into something like Rust or Zig. I can even foresee a future where we intentionally maintain two parallel implementations, with machine-defined translation between them, such that we're able to do massive changes on the higher level implementation in minutes, and then once we finish iterating, have it run overnight to reimplement (or rewrite) it in the performant language. A bit like the difference between a unoptimized debugging version of a project, and the highly optimized one, but on steroids.
Worth reiterating due to the skyrocketing costs of RAM.
The sad reality is it will likely be the older languages (I tend to see Ruby vibed a lot) just because there is so much more to train on.
With a bit of AI sprinkled in, Rust code can surely also waste gigabytes of RAM on "Hello World" ;)
> Good code still has a cost
> Delivering new code has dropped in price to almost free... but delivering good code remains significantly more expensive than that.
Writing code was always cheap to start with. Just outsource it to the lowest bidder. Writing good code remains as expensive.
The same when programmers from different languages are considered. How many Scala/Haskell engineers can I find compared to Java is not the question. It is about how many good engineers you can hire. With Haskell that pool is definitely denser.
> It’s simple and minimal
This. All LLM code I saw so far was lots of abstraction to the point that it’s hard to maintain.
It is testable for sure, but the complications cost is so high.
Something else that is not addressed in the article is working within enterprise env where new technologies are adopted in much slower paces compared to startups. LLMs come with strange and complicated patterns to solve these problems, which is understandable as I would imagine all training and tuning were following structured frameworks
Because it has been trained on Java class spaghetti.
When it’s trained on enough APL/K code, you’ll get minimal abstraction.
One of the biggest challenges right now in my opinion is disambiguating what processes _were_ necessary from those that are _still_ necessary and useful in light of exactly this.
Precisely, especially because habits have been bound up in the high (and difficult to measure!) cost of code. We got precious about it, really.
Not necessary: stand up meetings.
If your code output has been devalued then the strategy of lowering your input as a person might not be the best approach.
Stand up is where I find out what code I’ll have to fix 6 months from now after my team member finishes ignoring all my advice. Useful to me.
LLM's have made code cheap in the same way McDonalds has made eating out at a restaurant cheap.
I wonder if they will make code fast in the way that McDonalds made food fast. For many business needs, knowing when a project will finish would be equally or even more valuable than knowing that it will contain more code or employ fewer programmers.
Writing code has always been cheap. Deciding what the logic should be, and being able to change course was the hard bit.
But that's the thing - changing course is suddenly no longer hard. We've already reached a state where I can have AI generate a decent set of tests from an existing codebase (or better yet, I'd already have them ahead of time), and to then do a massive refactoring or even a full rewrite while I get a good night's sleep. There is nothing "has always been" about this.
I see lot of comments downplaying the significance of this but other than very large and/or mission critical infrastructure roles, your "taste and experience" is going to become cheap just like code.
Currently there is this notion that white collar workers and artists still have which is that they bring "taste" too to the experience but eventually AI will come for those as well, may or may not be LLM, and not sure about timelines.
Even as we speak, when I read through HN comments, I always ask : "Did an AI write this" or did someone use AI to help write their response. This goes beyond HN but any photo or drawing or music I hear now I ask the same question but eventually nobody will care because we are climbing out of uncanny valley very quickly.
Exactly. I feel like the latest models are basically a couple MCP servers away from just doing the whole thing. You just say, here’s what I want the system to do, and it’ll just do everything. No knowledge required. You need only know how to ask.
The rule of good fast cheap still applies the same as always, but business leaders consistently choose to ignore this reality and insist upon fast and cheap without acknowledging that it will come at the cost of good.
What's worse, is that these decisions are usually made on a short-term, quarterly basis. They never consider that slowing down today might save us time and money in the long-term. Better code means less bugs and faster bug-fixes. LLMs only exacerbate the business leader's worst tendencies.
If writing code is cheap now why is there so much money involved?
I like the idea of we will always need Pilots.
We have autopilot and i'm sure if we tried could automate take off and landing of commercial flights.
But we will keep pilots on planes long after they are needed.
The Airbus A320neo can already takeoff, ascend, cruise, descend, and land all by autopilot. It can even download your flight plan from the airline's servers.
But you still need the pilots because the system can only handle the happy path. As soon as there's any blockade or strong weather change, the autopilot will just turn off. And then you need the pilots.
I would say software engineering with AI is similar: The AI can handle CRUD just fine. But once things get messy, you need someone who can actually think.
To fly a plane with 300+ passengers you still only need 2-3 pilots. That has remained consistent with the invention of autopilot. While we might still need a few human engineer experts, maybe we only need a few for small to medium sized companies? That may not eliminate the career for the top % but it effectively does for the vast majority of engineers.
We do automate lots about flying, not just take-off and landing. It's why a 4-engine aircraft in the 1960s required flight crews of 6-8 people just to fly the thing when they can be routinely flown with 2-3 today.
Autolands absolutely do exist.
But writing good code is still not cheap.
See my heading half way down the page!
Well another consequence of that is that you’re going to have a lot more tools to maintain.
And LLMs aren’t half as good as maintaining code as they are to generate it in the first place. At least yet.
"Writing" code is cheap but this just scratches the surface. Its a completely different paradigm. All forms of digital generation is cheap and on the verge of being fully automated which comes with self recursion loops.
Automated intelligence is now cheap....
This is the first "chapter" in a not-quite-book I've started working on - I have an introductory post about that here: https://simonwillison.net/2026/Feb/23/agentic-engineering-pa...
The second chapter is more of a classic pattern, it describes how saying "Use red/green TDD" is a shortcut for kicking the coding agent into test-first development mode which tends to get really good results: https://simonwillison.net/guides/agentic-engineering-pattern...
the interesting shift is where the time goes. before: thinking + typing. now: thinking + reviewing. the thinking part didn't get cheaper -- domain knowledge, edge cases, integration constraints -- none of that is free. what changed is you now review AI output instead of type your own, which is genuinely faster but not as different as it sounds. the hard part was always understanding what to build, not the keystrokes.
> the interesting shift is where the time goes. before: thinking + typing. now: thinking + reviewing.
It's widely accepted that you can't learn just by reading, you have to write. So only thinking and reviewing is a great way to lose all the business domain knowledge.
> the thinking part didn't get cheaper -- domain knowledge, edge cases, integration constraints -- none of that is free. what changed is you now review AI output instead of type your own, which is genuinely faster but not as different as it sounds
It's very different - you lose business domain knowledge if you're only reading.
Understanding computers and programming is not the same as coding.
Sometimes it feels what we are seeing is Code becoming just like any other "asset" in the globalised economy: cheap - but not quality; just like the priors of clothing (disintegrating after a few washes), consumer electronics (cheap materials), furniture (Instagram-able but utterly impracticable), etc: all made for quick turn-overs to rake in more profit and generate more waste but none made to last long.
Put another way: “reading code costs the same as it always did” arguably more when you consider that the cost of reading goes down when the ability read goes up. in other words if you wrote the thing it is likely you can read it fast. but reading someone elses stuff is harder.
Scathophagidae are flies that really like eating shit. We know how to cheaply produce massive amounts of shit.
But that doesn't mean we solved world hunger. In the same way, AIs churning out millions of lines of code doesn't mean we have solved software engineering.
Actually, I would argue that high LOCs are a liability, not an asset. We have found a very fast way of turning money into slop, which will then need maintenance and delay every future release. Unless, of course, you have an expert code reviewer who checks the AI output. But in that case, the productivity gains will be max 10%. Because thoroughly reviewing code is almost the same amount of work as writing it.
i’ve yet to see an agent that can take a figma design and produce high fidelity UI
Have you tried Gemini 3.1 Pro for that yet? They put a ton of work into improving its frontend abilities.
maybe writing code is cheap . But writing unit tests that actually test stuff that matters is suddenly so much more important and expensive.
Yeah it's more important, but I think that has become a whole lot cheaper too.
For everyone who is responding to the "Writing code is cheap now" heading without reading the article, I'd encourage you to scroll down to the "Good code still has a cost" section.