CRAFTS: The Agentic Coding Loop I Trust.

I wanted agents I could leave alone and still trust the output.

Trust it enough that when it said the work was done, I didn’t still have to sit there asking follow-up questions and iterating until the broken parts were actually fixed.

That’s what pushed me toward Anthropic’s long-running application harness pattern - the planner, generator, evaluator setup they used for autonomous coding. It was a good base, but I still needed more.

So I built CRAFTS on top of it.

I didn’t get there in one shot; it congealed over time as I kept adding the missing pieces that made agent output trustworthy enough for real software: planning before implementation, TDD in the build loop, adversarial review, security hardening, cleanup, and durable write-backs so the next run starts from a better place than the last one.

The goal was a result I could actually walk away from and still trust when I came back.

What CRAFTS is

CRAFTS is a methodology and loop. The acronym is:

I found the system first, then spent an embarrassing amount of time trying to name it something I could actually remember. The result is a mnemonic that a human can hold in their head, which feels slightly absurd given how much work went into making it easy to say out loud. It is also weirdly satisfying as a skill name. Telling an agent to /craft some code is a little too on the nose in the best possible way.

If you want the reference implementation, the CRAFTS skills live in my agent utilities repo: agent-utilities.

This is not ceremony for sport. It makes agent output usable for actual engineering work.

Here’s how the loop works:

If you only care about speed, sure, skip most of this and call it productivity. If you care about maintainability, portability, security, and not having to re-teach the same lessons every session, the extra structure stops being optional pretty quickly.

Conceptualize

Conceptualize is the project-manager part, except the project manager can inspect the codebase and actually use that context.

It takes the request, pulls in the relevant files, decides what the work really is, writes the acceptance criteria, and sets up the tests that prove the work is done. A lot of agent failure starts way before code exists. The model simply never got a sharp enough definition of done.

I want that work done before implementation starts. Not after the build has already wandered off into the weeds.

Render

Render is the build loop.

No poetry there. Just implement against the criteria until the tests pass.

And yes, I think reliable AI-written code needs TDD. If you want to trust the output, you need something objective to evaluate it against, and tests are the cleanest version of that. CRAFTS makes that explicit by putting the tests inside the implementation loop instead of treating them like an afterthought.

Sometimes the tests are not the whole story, though.

That is where Render becomes CRAFTS-HITL. The agent scaffolds up to a critical seam, leaves a TODO(human) marker, and stops. The human takes the judgment call, and the agent resumes and finishes the loop. That was the whole argument in TODO(HUMAN): The Case for Deliberate Presence in Agentic Development - business-critical work needs that seam, and vague specs need a human to pin them down before the ambiguity compounds later.

Assess and Fix

It’s loops all the way down, and A -> F is the conversational one.

Assess, Fix, and Tighten are really one quality loop wearing different hats for the sake of the acronym. Assess looks at whether the code satisfies the acceptance criteria, fits the architecture, and stays maintainable. Fix decides what is actually worth changing. Tighten catches the security issues, boundary problems, and unsafe defaults that still need to be handled before the work is actually done.

Assess says what it found. Fix decides what is actually worth changing. The evaluator can surface issues that matter, but it does not get the final say, and the builder is allowed to push back when something is just stylistic preference or a small detail that does not move the needle. If issue one through three are real, fix them. If issue four is noise, say why and move on. That back-and-forth is what keeps the loop honest.

I also bias the evaluator toward a different model family than the builder. Same-model review tends to share the same blind spots. Different models do not magically become wise, but they are better at catching the things the builder would have happily waved through.

Assess covers correctness, simplicity, maintainability, naming, reuse, and whether the thing actually matches the plan. It also looks for ways to simplify the code and make it easier for the next person - or agent - to work in later.

Tighten

Security is not a polish pass. It is part of whether the work can be trusted at all.

Tighten is the phase where I check the things that turn a working feature into something safe to ship: trust boundaries, input handling, injection risks, secrets, permissions, unsafe defaults, and the places where a clean demo turns into a bad day in production.

If the code crosses a trust boundary, handles user input, stores secrets, or can fail in a way that matters outside the app, Tighten is required. This is one of the lines between real software engineering and vibe coding.

Sharpen

Sharpen is where today’s work becomes tomorrow’s advantage.

This is the phase that turns CRAFTS from a workflow into something that compounds. It captures durable learnings - conventions, gotchas, decisions, and recurring patterns - and writes them back into the living documentation for the domain.

If the code proved the spec wrong, Sharpen updates the spec and explains why. That’s important because software is not static. The constraints move, the codebase changes, and the documentation has to move with it if it is going to stay useful. Evergreen docs are not a nice-to-have in that kind of system - they are how the next agent avoids rebuilding on top of yesterday’s assumptions.

That part matters more than it sounds like it should.

Without Sharpen, you still have a decent process. With it, the next run starts with less confusion, fewer repeated mistakes, and better context. The system gets quieter in the best way.

Why domain isolation matters

Sharpen works best if the knowledge it writes back stays scoped.

That is where domain isolation comes in. Split file trees, local documentation, clear boundaries. When each domain owns its own durable notes, the learnings stay relevant, the context stays smaller, and the model does not have to drag a pile of unrelated decisions into every new session. That means less context pollution, fewer tokens, and lower cost. It also makes the next run easier to reason about because the important stuff is still local.

When everything gets dumped into one global file, you get a junk drawer with confidence issues. When the domains stay separate, the write-backs stay meaningful and the token bill stays a little less stupid.

So CRAFTS is not just a sequence of steps. It is a sequence that depends on structure around the codebase - enough organization that the write-backs stay meaningful, and enough separation that one domain’s lessons do not pollute another’s.

Why this instead of the usual agent story

The usual agent story is mostly about capability. Mine is about trust.

I wanted autonomy, but only if the output stayed trustworthy. That is the actual constraint. Everything else hangs off it.

Anthropic’s long-running application harness pattern gave me a useful starting point. CRAFTS is the version I arrived at after deciding that real software needs more than role separation. It needs quality gates. It needs security. It needs cleanup. It needs a memory system that does not rot the moment the session ends.

And it needs to keep getting better.

If you’re already building with agents, steal the parts that work, adapt the loop to your stack, and see what holds up in practice. I’m curious what other trust-building patterns people are finding.