Over the past few months I have watched an avalanche of "ultimate prompts" for Claude Code, collections of 30 must-have MCPs, and skills you "have to" install to be productive with AI. I wanted to test the opposite hypothesis against my own data: you need none of them. You need to treat the AI exactly the way you would treat a team of engineers.
So I did something mildly meta: I asked Claude Code to read its own history. Every Claude Code session is stored locally as JSONL, in ~/.claude/projects/. I had the AI parse the whole of July — every prompt I wrote, every tool call it made, every error — and grade me. No softening.
The result: 107 sessions across 22 working days, 599 real prompts, 14,608 tool calls, 312 MB of transcript. The work of a single person — me — for the company's main client, a US e-commerce product, plus internal projects.
The short verdict: the strategy works. Here are the numbers, the principles behind them, and — because an audit that only finds good news is not an audit — the places where I fail exactly like a bad manager.
The numbers that matter
Of 107 sessions, roughly 95% closed with the result delivered and verified — commit, deploy, checked on the real environment, ticket moved along. Only 4-5 sessions were genuinely abandoned, most of them for banal reasons (one because I gloriously started it in the wrong project).
The correction rate — how often I had to say "doesn't work", "wrong", "redo it" — was 8% of all follow-up messages. The absolute maximum in a single session: 4 corrections. Zero frustration loops, zero sessions where the AI walked me in circles. That narrative exists, but not in my data.
And maybe my favourite number, because it is not about AI at all but about life: this entire month happened between 9am and 7pm, zero weekend sessions, two sessions after 9pm in the whole month. The output of a small team, delivered by one person, on a normal human schedule.
Where do those results come from? Not from special prompts. From three principles any experienced engineer already knows — because they are the principles you use with people.
Principle 1: A good prompt is a good ticket
The clearest finding of the audit concerns the length and structure of the first message in a session. The distribution is bimodal, and the difference in outcome is brutal:
- Prompts under 120 characters — the "let's look into this one too" kind — systematically produced 2-4 clarification rounds and blind tool calls where the AI guesses what I want.
- Prompts over 700 characters — 19 in the whole month — had a median of one single prompt per closed task. You write the spec, you walk away, the task is done.
What do those 19 have in common? No magic formula. They have exactly the structure of a well-written ticket: the file and the line, the current behaviour, one piece of concrete evidence (an order ID, a request ID, a log line), the desired behaviour and the acceptance criterion. The most efficient task of the month — a lost-emails bug in a Lambda handler — was solved from a single ~900-character prompt containing all of the above: one prompt, 75 tool calls, zero corrections, fix in production.
Conversely, the most expensive incident of the month started from an undefined "here": I asked for a change "here", the AI understood "everywhere", updated every record in production, and a few turns later I admitted in chat: "I misread the spec myself." With a human engineer the same vague ticket would have caused the same damage — except I would have found out at the demo, not in ten minutes.
Distilled, the rule I apply from now on is three lines long, not 700 characters:
WHERE: exact file / page / URL — not "here", not "this"
NOW: what happens + evidence — ID, log, screenshot
WANT: the acceptance criterion — how we know it is done
That is not prompt engineering. That is what a lead has asked of any ticket for the last 15 years. The skill already exists in the industry; it just needs to be applied to the machine as well.
Principle 2: A minimal process, not a tool collection
My "AI tooling" stack is embarrassingly short: the terminal, a browser driven through the Chrome MCP, and the task tracker. That is all. I do not have 15 MCPs installed, I do not have a library of skills downloaded from GitHub. I wrote about my Claude Code workflow in the terminal and, in essence, almost nothing has changed since.
The data confirms nothing is missing: 50% of all tool calls in July are plain Bash — grep, git, curl, cat. The AI works with the same primitive tools any engineer works with in a terminal, and it is enough.
The only MCP that genuinely matters is the browser — and not because it is sophisticated, but because of its role in the process: verification on the real environment. The instruction that shows up obsessively in my sessions is "check it with Chrome on the real environment, not in preview". The audit identifies it as the direct reason for the 95% completion rate: nothing is declared done until it has been seen working where it actually runs.
In other words: it is not tools you are missing. It is a "definition of done" you apply without exception.
Principle 3: Treat the AI like a team of engineers
This is the core. Looking at my own sessions, everything that works is an old team-management practice, applied to a "team" that answers in seconds:
Design review before code. "Give me an implementation plan and tell me about it" appears in ~20 sessions in July. Number of corrections in those sessions: zero. Not a coincidence — it is the same reason you do not let a new colleague write code in an unfamiliar system before you have discussed the approach.
Limited access until you understand the problem. "READ-ONLY, we are only analysing, we change nothing" — used systematically for investigations. Production accidents caused by analysis sessions: zero.
Review before anything goes public. "Show me the comment before you post it on the ticket." Exactly what you ask of a junior before they answer the client.
Deploy discipline. Commit → push → build → verification on the real environment → ticket moved to Verify with a short comment. Repeated consistently across ~60 ticket sessions.
And the most interesting finding of the audit, the one that amused me most: the best prompts of July were not written by me. The machine wrote them. When a session delegates a task to a new session (by spawning tasks in separate worktrees), the auto-generated spec has a median of ~900 characters and the full ticket structure — and those 12 delegated sessions all closed with a median of one prompt per task. The AI learned the format from my process and applies it more rigorously than I do. That does not undermine my thesis — it confirms it: the process is what transfers, not some "prompter" talent.
Where I get it wrong — and why that is reassuring
An audit that finds nothing bad is propaganda. Mine found plenty, and the genuinely reassuring part is that every mistake I make with the AI is a classic mistake of managing people:
Micromanagement. 31% of my turns have fewer than 3 tool calls — meaning a third of my interactions are "do exactly this small step". I repeated the same process instruction ("when you finish, commit, push, build, verify") more than 25 times in a month, instead of writing it once in CLAUDE.md — the equivalent of onboarding written once, not recited at every task. Meanwhile, real delegation (agents, spawned tasks) was used only 34 times across 107 sessions.
Vague tickets. "do we hav this?" — 14 characters, typo included — generated 156 tool calls in which the AI went looking for what I meant. It found it, but I paid in time and tokens. With a human, the same Slack message would have produced a "what are you referring to?" and ten lost minutes.
Marathon meetings. One session on 13 July: 15 different tickets, 41 prompts, 547 tool calls, almost 18 MB of context. By ticket 12, the context of the first 11 is pure ballast — the audit shows that 17% of July's file reads are re-reads of the same file in the same session, a direct sign of bloated context. The correct rule is the same as with people: one subject, one meeting. One ticket, one session.
Expensive verification. 1,405 browser screenshots in a month — 41% of the entire data volume of the sessions — most of which were "reading" text that could have been extracted ten times more cheaply from the DOM. In a single session: 127 screenshots. The lesson, equally valid for reports you ask of people: request the cheapest format that answers the question.
Clarification: still automated — only the channel changes
After publishing I got a fair question: "does the screenshot recommendation mean more manual verification?" No — and it's worth stating explicitly, because the distinction is easy to miss.
Automated verification on the real environment is non-negotiable: it's the direct reason for the 95% completion rate and exactly what lets me delegate a task and walk away. The recommendation is only about the channel. A screenshot and a DOM read (read_page, console, network) are equally automated — they just cost differently. When the check is actually textual ("message X appears", "the request returns 200"), the DOM answers the same question at a fraction of the context. Screenshots stay for what needs eyes: layout, images, styling.
And the counterintuitive part: bloated context is the enemy of parallelism, not its friend. A session with 127 screenshots fills its window, starts re-reading files (that's where the 17% re-reads come from) and dies sooner. The same session, verifying through the DOM where possible, lives longer and leaves room to run more sessions in parallel. You verify just as much, just as automatically — you only pay the image price where an image actually sees something.
None of these problems is "the AI hallucinates" or "the AI is not capable". All of them are about how I lead it. The only difference from a team of humans is the speed of the feedback loop: my management mistakes show up in minutes, not a sprint later. Which, if you think about it, is the fastest management course I have ever taken.
What I change in August
The audit ended with five concrete actions, which I leave here because they apply to anyone:
- Repeated process goes into CLAUDE.md, not into the prompt. Written once, always applied, no accidental variation.
- The three-line rule (WHERE / NOW / WANT) for every opening prompt. No "here", no "this".
- One ticket = one session. And the inverse corollary: four small related tasks are one prompt with a list, not four sessions.
- The repo explicitly in the first line of the prompt — I had 11 sessions started from the wrong directory, one of them lost entirely because of it.
- Screenshots only for what you verify with your eyes (layout, contrast, images). For text and structure, extracting from the page is ten times cheaper. Security bonus: never screenshot admin panels holding secrets.
In a month I will run the same audit on August and we will see whether the numbers move. That, in the end, is the advantage of everything being logged: managing your AI team is the first management in history that is fully measurable.
As usual, my disclaimer: I believe AI is the future of our profession and that today's problems — context that bloats, expensive verification, the need for supervision — will be solved. But the current state deserves to be discussed exactly as it is, with data, not with enthusiasm or panic. The numbers in this article come from an audit of my own Claude Code sessions in July 2026; the method is described in the article and can be replicated by anyone with a ~/.claude/projects/ directory and a spare hour.