For forty years we took it for granted that writing a line of code was an investment. It cost someone expensive their time, so the line was worth what it had cost to produce, and we booked it as equity: more code, more company. On that belief we built lines-per-developer metrics, the mystique of the ten-times-more-productive programmer, and the idea that a large repository is a defensive moat.
That belief rested on an assumption that has just broken: that writing code is expensive. With an agent like Kiro generating functions from a specification, the marginal cost of producing the thousandth line is not the cost of the first; it trends toward zero. And when the cost of producing something trends toward zero, that thing stops behaving like an asset. It starts behaving like inventory.
Code was never an asset: it was inventory booked wrong
An asset produces value while you hold it. A building, a patent, a brand: you keep them and they work for you. Inventory is the opposite. It is goods on a shelf that have not produced anything yet, and that while they wait, cost you money: they take up space, they must be insured, they decay, they go obsolete, and if you do not sell them, one day you pay to get rid of them.
Code in production has both faces. The part serving a customer is an asset. But everything else (the function you might use next quarter, the flag you left just in case, the microservice that copied the previous one's pattern) is inventory. It is stored in a repository, insured with tests, decays the moment a dependency changes, and must be understood every time someone touches it. The difference is that until now inventory was so expensive to manufacture that we mistook it for investment. When something hurts to produce, you assume it is worth something.
This is not a new metaphor in disguise. It is the same intuition Ward Cunningham and Martin Fowler have defended for years when they talk about technical debt: code is not only what it does, it is a liability you carry. Fowler himself warns that the debt metaphor does not fit perfectly, because a loan has predictable interest and code does not. Inventory fits precisely there: nobody knows how much the stock that never turns will cost you until you try to move it.
Why does the warehouse metaphor hold and the asset one does not?
Gregor Hohpe has a rule for telling whether a metaphor is a thinking tool or just decoration, and he explains it in Mighty Metaphor: it is not enough for the image to look alike, the dynamics have to match. His example is the fuel gauge, which he dropped because the tank fills up fast and empties slowly, exactly the opposite of the thing he wanted to explain.
Let us apply his test to inventory. Do the dynamics match?
In a warehouse, the cost of producing a unit can collapse without lowering the cost of holding it by a single cent. A more efficient factory does not reduce the rent on the warehouse, the insurance, or what you lose when the model goes out of fashion. More than that: when producing becomes almost free, the temptation is to overproduce, to fill the shelf "just in case," and then the cost of holding the stock shoots up while the cost of making it disappears. That is exactly the effect of a coding agent. The cost of writing falls to zero; the cost of reading, understanding, testing and retiring that code does not move, because it is still paid by a human with the same head as always.
The dynamics match. And because they match, you can deduce things I have not written: if code is inventory, then you will want just-in-time generation instead of speculative stock, small batches reviewed whole rather than thousand-line dumps, and a work-in-progress limit on what the agent produces before a human has digested it. I have not argued any of that and you are already seeing it. That is what separates a model from an ornament.
The cost of producing collapses; the cost of holding does not. The constraint moves from the factory to the warehouse.
The napkin math
Let us put numbers on it, with the assumptions in plain sight so you can redo the math with yours. None of this is a measurement from a real client; it is arithmetic to think with.
A developer writes, being generous, about 100 net lines of code that survive the day. An agent supervised by that same person produces, say, 2,000 lines a day that pass a shallow review. Production multiplies by twenty. That is the headline being sold.
Now the other side of the balance sheet. Reading and truly understanding code, enough to modify it without fear, runs about 400 lines an hour in a familiar language. That person's comprehension capacity did not change: it is still a human brain, about 3,000 lines a day if they do nothing else, which never happens. We produced 100 and could digest 3,000: plenty of spare warehouse. Now we produce 2,000 and can still digest 3,000, and on top of that we must digest what was already there.
- Before: production 100/day, comprehension 3,000/day. The bottleneck was writing.
- Now: production 2,000/day, comprehension 3,000/day. The bottleneck is the warehouse, and it narrows every day the agent works.
The constraint moved. For forty years we optimized the factory because that is where the limit was. The limit is no longer there.
I know what you are about to say
But generated code is better and more consistent than mine! The agent does not get tired, it follows the standard, it writes tests.
True, and it changes nothing. A warehouse full of flawless goods is still a warehouse you have to pay for. The quality of the unit lowers the cost of holding it, it does not remove it: you still have to understand it to change it, it still expires when the dependency changes, and now you have twenty times more flawless units to digest. A perfect, oversized inventory is not an asset; it is a warehouse problem with a better finish.
And there is a worse trap. When producing takes effort, that effort acts as a natural brake: nobody writes a thousand lines on a whim. When producing is free, the brake disappears exactly when it is needed most, because every line the agent adds "for free" carries the same holding cost as one you sweated over. The bill does not arrive at generation time. It arrives six months later, when someone has to understand why that thing is there.
The cost of writing code was the only thing keeping us from drowning in it. Removing it did not make us faster: it took away the one limit we had.
So where is the architect's leverage?
If the bottleneck was the factory, it made sense for the architect to worry about how code gets written: patterns, reviews, standards applied line by line. But the architect never wrote at the speed of the new bottleneck, and is not about to start now. Reviewing two thousand lines a day per agent by hand is as realistic as asking your developers to write bug-free code.
The leverage moves, and I already wrote about where. In architects architecting architecture I argued that an architecture framework is built by bringing decisions forward ("shift left"), not by reviewing at the end. With agents that stops being a stylistic preference and becomes the only physical option, because reviewing at the end no longer fits in the day. What the architect controls is not each line: it is the constraints the agent reads before writing it.
That is where a platform like Amazon Bedrock AgentCore stops being an infrastructure detail and becomes the place where those limits live: identity, permissions and guardrails that bound what the agent can touch. And it is where the spec-driven flow of Kiro, with its specs and its hooks that check the generated output against a rule, becomes the modern equivalent of the assembly line: you do not control each part, you control the template that produces them. The architecture decision no longer lives in the code; it lives in the ADR, the specification and the governance rule, which is the same thing Yagni had been saying since before agents, except now the cost of ignoring it is multiplied by twenty.
As I argued in Multi-cloud, the worst practice, indecision dressed up as flexibility gets paid for in maintenance work. With agents it is the same, only faster: every option you leave open "just in case" is now materialized by the agent into real code, and that code goes straight to the shelf.
My suggestion
On Monday, bring a single question to your next architecture review: what is our holding cost per thousand generated lines, and who is paying it? Do not answer it with a feeling; put a calculation on it like the one above, with your own numbers for how much code ships per week and how much the team can truly digest.
And if you want something even more concrete, try this for a sprint: put a work-in-progress limit on what the agent generates before a human has understood and approved it, just as you would limit stock in a warehouse with finite space. Treat every spec and every guardrail as the template that decides what gets manufactured, not as paperwork. If by the end of the sprint the team understands everything in production, congratulations: you are managing inventory instead of hoarding it. If not, you know where your bottleneck is, and it is not writing. ;)