The four challenges of agentic development
After months of using AI coding tools across different projects, the same friction kept showing up. I built a small system to address each piece of it. Here's how it's shaped, and what it tries to fix.
Agentic development is genuinely powerful. Claude Code, Cursor, Codex, etc; these tools can ship real work. But after a few months of using them seriously, you start noticing the same friction showing up everywhere: across projects, across teammates, across sessions. The friction isn't about the model getting things wrong (this still happens but this system builds some guardrails). It's an structural approach to reduce repetition and create guardrails for more consistent results.
I've been iterating on a Claude framework for months. It's a personal system I keep refining as I use it.
What's emerged is less "a clever prompt library" and more an answer to four specific problems I kept
hitting. The framework lives in ~/.claude/configs/ and bootstraps with a single command.
But the more interesting story is which problems it solves, and why those problems aren't
solvable with better prompting.
This blog lays out the four challenges first, then walks through how each tier of the framework addresses them.
Where agentic dev breaks down
Four issues and each one is solvable (or at least improvable!), but only if you treat it as a system problem rather than a "write a better prompt" problem. The order matters: each later challenge gets harder to address until you've solved the ones before it.
Context drift & prompt sprawl
Same opening instructions every session. Same coding standards re-typed in every repo. Two teammates ask the model the same question and get different shapes of answer, because they prompted it differently, and the model has no shared baseline to fall back to.
Prompts are ephemeral. Whatever you taught the model last session vanishes when the session ends. Drift accumulates silently: two engineers, same codebase, divergent "AI-assisted" outputs. "Just write better prompts" doesn't scale; there's nowhere durable for those prompts to live, and no shared vocabulary to write them in.
→ Addressed by Tier 1: primitives and layered configs.
Onboarding & team alignment friction
A new teammate joins. To use AI effectively on the project they need: which conventions to follow, which commands the team relies on, which kinds of tasks have already been encoded, which mistakes the team has already corrected for. None of this is written down in a place the model can consume. It's folklore. Passed verbally, badly, slowly.
Onboarding to "the team's way of working with Claude" takes weeks. The model could be productive on day one, but only if the team's accumulated standards are loadable, not lore.
→ Addressed by Tier 1: layered configs (global → project → repo) + bootstrap command.
Corrections that never stick
You tell the model "don't mock the database in integration tests." It nods. Next session, in a different repo, it mocks the database. You correct it again. And again. The lesson never travels. This can be partially improved using Claude's memory, but persistence is the key. Corrections are the highest-signal training data you produce, and they evaporate the moment the session ends.
Repetition isn't just annoying; it actively erodes trust in the tool. If feedback doesn't compound, every session starts from the same baseline. The system gets no smarter; only the human does.
→ Addressed by Tier 2: feedback memories + /refine + hooks.
Hallucination & single-angle blind spots
The model reviews a PR and confidently flags an issue that doesn't exist, or misses one that does. A single context window, a single perspective, no independent verification. Confidence and correctness become uncorrelated. For high-stakes work (reviews, incidents, architecture audits) one-shot answers from a single agent aren't trustworthy.
You need cross-checks, multiple angles, and convergence over iterations. Hallucination feels more like a workflow problem than a model problem. You can build patterns around it instead of waiting for it to improve.
→ Addressed by Tier 3: multi-agent patterns (one-shot swarms, iterative validation).
Three tiers, each addressing a class of problem
The framework is layered. Each tier sits on the one before it and addresses a different class of challenge:
| Challenge | Tier | Primary mechanism |
|---|---|---|
| Context drift & prompt sprawl | Tier 1 | Primitives + layered configs |
| Onboarding & alignment | Tier 1 | One-clone bootstrap, shared vocabulary |
| Corrections that never stick | Tier 2 | Feedback memories + /refine + hooks |
| Hallucination & single-angle bias | Tier 3 | Parallel swarms + iterative verification |
Give the model a durable, shared vocabulary
resolves · context drift · prompt sprawl · onboarding friction
The fix for drift and onboarding friction isn't "better prompts"; it's primitives that live on disk, layered globally then per-project, with a single bootstrap entrypoint. Six primitives form the vocabulary every other tier reuses:
- Rules: durable standards in markdown, referenced by commands or a top-level
CLAUDE.md. - Commands: slash invocations. Workflow ones like
/commit,/ship, and micro ones like/diff,/wip. - Skills: structured guidance that sits between rules (always present) and commands (only run when you call them). They watch for context and load themselves when relevant.
- Output styles: switchable communication modes such as concise-dev, code-reviewer, planning-mode.
- Templates: shared output shapes (PR descriptions, reviews, ADRs). One source for many consumers.
- Hooks & agents: lifecycle hooks and expert personas. The substrate for Tiers 2 and 3.
These layer in three scopes (global → project → repo), with specificity winning. The team's Kotlin style sits at the project layer; this repo's quirks sit at the repo layer; universal defaults like commit format sit globally. Standards live in versioned files, not in your head. The model loads them; you don't re-type them.
Onboarding becomes a one-line operation: git clone + run INITIALIZE.md.
A new teammate goes from zero to "follows our standards" in minutes, not weeks. Folklore
becomes loadable.
Help corrections compound over time
resolves · corrections that never stick · feedback evaporating with the session
DRY isn't just "don't repeat across repos"; it's "don't repeat across sessions." Tier 1 makes the blocks layer in space. Tier 2 makes them learn in time.
This part is less a set of mechanical steps and more a re-wiring of how you work. Once the pattern takes hold, two beats start happening on their own:
1 · Automate new primitives. The third time you've typed something (a review checklist, a deploy preamble, a refactor pattern) that's the signal to encode it as a command, skill, or rule. Five minutes of work, durable from there onward. It slowly becomes a reflex rather than a chore.
2 · Iterate on what's already there. Every session leaves behind small observations: things you corrected, preferences you stated, edge cases you flagged. Most of that lives in an ephemeral memory layer and never travels further. The powerful pattern is translating that memory into your durable config layer. What was a one-off correction becomes a permanent rule. The primitives you already built don't stay frozen; they keep absorbing what you've learned about your own work.
A concrete implementation of this loop is the /refine command, surfaced
periodically when feedback accumulates. It gathers pending memories, routes each to the right
rule file, suggests confidence-rated edits, and folds them into configs on your approval. Each
run is one small iteration step on the primitives you've already built.
Memory is ephemeral noise; configs are durable, shared, git-tracked.
/refineis the bridge that promotes what's worth keeping; and only what's worth keeping.
Both beats reinforce each other. Friction that hits a third time becomes a new primitive, and existing primitives keep getting refined as you keep working. The framework slowly tunes itself to how you actually work.
Build verification patterns around hallucination
resolves · single-perspective bias · confident wrongness on high-stakes work
With self-improving blocks in place, you can compose patterns that fight hallucination at scale. Two families:
One-shot swarm · parallel fan-out. A parent agent gathers context and spawns
specialists in one message (kotlin-reviewer, python-reviewer, db-migration-expert) each in a
fresh context window, reading only what it needs. They run in parallel; the parent synthesizes
their reports against a shared template. Multi-perspective view at one moment, no
cross-contamination. Commands: /swarm-review, /swarm-incident,
/swarm-deep-dive, /swarm-spike.
Iterative swarm · sequential + inner verification. A baseline (v1) is
produced; then each subsequent iteration is itself a parallel mini-swarm (verifier,
gap-finder, cross-referencer) validating and correcting the prior version. The loop
early-terminates when two consecutive iterations agree (verifier finds zero corrections,
gap-finder finds no new gaps). Residual error rate at that point is low. Commands:
/go (≤3 iterations, inline), /fly (≤10 iterations, versioned spike
folder), /slice (phased execution plan).
The trade-off is explicit. One-shot trades depth for breadth; great for PR reviews and incident triage. Iterative trades time for confidence; great for spikes and architecture decisions where being right matters more than being fast.
Both families output to shared templates (Tier 1) and feed back into rules via
/refine (Tier 2). The composition matters: Tier 3 only works because Tiers 1 and
2 are already in place.
Three takeaways
Zoomed out, the framework looks like a stack. Six primitives at the base, composed into commands and skills, composed again into advanced multi-agent workflows. Each layer reuses the one below it, so nothing gets rebuilt from scratch.
Treat it as a system
Drift, repetition, hallucination. These usually aren't prompt-writing problems. They're closer to workflow problems, and the fix often lives outside the chat window.
Let it learn
Corrections are the highest-signal training data you produce. A feedback layer plus
/refine plus hooks turns them into permanent improvements that compound
across sessions.
Then compose
With a solid base, multi-agent patterns that address hallucination become a one-line command, not a research project. Composition is where the leverage shows up, and the substrate is what makes it cheap.
What's next
The building-blocks pattern has always felt more natural to me, and this framework is the result of several iterations and corrections I've found useful along the way. It's open sourced, designed as the foundation for your own process, and built to be shared.
I'll keep iterating on it as I refine my own development workflow. I hope it sparks ideas, or confirms patterns you've already arrived at on your own. The goal was always to help more engineers shape or iterate on their own agentic process.