What "Just Prompting" Looks Like

A colleague asked me this week how I've built the things I've built over the past year: the Agent-Friendly Documentation Spec, the afdocs checker, agentsummons and agentminutes, Agent Skill Implementation, the Agent Reading Test. He characterized it as "just prompting," and then asked whether there was something in how I prompt that we could teach non-technical colleagues in his department.

I was skeptical. My private theory was that whatever works for me works because I have enough domain background to notice when the agent is wrong, and that isn't something you can easily hand off. But a private theory is exactly the kind of thing I'd tell an agent to go verify, so I did the same thing to myself. I had Claude Code read every prompt I've given it since December 2025 and tell me what it found.

The short version: the mechanics really are "just prompting," in that there's no technique in there worth the name. What's happening underneath is code review, in verbal form, chatting with my agent. Most of the review habits turn out to be copyable by anyone.

What I looked at

Claude Code keeps a history file of every prompt you've typed, and full session transcripts for the last thirty days. Between the two, I had 7,753 prompts across 857 sessions, from December 10, 2025 through September 20, 2026. I excluded slash commands and a few hundred headless evaluation runs where a tool of mine was feeding content to the model, since those weren't me talking.

The full transcripts only go back a month, so for anything that needed the agent's reply as well as my prompt, the sample is August and September. The pattern counts came from regular expressions over the prompt text, so treat them as lower bounds. This was an afternoon's audit of my own logs; it would need a bigger sample to count as a study.

Is it prompting?

If you're picturing prompt templates, role assignments, or "you are a senior engineer with twenty years of experience," there's none of that. The median prompt is 28 words. A third of them open with "Ok." The longest ones, at 50 words for a typical session opener, are context dumps: here's the repo, here's the file, here's the URL, here's what I already did, here's what I want to think through. Then the session runs as a conversation, five or six turns at a time.

Here is a fairly typical run of prompts, verbatim, from a release session:

Ok, I've committed and CI is green. Let's tag and push the release

Do we need to document any of the changes in the documentation site?

We should probably generate a fresh minimal session and re-capture the affected cli.md examples from it. I'm concerned we'll forget about it otherwise.

Can we add some details to CLAUDE.md that when we add a new documentation page, you should not commit and deploy until I've had a chance to read it?

That reads like a standup with a teammate, because that is what it is. I report what I did outside the chat, ask what's next, catch something we'll forget, and set a rule about what the agent is allowed to do without me. None of it is a prompt in the sense my colleague meant.

Every pushback was correct

One interesting finding came from the 2% of prompts where I told the agent I didn't believe it. Only about 158 prompts across nine months do this, and I could only check the ones from the last month against the agent's reply. But in all eight cases I could check, I was right and the agent had assumed instead of verified.

Every one of these has the same shape. The agent had a proxy for the truth: a status code, a label, a marker name, elapsed time, a registry field. It reported the proxy as the truth it was standing in for. My pushback forced it to go get the primary evidence, and the primary evidence disagreed with the proxy.

The agent's own reply on the soft 404 illustrates something I've written about before: "I made exactly the mistake an agent would make. I checked status=200 size=56KB and reported 'resolves fine' without looking at the body." I've written about how confident-sounding output can be wrong and about the verification gap in AI content pipelines. Reading my own logs, closing this gap is a lot of what I do when working with agents.

What anyone can copy

When I went looking for the habits that recur across every project, I found a dozen. It turns out you don't have to be a domain expert, but you do need to learn how to make the agent show its evidence.

Ask where a claim came from. "What are you basing that on?" "Is this a known, documented fact, or where did this come from?" "Are you speculating?" "Where is the fetch buffer information coming from? I was unaware of this as a limit." These are the least common hits in my logs by sheer volume; under one percent of prompts; but it basically always caught a verification gap. A rule for anyone: before you use a number or a fact the agent gave you, ask where it got it.

Compare the output to one thing you know is true. "I've watched agents curl and never a human." "When I view source I don't see it twice." "I'm listed as the maintainer, I just set that up." I'm checking the agent against my own lived experience, which has nothing to do with expertise in the agent's domain. Every professional has lived experience of what customers say, what campaigns did, what a real lead looks like. Use your expertise to frame the agent's output.

Say how sure you are about your own input. "I'm quoting this from memory so I'm not sure about what I'm saying." "I believe the Build folks did these updates." "My memory could be faulty." Eleven percent of my prompts hedge like this. It's the mirror of the first habit: I'm telling the agent which of my claims to verify instead of building on.

Paste the thing instead of describing it. The error text, the paragraph you object to, the email you're replying to, the pitch you received. One prompt in sixteen carries a pasted block, and one in ten a file path. Describing from memory is how drift starts.

Tell it what you did outside the chat. "Committed and pushed, CI is green - tag it." "I've deployed the site - confirm the new section is available." "I initiated the first fetch at 9:49PM local time in Vermont." The agent can't see the world. You are its instrument readings, and it can't reason about state you haven't reported.

Ask for alternatives with costs, then choose. "What other approaches might be viable?" "Can you help me think through the pros and cons?" "How do other projects handle this? We can't be the only ones in this scenario." Then: "Let's go with 4." "Implement option 2 plus the #1 mapping." The convention-seeking question in particular ("how do others do this") needs no expertise to ask and reliably surfaces things I hadn't considered. And it almost always stops the agents from re-implementing something that someone else has already done, better.

Ask it to find contradictions in its own work. From a spec editing session: "single-fetch-completeness is about not requiring multiple fetches. But in other places we talk about progressive disclosure, and embedded-data-serialization specifically requests breaking up things. So how do we square these?" Followed by asking for a full pass for tensions between sections. The agent found more.

Ask who the reader is. "Most of the users of this tool aren't developers - they're documentation folks who just want to know what they need to do. Can we reframe this as text?" "Does an average docs person know or understand HTML conversion pipelines?" This is the technical-writer habit in my prompts. Agents are really bad at inferring audience unless you help them.

Ask what got skipped. "Anything else we should roll in while we're working on testing?" "Have we adequately exercised this through ample test coverage?" "Any hanging threads from this session before I log off?" "Did you have the info you needed to perform this validation?" Agents finish the task you named and stop. They rarely volunteer the adjacent thing.

Write decisions down somewhere that isn't the chat. About 150 prompts ask to capture something to a file, an issue, a project instructions file, or memory. "Let's file an issue on the repo about curl so we can capture this thought and not lose it in this session." "You're about to get auto-compacted - can you capture your current state so you don't lose any important details?" Nothing important should live only in the conversation, because the conversation ends.

Say what must not happen. "You should not commit and deploy until I've had a chance to read it." "Leave yourself out of the commit message." "I'm not sure I want you to load the example skills in case they contain some sort of attacks." "Can we commit scripts without leaking details about my personal computer and setup to the public internet?" Twelve percent of my prompts set a constraint like this. Agents are eager, and eager needs fences. This one is a slippery slope, though, because if you name one thing that must not happen, agents may instead do the other thing you forgot (or didn't know enough) to name.

Ask why about the agent's own choices. "Why do you need an OAuth token? Don't we invoke Claude headlessly?" "You did not ask me about the design choice here. Why not handle this correctly?" "What is that session link, and why is it there? What would somebody who isn't me see if they go to it?" That last one turned up a link to my private session logs in a public pull request description. This is a variation on asking it where its claims come from; another flavor of the same problem.

What you can't copy

Look at the triggers in the pushback table again. I knew a 200 response can carry a 404 page because I've spent months testing how agents fetch documentation. I knew agents shell out to curl because I've watched them do it countless times in session logs. I knew the npm metadata was stale because I had configured the publisher myself ten minutes earlier. I knew 156KB of CSS could push content out of a truncation window because I'd seen it happen to my previous employer's docs.

None of those triggers can be taught in a workshop. The habits above are the questions; experience is what tells you when to ask them. So my skepticism was half right. A non-technical colleague can't prompt their way to my particular judgment about agent behavior, because the judgment came from a year of looking.

But the other half matters too. The habits work as a ritual even when you don't know the answer, because they force the agent from proxy to primary evidence, and the primary evidence is usually where the error is. And the colleagues my coworker was asking about have their own domain. Their department's equivalent of "I've never seen a human curl" exists, and they already know what it is. What they may not have is the reflex to say it to the agent instead of to themselves. And it does require the willigness to slow the work way down while making darn sure you (and the agent) understand everything you need to understand about what it's doing.

Do my prompts read like an engineer's?

I also asked Claude to answer a question I ask periodically about myself: whether my prompts read like an engineer or a non-technical person. I've been a professional writer since 2007 and only started calling myself a developer in the last few years. People make assumptions about my capabilities and background, and I also have days where those questions creep into my head as self-doubt, so I was curious what the paper trail of my interactions would say.

Its answer was engineer, without hedging, and the evidence it cited was less the vocabulary than the reasoning. Arguing that a diffing tool shouldn't exit with 1 for a diff because 1 conventionally means error. Asking whether a CI secret could be exfiltrated before adding it. Objecting that changing a type in a validator would obscure what the spec requires, or muddy intent to a human (or agent) reading the code. Non-technical prompts describe symptoms; mine name mechanisms and propose where the fault is before asking.

Two things kept it from reading as pure engineer, in Claude's assessment. I pay constant attention to who will read the output and how a label lands. And I ask how other projects handle a problem before inventing an answer. Its phrasing was "a tech lead with a writer's ear for audience," which I'll take.

Somewhere in that verdict there's a lesson for the "just prompting" framing. The agent did the typing. The review and judgment was mine.

If you want to know why one person's agent output is better than another's, look at what happened when the agent was wrong.