Apple Podcasts
SpotifyAn agent writes the code, more agents review it, and the honest answer to what you did all day has gone fuzzy. Almost none of the constraints that still bite are about the model. They are about the context you feed it, the verification you keep, and knowing which problem is worth solving at all. This covers reference implementations instead of longer prompts, a stopping rule for review rounds, why every artifact an agent leaves behind becomes the next agent's context, the credentials sitting in your local transcripts, and why token spend measures nothing you want measured.
Your job description stopped matching your day
A year ago the job fit on one line. Cloud engineer, SRE, the person who makes the containers run and keeps them running. Now an agent writes the code, more agents do the first three reviews, and the honest answer to what you did all day has gone fuzzy.
Almost none of the constraints that still bite are about the model. They are about what you feed it, what previous sessions left lying around, and whether the thing you are building was worth building. The work got faster and the beach never arrived. What arrived instead was ten projects in parallel, all harder than the one project you would have taken on before, a pile of generated text somebody has to read, and dashboards that count what is easy to count.
So the question is not whether the agent can write the code. It can. The question is which parts of the job survive that, and they turn out to be specific: the context you assemble, the verification you keep, and the domain knowledge that tells you a request was wrong before you build it.
Point the agent at an example, not an adjective
Start where output quality actually comes from, which is not the prompt.
When the output is bad, is the model the problem?
Usually not. It is the context: what you gave it, how much of the window is left, and which stale artifacts it picked up on the way.
The most transferable technique we heard is to stop describing your standard and build one. Write an example project with the abstractions you want, concerns separated, and different stages depending on how secure a path needs to be. Then stop explaining and start pointing: aim the agent at that repository and tell it what to build.
It carries across languages: the model reads the structure in Go and applies the shape in whatever you are writing next. This is not an argument against explicit instructions. Anthropic’s prompting best practices puts examples beside being clear and direct, calling them “one of the most reliable ways to steer Claude’s output format, tone, and structure”. Working code that already does the thing leaves less to interpret than a paragraph describing it. The trade-off: building the reference is real engineering that ships nothing the day you do it, so build it for the pattern you will apply ten times, not once.
Context has a ceiling as well as a floor. Past roughly 200,000 tokens even the top models start to choke on themselves, so the splitting has to be yours. Left to decompose a task itself, an agent will hand you a fifty-step migration plan for something you already knew how to do. That is the same window arithmetic we measured in episode #2 and argued from in episode #12: the constraint is not how smart the model is, it is how much attention you left it for the actual problem.
“When I know a problem very, very well, I can very easily define it in three lines, and it’s perfect. Another person is going to ask the same thing in more or fewer lines, and the output is really not that good, using the same model.”
Which is why the other half of the fix is a glossary: the terms you use, written down, shared with whatever the model thinks you are talking about. Know the problem space and you can define the problem cheaply. If you don’t, you get a vague question and a vague answer.
Everything the agent writes becomes the next one’s input
The output is not only code, and the rest of it does not disappear just because you stopped reading it.
Should I let an agent leave comments and design docs behind?
Only the ones you would maintain by hand. Everything else becomes context for the next session, whether it is still true or not.
Generated comments are the clearest case. A comment cannot rescue unreadable code, so banning them outright costs less than it sounds. The argument with wider reach is staleness. A comment describes the code as it was when it was written, and a few changes later it describes something that no longer exists. The next agent reads it as current: here we used to have a different thing, but now it is gone. Design documents and decision records do the same, at a larger size. An agent will happily fetch a decision made six months ago, on models that are now obsolete, and reopen it.
Every artifact an agent leaves behind is an input to the next agent, so generated documentation carries a maintenance cost even when no human ever reads it.
Pick a stopping rule for reviews
Bad context produces bad code quietly. The only thing standing between that and a release is whatever verification you built, and that has grown into more machinery than most teams have admitted to running.
How many review rounds are enough?
Nobody has a principled answer, so the limit has to be a number you pick. Ours is two.
Our own pipeline starts with a grilling session on the plan. Three sub-agent reviewers in Claude and one in Codex review the proposal in parallel and report what is wrong and what is missing. If the plan changes, that is another round, and you can go a long way into those cycles and ship nothing. Then implementation, with deliberate handoffs: as a session approaches 200k we start a new one and carry traceability in handoff files. Then three to five sub-agents plus Codex review the implementation and the session fixes what comes back.
Generated tests are where this gets concrete, and roughly half of them are useless. Enforce the distinction between a test that fixes a requirement and a test that confirms the function ran. The first is documentation with a failure mode: change the code in six months and it tells you who broke what. The second is the agent’s own feedback loop, watching the branches execute and treating that as evidence. You can prompt for the first kind, but the default is the second, so a suite nobody steered is optimized for the agent’s confidence rather than your regressions.
“How do you know it’s good enough or that it should stop? How many reviews are enough reviews? Because if you let it, it’s just going to find something. It keeps digging the hole.”
The harness moves under you
Verification machinery runs inside a harness, and the harness is not a neutral container.
Are agent harnesses interchangeable?
No. The model is half the system and the harness is the other half, because raw models make mistakes the harness exists to catch, right down to emitting JSON that does not validate.
The catch is that harness work does not stay done, because it is tuned against a specific model’s habits. One skill in B.O.R.I.S had to be rewritten when the latest Claude developed a preference for piping output through head and reading the first sixty lines. The skill now says the output is already optimized, not to pipe it, and that the tool will say when there is more to read. Without that last part, a truncated result and a complete result look identical to the model.
“Every three months the model changes, so I have to relearn everything. You have to delete whatever instruction you have. You have to review your skills non-stop.”
Two related costs are easy to underestimate. Skills do not live in one place across harnesses, so moving means rebuilding them. And moving is expensive enough that people stay on a harness they have real complaints about rather than pay it.
The same lesson turned up in our own CLI. bmcp hit a case where terminal credentials were present but expired, could not recognize the expiry, reported itself unauthenticated, and the agent concluded the tools were broken. The fix was a flow decision rather than a technical one: use the credentials if valid, otherwise fall back to the configured SSO profile. It had to be spelled out repeatedly, because a model will happily optimize a flow no human would tolerate.
Which account has what, across two clouds
Harness churn is friction you can feel. Missing infrastructure context is friction you pay without noticing, and a second cloud makes it worse.
Why does a multi-cloud estate break an agent’s context?
Because loading everything at once does not tell it which cloud you mean. With AWS and Google Cloud side by side, the observed default is AWS.
The daily version is mundane and constant: it is very hard to know which account contains what. The questions are ordinary. Give me all the external IPs for that account. Can we do least privilege for that service account based on the logs. Each used to mean clicking through a console, or waiting half a day for a colleague in another timezone to wake up. With B.O.R.I.S the answer is just there. The second use is translation: how does this service work in AWS, and how would I adapt it to Google Cloud. Same which-account-has-what problem we took apart in episode #17.
The cheap half of the fix is not in your instructions at all. Name the cloud, the account or project and the region in the request itself, so nothing has to be inferred. The expensive half is tuning the standing instructions, because adding context does not improve behavior monotonically. It is a game of whack-a-mole, and you have to be careful which one you slack on.
Your transcripts are a credential store
One risk sits on the machine you are reading this on, and nobody ever classified it as a secret store.
Are local agent transcripts a security problem?
Treat them as sensitive. Anything that passed through a tool is on disk in plaintext, and so is every prompt you have ever typed.
Anthropic’s .claude directory reference is explicit that these files are plaintext, and that file contents, command output and pasted text all land in a transcript. So does any long-lived token the agent got its hands on. Everyone already keeps SSH keys in 1Password or the Secure Enclave. This is the directory nobody put on that list, and exactly where an exploit with disk access would look.
CLI session transcripts under ~/.claude/projects/ are swept once they are older than cleanupPeriodDays, which defaults to 30 days, has a minimum of 1, and rejects 0. Two things survive that sweep.
Transcripts from sessions you started or last continued in Claude Desktop or Cowork are kept at any age by default, so lowering cleanupPeriodDays does nothing for them. Those need desktopSessionCleanupPeriodDays, on Claude Code v2.1.248 or later.
And ~/.claude/history.jsonl holds every prompt you have typed, with its timestamp and project path. The documentation lists it among the paths the sweep never removes, so a credential you pasted into a prompt outlives every transcript that quoted it. Delete that file yourself, or stop writing it at all with CLAUDE_CODE_SKIP_PROMPT_HISTORY. The claude project purge command filters it, but the same run deletes that project’s transcripts, auto memory, checkpoint state and ~/.claude.json entry, so use --dry-run first. Then rotate the token, because deleting your copy does nothing about the one that already leaked.
Token spend measures nothing you want measured
Zoom out to the organization and the same question arrives in dashboard form: this is obviously faster, so how would you prove it is worth anything.
Does burning more tokens mean getting more done?
Not reliably. Spend tells you what the tooling cost, not what the work was worth.
Across three or four organizations the same distribution came back. At the top of the spend ranking sat both the people you would call top performers and people whose output you would throw away, burning comparable amounts, with a solid middle underneath. None of those organizations had token targets announced by leadership. The numbers were simply there, people looked at them, and anyone who knows the names behind them does a double take.
“Imagine you let your kids loose and say, let’s see who spent the most. And then afterwards you try to evaluate whether what they bought makes sense.”
Know what the leaderboards actually count, because neither is denominated in tokens. Cursor’s Usage Leaderboard ranks Chats, which counts messages sent rather than anything accepted, alongside accepted Tab completions and accepted agent lines. Anthropic’s analytics splits usage metrics from contribution metrics: lines accepted inside a session is one measurement, effective lines attributed to merged pull requests is another, and that attribution ignores which branch was targeted. Token and dollar figures live on separate billing surfaces.
No number in either family answers whether the change was worth making. A merged pull request that should never have been opened scores the same as one that fixed a customer-facing failure. The measured version is DORA’s ROI of AI-assisted Software Development report, which frames AI as an amplifier of an organization’s existing strengths and dysfunctions, and names the verification tax, the effort of checking that generated code is reliable and secure, as a cost that scales with volume.
What stays valuable when the container part is done
If spend does not measure value, the question turns personal: which part of this work is still worth paying a human for.
What is left that an agent cannot take over?
Knowing which problem is worth solving, in a domain you understand well enough to tell someone their ask is wrong.
The bar moved for a specific reason. The upper hand used to be that developers handed over Docker containers: make it run, keep it up, make it scale. That looked the same in every industry, and an agent can do it now. What clears the bar is a pairing: a business vertical you actually understand, with the vocabulary that goes with it, plus a technical discipline you are deep in. Cloud for fintech has its own compliance standards and its own sense of what matters, and anticipating how those requirements will change comes from time spent in that industry. Legal, sales and marketing already work this way. It is mostly us cloud engineers who take whatever comes.
The sharper edge is that the ask itself is often wrong. Somebody says they need a data pipeline, and they start making it expensive and reliable and throwing things at it, when what they needed was a message queue.
“If you only want the answer, that’s what you get. AI gives it to you. But you kind of need the lesson here.”
Two bills arrive later. Build got cheaper on the build side of build-versus-buy, and the maintenance obligation did not move: whatever you generate, somebody owns its upgrades, its security patches and its bugs. And if juniors treat generated output as truth, the usual reassurance is that abstraction has always moved up and almost nobody today knows assembler. The reply that undoes it is one sentence: we are moving to non-deterministic, anyhow.
Key numbers
| Number | What it is |
|---|---|
| 200,000 tokens | Where top models start to choke on themselves, and where we start a fresh session |
| 2 rounds | Our cap on review cycles, on the plan and again on the implementation |
| 30 days | Default cleanupPeriodDays for CLI transcripts. Desktop and Cowork sessions are exempt from it |
| ~3 months | How often a model change forces a pass over your skills and instructions |
What this means for your team
None of this is a tooling problem you can buy your way out of in an afternoon. The leverage sits in a handful of decisions that are cheap to make and expensive to keep postponing.
- Build one reference implementation for the pattern you repeat most, with the abstractions and the security stages you actually want, then point agents at it alongside your written instructions. Do it for something you will apply ten times, because the preparation only pays back across repetitions.
- Write down your stopping rule for reviews. An agent asked to find problems will keep finding them. Two rounds on the plan and two on the implementation is a defensible starting point, with extensive testing as the thing that substitutes for reading every line.
- Audit what your transcripts and your prompt history are holding. Lower
cleanupPeriodDays, setdesktopSessionCleanupPeriodDaysseparately because Desktop sessions are exempt, delete~/.claude/history.jsonlyourself, and rotate any long-lived token that has passed through a session or a pasted prompt. - Stop reading dashboards as performance. Learn what your numbers count, then ask what shipped, whether anyone can still explain it, and what the verification is costing you.
The trigger for redoing any of this is not a date on the calendar. It is a change underneath you: a model that starts reading your skills differently, or a harness that moves your config out from under them. When either lands, re-read the instructions you wrote for the previous one before you trust them.
Common questions, answered
How do I get an AI coding agent to write code in my team’s style?
Give it a worked example alongside the instructions. Build a small reference project showing the abstractions, module boundaries and security handling you want, then point the agent at that repository and tell it what to build. Anthropic’s prompting guidance calls examples one of the most reliable ways to steer output format, tone and structure. It carries across languages: the model reads the structure in one and applies the shape in another. The cost is engineering time that ships nothing that day, so build it for patterns you will reuse.
How do I stop my coding agent reviewing forever and never shipping?
Pick a cap and write it down, because there is no natural stopping point. An agent asked to find problems keeps finding them, and every round that changes the plan invites another, which is how a day disappears with nothing shipped. A workable shape: a grilling session on the plan, parallel reviewers across two different models, a hard limit of two planning cycles, then implementation with a second review pass, and extensive testing as the real safety net.
How do I get credentials out of my Claude Code transcripts and prompt history?
Set retention deliberately, delete the file retention never touches, then rotate the token. Anthropic’s documentation says files under ~/.claude are plaintext and that anything passing through a tool lands in a transcript, so any long-lived credential an agent touched is sitting there. CLI transcripts are deleted once older than cleanupPeriodDays, default 30 days. Two things survive that sweep: Desktop and Cowork sessions, which need desktopSessionCleanupPeriodDays on v2.1.248 or later, and ~/.claude/history.jsonl, which records every prompt you have typed and is kept until you delete it. Delete that file by hand or set CLAUDE_CODE_SKIP_PROMPT_HISTORY, then rotate any token that has been through a session.
Resources
- Julien Bisconti - the guest, a Stockholm-based engineer and SRE, Google Developer Expert for Google Cloud and maintainer of awesome-docker. Useful for why his answers skew toward workflow durability rather than novelty.
- Explore the .claude directory (Anthropic) - settles the transcript warning: plaintext files, the
cleanupPeriodDayssweep, the Desktop and Cowork exemption, andhistory.jsonlin the “kept until you delete them” table. Read Clear local data before reaching forclaude project purge. - Track team usage with analytics (Anthropic) and Usage Leaderboard (Cursor) - between them they settle that neither dashboard counts tokens, and that Cursor’s Chats column is not an acceptance at all.
- The ROI of AI-assisted Software Development (DORA) - the measured counterpart to the leaderboard argument, and a better number to argue with than an anecdote.
- Claude prompting best practices (Anthropic) - the documented half of the reference-implementation technique.