(I wrote this mainly from the perspective of what it feels like on the inside to write code as a human. I think https://news.ycombinator.com/item?id=47138965 explains it better in terms of the business aspect.)

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

This doesn't seem quite right.

"Producing" code involves a lot more than just typing it. It's slow because the dev is planning things out at the same time, at a micro level. Suppose "a few hundred lines" is 10kB of text; actually typing that out at full speed is maybe half an hour of work for a reasonably accomplished typist. But basically nobody even writes blog posts that fast. As soon as you're writing more than a sentence or two and actually care about how you come across (never mind having to satisfy a compiler) you're invoking system 2 thinking. (I didn't even consider tab completion in my napkin math; it wouldn't really matter, because you have to already be thinking to get value out of it!)

Time spent planning isn't really about saving coding time, because it really can't be. It's not like ultra-cheap code production suddenly lets you just implement all the things and see what happens. Features can be net negative, or even outright harmful to the product. It takes resources to evaluate any unplanned change and then integrate it if accepted. (cf. the recent buzz about FOSS projects getting flooded with AI-generated PRs.) Deciding "this feature will/won't be worth the effort" is a rough guess at best, because the actual code/test loop is where you actually hit the unknown unknowns (presumably LLMs would feel the same way, if they were conscious).

And perhaps most importantly, simply meeting feature goals isn't enough. This might be slightly less true in a world where your developers (now partly LLM) don't care about the existing coding style or architecture and can readily adapt on the fly. But I'm still convinced that just letting everything accumulate without a clear vision — without oversight and accountability — will always ultimately lead to a tech-debt reckoning.

Besides which, "a few hundred lines... a full day" is a highly optimistic metric along an axis that has long been understood to make little to no sense. That's a day where things are only added and not removed or changed (to fix them), in a relatively new system (so that interactions with other stuff don't have to be considered). Extrapolating that rate gives you absurd results, e.g. a team of ten developers might re-create the entire Python standard library from scratch in a year.

Well, that becomes more realistic when you already know exactly everything that you're going to do. But the LLM doesn't know that either. In fact, it doesn't even have the advantage of sharing your team's vision and wanting to see it come to fruition. Ask the LLM: "We're creating a new programming language; what modules should the standard library have?" How helpful is that going to be compared to the (human) new guy?