Pair Programming With an AI Tool Changed My Actual Daily Workflow

Six months of using an AI coding assistant as a genuine daily pair, not a novelty I tried for a week and dropped, and the honest report is more boring than either the hype or the backlash suggests. It didn't 10x my output. It didn't turn out to be glorified autocomplete either. It changed one specific part of my workflow a lot, and left most of the rest completely untouched.

What actually got faster

The unglamorous middle layer of engineering work — writing a test suite for code whose logic I already fully understood, scaffolding a new API endpoint that follows a pattern already established elsewhere in the codebase, translating a well-specified data transformation from one language to another — got genuinely, substantially faster. This is the work where I already know exactly what correct looks like, and the bottleneck was purely typing speed and the tedium of boilerplate, not thinking. That category of work plausibly did get close to the productivity gains people claim.

The AI didn't make me think faster. It made the parts of the job that weren't really thinking in the first place take a lot less time.

What didn't change, and where it actively cost time

Anything requiring genuine architectural judgment — should this be one service or two, does this data model hold up under a scaling assumption three years out, what's actually causing this specific gnarly production bug — the tool was no faster than before, and occasionally actively slower, because a confidently-wrong suggestion for a subtle bug sent me down a plausible-looking dead end more than once. The failure mode wasn't the tool being bad. It was that its confidence doesn't correlate with correctness on genuinely hard, context-dependent problems the way it does on well-specified boilerplate, and it took me longer than it should have to internalize which category a given task was in before trusting the output.

• Fast, reliable win: boilerplate, test scaffolding, translating known logic between languages, writing the fifth variation of a pattern already established in the codebase.
• Genuinely risky: debugging subtle production issues, where a confident wrong guess costs more time than no suggestion would have.
• Net workflow change: faster on the predictable middle of the work, unchanged on the hard edges, and a new skill of its own — knowing quickly which category a task falls into before trusting the output uncritically.
• The actual time savings showed up less in 'lines of code per hour' and more in fewer context switches — less tab-switching to Stack Overflow or old code for a pattern I already knew but didn't want to retype.

If I'm honest about the net effect on a typical week, it's meaningfully positive but far short of transformative — closer to a genuinely good second monitor than a new team member. The real workflow change wasn't the tool doing my thinking for me. It was reclaiming the hours I used to spend on work that was never actually thinking in the first place, and redirecting that time toward the architectural and debugging judgment calls the tool still can't reliably make for me.