You Bought AI Coding Agents. Product Debt Came Free.

The floor was finished on a Thursday. I remember because the light comes in low through that window in the afternoon, and the herringbone caught it the way we had hoped it would when it was still a drawing: long planks of tile with the grain and the touch of oak, laid at forty-five degrees, joints so narrow that from the doorway the whole surface reads as a single wooden floor.

I knelt to look at the joints. It is a habit from a long time ago. Up close, the grout was wrong. Not everywhere, which would have been easier. In patches. Here a joint darker than its neighbours, there one that had lost its colour altogether, and over all of it a thin veil, a haze that dulled the surface like breath on a mirror. I ran a thumb along it. It did not come off. The man who had laid the floor stood beside me. He had done beautiful work; the laying itself was as good as any I have seen. He said the haze would come away with the right cleaner, and I wanted him to be right.

I was fourteen the first summer I worked on a site. In my town, in those years, that was the age. The site manager handed you to a crew, the crew lead taught you the trade with the tenderness of a drill sergeant, and every morning three men stood over the drawings arguing: the engineer, the surveyor and the site manager. We waited for the argument to end, because the end of the argument decided our day. Either we carried on, or we tore out yesterday’s work to match what the drawings had meant all along.

I tore out a lot of yesterdays. I never thought about what they cost. At fourteen the pay came at the end of the month, and the pay was the motorbike for the whole of the next school year. Whether the rework meant anything to the man who owned the site, or to the client who would live in the building, was not a question that crossed my mind. Rework was just Thursday. Later, at university, I watched the same scene from further away: the storm at handover, the keys changing hands, the building forgotten by the client the moment it was theirs. I still did not think about the cost. It was never my invoice.

Almost forty years later I became the client, and the invoice arrived with my name on it. The floor was the part of the office where nothing had been left to chance. The layout was drawn, then laid out in full as a collage before a single cut was made. Decoupling membrane underneath, expansion joints for the underfloor heating, materials from the top of the market, someone from my side on site every day. On the drawing and on the ground, the floor was exactly the floor we had designed. It was, until the last hour, a perfect job.

The grout was epoxy. It outperforms everything else, and it forgives nothing. It has to be cleaned within a window, with the right products, in the right order, or it stays. Nobody was careless. The window closed anyway, and the haze stayed.

I will come back to what that haze costs. First I want to show you the other room, because the two rooms together are the whole story.

The paper prototype in my kitchen

The kitchen is next to the floor. Months earlier, when the kitchen existed only as a drawing, I had done something the architect had never seen anyone do. I took the drawing, cut cardboard to the size of every unit, taped the outline of the worktop to the bare screed, and cooked a dinner in it. An imaginary dinner, pans that were not there, a fridge made of a cardboard box. I cook, I am left-handed, and I know exactly how I move in my kitchen: nothing should require a stretch, nothing should require a thought. The first dinner, a few units were in the wrong place. I moved the tape. The fourth dinner, nothing needed to move.

The architect stood in the doorway for that. He said, politely, that the drawing was already correct. It was, in the sense that it would have passed any review. He asked where the habit came from, and I told him the truth: from racing, before it came from software.

A racing bike is fitted to its rider until every control can be found blind. Racing is where ergonomics stops being a word and becomes the difference between riding and not riding. Mattia Pasini crashed in motocross at thirteen and lost much of the use of his right arm to nerve damage. He moved the front brake to his left hand, so the left could do what the right no longer could, and won Grands Prix again with that layout. The late Alex Zanardi lost both legs at the Lausitzring in 2001, came back to win in a BMW with hand controls, and then won four Paralympic golds in handcycling. And there are whole associations of para-athletes who race anyway, on bikes and cars rebuilt around what their bodies can still do. They lost a limb or the use of their legs, and they still push on the circuit, knee down on a bike or flat out in a car, doing something most people cannot imagine attempting. The machine was made to fit the human, not the other way round. That is the whole of ergonomics, and it is why a product deserves the same respect as a motorbike. When Jeff Gothelf and Josh Seiden published Lean UX in 2013,[*1] they gave that instinct a discipline, and for more than a decade I practised it on software, in startups and then at IBM, inside the CIO Design organisation that Fletcher Previn, then IBM’s CIO, and Kristin Wisnewski led, where in my years there design, user research and developer experience worked as one team instead of three departments. Kristin carries that work forward today at Cisco, where Fletcher is CIO. The cardboard on the screed has a proper name in that discipline: a usability test on a paper prototype. Low fidelity, full scale, run with the person who will live with the result, before anything is built. Carolyn Snyder wrote the book on it in 2003, and Nielsen Norman Group still teaches it under the same name;[*2] Lean UX simply made it the default first experiment. I had run hundreds of them on software and in my workshop. This was the first one I ran on my own kitchen.

The day the real kitchen went in, the architect stood where he had stood before and watched me move through it. Nothing needed to change. He understood the cardboard then, not because I had explained it, but because there was no rework to explain.

Vibe coding, fast and flawless until handover

Vibe coding became the joy and the sorrow of half the companies I talk to, and the sorrow arrives at handover. Code built to be fast looks like my floor from the doorway, perfect until somebody kneels to look at the joints. AI brought in without rules, and without somebody beside you who knows what acceleration does to a company, its people and its processes, is that floor without its last hour. The AI budget gets approved for one reason, and a good one: code that took a quarter now takes a week. The promise kept. The financial dashboards green, at first. And somewhere the haze, the thing that does not come off, arriving from a place the green does not cover. If that sounds familiar, you already know that speed is not the whole of what you bought, and that is why the quarter leaves you uneasy rather than relieved.

Here is the sentence I would put on the board slide:

Speed and knowing what to build are NOT two axes. They are ONE axis, and the discipline that holds them together has a name: product engineering.

Split them, and the two debts you already know about start feeding each other. The speed half is measured now, and it is real. Across 28.7 million workflows, CircleCI watched throughput on feature branches climb while merges into the main branch succeeded 70.8% of the time, the lowest rate in over five years.[*3] DX, across more than 500 engineering teams, found that AI saves an estimated 4 to 6 hours a week, that the median pull request has nearly doubled in size, that change confidence fell 6.1%, and that the share of time spent on new features stayed flat.[*4] Bain said it without decoration: teams see 10% to 15% productivity gains, “but often the time saved isn’t redirected toward higher-value work.”[*5] That is the floor. Laid beautifully, fast, with the haze on top.

Product debt starts after the unboxing

The other half has never been on a dashboard, and I found its number in the last place I expected. When OpenAI built SWE-bench Verified, the benchmark the industry used for two years to rank coding agents, it worked with 93 experienced developers to read the real GitHub issues the original benchmark was made of. They flagged 38.3% of them as underspecified.[*6] More than a third of real-world tasks did not say clearly enough what to build, so they were thrown out. The industry then spent two years measuring agents on the part that was already clear, until this year OpenAI itself stopped reporting the benchmark.[*17]

The research since has only sharpened it. Give a strong model an ambiguous requirement and it will “frequently produce functionally divergent implementations for the same ambiguous requirement” without recognising the ambiguity; the strongest models are affected most.[*7] Coding ability, another team found, “does not inherently translate to effective requirement clarification”; the models simply ask fewer questions than they should.[*8] And when a group including Lionel Briand re-examined the patches counted as solved for the top thirty agents, one in five was semantically wrong and had passed only because the tests were too weak to notice.[*9] Green tests. Wrong software. A haze on the whole surface.

None of this is new to the trade. Before any of it, Pendo had measured that 12% of a product’s features carry 80% of its use,[*10] and Ronny Kohavi had shown at Microsoft that only about one idea in three moves the metric it was built to move.[*11] What changed this year is not the ratio. It is the numerator. When building is nearly free, the wrong two thirds arrive at the same speed as the right third, and the review queue cannot tell them apart. Your people are not going rogue. They are serving demand that could never be served this fast before, and every tool on the market rewards them for it: the platforms that turn a sentence into an app in an afternoon, and the factories inside the IDE that build competent code against whatever they are told. The first kind ships the haze in the code. The second kind ships it in the feature.

I wrote in August that every codebase carries two debts, not one, and that the second, what got built, has no instrument pointed at it. Product debt regenerates tech debt: every wrong feature, every reversal, every correction is rework. Teresa Torres said the human version in a single sentence last year: “Even if the cost to build goes to zero, if you keep building the wrong thing, you’re still wasting your life.”[*12] A product manager answering this year’s State of AI in Product survey wrote the corporate one, in a line Melissa Perri says she now quotes to every leader she has spoken to since:

“Delivery of designs and code got very fast. Delivery of good decisions became the new bottleneck.”[*13]

What rework really costs

Now the cost of my haze. With joints that narrow, you cannot grind epoxy out without chipping the tile. The only rework is the whole floor: take out the kitchen, break up the surface, dispose of it, buy the tile again, lay the membrane again, lay the floor again, grout again. That bill is larger than everything spent on the floor so far. One detail, in the last hour, costs more than the entire job. The alternative is to keep a floor that is not the floor I wanted, and to live with it. That is a different bill, and every product leader knows its name: the user who stops noticing, then stops caring, then stops coming. It seems like a saving. It is the more expensive of the two.

Construction has always known this. The Construction Industry Institute traced 79% of the cost of deviations on industrial projects to design changes, errors and omissions, not to the crews.[*14] A longitudinal study of 346 projects found rework cutting one contractor’s yearly profit by 28%.[*15] In Arcadis’s latest construction disputes report, covering the United States, “errors and/or omissions in the contract documents” is the second most common cause of disputes, with the average dispute worth 56 million dollars and running for a year.[*16] Rework in construction has a number, a root cause and a lawyer. In software it has a quieter name. Velocity drop. Those who really get the essence of the industry call the sum of the two debts delivery debt, and it costs more than anyone puts on the slides for the board.

Product engineering, spec-driven development at vibe coding speed

The cardboard is the answer, and it is the reason nWave grew a product side. Inside the nWave SW Factory, before the first line of production code, four user-centric phases decide what gets built and how. Discovery, to find what the user is actually trying to solve. Discuss, to learn how the user imagines it solved. Design, which is architecture and DevOps but also the shape and the ergonomics of the thing. And Distill, where the design goes on the screed in cardboard: paper prototypes, mock-ups, a vibe coded prototype built to be thrown away, all of it measured with real people, goal completion, A/B tests across the personas, and the emotional arc of somebody using it rather than merely finishing it. The journeys that survive become the walking skeleton tests, and only then does the nWave SW Factory build against them with the engineering discipline that turns a throwaway prototype into code somebody can sign for. Inside the nWave team we say it bluntly:

Super human quality at vibe code speed.

The prototype’s technical debt leaves with the prototype. The product debt was drained before it could regenerate anything.

That is what product engineering means when it is one discipline rather than two departments. Speed and knowing what to build, laid together, before anyone cuts a tile.

The floor is still there. In the low afternoon light it is beautiful, and up close the haze has not moved. Every time I kneel to look at it I think about a fourteen-year-old tearing out yesterday’s work without once asking what it cost, and about how long it took him to read the invoice. So when somebody on your team says that discovery before code is slow, that a product side in the factory is a luxury, that speed is the point, remember the haze after the unboxing. You are already paying for the current solution. The bill is just spread across a review queue, an incident count, a churn rate and a roadmap of features most of your users will never touch. The only choice left is whether you pay it before the tiles are cut, or after.

You invested in speed, and speed arrived. That half of the decision was right. Now it is time to put the second half in place. I have sat with leaders who discovered the second axis the way I discovered the grout: at handover, with the invoice already paid. nWave is open source, and you can put it on a laptop this afternoon. What we have learned is that a tool installed alone becomes an expensive driving school. The organisation spends its first months learning the controls instead of driving, and that time has a cost too. So the tool and the people ready to run it arrive together. That is what The POD is for: a small team that jumpstarts nWave inside your company, with your people, on your codebase, so the investment begins paying in the first sprint rather than the third quarter.

When you are ready to put the drawing on the floor before anyone cuts a tile, I am beside you. Your timeline. Your choice.

→ nWave

Next week: the last two axes on the board. The one that keeps your software alive after the release, and the one that pays for all of it. Half the companies I meet are trying to leave the cloud because of the second one. Together they explain why the AI bill went up while the roadmap stayed the same.

Sources

Every number in this piece traces to one of these. They open in a new tab, so the article stays where you left it.