> 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 cycle.

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 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.

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.

> 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.

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.

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.

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.

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.

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.

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.

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.

>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.

> If we want to keep shipping at this speed

Do we? Spewing features like explosive diarrhea is not something I want.

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!

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.

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.

> 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.

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.

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.

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.

>Code is a liability, not an asset

Then "AI" code is even more of a liability.

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?

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.

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)".

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".

>> 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.

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

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.

[0] https://news.ycombinator.com/item?id=47120899

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" ;)

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.

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.

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.

Out of curiosity, are you the same person who's constantly creating brand new accounts to have a go at me or are there more than one of you?

Have you tried Gemini 3.1 Pro for that yet? They put a ton of work into improving its frontend abilities.

See my heading half way down the page!

Yeah it's more important, but I think that has become a whole lot cheaper too.