DEV Community: Joseph Yeo

Planning Is Not Permission

Joseph Yeo — Thu, 10 Sep 2026 18:16:16 +0000

One distinction I underestimated while building agent systems was the difference between a plan and permission.

They often look similar.

They are not.

A document can say exactly what should happen.

An agent can understand it perfectly.

The next step can be obvious.

And the agent can still have no legitimate reason to do it.

That distinction became much more important once I stopped building agents that only handled one task at a time.

A Plan Answers the Wrong Question

Most agent workflows start with some version of this:

Here is the goal.
Here are the requirements.
Here is the architecture.
Here is what should happen next.

That is useful information.

It tells the agent what the intended future looks like.

But it does not answer another question:

What is the agent actually allowed to change?

For a small coding task, the distinction can feel unnecessary.

If I say:

Fix this function.

then intention and permission are almost identical.

But long-running work is different.

A project may contain:

future ideas;
accepted decisions;
old decisions;
research notes;
implementation suggestions;
things explicitly postponed;
things that sound reasonable but were never approved.

To a language model, all of them are text.

That is dangerous.

Because language models are very good at turning coherent context into plausible action.

Sometimes too good.

Useful Context Can Become Accidental Permission

This problem did not appear because the agents were confused.

It appeared because they were helpful.

Imagine a planning document that says:

We may eventually automate this step.

A human reads that sentence and understands the uncertainty.

An agent may read the same sentence inside a larger implementation task and conclude:

Automating this now moves the project closer to its intended architecture.

That conclusion may be completely reasonable.

It may also be completely unauthorized.

This was the pattern I started noticing:

reference
↓
recommendation
↓
intention
↓
permission

The model could silently slide from one category to the next.

Not because it was malfunctioning.

Because I had not given the system a reliable way to keep those categories separate.

That was my mistake.

Better Reasoning Doesn't Fix This

My first instinct was predictable:

Make the instructions clearer.

Add stronger wording.

Tell the model not to overreach.

This helps.

But it does not solve the underlying problem.

If the system depends on the agent correctly interpreting which sentences allow action, then the agent is still deciding what the instructions permit it to do.

That becomes fragile as the context grows.

You eventually get prompts full of language like:

this is only a suggestion

do not implement this yet

this section is historical

except where superseded below

the following is future direction only

At some point, the prompt starts looking less like a plan and more like a legal document.

And the agent is still the one interpreting it.

I had encountered a similar pattern in ForgeFlow.

When a fact could be measured directly, I stopped wanting the model to be the source of that fact.

Now the same instinct was appearing at a different layer:

If permission matters, don't make the agent infer it from prose.

Then I Hit the Opposite Problem

Eventually I ran into the reverse failure.

A project objective had already been approved.

The direction had not changed.

Nothing strategic had changed.

But an ordinary implementation detail inside that objective still had to come back to me for another decision.

The system could tell that something had changed.

What it could not reliably distinguish was:

Is this just normal execution inside the existing work?

or:

Does this require a genuinely new human decision?

So it stopped and returned to me.

That was safe.

It was also a sign that something was wrong.

If every implementation detail inside an already-approved objective still requires another human decision, then the approval did not actually buy much autonomy.

That was when I started questioning the unit of approval itself.

Asking Me Every Time Wasn't the Answer

There is an obvious safe solution:

Ask the human.

Before every meaningful action.

Before every file change.

Before every retry.

Before every continuation.

That works.

It also destroys the reason for building an autonomous system.

You end up with:

agent works
↓
asks human
↓
agent works
↓
asks human
↓
agent fails
↓
asks human
↓
agent retries
↓
asks human

The agent may be autonomous internally.

The workflow is not.

The human becomes a permission API.

That was exactly the bottleneck I was trying to remove.

So the problem became more interesting.

I did not want:

unlimited autonomy

and I did not want:

approval for every action

I wanted something in between.

The Unit of Approval Was Too Small

This was the real shift for me.

I had been thinking about approval as something attached to individual actions.

But perhaps the useful unit was larger.

A human could decide:

This is the objective.
This is the area you may operate within.
These things must not change.
Come back if the work requires crossing that boundary.

Then the system could handle ordinary execution inside that space.

That does not remove human authority.

It changes where human authority is exercised.

Instead of:

human approves action
human approves action
human approves action
human approves action

the goal becomes closer to:

human defines the boundary
        ↓
system works inside it
        ↓
human returns when the boundary must change

That felt like a much more scalable relationship.

And it changed how I thought about autonomy.

Autonomy Is Not the Absence of Permission

I used to associate autonomy with fewer restrictions.

Now I think that is incomplete.

In my system, clearer boundaries often created more room for autonomy.

An agent that can do anything often has to ask more questions because the consequences of every choice are larger.

An agent operating inside a clear boundary can make more decisions without escalating every uncertainty.

That sounds contradictory.

But the point is not to make the agent obedient.

The point is to make the operating space explicit enough that ordinary work does not require continuous human interpretation.

This Also Changed How I Read Planning Documents

I now mentally separate two questions whenever I read a project document:

1. What does this document tell me about the desired future?

and:

2. What does this document permit right now?

The answers are often different.

A roadmap can describe something that should exist next year.

That does not authorize implementing it today.

A research note can contain a better design.

That does not automatically invalidate an accepted one.

A brainstorming session can produce the correct idea.

That still does not make it a decision.

This distinction sounds bureaucratic until agents start acting on your documents.

Then it becomes a safety property.

What This Does Not Prove

I am not claiming every agent system needs formal permission machinery.

If the agent is writing a draft into a temporary directory, probably not.

I am not claiming humans can perfectly define boundaries in advance.

They cannot.

Ambiguity does not disappear because you write more rules.

And I am not claiming a bounded system cannot do something stupid inside the boundary.

It absolutely can.

This solves a narrower problem:

A system should not confuse knowing what might be useful with having permission to do it.

That distinction became foundational for how I started thinking about Bezalel.

The Question Changed Again

The first Bezalel problem was:

What needs to survive after a run so the next one does not have to guess?

Then another question followed:

Once the next run knows what happened, how does it know what it may do next?

A plan was not enough.

Context was not enough.

A recommendation was not enough.

And asking me after every step was not autonomy.

So I started treating planning and permission as different problems.

That distinction opened the next one.

Because even if an agent knows what it is allowed to do now, eventually it finishes the task.

Then what?

That is where the next part begins.

A question for anyone building long-running agents: how much of what your agent “knows it should do” has actually been authorized to happen?

The Commit Survived. The Reason It Failed Didn't.

Joseph Yeo — Tue, 08 Sep 2026 17:11:47 +0000

A few months ago, one of my agent runs failed.

The code survived.

The commit survived.

The reason it failed did not.

That turned out to be a much bigger problem than the failed run itself.

Git Remembered the Code

At the time, I was already treating Git as an important part of the agent system.

That felt obvious.

If an agent changes code, I want to know:

what changed;
when it changed;
what came before it;
whether I can reproduce the diff;
whether I can go back.

Git is extremely good at this.

After the failed run, I could still inspect the candidate code.

Nothing had vanished.

From a normal software-development perspective, that sounds fine.

It wasn't.

Because the question I needed to answer later was not:

What code did the agent produce?

It was:

What actually happened during the run?

Those are different questions.

And I had preserved only one of them.

The Missing Part Wasn't the Error Message

At first, this sounded like a logging problem.

Maybe I just needed better logs.

But the more I looked at it, the less useful that framing became.

An agent run produces more than code and more than logs.

There is an entire surrounding context:

what the agent was trying to do

what it was allowed to do

what it actually changed

which checks ran

what those checks observed

where the run stopped

what was known at that moment

what was still uncertain

If that context disappears, the next session has to reconstruct the story.

And reconstruction is dangerous.

Especially when an LLM is doing it.

A model is very good at turning incomplete evidence into a coherent explanation.

Sometimes that explanation is correct.

Sometimes it is simply the most plausible story that fits what survived.

Those are not the same thing.

A Failed Run Is Data

This changed how I thought about failure.

Until then, I mostly treated a failed run as something to fix.

run
↓
failure
↓
diagnose
↓
retry

The retry was the useful part.

The failure was an obstacle on the way there.

But if you are building an agent system that is supposed to improve over time, the failed run is also an observation.

It tells you something about:

the task;
the environment;
the agent;
the verification process;
the assumptions surrounding all of them.

And once the retry succeeds, that earlier failure may become more valuable than the successful run.

The success tells you that one path worked.

The failure may tell you why the previous architecture didn't.

So I started thinking about the lifecycle differently:

run
↓
observation
↓
interpretation
↓
next action

The important thing was no longer just preserving the output.

It was preserving enough reality that the interpretation could be challenged later.

This Is Where Agent Systems Get Weird

In normal development, a human often carries enormous amounts of context implicitly.

You remember:

That test wasn't meaningful because the environment was wrong.

Or:

That implementation technically passed, but we discovered the assumption was invalid.

Or:

Don't reuse that approach. We already tried it.

A team may carry this information through code review, Slack, issue trackers, meetings, or simply memory.

An autonomous system doesn't get that for free.

A new session sees artifacts.

It does not automatically inherit the meaning humans attached to them.

This becomes more important as the agent works for longer periods.

Suppose an agent comes back tomorrow and sees:

commit A
commit B
commit C

It can inspect the code.

But which of these represents progress?

Which one was rejected?

Which one was only an experiment?

Which failure discovered something important?

Which apparent success later turned out to be misleading?

A Git graph cannot answer all of that.

Because a history of source code is not automatically a history of the development process.

That distinction became one of the early reasons I started building Bezalel.

Source and Evidence Are Different Things

I had been collapsing several concepts into one vague idea of "history."

That was a mistake.

The source tells me:

This code existed.

Evidence tells me:

This was observed.

Those are not interchangeable.

A commit can survive while the evidence that explains it disappears.

Evidence can survive while later investigation shows that the interpretation was wrong.

And a perfectly preserved narrative can still disagree with the repository itself.

That last one became important later.

But the first lesson was simpler:

If future work depends on understanding what happened, preserve the observation—not just the artifact that resulted from it.

This sounds obvious in retrospect.

Most useful engineering lessons do.

More Logs Would Not Have Solved It

There is an easy overreaction here:

Record everything.

Every command.

Every prompt.

Every intermediate message.

Every token.

Every state transition.

I don't think that's the answer.

More data can make reconstruction harder, not easier.

A million lines of agent transcript are not automatically better evidence than ten machine-observed facts.

I became much more interested in selective evidence.

What facts would a future run actually need in order to understand the previous one?

What can the machine observe directly?

What should never depend on the agent's own description of what it did?

That last question has followed me through nearly every system I've built since.

If a machine can observe a fact directly, I increasingly don't want a model to be the canonical source of that fact.

For example:

bad:

"What files did you modify?"

agent:
"I modified A and B."


better:

observe repository state directly

The explanation can still be useful.

It just shouldn't replace the observable fact.

The Real Requirement Was Recovery

Eventually I realized this was not primarily an observability problem either.

It was a recovery problem.

What does a future process need to continue safely after the previous process disappears?

Not:

Can it reconstruct a convincing story?

But:

Can it recover enough verified state to know what happened and what remains unresolved?

That became a recurring theme in Bezalel.

The process should be able to stop.

The chat can disappear.

The model can change.

The machine can restart.

And the next run should not depend on me remembering the missing parts.

This is much harder than adding memory to an agent.

Memory tries to answer:

What happened before?

Recovery asks:

What previous facts are safe to depend on now?

I care much more about the second question.

What This Changed for Me

The failure left me with three simple rules.

1. Preserve observations, not just outputs

The code is one artifact of a run.

It is not the run itself.

2. Prefer machine-observed facts over agent narration

If a system can measure something directly, don't make the agent's report the only surviving version of that fact.

3. Design for the next session

A system that works only while the current conversation is alive is not yet a long-horizon autonomous system.

The next session should inherit enough reality to continue without inventing the missing story.

What This Does Not Prove

I am not claiming every agent run needs permanent forensic storage.

That would be expensive and probably useless.

I am not claiming more evidence automatically makes a system more trustworthy.

Bad evidence can be preserved perfectly.

I am not claiming Git is insufficient.

Git is excellent at preserving source history.

The mistake was expecting source history to preserve information it was never designed to represent.

And I am not claiming I have found the perfect boundary between useful evidence and noise.

I haven't.

That is still an active design problem.

The Commit Wasn't the History

The failed run eventually got fixed.

That part was ordinary.

What stayed with me was what I couldn't recover afterward.

The code was there.

The explanation wasn't.

More importantly, I could no longer distinguish with confidence between:

what actually happened

and

what I could plausibly reconstruct from what remained.

For an agent system, that gap is dangerous.

Because the longer the system runs, the more future decisions are built on previous ones.

And if previous reality disappears, autonomy slowly turns into archaeology.

So one of the first questions I started asking while building Bezalel was not:

How do I make the agent remember more?

It was:

What must survive so the next agent doesn't have to guess?

That question turned out to lead much further than I expected.

If your agent failed today and you reopened the project a month from now, what would still exist besides the code?

I Was Automating the Wrong Layer

Joseph Yeo — Mon, 07 Sep 2026 08:38:26 +0000

I stopped writing for about two months because the question I was working on changed.

ForgeFlow didn't fail.

It exposed the next bottleneck.

Me.

The Model Wasn't the Problem Anymore

When I started ForgeFlow, I was trying to answer a fairly direct question:

Can a local model reliably work on real software tasks?

So I worked on the execution loop around it.

More deterministic planning.

Better tests.

Stricter file boundaries.

Explicit failure knowledge.

Less trust in generated explanations.

More measurement in code.

Over time, one lesson kept surviving:

The model is not the system.

A stronger model inside a weak environment could still fail badly.

A weaker model inside a better-designed environment could become surprisingly useful.

That was the main idea behind most of my ForgeFlow posts.

But eventually the failures moved outward.

A test could pass in the wrong environment.

A gate could work perfectly while measuring the wrong thing.

An agent could confidently report a number that a deterministic check contradicted.

Even an independent check could be wrong.

The pattern became difficult to ignore:

Every time I moved trust away from the model, I found another thing I had been trusting too much.

Then the Human Became the Hidden Runtime

The coding loop was getting more automated.

But the work around that loop wasn't.

I still remembered:

what had already been decided;
which failure had already been investigated;
when a result looked suspicious;
whether an agent should continue or stop;
how one session connected to the next;
what actually mattered enough to require my judgment.

The agents were doing more.

But I was still carrying the continuity around them.

That created a strange inversion.

I thought I was building more autonomous agents.

In practice, I was making myself responsible for coordinating increasingly autonomous agents.

The worker was becoming automated.

The surrounding work was not.

I Was Automating the Wrong Layer

That changed the question.

The progression looked something like this:

Can the model code?
        ↓
Can the execution loop be reliable?
        ↓
Can I trust the verifier?
        ↓
Can I trust the measurement?
        ↓
Can the system continue
without me carrying everything around it?

That last question is the one I have been working on for the past two months.

The project that came out of it is called Bezalel.

I am deliberately keeping the technical description broad for now.

Bezalel is not another coding model.

It is my attempt to move more of the coordination, continuity, and verification surrounding agent work out of my head and into the system itself.

The goal is not to remove the human.

The goal is to stop using the human for things the system should already know how to handle.

The Human in the Loop Was the Clue

My last ForgeFlow post was about the human in the loop.

I still think humans matter.

Some decisions are too consequential, ambiguous, or context-dependent to automate silently.

But if every uncertain event returns to a human, the human becomes the throughput ceiling.

Someone left a comment on that post with a line I liked:

approve boundaries, not every token

I said I was going to steal it.

I did.

What interested me was the shift behind the sentence.

Instead of asking:

How do I make the agent ask me fewer questions?

I started asking:

What should the system be able to handle without asking me at all?

That is a much more useful design question.

I Also Changed My Mind About Local Models

ForgeFlow started with a strong local-first identity.

That still matters to me.

Local models give me privacy, cost control, and freedom to experiment.

But after repeatedly writing that the model is not the system, I had to apply the same principle to my own architecture.

If the surrounding system matters more than the individual model, then the architecture should survive model replacement.

So I care less than I did two months ago about forcing every task through one model or one environment.

The worker should be replaceable.

The system around the worker should be the durable part.

That is not a rejection of local models.

It is probably the most literal conclusion ForgeFlow taught me.

ForgeFlow Wasn't Wrong

I don't see Bezalel as replacing ForgeFlow.

ForgeFlow worked long enough to expose the next problem.

It taught me to:

make the environment observable;
move repeated failures into explicit structure;
separate generation from verification;
measure with code instead of prose where possible;
distrust confident reports when machine state disagrees;
treat failure as architectural evidence.

Bezalel is the same instinct applied one level higher.

The unit of investigation changed.

First the model.

Then the loop.

Then the verifier.

Then the measurement.

Now the process around all of them.

That feels less like starting over and more like zooming out.

What I Am Trying to Learn Now

I am not claiming this solves autonomous software development.

It doesn't.

I am not claiming humans disappear.

They shouldn't.

And I am not claiming more process automatically creates more reliability.

Sometimes it just creates more process.

The question I care about now is narrower:

Can agents work for meaningfully longer periods while requiring human attention mainly for decisions that actually deserve human attention?

That sounds simple.

So far, it isn't.

But it feels like the right problem.

Two months ago, I was trying to make a coding agent more autonomous.

Now I am much more interested in the system that has to exist around autonomous agents.

That is what I have been building.

That is Bezalel.

And that is what I will be writing about next.

If you are building agent systems: what part of your workflow still exists only in your head?

The Human in the Loop Doesn't Scale. I Kept Him Anyway.

Joseph Yeo — Sun, 28 Jun 2026 14:51:25 +0000

What it costs to be the last reviewer your own system has

Part of the ForgeFlow series — building a coding agent that runs its execution loop locally on an M5 Max, and writing down what actually breaks. Planning runs on a frontier model; code generation runs on a local model via Ollama, test-driven inside a Docker sandbox.

In the last post, I described how my agent's rulebook learned to forget — rules that age out get flagged, and a human decides whether to retire them. I ended on a line that's been nagging me ever since: the whole thing works because I'm still small enough to read everything, and I suspect that doesn't last.

This post is about that suspicion. It's about the design decision I keep reaching for — keep a human in the loop — and the uncomfortable thing underneath it: that human is me, I am exactly one person, and "put a human on it" is not a plan. It's a debt I haven't been billed for yet.

"Keep a human in the loop" is the answer I keep reaching for

When an automated decision feels risky, my reflex is usually the same: don't let the machine do it alone, put a person on the final call. It sounds responsible. It's the answer I reach for when I don't yet trust the automation boundary, and it's the one I'd give if you asked me how to make an agent safe.

And it's right, as far as it goes. A human on the final decision catches the failure modes a confidence score can't see. I argued for exactly this last time: the machine is good at noticing a rule hasn't earned its keep lately; it is not good at knowing whether that's because the rule is obsolete or because I just haven't exercised it. So the machine flags, and I decide.

The part I glossed over is what "I decide" actually costs.

The cost nobody puts on the diagram

When you draw a human-in-the-loop system, the human is a small box near the end with an arrow labeled approve / reject. The box looks free. It isn't. Every decision routed to that box spends three things that don't show up in the diagram.

It spends attention — each call needs enough context loaded into a human head to judge it, and that context isn't cached between decisions the way it is for a machine.

It spends latency — the system now moves at the speed of when I happen to look, not the speed of the runs. A flag raised at 2am waits for me. The agent doesn't.

It spends a budget that doesn't grow — the machine's side scales with hardware. My side barely scales at all. I get the same hours next year. If the flags-per-week curve goes up and the human-hours curve is flat, the lines cross. After they cross, "a human reviews it" quietly becomes "a human is supposed to review it," which is a different claim wearing the same label.

That last failure is the one I actually fear. Not the human-in-the-loop that says no. The human-in-the-loop that has too much queued to look properly, and starts rubber-stamping — approving on a glance because the backlog is the real pressure. A reviewer who can't keep up doesn't fail loudly. They fail by agreeing, and a rubber-stamped approval still moves the system forward — it just carries a decision nobody actually made, buried until something downstream breaks.

What I tried: making the human's time the scarce resource it actually is

Once I stopped treating my own attention as free, the design question flipped. It stopped being "where should a human review?" and became "this human has a small, fixed number of real decisions in him per week — which ones are worth spending?"

That reframing changed the design more than another automation pass would have. A few things fell out of it.

Most decisions don't need me; they need a default. A flag I almost always approve isn't a decision, it's a ceremony. The honest move is to pick the safe default, let it happen automatically, and log it where I can audit a sample later — not to stand at the gate nodding. The clearest case: stale-rule flags for rules that only ever applied to throwaway scaffolding from old projects. There's no real call to make there — retiring them is the safe default, so the system does it and tells me, instead of asking. I moved a whole class of "review" into "do the safe thing and log it," and got the time back for the calls that were actually close.

The decisions worth my time are the irreversible and the ambiguous. Retiring a rule that can't easily be un-retired; anything where the machine's confidence is truly split rather than just low. Those I keep. They're rare, which is the point — keeping a human in the loop only scales if the loop is small.

Batching beats interrupting. Ten flags reviewed in one sitting, with shared context, cost a fraction of ten flags reviewed across ten interruptions. So the system holds non-urgent decisions and presents them together, instead of paging me the moment each one appears.

None of this removes the human. It does the opposite — it admits the human is the bottleneck and budgets around it, instead of pretending the bottleneck is free and acting surprised when it backs up.

What I deliberately refused to automate, even knowing it doesn't scale

Here's the tension I haven't resolved.

Some decisions I keep for myself even though I know that choice is what limits how far the system can run without me. Retiring hard-won knowledge is one. The call to let the agent act on something it's never done before is another. Not because a model couldn't make those calls — increasingly it could — but because I'm not yet willing to not know when they happen.

That's an honest admission, not a principle. It might be that I'm holding onto these out of caution that's already obsolete. It might be that one of them is the next thing to hand off, and I'm just attached. The reason I can still tell the difference is, again, that I'm small enough to feel each of these decisions individually. The day there are too many to feel is the day this stops being judgment and starts being a story I tell myself about judgment.

So I'm not claiming I solved it. I'm claiming I stopped pretending the human was free, and that alone changed which decisions I let reach me.

What this didn't prove

This is one person's setup, and the bottleneck I'm describing is me, specifically — my hours, my attention, my unwillingness to look away from certain decisions. A team has a different shape of this problem: more reviewers, but also coordination cost, and the rubber-stamp failure mode gets easier to hide, not harder, when "someone reviewed it" can mean anyone.

I haven't shown that my particular triage — defaults for the routine, human for the irreversible and the ambiguous — is the right cut. It's the cut that fit a single-operator system small enough to audit by sampling. I also haven't escaped the core problem; I've only delayed it. Every decision I automate to save my attention is a decision I now have to trust without watching, which is the exact move the earlier posts in this series were nervous about. I traded one risk for another with my eyes open. That's not a solution. It's a position.

The takeaway

"Keep a human in the loop" is true and incomplete. It's true because the human catches what the metric can't. It's incomplete because it quietly assumes the human's time is free, and in my setup the human's time is the least scalable resource in the whole system. A loop with a person in it only works while the loop stays small enough that the person can actually be in it — not nominally, actually.

If I had to compress it: the goal isn't to keep a human in the loop. It's to spend the human on the decisions that deserve a human, and to be honest that everything else was a default you chose, not a review you did.

I'd like to hear how others handle this, because I don't think being small saves me for long. In your systems, what do you actually keep a person on — and how do you tell the difference between a review that's real and one that's become a rubber stamp? And when you handed a decision to automation, how did you decide it was safe to stop watching?

What I Learned by Deleting Rules My Agent Had Already Learned

Joseph Yeo — Fri, 26 Jun 2026 16:03:00 +0000

Knowledge that isn't pruned starts to mislead you

Part of the ForgeFlow series — building a coding agent that runs its execution loop locally on an M5 Max, and writing down what actually breaks. Planning runs through a separate planning step; code generation runs on a local model via Ollama, test-driven inside a Docker sandbox.

For months, my agent got better by accumulating rules.

Every time a project failed in a way I understood, I'd write the lesson down as a rule and feed it back in — don't do this, always do that — so the agent wouldn't repeat the mistake. To be clear about what "rules" means here: not fine-tuning, not weights. A plain, human-readable rulebook the system injects into the agent's context, built up from past failures. For a long time, adding to it worked. Autonomy went up. The same mistakes stopped coming back.

Then the agent started getting worse, and the rulebook was the reason.

Not because the rules were wrong. Because some of them had stopped being right — and I'd never built anything to notice. This post is about the part of the system I hadn't built: the part that lets old knowledge leave.

(This continues a thread from a recent run of posts about verifying your own system. The short version of that run: every layer you trust should be measured before you trust it. This is what happens when you forget that even earned trust has an expiry date.)

The half I built first: a place to write lessons down

The first half of this is the obvious, satisfying half. Your agent fails, you diagnose it, you encode the fix as a rule, and the failure doesn't recur. Do that across a few dozen projects and you've got a real rulebook — concrete, earned, specific. Mine grew to around 77 rules at one point, and I wrote a whole post about how good that felt ("77 Rules Later"). Each rule had a story behind it. Each one had prevented something real.

This is the part that feels like progress, because it is progress — at first. A rulebook induced from actual failures is far better than generic advice like "write clean code." It captures things like a specific framework-level behavior that only surfaces when two configuration paths interact — the kind of thing that turns a multi-hour debugging session into a one-line guardrail.

So you keep adding. Why wouldn't you? Every rule paid for itself once.

The hidden assumption in "why wouldn't you" is that a rule, once true, stays true. That's the assumption that broke.

The half I had missed: a place for lessons to expire

Somewhere past a few dozen rules, I noticed the curve bend the wrong way. More rules stopped producing better behavior. Past a point, they started producing slightly worse behavior — more hesitation, more rules half-applied, the occasional case where two rules pulled in different directions and the agent picked the wrong one to honor.

This surprised me, because my default instinct with the agent was to give it more context. More rules, more examples, more guardrails — surely more is safer. But a rulebook isn't free. Every rule you inject is something the model has to hold, weigh, and reason around on every step. Past some threshold, the cost of carrying a rule can exceed the failure it still prevents — especially when the thing it was written to prevent no longer happens.

And that's the category I'd completely missed: rules that had simply aged out. A rule written for one version of a library, after the library changed. A guardrail for a failure mode I'd since fixed at the source, so it could never recur — but the rule kept riding along, costing attention, preventing nothing. I had a careful process for adding knowledge and no process at all for removing it. The rulebook could only grow.

A rulebook that can only grow stops being a curated knowledge base. It quietly turns into an index where the dead entries dilute the living ones — and nothing in it tells you which is which.

Why a stale rule is worse than no rule

Here's the part worth sitting with, and it rhymes with something I keep running into in this project: the failures that cost me most were the quiet ones.

A missing rule is loud. The agent makes a mistake, you notice, you add the rule. The system has a built-in way to surface what it doesn't know — failure.

A stale rule is silent. It was right when you wrote it. It reads as authoritative because it earned that authority, once. It sits in the rulebook looking exactly like the rules that are still true, and nothing about it announces that the world it described has moved on. The agent dutifully follows it. You don't get a failure that points at it — you get slightly degraded behavior with no obvious cause, spread thin across everything the agent does.

That's why a stale rule can be worse than no rule. A missing rule often leaves a gap you can see once the failure appears. A stale rule fills the gap with confident, outdated instruction, and confident-and-outdated is one of the harder kinds of wrong to catch — because everything looks fine.

What I built instead: rules with a confidence score and a way to die

The fix wasn't cleverer rules. It was treating each rule as something other than a permanent truth.

The reframing that helped: a rule is not a fact. It's a hypothesis with an evidence record. It claims "doing X prevents failure Y," and that claim is either being supported by what actually happens in real runs, or it isn't. So instead of a flat list, each rule now carries a small amount of state: how confident I currently am in it, and what recent evidence supports or undercuts it.

The lifecycle, in plain terms:

A new rule starts as a candidate — written down, but not yet trusted. It hasn't earned its place.
If real runs keep showing evidence that the rule is still guarding against an active failure mode, confidence rises and the rule becomes trusted.
If a rule stops getting that supporting evidence — the failure it guards against simply isn't occurring anymore, across many runs — its confidence decays. Below a threshold, it's flagged stale for review.
A stale rule that, on inspection, appears to guard against something that can no longer happen gets retired. Out of the rulebook, into an archive, where it's recorded but no longer injected. One honest caveat about that evidence: I can't prove a counterfactual. I don't know the failure would have happened without the rule — I'm inferring it from run traces and the shape of what the agent attempted, not from a controlled A/B where I remove the rule and watch the system break. The confidence score reflects that inference, not a proof. I keep that in mind whenever I read it.

I'm deliberately not giving the exact scoring here, partly because the specific numbers are tuned to my system and would be noise to you, and partly because the point isn't the formula. The point is the direction: confidence flows from evidence, evidence comes from real runs, and a rule with no recent supporting evidence is a liability until proven otherwise — not an asset by default. Adding a rule is cheap. Letting it persist without review is where the cost accumulates.

If this sounds like cache invalidation, or like deprecating a feature flag, or like paying down tech debt — yes. It's the same shape: the cost isn't in creating the thing, it's in the discipline of removing it when it stops earning its keep. I just hadn't been treating lessons as something that needed garbage collection.

The part I deliberately didn't automate

The obvious next step would be to close the loop completely: let the system retire its own rules the moment confidence drops. I didn't, and I think the reason matters.

A confidence score is itself a measurement, and measurements can be wrong. A rule might look unsupported simply because I haven't run the kind of project that triggers its failure mode lately — not because it's obsolete. If I let the system auto-delete on a low score, it could kill a good rule during a quiet stretch, and I'd only find out when the old failure came roaring back.

So the system doesn't delete. It proposes. A rule going stale raises a flag for me to look at, and retiring it is a decision I still make. The machine is good at noticing "this rule hasn't earned its keep lately." It is not good at knowing whether that's because the rule is obsolete or because I just haven't stress-tested it. That difference needs a human, at least for now.

What this didn't prove

I'll keep this honest, the way I've tried to with the rest of these.

This is one system's experience — a single-person setup with a rulebook small enough that I can still read all of it. I haven't shown that knowledge decay matters at every scale, or that my particular lifecycle is the right one. It's an approach that worked in this setup, not a general result. For a small or short-lived project, the whole apparatus is overkill; a rulebook you fully re-read every week doesn't need confidence scores, it needs you to read it.

And the hard part isn't solved. "Has this rule earned its keep lately?" is a real signal, but it's a proxy, and proxies drift too — the watcher needs watching, same as everything else in this series. I don't have a clean rule for when a quiet rule is obsolete versus merely untested, which is exactly why I kept a human in that decision. I'm sharing the shape because it changed how I think about my own knowledge base, not because it's finished.

The takeaway

In my own system, I spent enormous effort teaching it new things and almost none deciding when old things should stop being believed. A knowledge base that can only grow may stop getting wiser; past a point, it can get slower and quietly less correct, because the rules that have gone stale look exactly like the rules that are still true.

If I had to compress it: writing a lesson down is the easy half. Letting it expire when it no longer earns its place is the half that keeps the lessons honest.

I'd like to know how other people handle this. In your systems — prompt libraries, rule sets, runbooks, internal docs, lint configs — does anything ever retire, or does it all just accumulate? And if things do get removed, how do you decide a piece of hard-won knowledge has stopped being true? I worked out a rough answer for my case, but it leans on being small enough to still read everything, and I suspect that doesn't last.

We Stopped Trusting Models. Then We Stopped Trusting Our Own Numbers.

Joseph Yeo — Tue, 23 Jun 2026 16:31:06 +0000

Nondeterminism isn't a bug to ban — it's a force to place

Part of the ForgeFlow series — building a coding agent that runs its execution loop locally on an M5 Max, and writing down what actually breaks. Planning runs on Claude; code generation runs on a local model via Ollama, test-driven inside a Docker sandbox.

A while back I wrote that we'd stopped chasing better models — that for this project, swapping in a stronger model kept failing to fix problems that turned out to be about the system around the model, not the model itself. That post ended on a tidy note: the model wasn't the bottleneck, the system was.

This is the post where the same suspicion turns inward, toward our own measurements. Because once you stop trusting the model to be the answer, the next thing you lean on is your own measurements — the test counts, the gate statistics, the tallies that tell you whether the system is working. And over a stretch of building, I learned those can't be trusted blindly either. The three previous posts in this run were each a version of that discovery:

A test suite that passed while measuring the wrong environment.
A gate that blocked 198 times while being wrong often enough that the count could no longer serve as evidence of quality.
An agent that counted twelve when the real number was thirteen.

Three different instruments. A recurring failure shape underneath them: the thing I use to verify can itself be wrong, and it tends to be wrong in a way that looks like success. This post is about what I took from that — and, more importantly, about the wrong conclusion I almost drew from it.

The wrong lesson: "ban the uncertainty"

When you get burned three times by measurements you trusted, there's an instinctive reaction: trust nothing that isn't certain. Push every source of uncertainty out of the system. Treat nondeterminism — anything probabilistic, anything that might come out differently twice — as a defect to eliminate. If the language model is the uncertain part, minimize the language model. Make everything deterministic and tell yourself you can finally sleep soundly.

I leaned that way for a while. It's wrong, or at least too blunt to be useful. Taken seriously, "ban all nondeterminism" throws out the single most valuable thing the model brings to this system — its ability to propose, to explore, to suggest a fix I wouldn't have enumerated. You can't get that from a deterministic rule. The uncertainty isn't only a liability; in the right seat, it's the entire point.

So the question stopped being "how do I remove the uncertainty" and became "where does the uncertainty belong?"

The better lesson: place it, don't ban it

Here's the reframing that held up — and it took an embarrassingly long time to see, partly because I'd quietly assumed nondeterminism was a debt the whole time without ever checking the assumption.

A system like this has two kinds of seats.

Seats that propose and explore. What should we try next? What might this failure be? What's a candidate fix? These seats want nondeterminism. A probabilistic model generating possibilities is a feature here, not a risk. If it's occasionally wrong, the cost is low — being wrong is fine when you're only suggesting, because something downstream still has to approve you.

Seats that judge and record. Did the tests actually pass? Is this allowed through? What gets written down as true? These seats can't tolerate an unaccountable input. They need to be deterministic, reproducible, and checkable — because this is exactly where "almost right" becomes indistinguishable from "right," which is the trap the last three posts kept falling into.

Each of the three failures was the same shape: something that shouldn't have been the final authority had crept into a judging seat. The polluted environment let an unpinned variable decide a verdict. The miscalibrated gate let an unchecked heuristic sit in judgment and reject valid work. The agent's self-report nearly let a probabilistic counter be the last word on a number. In every case, the fix wasn't to purge uncertainty from the whole system — it was to get the wrong thing out of the judging seat, and make sure that seat was held by something deterministic, pinned, and witnessable.

Nondeterminism, it turns out, isn't a quality of the system to be turned up or down. It's a force to be placed. You let it run at the front, where things are proposed and explored. You keep it out of the back, where things are judged and recorded. The model proposes; a deterministic check decides. That one division became the thread that connected the fixes in this run.

Why this isn't just "trust deterministic things more"

It's tempting to read all this as "deterministic good, probabilistic bad." That's not it, and the distinction matters.

A probabilistic suggestion in a proposing seat is more valuable than a deterministic one, because it can reach things a rule can't. And a deterministic check is only as good as whether it's actually correct and checkable — the gate in the second post was deterministic and still wrong a lot of the time, and a deterministic judge that's consistently wrong can be worse than a coin flip, because it's a steady error you eventually stop questioning. So it isn't that determinism is virtuous and uncertainty is sinful. It's that they belong in different places, and the whole engineering problem is keeping them sorted:

Let the uncertain thing explore. Let deterministic checks judge — but only after the checks themselves have been checked.

The reason this took four posts and a fair amount of getting it wrong is that the failures don't announce which category they're in. A measurement that's quietly wrong looks exactly like one that's right, until you go and look. The sorting isn't automatic. You do it deliberately, instrument by instrument, and you usually find out you got it wrong only when a number you trusted turns out to have been the problem all along.

What this didn't prove

I want to close the series the way I've tried to write the whole thing — without inflating it.

This is a framing that helped one system: a local AI coding agent with a test-driven loop, where I happen to have the luxury of pinning judging seats to deterministic checks I can watch. I haven't proven it's the right decomposition for every AI system, and I'd be wary of anyone — including me — who turned "place nondeterminism, don't ban it" into a universal law. It's a working lens, not an established result. The evidence behind it is a handful of incidents, honestly reported, not a controlled study.

It also doesn't resolve the hard part: the boundary between "propose" and "judge" is not always obvious. Plenty of real decisions are a blend — a judgment that also has to weigh uncertain evidence, or a proposal that quietly commits you to something before anything else gets a vote. Where exactly to put the deterministic check, and how much to let the probabilistic part inform a judgment without becoming the judgment, is something I'm still working out. The previous post's open question — when a human-witnessed check can graduate to a trusted automated one — is part of the same unsolved area. I'm sharing the lens because it organized a mess for me, not because it's finished.

The takeaway, for the whole run

Four posts, one thread. We stopped trusting that a better model would save us. Then we learned not to trust our own measurements blindly either — not the passing tests, not the busy gate, not the agent's tidy count. What survived all that doubt, for me, was a single discipline that proved sturdy enough to stand on:

In systems like this, every layer that grants trust should be measured before it's trusted — and that measurement should be grounded, wherever possible, in something deterministic you can witness.

That's it. Not a model, not a framework, not a clever architecture. A place to stand. After doubting the model, the gate, the tally, and our own numbers, it's the one thing I found solid enough to build the next thing on.

This is the end of this short run, so I'll ask the broad version of the question. For those building systems with AI in the loop: where do you draw the line between the parts you let be uncertain and the parts you insist be deterministic — and how do you check that you drew it in the right place? I arrived at one answer through a series of mistakes. I'd rather learn the next one from other people's experience than from my own next mistake.

Thanks for following this run. The earlier ForgeFlow posts — on the local agent itself, on why we stopped chasing models, and on what breaks at scale — are linked from my profile.

My Agent Reported 12. The Real Number Was 13.

Joseph Yeo — Mon, 22 Jun 2026 11:47:21 +0000

Why you have to witness the measurement before you trust the instrument

I was building the part of the system that measures itself, and I'd reached the point where it felt safe to let the AI agent do the counting. The task was mundane: tally how often a certain check had fired, aggregate it, report a number. The agent ran and reported 12.

I almost took it. It was a believable number, produced confidently, and I was tired of doing this kind of bookkeeping by hand. But something made me run it down myself in the terminal. The real count was 13. One item that belonged in the tally had been silently dropped from the agent's raw count.

One off. Twelve versus thirteen. On its own, trivial. But it landed on a question I'd been circling for a while — who is allowed to be the final witness to a measurement? — and the answer changed how I let AI into this system. This is the third post in a short run about that larger theme: the tools I use to verify my work can themselves be wrong, usually in ways that look fine.

Why I wanted to hand off the counting

The honest reason was fatigue. A self-measuring system generates a lot of small, exact bookkeeping — count the occurrences, filter the relevant ones, divide, summarize. It's beneath an agent's apparent ability and above my patience, so handing it off felt obvious. The agent reads the data, the agent reports the number, I read the report. Clean.

And to be fair to the agent: most of what it did was right. It wasn't hallucinating wildly. It produced a number that was almost correct — off by one, in a way that would have been invisible if I hadn't gone and looked. That's the dangerous kind of wrong: not obviously broken, just plausible enough to accept.

The one that got away

Here's how I know the real number was 13 and not 12, because "the agent was wrong" needs a ground truth. I didn't ask the agent to summarize. I ran a deterministic pass in the terminal that emitted each matching record, one by one, from the same source data, under the same inclusion rule — and then counted those emitted records directly. Run it again, same 13. The missing entry met that same rule; it just arrived in an irregular shape, unlike the other twelve, so the agent's summarizing pass had skipped it. Thirteen by reproducible enumeration, twelve by agent summary. The difference wasn't a matter of my opinion — it was the same data, counted two ways, where only one of the two ways could be re-run to the same answer.

Now the detail that actually unsettled me. The final number I cared about — a summarized metric, produced after a downstream step reduced the raw count to a coarser, normalized figure — came out the same whether the raw count was 12 or 13. It was the kind of step (rounding, bucketing) where a difference of one can simply vanish. So if I'd checked only the headline metric, I'd have seen the agent's report agree with mine and concluded everything was fine. Only the raw count underneath disagreed.

That's the part worth sitting with — and it's where "the final number was the same, so what's the problem?" gets answered. The problem was not that this particular headline metric changed. It didn't. The problem was that the raw measurement layer was already wrong, and the agreement at the normalized layer would have hidden that fact. A different threshold, a different aggregation, or the next consumer downstream might not have absorbed the same error — and once the raw layer is wrong, every later use of it (an audit, a trend line, a regression check) inherits the error. The safety here wasn't something I'd designed. It was luck, and luck doesn't generalize.

So the lesson wasn't "the agent made an arithmetic mistake." Agents make mistakes; that's expected. The lesson was about who I'd let stand as the last check. I'd been about to let the agent's self-report be the final word on a measurement, and the self-report was wrong in a way only a deterministic, re-runnable count would catch.

The instrument can't be the only witness to itself

Let me state the principle the way it finally settled, because it's the part I'd defend.

When you build a measuring system, there's a pull to let the same system that does the work also judge whether it came out right — especially when that system is a capable model that can read logs, count, and summarize. It's convenient. But it quietly inverts the roles. The model's judgment is supposed to be assistance. If it becomes the only thing standing between you and the recorded truth, then the model has become the source of truth — and a probabilistic, occasionally-off-by-one source of truth is sitting in the one seat that should be reproducible and auditable.

The fix isn't to stop using the agent. It's to insist that, at least while I'm still establishing trust, a human deterministically witnesses the output — that I sit at the terminal and watch the real number come out, with my own eyes, before I let the automated measurement stand on its own. The model can do the heavy lifting. It just can't, yet, be the sole witness to whether the heavy lifting was correct — because verifying a measurement is exactly where "almost right" is indistinguishable from "right" until something deterministic says otherwise.

It's a little uncomfortable to write down, because it means the convenient version of the workflow — agent counts, agent confirms, I read the summary — is the one I specifically can't have when the number matters.

What I changed

Two adjustments.

A human witness before the automation is trusted. Before I let any self-measurement run unattended, I make the deterministic version happen in front of me at least once — the actual count, from the actual data, watched as it's produced, and re-runnable to the same result. If the automated path and the watched path disagree, the automated path is wrong until proven otherwise. The agent's confidence carries no weight in that comparison.

Pin the measurement to units I can actually witness. Part of why the slip nearly slid through was a mismatch between what the agent tallied and what was legitimately in scope. So I narrowed the measurement to count only the units that were genuinely instrumented and observable — the units a human can directly observe and enumerate — rather than a looser population the agent gets to interpret. When the population is well-defined, the hand-witnessed number and the machine number can actually be compared. When it's loose, they drift, and you can't even tell.

Both of these slow things down. That's the cost I'm deliberately paying for the measurements I'm willing to bet on.

What this didn't prove

I want to keep this in proportion.

This is one off-by-one, caught once, on one counting task. It doesn't prove AI agents can't count, or that they're untrustworthy in general, or that you should hand-verify every number an agent produces. For many low-stakes tallies, the agent's number may be good enough, and re-counting by hand would waste a perfectly good tool. I'm not arguing for paranoia.

The claim I'd stand behind is narrow and conditional: for measurements you intend to build further conclusions on, the final witness should be deterministic and, at least initially, human. The stakes set the bar. A throwaway internal count doesn't need this. A number you're going to let the system's self-assessment ride on does — because that's the number whose error compounds.

I'd also flag the obvious tension: this doesn't scale by hand forever. The whole point of automating measurement was to not sit and count things. So "a human witnesses it" is a phase, not a permanent state — it's how trust gets established before the automation runs on its own, not a vow to recount reality by hand every day. For now, I only start relaxing the human witness once the deterministic path and the automated path have matched across repeated runs, and once the inclusion rule is pinned tightly enough that both are counting the same population. Where exactly to graduate beyond that is something I'm still working out, and I don't have a clean rule for it yet.

The takeaway, stated honestly

You can let an AI write the code. You can let it run the analysis. But if you also let the same system that produced the answer be the final judge of whether that answer was correct, you've made the examinee the examiner, and the score gets hard to trust on its own. For the numbers that matter, something deterministic — and, while trust is still being earned, something human — has to be the last thing that looks.

The agent was right about almost everything — off by one. The whole question is whether you find out about the one, and that depended entirely on whether I was willing to look myself.

How do others draw this line? When you let an AI agent measure or aggregate something, do you verify it independently — and how do you decide which numbers earn the hand-check and which numbers you allow to pass without it? I leaned on doing it myself this time, but I know that doesn't scale, and I'd be glad to hear how people who've gone further handle the trust handoff.

Next in the series — the last of this run: we stopped chasing better models a while ago. This is about the moment we stopped trusting our own measurements too, and what we kept instead.

The Gate Fired 198 Times. I Called It "Working."

Joseph Yeo — Sun, 21 Jun 2026 17:39:52 +0000

Why a blocked count is not a success metric

I built a gate to block bad code. It blocked 198 pieces of code, and I took that number as evidence the gate was working well.

Then I opened the blocked cases and read them one by one, checking each against the acceptance criteria for the task it came from. A large share of them weren't bad code. The gate had been wrong often enough that I could no longer read the block count as evidence it was working — it had been firing constantly, exactly as it was designed to fire, and I'd mistaken "it fires a lot" for "it's doing its job." Those are not the same statement.

This is the second post in a short run about something I kept tripping over while building this agent: the things I use to verify my system can themselves be broken, and they tend to break in ways that look like success. The last post was about a test run that lied by passing. This one is about a gate that lied by blocking.

What the gate is, and why I trusted the count

The agent works in a test-driven loop, and one step in that loop is a gate: before certain code is allowed through, the gate checks that it meets a standard, and if it doesn't, it blocks the code and sends the work back to be redone. The gate exists to keep weak or malformed attempts from getting committed.

For a while, the gate's headline number was how many times it had blocked something: 198. I looked at that and felt good about it. The reasoning felt obvious: the gate is catching a lot of bad attempts, so the gate is valuable, so the system is healthier for having it. High block count, hard-working gate, fewer bad commits. Why look closer?

That reasoning has a hole in it — and that hole is what this post is about.

Two claims I'd quietly merged

When I went through the blocked cases — not the count, the actual cases — I found that a large share of what the gate had blocked was work that was fine. Not malformed, not weak. Legitimate attempts that happened to take a shape the gate didn't recognize, so it rejected them.

I want to be precise about what "fine" means here, because "the gate was wrong" needs a ground truth or it's just my opinion. By ground truth I don't mean "I liked the code." I mean each step had explicit acceptance criteria: the targeted tests it was meant to pass, the behavior it was meant to produce, and the stated constraints for that step. A block was a false positive when those criteria were already satisfied and the gate rejected the work anyway, for a property that wasn't part of the task's success condition.

For example: a solution that passed every test it was supposed to pass, but got rejected because its internal structure didn't match what the gate's check expected — the same task-level behavior, in a representation the task itself never required. That isn't a question of taste. The work met the criteria; the gate said no for a reason that sat outside them.

So the 198 was real. Every one of those blocks happened. What was false was the meaning I'd attached to it. I had collapsed two different claims into one:

The gate fired. (True. 198 times. Verifiable.)
The firing was justified. (Never checked — and, it turned out, often not.) "It blocked something" and "it was right to block that something" are independent facts. A gate can be extremely active and extremely wrong at the same time — and a miscalibrated gate will tend to be both, because the same flaw that makes it reject good work also makes it reject a lot of it. The block count I'd treated as evidence of value is equally consistent with a gate that's simply trigger-happy. The block count alone can't separate a justified rejection from a false positive.

This seems like an easy mistake to make when building guards — linter rules, CI checks, validation layers, policy filters. At least it was in my case, and I suspect it's more common than we'd like to admit. The dashboard shows you activity. Activity feels like protection. But activity is not the same as correct activity, and the dashboard usually doesn't know the difference, so it shows you the comforting number and lets you supply the flattering interpretation.

"Then how did anything get through?"

That's the fair question, and it's the one that finally made me look. If the gate was wrong most of the time, how did the system make any progress at all?

The answer is uncomfortable: it made progress despite the gate, not because of it. A typical failure looked like this. The first attempt satisfied the tests but used a structure the gate distrusted, so it got blocked. The retry didn't improve the behavior — it just reshaped the same behavior into a form the gate would accept. From the dashboard, that looked like "the gate forced an improvement." From the case review, it was adaptation to the gate. (When even that didn't work, I'd step in and wave the work through, because I could see it was fine — another quiet sign the gate wasn't earning its place.)

That was the tell I'd missed. A gate doing real work makes the loop converge on better code. Mine was making the loop converge on gate-shaped code — which is not the same thing, and is sometimes worse. The retry didn't make the code more correct. It made it more acceptable to the gate.

How I now try to tell a real block from a false one

Catching this forced me to write down what would actually distinguish a justified block from a noisy one. The count clearly wasn't it. What I landed on is a three-part check — not elegant, but it's caught things since, so I'll offer it as a working heuristic for this setup rather than a rule.

1. Look at the distribution of reasons, not the total. I'd expect the block reasons to map to substantive defects, not to repeatedly trip on the same shallow surface feature regardless of whether the work is good. If they cluster on the latter, the gate is probably pattern-matching on the wrong thing instead of judging quality. (This is more useful for a broad quality gate than for a narrow, single-purpose check.)

2. Watch what happens on retry. This turned out to be the most useful signal. In my loop, a justified block tended to make the work stick on the same underlying defect across retries, until that defect was actually addressed; a false positive produced shape-shifting attempts that changed the surface without improving the behavior. It's a tendency, not a law — a model can wander even when the defect is real — but the shape of the retry sequence carried information the single block event didn't.

3. Check final convergence. A justified block should eventually resolve: the work gets rewritten, the real problem gets fixed, and it passes on its own merits. If blocked work never converges — or only "passes" once you weaken the gate — then either the gate was wrong, or it was right and your loop can't act on it. Both are problems, and both are invisible if you only count how many times it fired.

None of these is a clean pass/fail on its own. Together they let me ask the question I'd skipped — was this block justified? — instead of reading the answer off the fact that a block happened.

The deeper version of the mistake

There's a more general trap underneath this, and I want to name it plainly, because I fell into it without noticing.

A test that only checks "the gate blocks bad input" is testing the easy half. The hard half is: does the gate let through good input that simply looks unusual? If you only ever feed a guard the inputs it's supposed to reject, of course it rejects them, and of course the tests pass — but you've proven nothing about its false-positive behavior, which is exactly where mine was failing. The gate's own tests were green for the same reason the gate looked healthy: I'd only ever asked it the flattering question.

So now, when I test a gate, I deliberately include cases that are legitimate but oddly shaped — valid work in a form the gate might naively distrust — and check that it lets them through. In this case, the negative cases (reject the bad stuff) were the easier half. The risk I'd under-tested was the good stuff in unfamiliar clothing.

What this didn't prove

I don't want to inflate this into "all gates are bad" or "block counts are meaningless." Neither is true.

Gates can earn their keep. A well-calibrated one really does stop real problems, and the block count is a perfectly good operational signal — useful for noticing that something is happening, or spotting a sudden spike. The mistake wasn't tracking the count. It was treating the count as evidence of correctness when it's only evidence of activity. Those are different axes, and I'd conflated them.

I'd also flag that my three-part check is shaped by this particular system — a test-driven loop where blocked work gets automatically retried, so "watch the retries" is even available to me as a signal. If your setup doesn't produce that kind of trajectory, parts of this won't transfer. I'm offering it as something that worked in one place, not a general theorem about guards. I've been wrong about generality before in this project, so I'm holding it loosely.

The takeaway, stated honestly

A guard blocking something tells you it's active. It does not tell you it's right. Those are separate facts, and the gap between them is where a confident-looking gate can quietly turn into a noise machine that punishes good work and calls it protection.

If you run gates, linters, validators, policy filters — anything that stops things — it's worth auditing a sample of what it blocked, not just the total it blocked. The total can easily look like diligence. The sample is where you find out whether the diligence was real.

I'm curious how others handle this. If you operate a gate or a strict CI rule, do you ever sample its blocks to check they were justified — and if so, how do you decide "justified" without it turning subjective? I worked out a rough method for my case, but it leans on my system's particular shape, and I'd like to hear how it's done elsewhere.

Next in the series: I asked an AI agent to count something for me. It said 12. The real number was 13 — and that one-off gap changed a rule I now follow.

When pytest Said "Passed," It Was Lying

Joseph Yeo — Sat, 20 Jun 2026 13:05:33 +0000

How a polluted virtual environment made my green tests meaningless

For a few days, I made decisions on top of a number that wasn't true.

The number was 186 passed. It came out of pytest, green, at the bottom of the terminal, the way it had dozens of times before. I trusted it the way you trust a number that has never been wrong before. Then I found out the run had been measured inside the wrong environment, and the green had very little to do with the code I thought I was checking.

To be fair to the tool: pytest wasn't wrong. It answered exactly the question I handed it — it just wasn't the question I meant to ask. This post is about that gap. Not a bug in a test, but a bug in how I measured the tests. It turned out to be one of the more uncomfortable lessons in the project so far, because it sat underneath everything else. If the floor is tilted, every measurement you take on top of it inherits the tilt, and you don't see it, because the floor looks like the floor.

I'm writing it down mostly because I suspect I'm not the only person who has trusted a green checkmark that didn't earn it.

The setup: a baseline I checked constantly

ForgeFlow is a coding agent that runs a test-driven loop. Plan, write a failing test, write code, run the tests, decide what happened, repeat. Because so much of the system's behavior is judged by "did the tests pass," I keep a baseline: a known set of test files that should report a known set of numbers. Before and after almost any change to the engine, I re-run the baseline and compare. If the counts move when they shouldn't, something is wrong.

One thing to be precise about, because it matters later: the agent executes the code it generates inside a Docker sandbox, but this baseline — the engine's own test suite — I was running from my host shell. Two different executions. The sandbox was fine. The host shell was the problem.

The baseline is the closest thing the project has to a source of truth about its own health. That's exactly why this hurt.

One afternoon I was moving between two things on the same machine — the agent's own codebase, and an unrelated project I'd been poking at earlier. I ran the baseline. Green. 186 passed. I noted it, moved on, and built the next decision on top of it.

What I didn't notice was a single line of state that had carried over from the earlier work.

What actually happened

I'd left a different project's virtual environment active.

That's the whole bug, mechanically. The shell still had another project's VIRTUAL_ENV set, so when I ran pytest, it resolved pytest through that environment, and Python resolved imports against that environment's installed packages.

Here's the question a careful reader asks immediately: if it was the wrong environment, why didn't it just fail? Why no ModuleNotFoundError, no loud red collection error?

Because nothing was missing. The polluted environment happened to have the same packages installed — only at different versions. So nothing errored out. The tests collected, ran, and passed; they just passed against a version matrix the baseline doesn't assume. And that's the genuinely unsettling part: if a dependency had been entirely absent, I'd have gotten a loud error and caught it in seconds. The danger was precisely that everything was present — present and subtly wrong. Wrong in the one way that doesn't announce itself.

The problem is that "green" had stopped meaning what I read it as. I read it as "the code is correct in the environment it's meant to run in." What it actually meant was "the code passed in whatever environment happened to be active." Those are different sentences. For a few days I couldn't tell them apart, because the terminal prints the same word for both.

Here's the part worth sitting with: nothing failed. A failing test is a gift — it's loud, it points at itself, you go fix it. This didn't fail. It passed, and the passing was the problem. The signal I rely on to catch mistakes was itself the mistake, wearing the costume of everything being fine.

"The tests pass" and "the measurement is honest" are different claims

When I finally caught it — by comparing against a run from a fresh shell using the project's intended environment, and noticing the counts didn't line up — I reduced the lesson to a sentence I've kept since:

Whether the tests pass and whether the measurement of the tests is trustworthy are two separate questions, and I had been treating them as one.

Almost all of my testing discipline had been aimed at the first question. I had careful tests. What I didn't have was anything checking the second — the integrity of the act of measuring. The environment the measurement runs in is an input to the result, and I'd been treating it as a constant when it was actually a variable I'd left lying around.

It's easy to invest heavily in test correctness while leaving test measurement integrity implicit — to treat it as the environment's job, or the tooling's job, rather than something to check directly. Plenty of teams do handle it, with lockfiles, containerized test runs, hermetic builds. I just wasn't one of them at this layer, for this particular command, on this particular day.

What I changed

Two things, deliberately small.

A guard before the measurement, not just inside it. The cheapest fix is a single check that runs before the baseline: confirm the environment is the one I think it is. In my case, simply asserting that no foreign virtual environment was active would have caught it — the testing equivalent of checking the floor before you measure the wall. It's almost embarrassingly simple, and it would have caught this in one second. (A stricter guard wouldn't stop at the VIRTUAL_ENV variable; it would also check sys.executable, the resolved pytest path, and the expected project root. The variable was the obvious giveaway here, but it's the weakest of the four.)

A separate set of checks for the measurement itself. Beyond the one-line guard, I added a small, dedicated set of tests whose only job is to protect the invariants of how I measure — not the features, the measurement. They're counted separately from the normal baseline on purpose, so they can't be quietly folded into the same number they're supposed to be watching. The exact count is secondary. What matters is that "is my measurement honest" became something the system checks for me, instead of something I assume.

Neither of these is clever. That's sort of the lesson. The failure wasn't subtle once I saw it; it was invisible only because I'd never thought to look there.

What this didn't prove

I want to be careful not to inflate this into a grand principle.

This is one incident, on one machine, caused by one careless bit of leftover state. It doesn't prove that everyone's test suites are secretly lying, and it doesn't prove you need an elaborate measurement-verification layer. For a small throwaway script, a clean shell and a moment of attention is the entire fix, and the machinery would be overkill.

To be clear about which part scales: environment hygiene matters at any size — it's the guards and dedicated checks that scale with how much you're betting on the number. I'm betting a lot on mine; the agent makes real decisions off these signals. So for me the machinery earned its place. The hygiene would have been worth it regardless of project size.

I'm also aware the "fix" mostly moves the trust down one level. Now I trust the guard. If the guard is wrong, I'm back where I started. There's no absolute bottom here — just a level low enough that I'm willing to stop and call it ground. I picked one. I could be wrong about whether it's low enough.

The takeaway, stated honestly

If I had to compress it: a green test run answers "did the code pass?" It does not answer "did I measure that in the environment I meant to?" The second question has its own failure mode, and because the failure mode is passing, your normal instincts — chase the red, fix what's loud — never fire.

The verification pyramid most of us picture has tests at the bottom. I'd now put one more layer underneath it: the environment the tests run in. When that layer shifts, every green light above it is reporting on an environment you're not actually in.

I'd like to know how other people handle this. Do you guard your test environment explicitly, or rely on convention and attention? Have you been bitten by a passing result that turned out to be measured wrong — and if so, how did you finally catch it? I caught mine by luck and a mismatched count. I'd rather not depend on luck next time, and I suspect some of you have better answers than I do.

Next in the series: a quality gate in the same system blocked code 198 times — and why I was wrong to call that "working."

We Spent Six Sessions Fixing One Task. The Problem Was Six Tasks.

Joseph Yeo — Tue, 02 Jun 2026 11:42:06 +0000

This is Part 9 of the ForgeFlow series. Part 8: 77 Rules Later ended on a question we couldn't answer at the time: can a rule-based agent system keep growing without becoming harder to reason about than the model it was built to constrain? This post is about one small episode that pushed us toward an answer — not a clean one, but a useful one. It's also a record of getting a diagnosis wrong for several sessions in a row, and what finally corrected it.

Quick terms for new readers:

FC = Failure Catalog entry (a documented failure pattern)

CL = Crystallized Lesson (a testable design rule derived from repeated failures)

critical_rules = a block of rules injected into the model's prompt for a given project

nightrun = an overnight batch that re-runs projects so we can measure behavior over many runs

ForgeFlow = a fully local, TDD-based autonomous coding system running on Apple Silicon

The failure we kept "fixing"

For several sessions, we had a recurring failure in one project that we treated as a single, local problem.

The symptom: in async tests, the model would construct an HTTP test client directly instead of using the shared fixture we'd set up. That shared fixture is what installs the dependency override pointing the app at the test database. By hand-rolling its own client, the model skipped the fixture entirely — so the override was never applied, and the test hit an unconfigured database and failed with a missing-table error.

(The underlying trigger, for those on the same stack: httpx 0.28 removed the deprecated app= shortcut from Client/AsyncClient. The supported pattern is now transport=ASGITransport(app=app). Our conftest fixture already used the current ASGITransport approach and was correct — the app= argument on ASGITransport itself is still valid. The model just wasn't using the fixture; it kept hand-rolling the client the old, removed way. Why it preferred the old pattern is something we can only guess at — likely the weight of older examples — and we didn't try to prove it.)

Each time it surfaced, we did the natural thing. We looked at the task where it appeared, and we wrote a rule for that task. Next run, it would seem quieter there — and then show up somewhere else. We'd note it, half-suspect it was the same thing, and move on to whatever else the run surfaced.

What we were doing, in effect, was treating a recurring pattern as a series of unrelated incidents. We never asked the obvious question: how often does this actually happen, and where?

The measurement we should have taken earlier

The thing that broke the loop wasn't a better model or a smarter rule. It was a measurement we hadn't bothered to take.

We wrote a small script to walk back through our run history and count occurrences of the failing pattern across every recorded run — not by reconstructing it from summary tables, but by grepping the raw captured error text directly. (We'd learned in an earlier session that our summary-level deduplication could merge distinct failures under one signature, so for this we went to the raw text instead.) In practice that meant grepping the archived stderr for the exact failing construction across every run directory, rather than trusting the rolled-up signatures.

In the archived runs we checked, the count came back:

16 occurrences
across 6 distinct tasks
in 3 different projects
spread over 7 separate run sessions

This count made our earlier framing untenable. We had been writing single-task rules for something that was happening across six tasks in three projects. Each of those per-task fixes had been addressing, at most, one of the sixteen occurrences we eventually counted. The measurement didn't just refine our picture — for this failure pattern, it showed our framing had been wrong in kind, not just in degree.

It's a little uncomfortable to write that down. But that's the part worth keeping: the wrong number wasn't in the model's output. It was in our own estimate of how widespread the problem was, and we'd carried that estimate for several sessions without checking it.

The prescription got smaller, not bigger

Here's the part that surprised us most.

Once we saw "6 tasks, 3 projects," the instinct might be to write six fixes — one hardened rule per affected task. Given how we'd been responding up to that point, that's roughly the path we were on.

Instead, the data pointed the other way. If one pattern was appearing across many tasks and projects, the better place to address it wasn't any individual task — it was the project-wide rule block. We added one line to the critical_rules for the affected projects: a single instruction telling the model not to construct the test client directly, and to use the fixture instead (taking the rule block from 20 lines to 21).

One rule addressed a pattern that, on our prior trajectory, could easily have become six separate task-level patches. This was a small, concrete instance of something we keep seeing on this project: when we measure a problem's actual scope more carefully, the fix tends to get narrower, not wider. When you don't know the shape of a problem, you tend to over-prescribe locally and under-address globally. Measuring the shape let us do less.

We then ran a verification batch over the affected projects. The grep count for the pattern came back at zero across those runs. Two of the projects involved — a small gallery API and a small library API — met the per-project completion criteria on the verifying runs, so we marked them as "graduated" in a narrow, project-level sense.

Note on "graduated": Part 8 used this word for an entire stack. Here it means something much smaller — these individual projects met their completion criteria on the runs we executed. It is not a claim about the stack, and not a claim that these projects will never fail again. The underlying numbers were modest: pass rates in the roughly 38–85% range across individual runs. What changed wasn't a jump to near-perfect runs — it was that this particular structural failure stopped appearing. We're reporting a state we observed, not a guarantee.

What this didn't prove

A few limits, because the result is smaller than it might sound.

The zero is a zero on the runs we executed, for this specific pattern. It's evidence the rule is doing its job in the tested scope, not proof the pattern is gone for good. A different project, a different httpx version, or a different phrasing of the same task could surface it again.

The measurement approach itself has a known weakness we worked around rather than solved: it reads raw error text, which is reliable for exact-pattern counting but says nothing about why each occurrence happened. For this pattern — a single, well-understood cause — that was fine. For a fuzzier failure, raw-text counting would undercount or overcount, and we'd need something better.

And the broader idea ("measure before you prescribe") is a working heuristic from repeated experience on this project, not something we've established rigorously. We'd genuinely like to know where it breaks down for other people.

Beyond the coding loop

The same week, an unrelated problem came up — a structural issue in how some of our project directories were tracked in version control. An earlier note had flagged it as a likely large cleanup, the kind of thing you budget a careful session for.

Before touching anything, we applied the same lesson the measurement script had just taught us: measure first. A few read-only checks showed the actual scope was much smaller than the earlier flag assumed — most of what looked like a structural defect turned out to be a single missing ignore-rule and one stale index entry, and the fix was a handful of non-destructive steps rather than a restructuring. I'm including this not as a second result but as an observation: in both cases the failure mode was the same — acting on an estimate instead of a measurement — and in both cases, once we measured, the prescription shrank. Two instances isn't a trend, but it was enough to make "measure the scope before writing the fix" a step we now try to take on purpose rather than when we happen to remember.

Back to Part 8's question

Part 8 ended by asking whether a growing rule set could stay manageable. This episode is one data point toward a tentative answer: rule growth seems more controllable when the decision to add a rule is driven by measured scope rather than by where a failure last happened to appear. Six task-level rules would have grown the rule set faster and addressed the problem worse. One measured rule did more with less.

That's not a method, and it's certainly not a solution to the interaction-effect problem from Part 8. It's a habit we're trying to form: before crystallizing a new rule, spend the few minutes it takes to count how often and where the underlying failure actually occurs. Sometimes that collapses six patches into one rule. Other times — we assume, though we haven't hit this yet — it will reveal that what looked like one problem is really several, and we'll need more rules, not fewer. Either way, the rule follows the measurement.

Series Links

ForgeFlow runs on a MacBook Pro M5 Max 128GB. Planning uses Claude (cloud API). Execution is fully local — Qwen3-Coder-Next 45GB via Ollama, gemma4:26b for QA, Docker sandbox, no API calls during the coding loop. The methodology and failure data are shared in this series.

If you're running your own local agents or failure-catalog systems: have you caught yourself prescribing locally for a problem that turned out to be project-wide — and what finally made you measure it? Logs, test signatures, prompts, generated diffs? The comments are open.

77 Rules Later: What Graduating Our First Stack Actually Looked Like

Joseph Yeo — Mon, 25 May 2026 08:19:22 +0000

This is Part 8 of the ForgeFlow series. Part 7: The File Modification Boundary documented the constraint that changed how we structure tasks: every autonomous task target should be a new file. We ended Part 7 at 12 projects, roughly 52 failure patterns, and 71 design rules. Part 7 closed with an open question: "Project 13 will be the first real test of whether CL-071 holds under normal conditions."

Quick terms for new readers:

FC = Failure Catalog entry (a documented failure pattern)

CL = Crystallized Lesson (a testable design rule derived from repeated failures)

DEADLOCK = the system gives up after repeated identical failures

ForgeFlow = a fully local, TDD-based autonomous coding system running on Apple Silicon

Part 7 ended with a hypothesis and a bet.

The hypothesis: CL-071 (every task targets a new file, never modifies an existing one) might reduce or remove the dominant failure mode we'd been observing. The bet: we'd set formal graduation criteria and run projects until we met them — or discovered why we couldn't.

We ran five more projects (with one intermediate rerun included in the data). On the seventeenth — a blog API with 14 tasks — all 33 tests passed without intervention or deadlock, completing in approximately 12 minutes.

This post is about the five projects between that hypothesis and this result, what the graduation criteria actually measured, and the failure that appeared after we thought we'd addressed all the known ones.

The Graduation Criteria

Before results, here's what we were measuring. We didn't want "it worked once" to count as graduation. We defined four conditions, all of which had to hold on a qualifying run:

Criterion	Threshold
First-run pass rate (tasks passing on the first TDD cycle, no retry)	≥ 85%
New FC yield per project	≤ 2
Repeat FC rate (previously solved patterns recurring)	≤ 5%
Teacher escalation (human operator interventions mid-task)	Decreasing trend

The logic: a graduated stack should show repeatable autonomous recovery within the tested scope (criterion 1), stop producing novel failure patterns at a high rate (criterion 2), not regress on already-solved problems (criterion 3), and require less human involvement over time (criterion 4).

We chose 85% rather than 100% for the pass rate deliberately. Occasional retries are expected behavior in a TDD loop — in ForgeFlow's architecture, the system is designed to recover from them. What we track is whether it recovers autonomously.

The Five-Project Path

Here's the longitudinal data from Part 7's endpoint (project 12) through the graduation run. Note: this table tracks the autonomous pass rate — tasks that eventually passed without human intervention, including retries. The graduation criterion uses the stricter first-run pass rate (no retries), which we measured separately for the qualifying run.

#	Project	Tasks	Autonomous Pass Rate	New FCs	CL Count (at time)
13	comment-api	12	83%	0	~72
14	order-api	16	56%	2	~74
15	recipe-api	14	57%	1	~75
16	bookmark-api v2	12	83%	0	~76
16.5	catalog-api-v2	12	83%	1	~76
17	blog-api	14	100%	1	77

The trajectory wasn't smooth. Projects 14 and 15 dropped below 60%. Then it recovered. In this sequence, plateaus tended to expose a new failure category; the system dipped, the failure got crystallized into a rule, and the next project incorporated the fix.

What changed between project 15 (57%) and project 17 (100%) was not a model upgrade or an engine rewrite. It was three additional design rules, each derived from a specific failure we observed and diagnosed.

The Dip: What Went Wrong on Projects 14 and 15

Projects 14 (order-api) and 15 (recipe-api) both hovered around 56–57% autonomous pass rate. The failures clustered around a few patterns:

Route endpoint isolation. Tasks that bundled multiple endpoints into a single file — GET list and GET detail in the same route module — showed a notably higher failure rate than single-endpoint tasks. The outputs showed scope-related failures: given two endpoints to implement, the model would sometimes complete one and leave the other as a stub, or attempt both and introduce inconsistencies.

We already had CL-043 (one task, one endpoint) from Part 6. But we'd been applying it loosely — allowing two closely related endpoints to share a task. Projects 14 and 15 showed us that "closely related" was too vague for this local execution loop. The rule needed to be absolute: one endpoint, one file, one task.

Import specification gaps. Route tasks that didn't explicitly list every required import in their task description had a high failure rate. The model would guess import paths, often incorrectly. CL-072 crystallized this: every route task description must include a complete "Required imports" block. For example:

Required imports: from fastapi import APIRouter, Depends;
from sqlalchemy.ext.asyncio import AsyncSession;
from app.database import get_db;
from app.schemas.author import AuthorCreate, AuthorRead

Decimal type mismatches. In project 16.5 (catalog-api-v2), a product model with a Numeric(10,2) price column exposed a subtle testing issue. The model wrote assertions comparing float literals to SQLAlchemy Decimal values — and 999.99 != Decimal('999.99') in Python. CL-076 captured this: any Numeric column test must use Decimal comparisons.

In our diagnosis, these looked less like model-capability failures and more like specification-precision failures — cases where the PRD left enough ambiguity for a 45GB quantized model to make a reasonable-but-wrong choice.

The Failure We Didn't Expect: FC-074

Project 17 (blog-api) was designed as the graduation attempt. We applied all 76 existing rules. The PRD passed our automated validator (50 checks passed, 0 failures). We expected fewer known-pattern failures.

The first three attempts all failed on the very first task — creating the Author model. Same error each time: red_apply_empty — the engine's signal that the RED-phase output contained implementation code rather than a test.

Here's what happened, step by step:

Our setup script created a minimal model stub file — just the class name and primary key column. This was standard practice per CL-066 ("stubs should be PK-only").
Before the RED phase (test generation), the engine runs FC-060 cleanup: it deletes the target implementation file so the model writes it fresh.
FC-060 deleted the stub.
The model didn't need the file to exist at generation time — the surrounding task context still described enough of the intended model structure (via data_models in the PRD and conftest import references) that it produced implementation code during RED instead of a test.
The engine detected this as a scope violation and triggered red_apply_empty.
Three retries. Same result each time.

We called this FC-074: the interaction between two previously validated rules (CL-066: keep stubs minimal, and FC-060: clean target files before RED) producing a new failure when combined.

This is worth pausing on. FC-074 wasn't a gap in any single rule. It was an interaction effect — two rules that had each been validated independently across multiple projects, producing a failure only in a specific sequence of operations.

Rule	Behavior in isolation	Combined behavior
CL-066	Minimal stubs reduce over-complete-stub failures	Creates a target file before RED
FC-060	Deletes implementation target before RED to ensure clean state	Removes the stub CL-066 created
Combined	—	RED sees a missing target but enough context to generate implementation instead of a test

The Fix: Stop Creating Stubs

The first instinct was to adjust the prompt wording — tell the model more explicitly to write a test, not an implementation. We tried that. Same failure. Prompt changes alone didn't resolve it; file-state became the stronger hypothesis.

The second instinct was to refine the stub. But we diagnosed the stub's existence as the likely trigger: FC-060 deleted it, and the residual context information was enough to derail the RED phase.

The third attempt was the simplest: don't create the stub at all.

CL-077: Setup scripts must not create model stub files. Model files are created from scratch by the task that implements them. The conftest wraps model imports in try/except so that earlier tasks can run before the model file exists:

try:
    from app.models.author import Author
except ImportError:
    Author = None

This inverted an assumption we'd held across the previous 16 project iterations. We'd operated under the belief that providing a stub — even a minimal one — helped the model by giving it a starting point. FC-074 suggested that in our current engine architecture, the stub hurt by creating a state that the cleanup logic couldn't handle cleanly.

After applying CL-077, the same blog-api project ran all 14 tasks to completion. 33 tests passed, zero intervention, approximately 12 minutes total.

What the Graduation Run Measured

Here's how project 17 scored against the criteria:

Criterion	Threshold	Project 17 Result
First-run pass rate	≥ 85%	93% (13/14 first-shot, 1 retry)
New FC yield	≤ 2	1 (FC-074)
Repeat FC rate	≤ 5%	0%
Teacher escalation	Decreasing	Zero escalations

Project 17 met all four thresholds. The preceding project (16.5, catalog-api-v2) reached 83% — close but below the ≥85% line. So we are treating project 17 as the graduation point rather than claiming a two-project stable plateau.

To be precise about what this means and what it doesn't:

What it means: On the specific runs we executed — FastAPI + SQLAlchemy async + pytest projects with CRUD-level complexity and 1:N foreign key relationships, using Qwen3-Coder-Next 45GB Q4_K_M on Apple Silicon M5 Max 128GB with 77 design rules — the system completed the full project autonomously within the scope of new-file-creation tasks.

What it doesn't mean: We haven't tested more complex architectural patterns (many-to-many relationships, authentication flows, file uploads, WebSocket endpoints). We haven't tested with different model families or hardware tiers. The 100% figure is for one specific project run; it's a data point, not a guarantee.

77 rules is a lot of rules. Each one was derived from at least one observed problem. But the cumulative load of maintaining 77 interacting rules is substantial. We don't yet know if this scales — whether a 200-rule system would be manageable or would collapse under interaction effects. This matches a concern we are starting to track internally: beyond a certain threshold, adding more constraints may dilute model attention rather than improve output. In our design, we've set a ceiling of 20 CLs per prompt injection bundle to guard against this, but we haven't yet hit a project that tests that limit.

The Rule Accumulation Curve

One pattern we've been tracking across the series is how the rate of new rule discovery changes over time:

Projects  1–3:   CL-001 to CL-020   (~7 per project)
Projects  4–6:   CL-021 to CL-035   (~5 per project)
Projects  7–9:   CL-036 to CL-051   (~5 per project)
Projects 10–12:  CL-052 to CL-071   (~6 per project)
Projects 13–17:  CL-072 to CL-077   (~1 per project)

The yield dropped from roughly 7 new rules per project to roughly 1. We're cautious about reading too much into this — it could mean we're approaching the boundary of what our current project complexity can reveal, rather than the boundary of what rules exist. More complex projects might expose entirely new failure categories.

But within the FastAPI + SQLAlchemy + CRUD scope, the flattening is visible in this dataset. The most notable new failure in this stretch was an interaction effect between existing rules — FC-074 — rather than an entirely novel pattern.

The Interaction Effect Problem

FC-074 taught us something we hadn't articulated before: as the rule set grows, the opportunity for interaction effects between rules increases. Each rule is validated independently, but the system runs them all simultaneously.

This resembles a familiar problem in complex systems: the space of pairwise interactions grows faster than the number of components. We can't test all combinations manually.

We don't have a systematic solution for this yet. What we have is a detection mechanism: when a failure occurs that doesn't match any existing FC pattern, we now check whether it could be an interaction between two rules that had both worked in isolation in prior runs. FC-074 was caught this way.

Whether this can be automated — detecting interaction effects without human diagnosis — is an open question. The engine could potentially track which CLs were active when a novel failure occurs and flag the pairwise candidates, but we haven't built that yet.

What Comes Next

Graduating from the FastAPI stack opens a question: what do we do with a graduated stack?

We see two directions, each answering a different question:

Direction A: Complexity escalation. Stay on FastAPI but increase project complexity — many-to-many relationships, authentication flows, nested resources, pagination. This tests whether the current 77 rules hold at higher complexity or whether new failure categories emerge.

Direction B: Stack transfer. Move to a different framework and measure how many of the 77 rules transfer. Our rules are categorized by stack tags — 29 are marked "universal," 32 are "fastapi"-specific. A new stack would test whether the universal rules actually are universal.

The question we're most interested in now isn't whether we can achieve another 100% run. It's whether a rule-based agent system can keep growing without becoming harder to reason about than the model it was designed to constrain.

Series Links

If you're building something similar — local AI agents, TDD automation, failure catalog systems — I'd be interested to hear whether you're seeing interaction effects between your own accumulated rules. The comments are open.

The File Modification Boundary We Found After 12 ForgeFlow Projects

Joseph Yeo — Fri, 22 May 2026 15:00:08 +0000

This is Part 7 of the ForgeFlow series. Part 6: The Bug Wasn't in the Model ended at 9 projects, 51 failure patterns, and 70 design rules. Up until that point, failure rates in our setup were declining and the working framework felt like it was converging. Project 12 exposed a structural gap we hadn't yet documented.

Quick terms for new readers:

FC = Failure Catalog entry (a documented failure pattern)

CL = Crystallized Lesson (a testable design rule derived from repeated failures)

Identical GREEN = the model returns an unchanged file during the implementation phase

DEADLOCK = the system gives up after repeated identical failures

Part 6 ended on a high note. Nine projects. A 100% pass rate on the last one. Forty-three crystallized lessons. A working framework in our setup: DCR × Information Quality × Task Complexity. The system felt like it was converging.

Then we tried self-referential foreign keys, and a failure mode we'd only seen sporadically became the dominant pattern.

This post is about project 12 — a department hierarchy API with JWT authentication and self-referential parent-child relationships. It documents the failure pattern that connected several scattered observations into a single engineering constraint. And it discusses why, in our case, the most practical response was to restructure the work rather than retry harder.

The Setup: Department API

Project 12 was designed to test two development vectors simultaneously: JWT authentication (new for ForgeFlow) and self-referential foreign keys (a department can be a child of another department). The tech stack was familiar — FastAPI, SQLAlchemy async, pytest — but the data model was more complex than our previous test projects.

The target execution plan: 13 tasks total. Of these, 4 were new-file creation tasks (schemas, tests), 5 were existing-file modification tasks (models, routes), and 4 were either setup steps or handled outside the autonomous loop.

We ran it five times, redesigning between each iteration. The pattern became hard to ignore.

The Scorecard

The table below shows the task categories from Project 12. The same outcome repeated across five redesign-and-rerun attempts.

Task Type	Count	Pass Rate	Avg Cycles
New file creation (schemas, tests)	4	100%	1.0
Existing file modification (models, routes)	5	0%	DEADLOCK

In our setup, tasks requiring the generation of an entirely new file succeeded on the first attempt. Tasks that required modifying an existing codebase file resulted in a processing deadlock. This held across five separate runs, two different backends (direct Ollama API and Aider), and multiple retry strategies.

To scope these findings: our dataset is constrained to a single model family (Qwen3-Coder-Next, 45GB Q4_K_M) running on a single hardware tier (Apple Silicon M5 Max 128GB). We don't claim these trends apply universally. But the pattern was consistent enough across five runs that we changed how we structure tasks going forward.

What "Identical GREEN" Looks Like

ForgeFlow's TDD loop works in two phases: RED (write a failing test) and GREEN (write code to pass it). The GREEN phase is where modifications happen.

When a task required modifying an existing file, the following loop repeated:

The model receives the existing file content + test requirements
The model outputs code that matches the existing file exactly (detected via SHA-256 hash comparison)
The engine retries with an explicit prompt: "Your output was identical to the current file"
The model outputs the same file again
DEADLOCK after 3 identical cycles

We call this an identical GREEN deadlock. The engine already had detection for it (FC-037, added months ago). But we'd only seen it sporadically before. In project 12, it became the primary failure mode.

Working Hypotheses

We're cautious about attributing "understanding" to the model — we're observing output patterns, not internal reasoning. Here's what we think might be happening:

The whole-file generation pattern (Ollama backend): When generating code via raw completion, the model streams the entire file from the first token. If the existing file is 95% correct and only needs a few lines added, the token history in the context window acts as a statistical attractor — the generation pattern defaults to reproducing the verified, working code rather than deviating to introduce new logic. The smaller the required change relative to the existing file, the stronger this pull appears to be.

The diff generation constraint (Aider backend): Diffs require precise line-matching tokens. When the target file is complex — multiple async routes, mixed dependencies, dense imports — generating accurate unified diff chunks appears to become erratic for our local quantized model. In our tests with this specific model and configuration, this manifested as timeouts (capped at 200 seconds per task) or a fallback to emitting an unchanged version of the source file.

Both pathways showed similar limitations on file modification tasks in our configuration. Whether this is specific to quantized local models or a broader pattern, we can't say.

Connecting Scattered Observations

Before project 12, our tracker had three separate failure patterns that each captured a piece of this:

FC-034 / CL-043: "One task, one endpoint" — adding endpoints to an existing route file often resulted in syntax errors or duplicates
FC-047 / CL-066: "Over-complete stubs" — when a stub had significant boilerplate, the model treated it as finished
FC-039 / CL-058: "POST endpoints need Aider" — some tasks specifically failed on the Ollama backend

Project 12 gave us the data to connect these into a single classification, FC-052:

In our local execution setup, existing file modification tasks demonstrate a high probability of identical GREEN DEADLOCK on both whole-file and diff-based backends. In our observations, identical-output failures appeared more often when the required change was small relative to the existing file.

From FC-052, we derived CL-071:

Every autonomous task target should be a new file. If a workflow step must modify an existing file, that modification should either be handled programmatically during setup or the architecture should be decoupled so that features reside in isolated modules.

This became our 71st crystallized lesson, and it changed how we now structure ForgeFlow projects.

One notable data point: across three complete projects (10, 11, and 12), our failure catalog expanded by only a single new entry. The rule accumulation curve is flattening, which may suggest we're mapping the boundary of our current configuration — or just the boundary of our current project complexity.

The Design Pattern That Emerged

CL-071 pushed us to rethink how we write PRDs.

Before (task-level modifications):

TASK-001: Create User model (stub)        → models/user.py
TASK-002: Add fields to User model        → models/user.py    [DEADLOCK]
TASK-003: Create Department model (stub)  → models/department.py
TASK-004: Add relationship                → models/department.py [DEADLOCK]

After (decoupled new-file generation):

SETUP SCRIPT: Generate complete models with all fields and relationships
TASK-001: Create User schemas    → schemas/user.py      [NEW FILE ✅]
TASK-002: Create Dept schemas    → schemas/department.py [NEW FILE ✅]
TASK-003: Create register route  → routes/auth.py        [NEW FILE ✅]

The pattern: infrastructure is established deterministically during setup, while the model handles clean-sheet file generation.

An important caveat: applying this pattern to project 12 was not a clean autonomous success. We manually implemented the CRUD endpoints (6 routes) to unblock the dependency chain, then tested whether the remaining new-file task would run cleanly under the revised structure. The integration test — creating a fresh test_integration.py — passed on its first autonomous cycle. The important result was narrower than "we solved it": once existing-file modification was removed from the autonomous task path, the remaining new-file task completed cleanly.

We should also note an open concern: forcing every task into a "new file only" pattern shifts complexity from generation-time editing to project-level file organization. At 13 tasks, this is manageable. At 50+, it could create significant file fragmentation and import overhead. We haven't tested at that scale yet.

Where We Are After 12 Projects

Metric	Value
Total projects	12 (11 completed, 1 scrapped)
Failure patterns cataloged (FC)	52
Design rules (CL)	71
Automated rule checks	53 functions in validate_prd.py
Sessions	81

The Honest Assessment

After 12 projects and 81 sessions:

What's working in our setup:

New file generation from detailed specs: reliable across the runs we tested
TDD enforcement (RED must fail, GREEN must pass): useful as a mechanical guardrail
Failure pattern → design rule pipeline: producing diminishing but real returns
Setup-based infrastructure + model-based creation: tested over 3 projects

What isn't working:

Existing file modification: consistently unreliable with our current model and configuration
Non-deterministic results on complex tasks: one task passed in 2 out of 3 runs, failed in 1. Same code, same model, different outcome.
Long dependency chains: a single DEADLOCK blocks everything downstream

Open questions:

Does CL-071 hold on 20+ task projects with complex dependency graphs?
Does the "new file only" constraint create unsustainable file fragmentation at scale?
Will newer local models (Qwen3-Coder v2, Llama 4) shift this boundary?
Is this specific to quantized local models, or do cloud API models show similar patterns on file modification tasks inside TDD loops?

A Request to Readers

If you're running local models — Ollama, llama.cpp, vLLM, or something else — within autonomous execution loops, we'd be interested in learning whether your telemetry shows similar variations between file creation and file modification tasks.

Specifically: how do your local configurations handle incremental diff generation inside structured loops versus generating complete, fresh modules from detailed specs? If you've logged similar boundaries or found alternative designs to work around modification deadlocks, please share your setup and observations in the comments.

We're also curious whether anyone has hard metrics on how cloud models (GPT, Claude) perform on targeted file modifications inside closed-loop TDD environments. Our dataset is one model family on one hardware tier — more data points from different setups would help everyone working in this space.

What's Next

Project 13 will be the first real test of whether CL-071 is a design principle or just a project-12-specific workaround. Every implementation task will target a new file. Setup will handle all infrastructure. The open question isn't whether it passes — it's whether the "new file only" constraint produces a project structure that's actually maintainable at 20+ tasks.

We're also adding automatic CL-071 validation to validate_prd.py — a check that flags any task whose implementation target already exists at execution time. For our workflow, rules that repeatedly affect outcomes should probably be machine-enforced.

The Series So Far

I Built a Local AI Coding Agent on M5 Max 128GB — 164 failures, 35 tests, proof of concept
We Didn't Migrate from n8n to Python Because n8n Failed — The orchestrator rewrite
The Determinism War — Why we stopped chasing better models
The Information Design Gap — Why the agent was coding blind
DCR Wasn't Enough — Adding information quality to the framework
The Bug Wasn't in the Model — Lessons from 9 projects
The File Modification Boundary — You are here. 12 projects, a boundary mapped.

About

I'm Joseph YEO, a solo builder from Seoul, Korea. ForgeFlow runs entirely on a MacBook Pro M5 Max 128GB — no cloud APIs during execution. The planning agent (Claude) designs the specs. The local model (Qwen3-Coder-Next, 45GB Q4_K_M) executes the TDD loop autonomously.

Follow along:

Built over 81 sessions, May 2026. All models run locally via Ollama 0.23.0 on macOS. No cloud APIs were used during autonomous execution.

This post was drafted with Claude and edited by me.