Operating AI is easy. Directing it is the craft.

You ask an engineer why they solved something a certain way and, more and more, the answer is "it's what the AI suggested." Full stop. And they're at peace with that. And I'm not even talking mostly about junior profiles...

Here's a question, and it's not rhetorical: when was the last time you rejected an AI suggestion not because it failed the tests, but because it didn't fit your system?

It took me a while to be able to answer it. A couple of years ago, when the tool was new, almost everything it generated felt like a little gift and I accepted it without looking too closely. Back then accepting blindly cost little, because it generated little: a couple of functions, a test. Now it generates an entire system in an afternoon, and accepting blindly costs something else.

The problem isn't the tool, it's the stance you take toward it

This isn't about prompts. There are excellent guides on how to get more out of the tool, and this isn't one of them. The question I care about is a different one: what becomes valuable once you're already using AI every day, which by now is something almost everyone does. Mastering the tool stopped being a differentiator the day it went mainstream.

I support seven teams at Mercadona Tech, and the conversations that truly matter are hardly ever about how to write something anymore. They're about whether that something should have been written at all, about what breaks if it fails, about who keeps it standing when it's on fire. The AI has none of those for you.

There's a spectrum to how we use AI, and it helps to look at its two extremes. At one end is the operator: asks for code, gets it, pastes it, and massages it until it goes green. Fast, but their trail of decisions is opaque, to the team and, worse, to themselves. At the other end is the director: thinks first, uses AI to explore and accelerate, but keeps authorship of what ships to prod. But almost nobody lives at an extreme; we move through the middle and, depending on the day and the rush, we drift one way or the other. What matters is which way you drift, because when someone asks you "why like this?" three weeks later, you either have an answer or you have an "it's what Claude suggested."

The spectrum: how you use AI

What an agent never signs off on for you

Here's the crux, and it's more structural than it looks. AI, on its own or agentic, is excellent at generating options and executing them. And it is incapable, not out of immaturity but by construction, of bearing the consequence of choosing wrong in your system.

Bearing that consequence is what a Product Engineer vouches for. No agent puts its name on the line for you. You can treat the AI as an authority, and then what you accumulate is intellectual debt: code that works but that you wouldn't know how to defend. Or you can treat it as a tool you direct, and then it multiplies you. The difference isn't visible at the six-minute mark, when the PR passes the tests and everyone applauds the speed. It shows up a quarter later, when someone opens that area and asks why it's like this.

And the trap arrives disguised as productivity, which is what makes it dangerous. You ship more. You get praised for how fast you go. Your calendar blocks less focus time because, after all, you no longer need to think as much. And meanwhile, without it showing, every PR you close contains more decisions that aren't yours.

When you go back to an old PR and feel like you're looking at someone else's code, that someone is you two months ago, the day you accepted without looking.

The practice: the mental review before accepting

This isn't fixed with willpower or a New Year's resolution (especially since it's June 🙂). It's fixed with a small, repeated practice. The one that's served me most is to treat myself as the reviewer of the code the AI gives me, before accepting it. Three questions, in order:

1. Would I approve it if a teammate brought it to me in review? If the answer is no, don't accept it. It's exactly the same yardstick you'd use with any human. There's no reason to lower it because the author is a machine.

2. Could I explain it to another engineer in under a minute? If you can't, you don't understand it well enough to answer for it. And vouching for what you don't understand was never the craft, regardless of who wrote the code.

3. Do I know what breaks if this fails in production? If you don't, it's not your code yet. It's a suggestion pending adoption.

It costs between thirty seconds and two minutes per accepted block. And someone will say: "sure, that slows me down, and the whole point of AI was to go fast." I get it, but I think that's watching the wrong movie. What really slows you down is the obscure bug six months from now in an area nobody understands, the review your teammate does twice because your PR breaks the module's coherence, the question you can't answer in your performance review. Those two minutes are insurance at a steal of a price.

A case I see every week

You ask the AI for a retry on a call to an external service that fails now and then. It returns a RetryPolicy class, an interface, a RetryPolicyFactory.forX() factory, YAML config with maxAttempts, backoffMs, jitterFactor. Four files, thirty lines of plumbing, a factory test. First read: it handles timeouts, distinguishes retryable errors, there's coverage. Green. If you stay an operator, you accept it here.

Second read, the director's: your system does a single kind of retry, in one place, with values nobody has touched in two years. You don't have the generic problem the AI solved for. You have a concrete one. The sustainable version is a twelve-line function in the file where that logic already lives, with the literal values in the body. If a second retry case shows up tomorrow, you generalize then, with two real examples, not one imagined.

The AI wasn't wrong. It did what it always does: the standard solution for the generic problem, because it's what it has seen thousands of times. The one who knows your operational context is you. And that's the division of labor that truly makes the most of each side: it produces alternatives faster, you choose better.

That's why, when I face a non-trivial decision, I try not to ask it for the solution. I ask it for the options. "Give me three different ways to do this, with the real trade-offs of each in complexity, maintainability, and performance. Then I'll tell you which one fits our context." That prompt does two things at once: it produces material to think with and it places me as the decision-maker, not the executor. The bottleneck is no longer generating options, but choosing well among them with a context the tool doesn't have and you do.

What I'm not sure about

I'm not going to pretend this is a state you reach and then stay in. The border between operating and directing isn't a line, it's a gradient, and the tool pushes toward the easy side every day, for everyone. Directing isn't won once. It's a choice you repeat every time you accept a block, and the day you stop making it consciously, you slip back. I see it in people with far more craft than me.

What I genuinely don't know is how far this goes. If agents improve enough, maybe part of what I call "directing" today gets automated too. Long term, I'll tell you the truth, I don't know.

But there's one thing I am sure of: the responsibility for choosing wrong in a system that's actually in production isn't borne by a model. It's borne by a person with a name. And as long as that stays true, knowing how to direct is worth more than knowing how to type.

This, by the way, is just one of the six dimensions of the craft I've been thinking about for a while. The one about collaborating with AI without dissolving into it. The other five (deciding what to build, reading the system before touching it, writing what holds up, sustaining the outcome beyond the merge, and making visible the work that doesn't show up in the repo) I've gathered them all, with practices you can apply starting Monday and four printables, in a document called Product, not code. If this one resonated, the full map is there.

Get "Product, not code" (free) →

The close

Code is a means, not the end. That sentence is easy to underline and hard to practice, because the tool pushes the whole time in the opposite direction: produce more, accept faster, think less. Directing is resisting that current without giving up the speed it gives you.

When that sentence stops being a slogan and becomes how you decide every Monday (what you accept, what you reject, what you sign with your name), you're a different engineer from the one who yesterday pasted suggestions until CI went green. AI doesn't take you there. It takes you to the other side, if you let it.

So I'll leave you with the question from the start: when was the last time you said "no" to the AI because it didn't fit your system, not because it failed the tests? If you struggle to remember, don't read it as a flaw of yours. It's the current, and it pulls everyone. Knowing it's there is already half of what it takes to row against it.

I'm genuinely curious how you're living this. Do you direct or operate? And how do you notice?