So walk me through it, how does an AI assistant actually fit into your day-to-day engineering work?

Honestly it's a loop with checkpoints, and the checkpoints are where the real work happens. Decomposition comes first, and I don't hand that part off. Before I prompt anything I split the task into slices small enough that I can read each resulting diff completely, usually one function, one module boundary, or one behavior change. And the prompt for each slice reads like a little spec. Inputs, outputs, the edge cases that have to hold, the error behavior I expect. Because an underspecified prompt just returns the model's statistical default, and the default is usually the happy path.

Then after every accepted slice, something runs. Might be the unit test for that slice, might be the type checker, might be a probe in the REPL. That one rule does most of the work for me. And I never stack a second generation on top of an unverified first one, I got burned on that early, two unverified layers cost more to bisect than they ever saved to produce.

When I read a diff I look hardest at the places generated code fails most often. Swallowed errors. Cleanup that's missing on an early return. An API that looks plausible but belongs to the wrong runtime version. The fluent happy path gets less of my attention, since that's the part the model gets right anyway. I also know when to stop. If the model has looped twice on the same correction I abandon it and write that slice by hand. The assistant compresses typing and recall. The decomposition, the spec, the read, the run, those stay mine. And I can point to each of those checkpoints in the last change I shipped, not just describe them in the abstract.

Once you zoom out to the team, the interesting effects are economic. Assistants raise the volume of plausible code per engineer-hour while review capacity stays flat, so the default failure mode is quiet. Reviewers start skimming these big fluent diffs, approval latency stays constant while review depth collapses, and the standard for what reviewed means erodes without anyone ever deciding to lower it.

So I watch for that with numbers, not impressions. Revert rate per module. Escaped-defect rate traced back to the introducing PR. Review time per changed line, which you can pull from PR metadata. And time-to-diagnose during incidents in the modules where generation was heaviest. That last number is the one I care about most, because a team that accepted code faster than it built understanding pays for it when the pager goes off.

The norms I set are structural. You merge a diff, you own it, exactly as if you'd typed it, and postmortems never get to accept the assistant as an explanation. CI gates are identical for generated and hand-written code. Diff-size norms cap how much fluent output can land in one review. And juniors get an explicit rule. Generation is available for anything they can verify, and it stays off the table where they can't yet tell right from plausible.

The tradeoff I defend is deliberate lost throughput. Slice caps and mandatory per-slice execution cost raw speed, sure. In return I get a bounded review burden and a team that can still explain its own codebase. Verification discipline is what decides whether the assistant's extra output becomes working software or review debt.