AI Killed the Economics of Code Production. Now Engineering Discipline Is the Scarce Resource.

The economics of software production flipped sometime in the past year, and most teams have not fully reckoned with the consequences. Code that once took hours to write now takes seconds. Lines of code went from carefully curated assets to disposable outputs. The implication is not that engineering got easier. It is that the hard part moved.

The pattern

Charity Majors put it plainly in a widely circulated post: the economics of code production were turned upside down. Generation became free. That sounds like pure upside until you realize what it removes: the natural forcing function that scarcity provided. When code was expensive to write, you thought hard before writing it. Now that friction is gone, and something has to replace it.

The scarce resource is no longer keystrokes. It is engineering judgment: knowing what to generate, how to evaluate it, when to throw it away, and how to keep a codebase coherent when every contributor, human or model, is producing at volume.

Why now

This is not a prediction. It is the current state for any team that has adopted an AI coding assistant or is shipping LLM-generated features. The shift accelerated through 2025 and is the baseline assumption for new projects starting today. OpenAI's $150M Partner Network, announced this week, is aimed squarely at enterprise adoption of exactly these capabilities, which signals that the volume of AI-generated code in production systems is about to increase significantly across industries.

The Google DeepMind and UK government AI planning prototype is a parallel signal: consequential decisions are being handed to AI systems not because the code is cheap to write but because the output is trusted enough to act on. Trust, review, and evaluation are now the critical path.

How it works in practice

1. Generation is the easy part. Any competent prompt gets you working code. The leverage is in the prompt that scopes the problem correctly before generation starts, not in editing output afterward.
2. Review load scales with generation speed. If one engineer can now produce ten times the code, your review capacity needs to scale too, or you are accumulating unreviewed complexity. Automated evals, linters, and test coverage become load-bearing, not optional.
3. Disposability is a feature, not a bug, if you design for it. Treat generated modules as drafts. Build systems where replacing a component is cheap. This is a design discipline, not a vibe.
4. Evaluation methodology matters more than ever. A Show HN this week on evaluating local LLMs as translators is a small example of the right instinct: before trusting generated output in production, build a repeatable eval. The same logic applies to any AI-generated code path.
5. Prompts are now engineering artifacts. Version them, review them, and treat changes to a system prompt as a code change, because they produce code-like outputs at code-like volumes.

The trade-off

The honest caveat is that raising engineering discipline is culturally hard, especially in teams that adopted AI tools specifically to move faster. Slowing down to write evals, enforce review, and maintain architectural coherence feels like it defeats the purpose. It does not, but it requires deliberate investment. Teams that skip this step will ship faster in the short term and slower in the medium term as they debug systems no one fully understands. The prompt engineering practices that seemed optional when code was expensive are now the minimum viable process.

"Lines of code went from being treasured, reused, cared for and carefully curated, to being disposable and regenerable, practically overnight."

This is not a complaint. It is a design constraint. Build your process around it.

Where it goes next

The teams that win are not the ones generating the most code. They are the ones with the tightest feedback loops between generation and evaluation. Expect LLM workflows to increasingly include automated eval layers as a first-class component, not an afterthought. The prompt that generates code and the eval that grades it will be written and maintained together. That pairing is the new unit of engineering work.

The constraint is judgment. Invest there.