Standards Before Speed

I’ve now built a great deal of software with Claude Code, and I’m still not a software engineer.

I want to be precise about what that means, because it’s easy to hear as either false modesty or an excuse. It means I can read code and reason about architecture, but I don’t sit down and write the implementation. I direct. And what I’ve learned directing is that the single highest-leverage thing you can do is define your standards and protocols, and keep refining them.

Not better prompts. Standards.

The problem standards solve

Here’s the failure mode without them. You ask for something. You get back code that works but names things differently from the rest of your project. You correct it. Next session, same thing. You correct it again. Three weeks later you’re still correcting it, and you’ve spent more effort on the correction loop than the original work would have taken.

The model isn’t being obstinate. It has no way to know what “the rest of your project” looks like unless you tell it — and telling it conversationally means telling it again every single time.

A standards document turns a recurring correction into a one-time decision. That’s the entire trick, and it’s worth more than any prompt technique I know.

What actually goes in one

Mine has grown over time, but the things that earned their place are the boring ones:

Naming and structure. Where do new modules live. What a file is called. What a function is called. Whether it’s utils or helpers — the answer matters less than having an answer that never has to be relitigated.

What “done” means. Tests pass isn’t done. Tests pass, docs updated, no new lint failures, committed with a message that says what changed and why — that’s done. Write it down and “is this finished?” stops being a conversation.

What must escalate. The most important section, and the one people skip. Which decisions is the agent allowed to make on its own, and which ones stop and come to me? Anything touching data, anything touching money, anything that changes an interface someone else depends on. Everything else, go ahead.

The things you’ve already decided. Every time you find yourself explaining a preference for the second time, that’s a line item. Second time, not third — the second time is when you know it’s a pattern rather than a one-off.

Refine, don’t finalize

The word people get wrong here is “define.” They write the document once, exhaustively, up front, and then it goes stale because it was written before they knew what they’d need.

Mine gets edited most weeks. When I catch myself correcting the same thing twice, that’s a signal the standards missed something, and the fix goes in the doc rather than in the chat window. The document is a record of decisions I no longer want to make. It grows because I keep making new ones.

The other two things I’d tell you to do

Start a bug tracker. Not a mental list. Not a file called TODO.txt. An actual tracker with IDs and statuses. The moment you have agents finding and fixing problems, you need to be able to say “that one’s known, it’s filed, here’s its number” — otherwise the same defect gets rediscovered and re-fixed by three different sessions that don’t know about each other.

Start a backlog tracker, separately. Ideas and enhancements are not bugs, and mixing them is how a bug list becomes a wish list nobody looks at. Two trackers. Different things go in different places.

Both of these I had spun up by asking for them, and it took almost no time. That’s the part that still delights me — the infrastructure for working carefully is itself cheap to build now. The reason to do it isn’t that it’s hard. It’s that nobody tells you to.

Why this is the whole game

If you’re directing AI rather than writing code, your leverage is entirely in how well you’ve specified the world the agent operates in. Prompt quality gets you a good answer once. Standards get you good answers by default, forever, across every session, without you being present.

The gap between those two things is enormous, and it’s where most of the frustration with AI coding tools actually lives.

The projects, experience and opinions here are mine. AI helped me turn my notes and build records into this piece and polished it for Cairoglyphics.ai.