The longer I work with AI agents, the more convinced I am that the model is not the bottleneck. The bottleneck is me, articulating what I want in a way the model can act on without me hovering over it.
If you’ve ever managed a junior engineer in a different timezone, you already know this skill. The hardest part wasn’t their code. The hardest part was the four-paragraph email at the end of each day describing exactly what you wanted them to do tomorrow, in enough detail that they wouldn’t have to guess, in clear enough English that a non-native speaker reading it at 2am their time would arrive at the right answer.
Working with agents is that. All day. For everything.
What "good at this" actually looks like
I’ve been keeping notes on what separates the briefs that work from the ones that don’t. After about a hundred briefs of various sizes, the pattern is depressingly consistent. The ones that work share a structure. The ones that fail share a different one. Here’s the shape of the working ones:
Start with the outcome, not the steps. "After this change, calling getCustomerMRR(customerId) should return a number, not a Promise. All current callers should still compile." Not "convert the function from async to sync." The agent figures out the steps. You own the outcome.
Name the artifacts that already exist. If you mean a specific file, give the path. If you mean a specific function, give the function name. If there’s an existing helper that should be reused, name it. The hours an agent wastes searching for the right thing to import is the most boring failure mode.
State the boundaries. "Don’t touch the public API." "Don’t add new dependencies." "Don’t change the database schema." Agents have a powerful tendency to fix things you didn’t ask them to fix. Stating what is out of scope is at least as valuable as stating what is in.
Name the verification surface. "Run pnpm test:unit when done. If anything fails, stop and surface it." If you don’t name the verification, the agent picks one. You will not like the one it picks.
Tell it what to do if blocked. "If you can’t figure out which helper to use, stop and ask." Without this, an agent gets stuck and starts inventing. With it, an agent stops and you save an hour.
The brief I wrote at 9am that saved me six hours
One concrete example. I needed to migrate a Prisma schema from a soft-delete pattern (using a deletedAt column) to hard deletes for one specific table — but only that table, while keeping soft deletes elsewhere. Roughly forty queries touched it. The naive prompt would have been: "Convert this table from soft delete to hard delete."
The actual brief was about eight bullet points. It named the table. It named the migration file. It said "the goal is that after this change, calling prisma.fooBar.delete() actually removes the row from the database." It listed the four query helpers that I knew needed to change. It said "don’t touch any other table’s delete behavior." It said "run the test suite. If foo-bar-deletion.test.ts breaks, that’s expected — update the test. If anything else breaks, stop."
The brief took me about twenty minutes to write. The agent took about an hour to execute. Total: under two hours. Estimated hand-coded time: most of a day, because I’d have had to find all forty call sites myself, and I would have gotten interrupted in the middle, and I would have lost the thread by lunch.
The win was not the agent. The win was the brief. The agent could have failed completely and I’d still have a useful artifact — the brief — to hand to a junior engineer or to use as a checklist for myself.
The thing I still struggle with
I’m a worse brief-writer when I’m in flow. When I’m deep in a problem and want the agent to handle something adjacent, I write sloppy briefs because I don’t want to context-switch out of the main thing. Those sloppy briefs produce sloppy agents that produce sloppy code that I have to clean up later. Net negative.
What I’ve started doing — and this is the most counterintuitive habit I’ve picked up this year — is writing the brief in the morning, before I start working on anything. The day’s entire backlog of agent-able tasks gets briefs written for it at 9am, when I have the most patience and clearest head. The agents run while I work on the main thing. By 4pm I have a backlog of finished diffs to review.
This is not how anyone described knowledge work to me in 2022. It feels strange. It also works.
The skill
If I had to name the single skill that gets the most out of AI agents in 2026, it’s not prompt engineering or model selection or any of the things people talk about on Twitter. It’s clear writing.
Specifically: the kind of clear writing where the next person who reads what you wrote — even if they have never been in your head before — knows exactly what you want them to do, what success looks like, what they should not touch, and what to do if they get stuck.
That’s a writing skill. It is also, it turns out, an engineering skill. It always was. The AI just made the cost of doing it badly visible in a way it wasn’t before.
