Part 6: An operating system for coding agents: the disciplined build

[kasenur]

The first session with a coding agent is crisp: it reads the code, makes a clean change, writes a test. By the thirtieth, something has rotted — it re-discovers the same files, contradicts a decision it made three weeks ago, guesses the test command, and quietly stops writing tests because nobody made it. The fix isn’t a better model. It’s an operating system around the model: a constitution, an autonomy boundary, tiered context, durable memory, a review panel, and a post-edit hook.Why the harness, not the modelA useful way to say it: the agent is the model plus its harness — the prompts, the tools, the context policies, the hooks, the sandboxes, the sub-agents, the observability wrapped around the raw model. The model is maybe a tenth of what decides whether you get working software over a quarter; the harness is the rest. The evidence is blunt. On the public Terminal-Bench 2.0 benchmark, LangChain moved a coding agent from outside the top 30 to the top 5 — a jump from 52.8% to 66.5%, or 13.7 points — by changing only the harness (system prompt, tools, and middleware like self-verification and loop detection), keeping the same model.Examined honestly, most agent failures aren’t just model failures — they’re configuration failures: a missing tool, a vague rule, an absent guardrail, a context window stuffed with noise. So when quality decays across a long project, the lever is almost never “wait for a smarter model.” It’s the harness — and unlike the model, the harness is yours to build. The rest of this post is the concrete one.The four things that decay (and the artifact that fixes each)Discipline — skips tests, expands scope → a constitution read every sessionContext — re-learns the repo → tiered CONTEXT.md, maintained by a hookMemory — repeats corrected mistakes → durable per-fact memory filesReview — one blind spot applied uniformly → a multi-lens agent panel1. A constitution (CLAUDE.md / AGENTS.md)A lean, always-loaded file stating the non-negotiables: the workflow loop (Plan → Document → Implement → Test → Review → Commit), the autonomy boundary, the quality bars (tests in the same diff, no dead code, conventional commits), and adapter discipline (no vendor SDK in domain code). Keep it short — it’s read on every turn, so every line costs context budget.2. An autonomy boundary, not a kill switchThe highest-leverage single decision: let the agent run free on everything reversible, pause only on the two things that aren’t — pushing to a remote and deploying. As a permissions config:{

"allow": ["Read","Edit","Write","Grep","Glob",

"Bash(git add:*)","Bash(git commit:*)",

"Bash(npm test:*)","Bash(npm run:*)","Bash(npm ci:*)","Bash(pytest:*)"],

["Bash(git push:*)","Bash(npm publish:*)","Bash(aws:*)","Bash(terraform apply:*)","Bash(kubectl apply:*)"],

"deny": ["Bash(git push --force:*)","Bash(git push -f:*)","Bash(*--no-verify*)"]

}
}Now it works for an hour and commits a dozen times; you review at the push, not at every keystroke. The blast radius of “autonomous” stays bounded because the irreversible ops are the only gated ones. (Verify your runner’s match semantics — prefix vs substring differ — so --no-verify/--force denials and npm publish actually trip; broad globs like npm:* quietly allow npm publish.)3. Tiered context the agent maintainsOne giant context file rots and blows the budget. Tier it:Root CONTEXT.md — the map: what this is, how to run/test, one-line module index, invariants, where state lives. Cap ~200 lines; the session-start read.Per-module CONTEXT.md — responsibility, key files, deps, gotchas, how to test just this module. Read before editing that module.DECISIONS.md — append-only: date, decision, why, alternatives rejected. (This one earns its own deep treatment once several agents share the repo — expanded in Part II.)Rule: stale context is a bug, fixed in the same change that invalidated it — not “later.”4. Durable memory + a tiny knowledge graphContext describes the code; memory holds what the code can’t tell you across sessions — one fact per file, indexed:memory/

# type: user | feedback | project | reference

# {from, rel, to} — modules/decisions as nodes; depends-on/adapts/supersedesThe graph answers the question agents are worst at: “what breaks if I change this?”5. A review panel, not a reviewerInstead of one self-review, run focused sub-agents in parallel, each one lens, strict output😛roduct

— solves the stated problem? scope creep?

(plan stage)
architect — correctness, data model, failure modes, coupling
infra

— resource limits, deploy/rollback, resilience
security — authz, input validation, secrets, audit trail
test-eng — is the suite real, or happy-path theater? (per change)
→ each returns: [BLOCKER|MAJOR|MINOR] (confidence%) — file:line — issue — fix ; VERDICTOnly high-confidence BLOCKER/MAJOR gate. Diverse lenses catch what a single pass misses; the confidence threshold keeps it from drowning you in nits. (Note: these are parallel agents reviewing one change — distinct from parallel agents making changes, which is Part II’s whole problem.)6. A post-edit hook so nothing drifts silentlyThe piece that ties it together — fires after every edit and emits a checklist (a PostToolUse hook):Wire it in settings.json, pointed at a tiny script:{ "hooks": { "PostToolUse": [

 

[CuneytSari39]

Bu bilgileri uygulayacağım, çok teşekkürler.

 

[OzlemBaran27]

Peki bu konuda başka kaynaklar var mı? Öneri?