You know the loop. You ask an agent to add authentication. It adds authentication. You ask for structured logging, then for tests, then for a CI step to run those tests, then a health check endpoint because the deploy needs one. Six prompts later you have a working feature, and you’ve spent the whole session doing what a template used to do in fifteen minutes: filling in the blanks one at a time, just prompted instead of coded.

That’s not automation. That’s scaffolding through a chat window.

The challenge Link to heading

Here’s a question worth sitting with before you open your next repo. What would it take to make your next entire app build one-shot? Not “mostly there after a few rounds of fixes.” One prompt, one pass, code that’s production ready. Could you actually give an agent enough context to execute the whole implementation in a single go?

For most of us, the honest answer is no. And the reason isn’t that the model is too weak. It’s that I hadn’t written down what “everything” looks like.

Why prompting one piece at a time keeps you stuck Link to heading

Every prompt you send only encodes what you happened to type into it that day. Ask for auth and you’ll get some implementation of auth: maybe JWTs, maybe sessions, maybe whichever library the agent has seen most often. Unless you say which one your team actually uses, you’re rolling dice, and you’ll roll them again tomorrow on a different repo, because nothing you said today stuck.

That’s the real cost of piece by piece prompting isn’t obvious because it doesn’t feel slow, it feels fast. The problem is that it never compounds. You are the context the agent is missing, and you have to keep supplying it, forever, one message at a time, across every repo you touch.

Build a context store instead Link to heading

There’s a better unit of work than the prompt: a context store. A centralised written place that holds the conventions, patterns and decisions you’ve already made.

Picture the loop this way: You request a feature and the agent checks the store, so it can write code that already matches how you work, and when it makes a decision worth keeping, that decision gets written back into the store. Next time, a different repo, a different agent, a different week, nobody has to relearn it.

That loop, read first, write back after anything that matters, is the trick.

What actually goes in it Link to heading

Governance Link to heading

Somebody has to own the store itself, or it turns into a dumping ground. That means a taxonomy for what belongs where, an index that maps every page to a domain so an agent (or a new hire) can find the right doc in one hop, and a trigger for when each page needs revisiting, tied to a real event rather than “someday.”

Language and code Link to heading

A style guide per language you actually use, not a generic one pulled from a blog post. Error handling and exception conventions, so an agent doesn’t invent its own halfway through a file. API contract and versioning rules, so the fifth endpoint it writes looks like the first.

Testing and quality Link to heading

What “tested” means at your company: coverage scope, which layers get unit tests versus integration tests, how dependencies get pinned and bumped, and which lint, format and type checks are non-negotiable before a commit lands. Write this down once and an agent stops guessing.

Security and identity Link to heading

Auth and credential precedence: which system wins when two disagree. Where secrets actually live and how they get delivered to a running service. The least-privilege rules your IAM setup is supposed to enforce, spelled out plainly enough that an agent requesting a new permission can tell whether it’s reasonable before it asks.

CI/CD and developer experience Link to heading

Pipeline stages and merge gates. Pre-commit hooks and the repo hygiene they enforce. A release and versioning scheme that isn’t reinvented per project. One command surface, so “how do I run this” has a single answer no matter which repo you’re in. And a note on which tooling and docs an agent should reach for first, so it isn’t guessing at your stack from scratch.

Infra and observability Link to heading

Infrastructure as code conventions, resource naming and tagging, a deploy and rollback model that’s actually been used in anger. Logs, metrics and traces, all three, not just whichever one someone remembered to wire up. Liveness and readiness checks, and the alerting sitting on top of them.

LLM Wiki Link to heading

Organising knowledge stores of old was arduous, but not today - llm-wiki is a beautiful concept meant for this type of storage. Karpathy’s idea has been showing promisingly efficient retrieval, and has its own tools to increase quality. That with Google’s extensible OKF format is what I landed on. It’s easily visualised in Obsidian, but is still just folders of markdown files.

How do we work together? Link to heading

I made this exact change to this blog’s own .claude/CLAUDE.md this week. Instead of cramming every convention into one file that grows forever, it now points at an external context store: a folder called the AgentContextStore that any agent working on this repo is told to consult before making an architectural or engineering decision.

What I want to do next is to encourage us all to do the same. Store the ways you want to work, and when we work together, let’s distill the important bits down and share them, so our agents code right first time.

I look forward to a world when I don’t have to explain the projects conventions every time a new hot shot developer joins, and when I can hit the ground running with a new repo in the first minute, because the context store already has almost everything it needs to know.

Start with one module Link to heading

So here’s the concrete version of the challenge from the top of this post. Don’t try to write the whole context store this weekend. Look at the list above and find the thing that’s thinnest in your own fave repo right now, the one where every agent session ends up asking you the same question. Write that module down this week. Point your CLAUDE.md or AGENTS.md at it.

Do that once, and the next feature you ask an agent to build might not need six prompts. It might just need one.