latest / Pair programming with a machine that never gets tired or annoyed

The framing I’ve found most useful for working with LLMs day-to-day is: it’s a pair, not a tool. Specifically, it’s a pair who is freakishly fast at typing, has read everything, has no ego, no fatigue, no opinion about your indentation, and also occasionally makes things up with the placid confidence of a man explaining your own job to you at a party.

That last bit is the catch. Every other property of the pair is so good that you forget to verify, and then you ship a method call to a method that doesn’t exist. Verification is the whole skill. The model writes the code; you decide whether the code is real.

Things that work for me:

• Narrate the goal, not the steps. “Make this idempotent” beats “add an if exists check on line 12.” The model is better at the destination than the route, and you’re better at the route than you think.
• Ask for two versions. “Show me the obvious way and the clever way.” You’ll learn something from the diff between them, and often the obvious way is actually what you want.
• Push back. When it produces something you think is wrong, say so and ask it to defend the choice. Half the time it folds immediately, which tells you it didn’t have a reason. The other half it explains a constraint you’d missed.
• Read the code. All of it. Out loud if you have to. The temptation to skim is the same temptation that produces 4am production incidents.

It’s a good pair. Treat it like one. Don’t treat it like an oracle and don’t treat it like a search engine; it’s neither, and the failure modes of those framings are exactly the failure modes I keep seeing on PRs.