Cheaper Code Moves the Bottleneck: Here Is Where It Goes

A coding agent can turn a sentence into a working patch in the time it takes to read this paragraph. That feels like the end of the bottleneck. It is not. A generated patch is a proposal, not a product. It becomes a product only when a person has framed what it was for, checked that it does that, accepted it, and watched it behave in front of real users. Cheap generation does not remove that work. It moves it.

This is a judgement, not a measurement. But it is a judgement with a clear shape: as writing code gets cheaper, the effort that decides whether delivery is any faster shifts to the two edges around the writing — the quality of the context you set before the agent starts, and the observability you keep after it ships.

More Code Is Not More Delivery

01 · The argument

A patch is a proposal until a person has stood behind it

Count merged pull requests and an AI-assisted team looks dramatically faster. Count delivered outcomes — the customer problem that actually went away — and the picture is quieter. The difference is everything that happens around the keystrokes: deciding what to build and why, setting the limits it must respect, confirming it meets the need, and seeing whether it holds up once it is live.

None of that got cheaper when generation did. If anything it got more important, because there is now more generated code moving through it per hour. The teams that turn cheap code into fast delivery are the ones that invest where the agent cannot: in framing before, and in watching after.

A generated patch is a proposal. It becomes a product when a person stands behind it.Kintoro Labs

The Loop

02 · The shape of the work

Seven steps, and the agent owns only one of them

Put the work in order and it forms a loop of seven steps: frame, constrain, generate, verify, accept, observe, learn — and then what you learned feeds the next frame. Generate is the single step the assistant does most of. Every other step is a decision with consequences, and a named person stays accountable for it.

Read that way, "the AI writes the code" describes one seventh of the work. The other six sevenths are judgement, and judgement is exactly what does not get cheaper when tokens do.

What You Do at Each Step

03 · Each step has a finish line

A step is done when its condition is met, not when it feels done

• Frame. Write a short note that answers four questions: what the problem is and who has it, what already exists around it, what the solution must respect, and how you will know it worked. Done when a second person has challenged it.
• Constrain. State the architecture boundaries, the security and risk lines, the existing patterns to follow, and what is explicitly out of scope — in words a reviewer can check. Done when the limits are written, not assumed.
• Generate. Hand the agent the note and the shared context, and prefer small changes. Keep that shared context in one central place so every run reads the same thing. Done when there is a change to look at.
• Verify. A person checks each acceptance criterion, runs the tests, and reads the code — rather than trusting the tool's own summary of what it did. Done when the criteria pass against the diff.
• Accept. A named person confirms the work matches the customer need and decides whether it goes live. It is a decision, not a click-through. Done when that person has said yes.
• Observe. Before release, decide what you will watch: errors, usage, and whether the customer's problem actually went away. Done when the signals are in place before, not after, launch.
• Learn. Record the surprises — a wrong assumption, a missing constraint, a vague criterion — where the next framing note will find them. Done when the lesson is written somewhere the loop will reread.

One Small Change, End to End

04 · Illustrative — not a real project or result

A CSV export button, walked through the loop

Here is the loop on one small, illustrative change: adding a filtered CSV export to a reporting screen. Nobody in this example is real and it is not presented as a result; it is here to show the shape.

• Frame. Operations people re-key figures into spreadsheets every morning; the problem is manual re-entry, and success is that they stop. A colleague pushes back: which figures, in which view?
• Constrain. The export respects the same row-level permissions as the screen, matches the filters already applied, and adds no new data path. A date range beyond the retention window is out of scope.
• Generate. The agent gets the note and the permission rules, and produces a small change behind the existing view.
• Verify. A person exports as a restricted user and confirms the file holds only rows that user may see, matching the on-screen filter, and that the tests cover both.
• Accept. The product owner confirms it answers the morning re-keying problem and clears it for release.
• Observe. The team watches export usage and whether the spreadsheet re-entry actually stops.
• Learn. The permissions constraint was the part that mattered; the next framing note for an export leads with it.

The cheapest fix in that story happened before any code existed — in the sentence that said the export must inherit the screen's permissions. Miss it in the frame, and you find it in production.

The cheapest bug to fix is the one you frame out before the agent ever runs.

Telling Whether It Is Working

05 · Recommendations, not a scorecard

Judge by what was accepted and what held up, not by volume

Pull-request counts and lines generated are poor evidence that delivery got faster; they measure motion, not arrival. Five things are closer to the truth. These are recommendations — I cannot show you results from running them, only argue they point the right way.

• Accepted customer outcomes — changes a named person accepted as meeting a real need, not merged changes.
• Rework from misunderstood requirements — how often work came back because the frame was wrong.
• Defects that escaped to users — what verification and observation missed.
• Release reliability — whether shipping more often made delivery less stable.
• Lead time from an approved requirement to an accepted production result — the whole loop, not the generate step.

Notice what these have in common: four of the five live outside the generate step. If cheap code is helping, it shows up as more accepted outcomes and less rework — not as a bigger pile of patches.

What to Try This Week

06 · One workflow, one to two weeks

Run the loop once, on purpose, where a mistake is cheap

1. Pick one workflow where the cost of a mistake is low.
2. Name one person accountable for the outcome.
3. Write the framing note before any generation, and have someone challenge it.
4. Let the assistant implement while a person verifies and accepts.
5. Observe the release, and feed what you learned back into the frame.
6. After one to two weeks, compare it with how similar work went under your normal process.

Give every stage an owner, an explicit control, and something you can observe. Even for one small experiment, that is what keeps "the agent did it" from meaning "nobody did."

Where It Goes

Cheaper code is real, and it is worth having. But it does not shorten delivery on its own, because the work it makes cheap was never the hard part. The hard part is deciding what to build, setting the limits, confirming it is right, and standing behind it once it is live. Those are the edges, and the edges are judgement.

That is the bet we make at Kintoro when we build piMonk: let agents do the work, and keep the decisions with people. Cheap generation moves the bottleneck to judgement. The teams that win are the ones that put their best thinking there.

The agent writes the patch. A person makes it delivery.