"You may offload the work and much of the auditing, but not the accountability."
That's how Addy Osmani ends his article about thinking critically when agents do the work. I read it in early November and kept thinking about how I work.
Addy describes a spectrum. At the top is cognitive offloading: the agent does the work and you keep ownership of the result. In the middle is deferral, where the agent's output becomes your new input and stops being a hypothesis. At the bottom is what Steven Shaw and Gideon Nave at Wharton call cognitive surrender: the output quietly becomes your own and you feel no need to check it.
What stuck with me is that you slide down gradually. You read the last answer well, so you skim the next one. Every step seems reasonable.
I try to stay at the top. This is what I do to get there, before and after I ask an agent for something.
Before I ask#
It's the same old thing: garbage in, garbage out. It comes down to the config, the prompt, and understanding the problem. In other words, knowing what to ask for. Addy puts it this way: "Your prompt is a reflection of your understanding of the problem, and if you can't express it clearly, it may not be clear in your own mind."
That's why, when an agent gives me a bad result, I don't switch to another model anymore. First I check what I asked for. Charlie L (@charliesbot) said it in a tweet a while ago: Codex, Claude and Gemini are so good today that if a project gets bad results, the main reason will be a bad config, not the model.
I used to use ChatGPT and Codex. I moved to Claude mostly for plan mode: having the agent plan before it touched anything made sense to me. From there I started learning spec-driven development: first you write down what's going to be done, then you do it. I think it was February when I started paying for the $20 plan. By April I was on the $100 one.
Addy's advice: "Write your own request brief in your own words before you ask for help. Describe the audience, out-of-scope items, and the definition of done." On this blog that's already a rule: no post gets written without a list of facts first, each one with its source, plus who it's for. This post had its own.
The rules that weren't written down#
Addy points out that if you used to make a vague request, someone would push back, and that's when you'd realize you hadn't thought it through. "An agent often won't stop you there. It fills in what you left out and hands back something that looks done, even though the idea behind it is still fuzzy."
That's what my rules are for: don't touch more than needed, don't merge to main, tell me about changes, don't assume, and always ask me.
And they work. A few weeks ago I replied "yes" to an agent without saying to what. It had two things pending: merge two PRs, or open another one in my game's repo. Instead of picking, it stopped and asked me. I answered, and then I merged the two PRs.
But they weren't written anywhere. I repeated them to the agent every time I started a project. I noticed while putting together the fact list for this post, when the agent asked me where I kept them. A rule I have to repeat on every project is a habit, and habits get forgotten. So I put them in a file that applies to all my projects. One of them now says that a "yes" from before doesn't count for next time.
After: what I still review myself#
In that same batch of work, the agent wrote in a PR description that one of my automated checks "stalls for minutes on this post on main too." It said it with total confidence. Another agent, the one that reviews before merging, ran the whole thing: 211 checks, all passed, and it didn't stall. It got fixed before the merge.
By then the claim had stopped being a hypothesis. That's deferral, and the second reviewer stopped me before I slid into surrender.
Addy again: "A green check means one thing. What did it check? What did it not check?" That's why I still read the diff myself. I look at which modules it touches and whether it makes sense for it to touch them. And I check that the unit tests actually test something, that they aren't there just to pass.
What I learn, I write down#
Another of Addy's ideas: "When something doesn't meet your standards, note why in shared config, a hook or a test so that it doesn't happen again."
That one I do. This blog has had its own config since September 12: four agents that edit, translate and review, three skills, and a hook that checks every post when it's saved. I didn't build it in a weekend. I fix it day to day, when something goes wrong. The skill that defines how I write came out of my own chats, and that's where the words I kept striking ended up, because nobody says them out loud, like "costura" (seam) or "la frescura" (freshness). At work it's similar: the team shares a CLAUDE.md with a few rules.
Config is where I keep what I learned from reviewing. But the reviewing is still on me.