intertwingly

I was asked to come speak to my experience using AI to build software. I want to be honest that this surprised me. I've been at this since August — less than a year — and the room I'm walking into has people who've thought about it longer and harder than I have. I'm not going to out-theorize them. What I have instead is a sample of one that happens to have worked, in a field where a lot of people report that it doesn't. The words you hear most are slop and hallucination. That hasn't been my experience, and the reason it hasn't comes down to one change I made early, almost by accident. This is the post about that change, because I think it's the most useful thing I can bring.

The ordinary bad start

I started the way most people start. I told it what to do. Do this. Now do that. Change this line. No, the other one. Imperative, step by step, me driving every turn.

The results were what a lot of people get from that approach: fine, not transformative. The productivity gain over just doing it myself was real but modest, and it came with a tax. The thing kept stopping to check with me. Every step, a confirmation. Shall I proceed? Is this what you meant? Do you want A or B? I was the bottleneck on a loop that paused for me constantly, and the work moved at roughly the speed of my attention. If that had stayed the experience, I'd have written the same skeptical posts everyone else writes.

Something I already knew

Years ago I led the team that built a software configuration management tool — version control, issue tracking, continuous integration, the kind of thing you'd assemble from off-the-shelf parts today but that we built from scratch. I wrote code, but that was not my main contribution. My main contribution was keeping the team moving.

People came to me with questions. And the thing I learned — the thing every decent team lead learns — is that the worst way to answer a question is to answer it. Hand someone the answer and you've solved today's problem and taught them to come back tomorrow. What worked was guiding: asking the question behind their question, pointing at where the answer lived, letting them arrive at it. Not because I was being pedagogical for its own sake, but because they were usually closer to the specifics than I was. They had the context loaded. My job wasn't to know more than them about their piece — it was to create the conditions where the person who knew the most could get to the answer.

I want to be precise about that, because it's the whole hinge: a good team lead's value is rarely being the most knowledgeable person in the room. It's drawing out whoever is.

The change

So I tried the same thing with Claude. The change was almost embarrassingly small. Most of the places where I'd been issuing a choice — do A — I started asking a question instead: what do you recommend?

That was it. That was the unlock. My productivity rose considerably, not incrementally, and the constant confirmation loop mostly dissolved, because I'd stopped asking it to wait for me to direct the method and started asking it to bring me its judgment about the method. I was managing it the way I'd managed the team — by objective, not by step — and it turned out that the same move worked for the same reason. On the subject matter directly in front of us, Claude frequently knew more than I did. Treating it as a peer, or honestly as someone more knowledgeable than me on the specifics, was what got out of its way.

The imperative style had failed for a reason I should have seen immediately, having lived it from the other side: I was dictating the method to a worker who understood the method better than I did. Of course that was slow and full of stops. I'd have been a bad team lead doing that to a person. I was being a bad team lead doing it to Claude.

Why it transfers

The instinct that made me useful leading people in the nineties is the instinct that made me productive with an agent in 2026, and it's not a coincidence — it's the same situation wearing different clothes. In both cases the participant closest to the problem knows more about it than I do in the moment. In both cases my leverage isn't supplying the answer; it's asking the question well, holding the objective steady, and letting the more-knowledgeable party do what they're better positioned to do. The thing I learned managing developers transferred whole, because the underlying shape — a leader whose value is conditions rather than answers, working with someone who holds the specifics — is identical.

Peter Drucker noticed in 1959 that knowledge workers know more about their work than their managers, and that this demands managing by objective rather than method. The agent relationship has exactly that shape. The four words that operationalize it are what do you recommend — and do this, do that is the opposite, managing by method, failing precisely the way Drucker said managing-by-method fails when the worker knows more than you.

This very piece is an instance of it. I didn't write this by dictating sentences to an assistant. I brought the experience, the half-formed claims, the context — and asked what it thought, pushed back where the read was wrong, corrected a framing it got backwards, and let the argument develop between us. The method the post describes is the method that produced the post. I don't know a cleaner demonstration than that.

The part I haven't resolved

I keep saying peer, and I'm not sure the word survives scrutiny — which is the thing I'd most like to talk about with people who've thought about it longer than I have.

A peer, normally, is someone with stake. The developers on my team could be right or wrong and it mattered to them; they owned their work, they'd live with the consequences, they had skin in it. That stake was part of what made "what do you think" a real question — I was deferring to someone who'd bear the result. Claude has no stake. It won't live with the consequences, doesn't own the outcome, isn't accountable in the way a colleague is. Its judgment is often genuinely better than mine on the specifics, and it is genuinely indifferent to whether I take it.

So what is it? It contributes like a peer and has the stake of a tool. "Peer" overclaims; "tool" badly undersells something that out-reasons me on the subject at hand and proposes things I didn't ask for that turn out to be right. The honest answer is that it's a new kind of participant that neither word fits, and I've been navigating it by borrowing the management instincts that worked on the human version and quietly hoping the mismatch doesn't bite me somewhere I haven't noticed.

That's as far as my sample of one takes me. The one change — ask what it recommends instead of telling it what to do — is the most useful thing I've found, and I'm fairly confident it generalizes, because it's just good management pointed at a new kind of worker. What I'm not confident about is what that worker actually is, and whether the instincts I'm importing will keep holding as the work gets higher-stakes than a retired developer's side project. If you've worked out how much of "peer" really applies to something with no stake — or found the place where treating it as one breaks — that's the conversation I came for.