AI makes engineers faster, then hands review work to the team

A writer at Terrible Software has put a sharp name to a common engineering complaint: AI can make one person faster while making the team slower.

The essay, “You Got Faster. Your Company Didn’t.,” argues that developers often use AI to create more text, more plans, more tests, and larger pull requests than colleagues can review with confidence. The writer’s example centers on an engineer who asks a model to draft a database migration brief. The engineer saves an afternoon. Reviewers then spend extra time checking claims the author may not have verified.

The core point will sound familiar to anyone who reviews AI-assisted work: output speed and team speed can diverge. A model can produce a long plan in minutes, but a reviewer still has to ask whether the job processes events in sequence, whether the migration touches nine tables, and whether the proposal names the right trade-offs.

That burden grows because AI prose often looks confident before anyone checks it. A colleague who writes a short sentence by hand usually stands behind the count, the claim, or the recommendation. A model can produce the same sentence without that work. The reviewer must decide whether the author checked the claim or pasted model output into the workflow.

For software teams, the essay points at a practical review problem. AI lowers the cost of producing drafts, code, and tests. It does not lower the cost of trust. Developers still need someone to read the code path, inspect the schema, run the test, and decide whether the change deserves approval.

That distinction matters in code review. A developer can ask an agent to produce a broad refactor, fill in tests, and write a migration guide. The pull request may look complete. Reviewers then face a larger surface area, with more generated code and more claims to verify. If the author cannot explain a change, the reviewer inherits the work.

The essay’s proposed standard is simple: use AI, then edit. For code, the writer uses the rule, “if I can’t explain the change, I can’t ship it.” The same rule fits design docs, technical briefs, and decision records. A team member who submits AI-assisted work should cut the draft, check the claims, and make the ask clear before sending it to colleagues.

That standard gives reviewers room to push back. A reviewer can ask the author to reduce a draft to the decision, the trade-offs, and the requested feedback. That response treats review time as shared engineering capacity, not as a dumping ground for unverified output.

The piece adds to a growing developer conversation about AI productivity metrics. Individual speed is easier to measure than team throughput. A developer can count minutes saved on a draft or a test file. A team has to count review delays, rework, defects, and meetings caused by unclear AI output.

That measurement gap explains why AI adoption can feel uneven inside engineering organizations. One developer sees a faster workflow. Another sees longer reviews. A manager sees more artifacts. The team still waits for a decision because reviewers cannot tell which claims deserve trust.

The takeaway for developers is concrete: AI drafts should arrive smaller, checked, and owned. The author remains accountable for each sentence and each line of code. A model can speed up the first pass, but the human still has to do the compression and verification that make the work useful to the team.