Sam’s generated billing rule review. A customer release was one hour away.

AI coding tools create value when they shorten a bounded task with clear ownership. They become expensive when your best engineer spends afternoons reviewing work nobody can explain or safely change.

At 3:40 p.m. on a Tuesday, Nia, a composite founder in Accra who kept a cracked blue notebook beside her laptop, opened the sprint board before a customer call. Her strongest engineer, Sam, had been hired to solve the part of the product that kept failing under real customer data. Instead, every card assigned to him that week said some version of “review generated changes.”

One pull request had touched a billing rule, a background job, and an API response. The AI tool had produced a lot of code quickly. It had also repeated an old assumption about how accounts moved between states. Sam had found it before release, but the call was in an hour and the customer was waiting for a version they had been promised. If the team shipped the wrong rule, they could lose trust before the next renewal conversation. If they held the release, the roadmap slipped again.

The problem was not that the tool wrote bad code. Much of it was usable. The problem was that Nia had quietly reassigned her hardest engineering problem to a person whose job had become checking a machine’s homework.

The board showed output, not progress

The first sign was not a production incident. It was the sprint board looking busy while the difficult work stayed in the same column.

Generated code is easy to count. Files changed, pull requests opened, tests added. Those signals can make a small team feel faster, especially when runway makes every delayed feature feel personal. But a large diff can hide a transfer of work: the AI generates the first draft, then the engineer reconstructs the intent, traces side effects, checks edge cases, and decides what the code is allowed to change.

That review work is engineering. It deserves to be planned as engineering.

Nia had treated generation as acceleration because the first demos arrived faster. Sam saw something else. He was no longer spending his best hours deciding how the system should behave when a customer changed plans mid-cycle. He was spending them finding where generated code had made that decision without enough context.

The distinction matters most in a small team. A larger company may have specialists who can absorb review, testing, and operational cleanup. A four-person product team has fewer places to hide a wrong abstraction. Every hour your senior engineer spends untangling low-context changes is an hour they are not reducing the uncertainty that only they can see.

Put a boundary around what the tool may decide

Nia and Sam did not ban the AI tool. They changed the work around it.

They split the board into two kinds of tasks. The first group had tight boundaries: updating repetitive interfaces, writing tests for an already-understood path, preparing a migration plan for review, and documenting code that the team already owned. The second group involved product decisions, irreversible data changes, permissions, billing, or behavior that had not yet been agreed. AI could assist with exploration in those areas, but it could not produce a merge-ready answer on its own.

They also made one small rule: every generated pull request needed a short note from the person opening it. What problem does this change solve? What assumptions did the tool make? What should fail if those assumptions are wrong?

That note slowed the first five minutes. It saved Sam from spending forty minutes inferring intent from code.

This is close to the ownership question in AI Code Approval: What Daniel Learned About Ownership and Human Review. Approval has to sit with someone who understands the customer consequence, not with the person or tool that produced the most lines.

Protect the engineer’s scarce attention

By Thursday, Nia had moved Sam’s hardest product problem into the morning and kept generated-code reviews in a fixed afternoon window. The change looked almost embarrassingly simple. It gave the team a way to see the trade they had been making.

Sam still reviewed AI-assisted changes, but the work had a queue, an owner, and a limit. When the queue grew, Nia had evidence that the team was asking the tool to create more than it could safely hand off. They reduced the scope of generation instead of telling Sam to work later.

This is where founders can get trapped by the wrong comparison. The question is rarely whether an AI tool can write a component faster than an engineer. The useful question is whether it returns the engineer to the decision that would otherwise remain unresolved.

For Nia, that decision was the account-state model. The customer call ended with a narrower release and a date for the rest, which felt painful in the moment. The team avoided shipping a rule they could not defend. The following week, Sam wrote the underlying model with fewer interruptions, and the generated work became easier to review because it had a clearer system to fit into.

The board finally had fewer cards. It also had more actual progress.