You’re not pair programming with AI anymore

Illustration depicting the process of coding and collaborating with AI. Step 1 shows a person coding alone with the text 'You wrote the code'. Step 2 illustrates collaboration with a friendly AI character, saying 'You paired with AI'. Step 3 features the individual in a customer role giving specifications to the AI, stating 'Now you're the customer'.

We’re reaching the point where we don’t develop with the AI anymore. We’re its end customer. We ask for something and we check that it matches what we wanted.

The part I didn’t see coming is which half of my CV adds value here: The several years I spent in Quality roles, despite my efforts to switch to a generalist engineering role.

QA teaches you to define done before anything gets built. It teaches you to test behavior instead of implementation, which is exactly the skill you need when the implementation isn’t yours. And it teaches you to ask the uncomfortable version of the question: not “did it work when I tried it” but “what did I not try”. Engineers who relied on reading code to know whether it was correct have lost their main instrument. The ones who relied on specifying and probing barely felt the change.

So the shift isn’t about admitting the AI is faster at the typing. Most of us got there months ago. It’s about where the attention goes now that the typing is gone.

The stages arrived quickly. First we wrote and it autocompleted. Then we paired, driving and navigating in turns, and that felt natural, because collaboration is what good engineers are trained to do.

Stage three is awkward because the instinct that made stage two work now gets in the way. Pairing means staying in the loop. You interrupt, you steer mid-thought, you read the diff line by line and flag every choice you’d have made differently. When the agent was slower and worse than you, that was load-bearing. Now it does in minutes what would have taken you an afternoon, and a lot of that interrupting is friction on something already heading somewhere reasonable.

Not all of it, though. The rule I keep coming back to: interrupt when the spec is wrong, not when the code is.

If it’s building the wrong thing, stop it now, because wrong directions only get more expensive. Agents converge on plausible, not on correct, and a confidently wrong approach doesn’t fix itself by running longer. But if it’s building the right thing in a way you wouldn’t have chosen, sit on your hands.

The rest of the work moved to the edges.

At the front, you owe a real request. Not a vibe, or something like “make the checkout faster”, but what you want, what counts as done, what must not break. A customer who can’t articulate the order gets what they described instead of what they meant, then blames the vendor. We’ve all been handed that ticket. Now we’re the one writing it.

At the back, you owe verification, and “just verify the behavior” is where this advice usually goes wrong.

Two different things were hiding inside “reviewing the code”, and they’ve come apart. One is the style review: would I have written it this way? Mostly vanity now, and you can let it go. The other is reading for blast radius: what did this touch, what did it add, what can it reach that it couldn’t reach before. That one doesn’t go away, and your tests won’t do it for you.

Tests answer the questions you thought to ask. Verification exists for the one you didn’t. There’s no test for a dependency you didn’t know got added, or a permission that quietly widened, or a retry that swallows the error you needed to see. And if you hand the test writing to the agent as well, it writes tests its own implementation passes. Green suite, nothing verified.

The fair objection is that verifying properly takes as long as writing it yourself. Sometimes it does. What actually happens is that the cost moves to the front. Define done before the work starts and verification is quick. Skip that and you’re reverse-engineering the spec out of the diff afterwards, which is slower than writing it would have been. There’s also a class of change where the edit is tiny and the blast radius is enormous, and there verifying really does cost more than doing it yourself. Those stay in your hands, or go out with tight bounds. Telling one from the other is still your call.

The customer framing does break somewhere, and the break is the interesting part. A customer can walk away. There’s a vendor with a reputation and a contract and someone else holding the liability. We have none of that. The agent has no skin in this. We’ve handed over most of the authorship and kept all of the accountability, and we’re still the ones getting paged at 3am.

So: not 100% a customer, maybe closer to a lead with a very fast contractor and nobody to escalate to 🙂

We haven’t become a burden. We moved. The instinct is still the right one, it’s just aimed at the wrong part of the work. Take it to the front and the back. And get out of the middle.

Leave a Reply

Discover more from Alex López

Subscribe now to keep reading and get access to the full archive.

Continue reading