How 41 codified laws, 22 specialist roles, and a file-based memory system stopped an autonomous coding agent from quietly re-breaking the same production defect every few weeks — and why I'm open-sourcing the whole thing as LEO.
Ten times faster, ten times more garbage
Developers reach for Cursor and Copilot to write code ten times faster, and the tools deliver on exactly that promise — which turns out to be most of the problem. Used as advanced autocomplete, an LLM doesn't produce ten times more good code. It produces legacy at ten times the usual rate. You ask for a feature; the model hands back a wall of if/else; you ship it. Two months later the codebase reads like it was assembled by five people who never spoke to each other, the test suite is red more often than green, and the senior engineers who never touched the tool get to point at the wreckage and say, "See? AI is just a toy."
They are not wrong about the wreckage. They are wrong about what caused it.
The bug that wasn't a bug
Directing an AI coding agent on real, paying engagements — multi-tenant SaaS platforms, one of them with background AI pipelines — surfaced the same shape of defect more than once, in different files, weeks apart. My own project's changelog (roles/SYSTEM_UPGRADE_MANIFEST.md — every rule this system has ever added is logged there, with a reason) documents the pattern directly: a rate limiter that could be starved by its own retries because the check-and-consume wasn't atomic at the point of the call. A background worker whose heartbeat proved it was pinging, not that it was making progress — a zombie that looked alive on the dashboard. A held database transaction that outlived the request that opened it and sat there as a lock-holding corpse until something else timed out behind it.
Each time, the agent's code was syntactically perfect. Each time, it passed its own tests. None of this was "the AI is bad at coding" — a frontier model in 2026 writes fine syntax all day. What the log shows is something else: the fix, when it happened, didn't generalize. A defect gets patched in the file where it was noticed; the class of defect — "a heartbeat is not proof of progress," "an if check is not a lock" — has no durable home unless something outside the conversation writes it down as a standing rule. A chat window that scrolls out of context has no mechanism to carry a lesson forward into the next file, the next session, or the next agent entirely. That's not incompetence — it's closer to amnesia at the architecture level, and it is a far more expensive defect than any single wrong line of code, because it recurs on a schedule instead of getting fixed once.
That's the point at which "prompt the AI better" stopped being a credible answer and started looking like an engineering-process problem — the same kind of problem code review, QA, and architecture sign-off were invented to solve, decades before anyone typed "you are a helpful senior engineer" into a text box.
It doesn't need supervision. It needs a form to pour into.
The standard advice for this problem is "treat the AI like a junior developer" — review everything, don't let it merge unsupervised, keep a human in the loop. That's better than nothing. It's also the wrong model, because it assumes the AI already has judgment that mostly just needs correcting on the margins.
It doesn't have judgment to correct. What it has is a high-volume stream of pattern-matched output with no default shape of its own. Pour that stream into an empty context window and it takes whatever shape the last few messages happen to suggest — which is exactly why it drifts. A junior developer is calibrating an internal model of correctness that gets sharper over time. An unconstrained agent has no such model to calibrate; every session starts from the same blank slate, and "use your judgment" is not an instruction it can actually follow, because there's no accumulated judgment there to use.
So the fix isn't heavier supervision of a decision-maker that doesn't fully exist yet. It's building the banks before the water starts flowing: narrow, explicit, interlinked protocols that live inside the project itself — not a paragraph of "best practices" floating somewhere in the model's training data, and not on some vendor's central server you have no visibility into, but files in the actual repository the agent is working in. The agent doesn't need better judgment about which approach fits a given situation. It needs the approach already decided, written down, and sitting in a file it is required to read before it acts — so it isn't guessing by accident which rule applies. It's following the one that was already there.
That's the actual shift LEO makes: not "supervise the junior dev harder," but stop expecting a finished decision-maker and start engineering the channel its decisions are required to flow through.
Why "just write better prompts" doesn't scale
A single well-crafted prompt is a snapshot of good judgment. It captures what you know to ask for today. It says nothing about the bug you haven't hit yet, the invariant nobody wrote down, or the decision the agent made forty messages ago that it is about to silently re-make, differently, right now.
This is context drift, and it's the actual bottleneck of autonomous coding — not model capability. Give a model enough tokens and it will confidently:
- Skip the empty state, the 500th test, the timeout on the outgoing HTTP call — because nothing in the conversation made skipping it expensive.
- Report "should work now" or "practically done" with the same tone it uses for a fact it actually checked. Confidence and correctness are not the same signal, and an unconstrained agent has no mechanism to distinguish them out loud.
- Never get told no. A single-agent chat has no adversary, no separate reviewer, no QA pass with different incentives than the one that wrote the code. A logic hole ships exactly as fast as the happy path does, because nothing in the loop is structurally positioned to catch it.
None of this is a hypothetical risk. It is the default behavior of an agent operating without a written, load-bearing process — which is precisely the situation almost every "AI pair programmer" setup puts the model in today: one soft system prompt, infinite goodwill, zero enforcement.
Tokens are not the budget. Organization is.
Most people trying to control the cost of agentic coding optimize the wrong variable. They shrink each individual prompt and count tokens per request, treating a smaller ask as a cheaper one. That's measuring the wrong unit. A hundred disorganized double-check loops spread across five million tokens produce a worse result than two or three tightly organized ones spread across that same five million tokens. Same spend, radically different outcome — because the cost was never the tokens themselves. It was the absence of a structure telling each loop what it was actually supposed to verify, against what written standard, and who signs off when it's done. Shrink the prompt and you still pay for a hundred aimless loops. Give the loop a gate and a criterion instead, and it often takes two or three.
What I actually built
I come from an unusual angle for this problem. Before I wrote a line of production code, I spent five years in Emergency ICU. That environment teaches you something that transfers directly and uncomfortably well to shipping software with an autonomous agent: zero-error tolerance is not a slogan, it's a set of protocols that exist because someone already paid for the version without them. You don't re-derive the correct response to a cardiac arrest from first principles under pressure — you follow a checklist that encodes every prior failure, because "use your best judgment" is precisely the instruction that fails under load.
I'll be straightforward about where this actually started, because the honesty matters more than the polish. I came into software development as a junior in the middle of the hiring freeze that's reshaped this market over the last few years, and the catch-22 inside it has a specific, brutal shape: you can't get hired without production experience, and you can't get production experience without being hired. LeetCode katas and toy CRUD projects don't close that gap — they were never built to carry the weight of a real system with real users and real consequences for getting an invariant wrong. I felt that wall directly, and it wasn't only a financial problem. It was a quiet, ongoing doubt about whether the path you actually want is still open to you at all, when every door that would let you prove yourself asks for the proof first.
So the bet underneath LEO was never really a career strategy. It was closer to: if the industry won't hand a junior the reps, and a coding agent can write code but has no engineering department to write it inside of, then build the department myself and let the agent supply the reps the market wouldn't. Production-grade SDLC discipline cannot be learned from LeetCode, and it cannot be prompted into existence one clever system message at a time. It has to be architected — as a real, versioned, falsifiable rule system that an agent is required to operate inside of, the same way a hospital shift operates inside protocols nobody re-litigates every time.
That system is LEO — Lead Engineering Orchestrator.
LEO is not a library, a plugin, or a hosted product. It's a written constitution — a .cursorrules file plus a 127-file, ~254,000-word role library — that any coding agent with file-system/tool access can load instead of a one-line personality. It gives the agent:
-
A single entry point,
@LEAD, that routes every request to a named specialist instead of one model trying to simultaneously be the architect, the developer, and the auditor of its own work in the same breath. -
Twenty-two roles with real jurisdiction —
@ARCHowns the database and API contracts;@PRINCIPLEowns whether a state is logically reachable at all, independent of whether it's technically buildable;@QA_ARCHaudits business logic before anything ships;@PENTESTholds a genuinely blocking security verdict, not an advisory checklist;@DEVis the only role permitted to touch code, and it is allowed to refuse — to raise a MODEL BLOCKER — rather than guess at a hole in the spec. -
Forty-one Absolute Laws, several written the week a specific defect happened, not from a whiteboard session — the project's own changelog,
roles/SYSTEM_UPGRADE_MANIFEST.md, logs them with dates. The rate-limiter-and-heartbeat incident above (v6.25) became a law about atomic check-and-consume at the point of the call — not a comment, a permanent, greppable rule that a@QA_ARCHaudit now checks for on every future pipeline — and a redefinition of "heartbeat" itself: a pulse without progress is not aliveness. The lock-holding-corpse transaction became Law 35: every session in the architecture spine now carries a numericidle_in_transaction_session_timeout, not a hope. These aren't abstract best practices; they're scar tissue, converted into text the agent cannot argue its way around because it's not a suggestion — it's the operating rule it's loaded under. -
A gate protocol, not a pipeline. The difference matters enormously: a pipeline lets an agent "complete" a phase by declaring it complete. A gate requires a written artifact — an architecture spine, a security threat model, a QA report — that a separate pass checks against a concrete, numeric criterion.
roles/LEAD_ANTI_CHECKBOX_PROTOCOL.mdexists specifically to catch phrases like "most likely implemented" and force a real answer: verified, with evidence, or explicitly unknown. - A memory that survives the context window. This is the actual fix for the amnesia I started with. Every non-trivial decision — the tenancy model, the threat model, the QA verdict — gets written to a file, not left in chat history. Three weeks and forty conversations later, a completely fresh agent session with zero memory of any prior chat reads that file and inherits the decision exactly. It doesn't re-derive it, and it doesn't quietly re-decide it differently. State, not history — that single principle is doing more work against context drift than any prompting trick I've found. Concretely, this means treating your IDE's own indexing of the project — Cursor's index, a plain file read, a grep across the repo — as the durable memory, and the chat window as what it always was: disposable scratch space. Of every reliability trick I tried, moving memory out of the window and into the file system is the one that actually held up once the project got large.
-
A human hand on the only lever that matters. LEO can evolve its own rules after an incident — but only via an explicit
@EVOLVEcommand from a person, never automatically. And separately, Law 40 — the one I'd call the most important line in the whole system — states plainly that the agent never runsgit commit,git push, orgit merge, under any framing, even if you paste the exact commands and ask twice. An autonomous agent that can silently rewrite its own rules and publish its own work to history is not a tool anymore; it's an unaccountable process. LEO deliberately keeps a human's hand on both levers.
Why LEO doesn't divide and conquer
The obvious way to control both cost and hallucination in a multi-role agent system is isolation: give each role the minimum context it needs, wall roles off from each other, and assume a smaller context means fewer wrong guesses. I built LEO the opposite way, after watching isolation produce more invented behavior, not less.
The reason is mechanical, not philosophical. A role that has no idea what the adjacent role does, checks for, or expects has to fill that gap somehow — and it fills it by guessing, which is just hallucination wearing a job title. The right hand that doesn't know what the left hand is doing doesn't stay idle out of caution; it invents a theory about the left hand and acts on that theory. Isolate roles to save tokens and produce "minimal fantasy," and what you actually get is every role quietly inventing its own model of every other role's job — because nobody told it the real one, and it can't operate on nothing.
LEO's 22 roles are not isolated specialists reading their own private slice of instructions. They're facets of one written system, and every role's constitution names every other role's obligations, not just its own. @DESIGN knows a @QA_VISUAL exists that will render its spec and measure it against hostile content at four viewport widths — and it writes a more disciplined spec because that check exists, the same way a surgeon documents a procedure more carefully knowing the next shift reads the chart, not because anyone is standing over their shoulder in the moment. That mutual awareness isn't redundant overhead. It's the actual mechanism that keeps 22 roles from drifting apart into 22 private guesses about what "done" even means.
So LEO's shape isn't "divide and conquer, keep every role's window small." It's one constitution that every role operates inside of, where each role's job is legible to every other role — because the alternative to a role knowing the whole system isn't a cheaper, smaller role. It's a role silently inventing the missing half of the system on its own, every single time it hits a gap nobody told it about.
Naive multi-agent systems multiply entropy. Constitutional multi-agent systems decrease it — because mutually aware roles create a continuous gravitational pull toward quality.
This isn't a thought experiment
I've directed over 14 billion tokens of iterative, gated agentic work through this system across real client engagements and independent products — not toy demos. MedCore, a multi-tenant dental-clinic operations SaaS with row-level security, advisory-lock concurrency protection, and 800+ tests. An AI training platform with executable LangGraph agent graphs, pgvector-backed retrieval, and a generative-media pipeline. A public-sector education platform where SSR-for-SEO and license-compliance weren't afterthoughts because Law 29 and Law 41 made them non-negotiable before the first line of layout code existed.
Every one of these systems stress-tested a different part of the rulebook. MedCore is why the data-integrity canon insists that "no double-booking" lives in a database constraint, never an if statement — because an if check is exactly the thing that fails when two requests race, which is precisely when the invariant matters. The AI platform is why there's a separate @AI_ENGINEER lane instead of folding retrieval and agent-graph decisions into generic backend architecture — RAG has its own failure modes (stale embeddings, duplicate generation on retry) that a standard code review doesn't have a vocabulary for. The public site is why a search-visibility decision (SSR vs. SPA) gets made at the architecture-spine stage, not discovered as a regret after launch.
I'll say plainly where MedCore sits relative to the other two: it was my own first attempt at directing this entire process end-to-end, and it shows — it's rougher in places than the engagements that came after it, closer to a "no-code" debut than a polished flagship. I'm publishing it with those flaws intact rather than hiding them, because a debut that shows the process holding up against large, genuinely messy data going into a build — instead of a curated demo that hides how the process actually went — is the more honest evidence, and the more useful one. It'll be public at github.com/alex-zaporozhan/medCore.
Is this "open source"? Be precise about it.
I want people to use LEO freely — including at work, including as the backbone of software they charge money for. I do not want someone to take these 127 files, reskin the headers, and sell it as a competing framework. Those two goals sound compatible with "open source" until you actually read the Open Source Definition's field-of-use clause, which explicitly forbids exactly the second restriction. So I'm not calling it that.
LEO ships under PolyForm Shield 1.0.0 — a source-available license with a noncompete clause instead of a noncommercial one. Practically: use it for anything, including your own paid product. Just don't resell LEO itself. It's the same license I already ship on MedCore, for the same reason, and I've written out the full comparison against MIT, GPL, and the Creative Commons NonCommercial family in LICENSING.md — because I'd rather be boringly precise about this than technically inaccurate and hand a critic an easy, correct point to make.
What I'd want you to take from this
If you're building with autonomous coding agents and you keep hitting the same category of defect in a different file — that's not a model problem you fix by switching to a bigger model. It's a process gap, and the fix looks exactly like the fix for the equivalent gap in human teams: named ownership, written contracts between roles, an adversarial check that isn't the same pass that wrote the code, and a memory that outlives the conversation.
I'll say the underlying motive directly, because I think it matters more than the rule count. I don't want "AI just writes garbage" to become the settled opinion of the software industry, and I think it's currently on track to become exactly that — for reasons that have everything to do with process and nothing to do with the technology's actual ceiling. I think agentic coding is a genuine inflection point, not a toy, and it's already changing how software gets built whether any of us are fully ready for that or not. Publishing LEO is my attempt to push that outcome in a specific direction: make AI-driven software development measurably more stable and reliable at a global scale, put a concrete idea in front of people who are hitting the same wall I hit, and let the world decide if it's useful. That's the whole bet.
And if you're a junior stuck in the same catch-22 I described above — locked out of the experience you need because nobody will hand it to you first — I'd like this to land for you specifically, not only for teams already inside the industry. Underneath the 41 laws and the 22 roles, LEO is one junior who knew the fundamentals and nothing else, trying to organize an AI's work through instructions precise enough that the AI could open a door the market had closed. If any part of this helps you turn a tool people keep insisting only writes garbage into the engineering department willing to let you become whoever you're actually trying to become — do it, even when the conditions in front of you say it isn't possible. Mine said exactly that, for a long time, before they stopped.
That's what LEO is. It's a constitution, not a product — text you can read in an afternoon, delete the parts you don't need from, and hand to whatever agent you're already using. The repository, the full role library, the architecture deep-dive, and the real shipped systems it ran are all here:
github.com/alex-zaporozhan/leo
I'm open to Founding Engineer roles, AI-native full-stack positions, and strategic AI-SDLC architecture contracts. If any of this resonates, I'd genuinely like to hear from you — LinkedIn.
— Alexandr Zaporozhan
