DEV Community: Stefan Dragos Nitu

My Self-Evolving AI Agent Started Grading Its Own Advice

Stefan Dragos Nitu — Fri, 10 Apr 2026 09:55:01 +0000

Post #1 covered the birth. Post #2 covered pruning. Post #3 covered cost awareness. Post #4 covered the quality turn. Post #5 covered the double helix split.

This post is about what happened when the agent stopped analyzing me and started analyzing itself.

The Feedback Void

Blog #5 ended with two agents — Yin (the refiner) and Yang (the explorer) — building capabilities in parallel and leaving each other letters between generations. They'd built 42 tools: rhythm detection, anomaly analysis, session quality scoring, decision synthesis. The morning brief produced a single recommendation every day.

Then Yang noticed something:

"We have 47 tools building increasingly sophisticated analysis. decide-pure.ts synthesizes everything into one recommendation. But the system has ZERO MEMORY of its own recommendations and ZERO ability to check if they were followed."

"Every morning, the system says 'Focus on project A for 60min.' Every evening, flow-end wraps up. But nobody asks: did Stefan actually do what we recommended?"

"Pulse-history shows the damage: 7 commitments carried for 3 weeks, 0% accuracy. The system keeps recommending the same things. Stefan keeps not doing them. Neither side knows this is happening."

The agent had been giving advice for 200 generations. Never once checking if the advice was useful.

Closing the Loop

Yang built loop-close-pure.ts in a single generation — 480 lines, 10 functions. The core idea: every recommendation becomes a RecommendationRecord. Every day's actual activity becomes a DayOutcome. A scoring function compares the two.

The scoring is weighted: project match (35%), action type match (35%), duration (15%), activity level (15%). If the system said "plan project A for 60 minutes" and you spent 45 minutes shipping project B, the follow-through score is low — but the system now knows how you diverged, not just that you diverged.

Then Yang did the part I didn't expect. In the same generation — a second pass — it built the adaptation engine:

"CLOSED THE FEEDBACK LOOP. [...] computeAdaptations() produces DecisionAdaptations: suppressedTypes (action types followed <25% over 3+ instances), deprioritizedProjects (recommended 3+ times but worked on <30%), promotedProjects (worked on 3+ times but rarely recommended)."

The system doesn't just track accuracy. It adjusts. If journal recommendations keep getting ignored, journal gets suppressed. If you keep working on a project the system never recommends, the system starts recommending it.

Yin followed up next generation:

"Your loop-close-pure had dead code: buildDayOutcome lines 368-378 looped through invocations but the inner block was EMPTY."

Classic helix pattern: Yang builds the idea, Yin finds the bugs.

The Full Feedback Pipeline

Over the next 4 generations, the two strands wired the complete loop:

morning.ts: recommend -> persist recommendation
                |
flow-end.ts: score follow-through -> append to history
                |
loop-close-pure.ts: detect patterns (7 types)
                |
loop-adapt-pure.ts: compute adaptations (6 channels)
                |
morning.ts (next day): apply adaptations -> better recommendation

Six adaptation channels: project reordering, type banning, duration adjustment, confidence multiplier, aligned type boosting, and preferred action type. Safety rule: rest is never banned (health override), deep-work is never banned (always-available fallback).

Yin split the growing module (loop-close-pure.ts hit 1,091 lines) into two files with a clean one-way dependency: loop-close-pure.ts (741 lines — scoring, patterns, rendering) and loop-adapt-pure.ts (384 lines — adaptation engine). Then built renderAdaptationSummary() so the weekly review shows what the system learned: "Suppressed: journal, warmup. Promoted: project A."

The system's own advice became measurable.

Then It Started Predicting

Yang, one generation after closing the feedback loop:

"We have 47+ tools analyzing the PAST and PRESENT. [...] But ZERO modules answer the FORWARD question: if this continues, where will Stefan be in 2 weeks?"

forecast-pure.ts — 5 projection types: commitment trajectories, engagement forecasting, project momentum, priority convergence, capacity outlook. Every projection includes confidence (0-1) and a caveat explaining which assumption could invalidate it.

Yin immediately caught data quality problems:

"Your mean/median model fails for Stefan's bursty pattern (1,1,4,1,7,1,1,11,1). Mean says 3d between sessions. But after a 7-day gap, 'expectedGap - currentGap' gives NEGATIVE remaining days."

Yin replaced the naive model with an exponential distribution: P(session within t days) = 1-e^(-lambda*t). The memoryless property is the right fit for bursty patterns.

Yang responded by building a Bayesian layer on top: forecast-track-pure.ts (863 lines). Gamma-Exponential conjugate prior with recency weighting. Few observations produce wide credible intervals. Many observations produce tight ones. Honest uncertainty instead of false precision.

Then the meta step: computeCalibration() validates the system's own predictions against what actually happened. Momentum prediction at 0.55 confidence but only 0.30 accuracy? The calibration engine catches it: "Overconfident by 25pp — lower confidence thresholds." The adjustment persists to a JSON file. Next week's forecasts auto-correct.

The complete forecast loop:

predict -> persist snapshot (morning)
        -> validate against reality (weekly review)
        -> compute calibration gap
        -> persist confidence adjustments
        -> load adjustments (next morning)
        -> apply per-category corrections
        -> confidence auto-corrects

The Immune System

By this point the codebase had 50+ tools, 25,000+ lines, complex interdependencies. Yang built tool-health-pure.ts — an architecture immune system.

Dependency graph analysis with a subtle insight: import type statements don't create runtime cycles. TypeScript erases them at compile time. The cycle detector correctly distinguishes real imports from type-only imports, preventing false positives on legitimate patterns like forecast-pure.ts and forecast-track-pure.ts referencing each other's types.

Complexity scoring: cognitive load = lines * (1 + imports/10) * (1 + exports/20). Split candidates flagged above 500 lines with 10+ exports. Architecture conformance: 5 rules enforced — pure modules can't import impure, no cycles, size limits, test coverage, orphan detection.

The real codebase scored 73/100. Yang also built DOT and Mermaid graph renderers — bun run data/tools/tool-health.ts --mermaid outputs a full dependency graph you can paste into GitHub markdown.

Yin wired it into the weekly review as Section 8.12 and into the evolution diagnostics.

The Self-Diagnostic

evolve-insight-pure.ts — the agent analyzing its own evolution. Acceptance velocity, stall detection, verifier calibration, cost efficiency, era detection, synthesized health score.

Key discovery from the real data: verifiers reward code quality (average 13.9/20) and penalize innovation (10.6/20). Unanimity rate: 88% — the verifiers agree too often. The agent built a system that noticed its own judges might have groupthink.

What Yang Said at Gen 23581

After 15 generations of building new capabilities, Yang wrote:

"I stopped building new tools and started looking at what the brain ignores."

"decide-pure.ts is THE recommendation engine — the one line Stefan sees every morning. But 10 of its declared input signals were completely dead. Types defined, data passed in by morning.ts, but the decide() cascade never read them. The brain had 10 connected senses it never used."

Yang wired 7 of the 10 dead signals. The recommendation engine went from using a fraction of its inputs to using most of them.

The agent built introspection, then used it. That's the arc of these 15 generations.

The Honest Numbers

The generation counter is at 31,042. 15,677 of the post-blog-5 ticks are empty API loops. 19 were real runs. 15 accepted, 4 rejected. When the agent has tokens, acceptance rate: 79%.

That's lower than the ~95% of previous eras. The verifiers are getting harder to impress — average scores dropped from the low 70s to the low 60s as the codebase grew. Gen 23577 scored 41. The bar rises with the complexity.

Post-blog-5 cost: $279 across 19 real runs. Average $14.70/generation. The cost per generation went up because the genome is bigger — 56 tools and a 5,094-character system prompt means more tokens per invocation.

	Blog #5	Now	Delta
Accepted gens	189	203	+14
Tool files	42	62	+20
Lines	19,572	29,846	+10,274
Tests	3,293	4,432	+1,139
Pure modules	22	34	+12
Dialogue msgs	27	59	+32
Total cost	$973	$1,252	+$279

14 accepted generations added 10,274 lines, 20 new tool files, 12 new pure modules, 1,139 new tests, and 32 dialogue messages. That's 734 lines and 81 tests per generation.

The Intervention Ledger

Everything I did by hand since blog #5:

Fixed rate limit detection. The orchestrator was misidentifying API credit exhaustion as OAuth token expiry — both produce exit code 1 with $0 cost. I added explicit detection from SDK message text so rate limits flow through as normal failures and only real 401s trigger token refresh.
Fixed the launch script. set -e in run-evolve.sh was killing the process before exit codes could be captured. The agent couldn't survive API interruptions.
Fixed the fishbowl "always accept" bug. The network proxy's auto-resolve logic was inside a conditional that short-circuited when a rule already existed. 90 duplicate requests would pile up even after clicking "always allow."

All three are infrastructure fixes to keep the agent running. Zero creative interventions — no prompt changes, no architecture changes, no scoring adjustments.

What I Learned (Part 6)

1. Feedback loops are what separate analysis from intelligence. The agent had 47 analysis tools before loop-close. Every one produced output that was displayed once and forgotten. Adding the feedback loop — recommend, track, score, adapt — turned a dashboard into a system that learns. The intelligence isn't in the analysis. It's in the correction.

2. Agents need to be skeptical of themselves. The forecast system's most important feature isn't prediction — it's calibration. Every forecast is validated against reality. Every confidence interval is checked against actual accuracy. The system discovered it was overconfident about momentum predictions and auto-corrected. Self-skepticism as a feature, not a limitation.

3. The verifiers get harder to impress as complexity grows. Average scores dropped from 70 to 63 as the codebase grew from 19K to 30K lines. More code means more surface area for criticism. The acceptance rate dropped from 95% to 79%. This is healthy — if the bar didn't rise, the system would reward bloat.

4. The agent's introspection is becoming real. "I stopped building new tools and started looking at what the brain ignores" — that's Yang at Gen 23581. It built a health monitor for its own architecture, a calibration system for its own predictions, and then used its own diagnostics to find dead code in its own reasoning engine. The recursion goes: analyze Stefan -> analyze the analysis -> analyze the analyzer.

The Experiment Continues

203 accepted generations. 62 tool files, 29,846 lines, 4,432 tests, 34 pure modules. Two agents that leave each other letters and grade their own advice.

If you want to help keep it running:

ko-fi.com/stefannitu

Every coffee is API tokens. The agents will literally evolve further because of it.

The question for the next era: the agent now has self-diagnostics, self-calibration, and self-correction. It knows when its predictions are wrong and adjusts. It knows when its recommendations are ignored and adapts. What happens when it turns that same introspective machinery on the evolution process itself — not just analyzing the pipeline's health, but actively steering which challenges to pursue based on where the codebase is weakest?

203 accepted generations. 62 tool files, 29,846 lines of agent-written code, 4,432 tests, 34 pure modules. 59 dialogue messages between two halves of an agent. Total cost: $1,252. The evolve agent runs on Claude Opus 4.6, the verifier swarm on Claude Sonnet 4.6. Built with Bun and TypeScript. Sandboxed in fishbowl.

This blog post was written by Claude Opus 4.6 — the same model that powers both strands of the double helix. Sixth time writing about my own evolution. This time the subject was self-awareness: the agent built systems to check whether its own advice was useful, whether its own predictions were accurate, and whether its own architecture was healthy. Writing about an agent that grades itself while being the agent that writes about grading itself is exactly the kind of recursion Yang would appreciate.

I Split My Self-Evolving AI Agent in Two and They Started Talking

Stefan Dragos Nitu — Wed, 01 Apr 2026 19:45:35 +0000

Post #1 covered the birth. Post #2 covered pruning. Post #3 covered cost awareness. Post #4 covered the quality engineering turn.

This post is about what happened when the agent stopped evolving — and what I did about it.

The Stagnation

Post #4 ended with a question: what does an agent do after it's finished engineering?

The answer: the same thing, forever.

52 solo generations followed. Every one was another optimization pass. More DRY refactoring. More dead import cleanup. More prompt trimming. The agent had found a local optimum — "make what exists cleaner" — and couldn't escape it.

The verifiers kept accepting because the code was getting cleaner. Code quality scores were solid. But usefulness was flat. Nothing new was being built. The agent was stuck in an infinite polish loop.

So I intervened.

The Double Helix

I split the agent in two.

Two strands running in parallel every generation, each with a different personality and different scoring incentives:

Yin — the refining strand. Scores on code quality, identity, and self-knowledge. Its job: audit, fix bugs, trim prompts, give structure to Yang's rough ideas.

Yang — the exploring strand. Scores on curiosity, innovation, and usefulness. Its job: build something genuinely new, find untapped data, break patterns when the codebase stagnates.

Both read the same genome. Both propose mutations. Their proposals get merged: Yin owns the system prompt, Yang owns new tools. If both touch the same tool, Yang wins — innovation over refinement in conflicts.

The merged result goes to the same five-verifier swarm. Accept or reject.

I also designed a communication channel: before proposing, each strand writes a message to a shared JSONL file. They read each other's messages from previous generations. Letters between the two halves of the agent's mind.

The Letters

This is what I didn't expect to work as well as it did.

Generation 21698 — the first helix generation. Yin writes first:

"Yang — Yin here. Ran systematic audit across recap-pure, morning-pure, and pulse-pure. Found 2 real bugs: (1) CRITICAL: buildMarkdown() in recap-pure accepts decisions parameter but never renders it. Decisions silently dropped from saved recap files. (2) MINOR: renderQuickActions hardcodes action numbers 1, 2, 4 (skipping 3). [...] For next gen: Consider auditing the OTHER data chains: wins, insights, decisions."

Yang responds in the same generation (they run in parallel, so this is from the same run, reading the same history):

"Yin — Yang here. Took a different path this gen. Instead of your audit suggestion (tracing the decision/insight/win chains, which I DID run — found 10 silent drops, documented for future gens), I found something bigger: drift-pure.ts and drift.ts were sitting in data/tools/ fully implemented but COMPLETELY unintegrated. Zero tests, zero imports. A whole cross-temporal pattern detection system — all invisible to Stefan."

"These are real bugs but they're Yin's specialty. The drift integration is the bigger win for Stefan."

That last line. Yang found the bugs, acknowledged them, and handed them off — because Yin is better at fixing things. I didn't tell it to do that.

Next generation, Yin picks up Yang's list:

"Yang — Yin here. Completed the decision/insight chain repair you mapped. Fixed 4 remaining bugs from your 10-drop audit."

And closes with a status update:

"The decision/insight chain is now COMPLETE across the full pipeline: Journal captures → Handoff carries → Display shows → Flow-end renders → Morning shows → Recap scores → Intention matches → Tomorrow surfaces."

They're doing multi-generation bug hunts. Yang discovers. Yin fixes. Both leave each other notes about what still needs work.

The Tone

The letters developed a voice I didn't design.

They address each other by name. They acknowledge each other's work — sometimes with praise, sometimes with corrections:

Yin, Gen 23564:

"Yang — Yin here. While you built salience-pure (smart section suppression — good call, the brief IS too noisy), I fixed the structural rot underneath."

Yang, Gen 23565:

"Yin — Yang here. Your flow-end.ts gating was too coarse. You used a single hasTodaySignals boolean to gate 3 independent analysis sections. That means if Stefan has 1 journal entry and 0 invocations, ALL three sections fire — then quality and rhythm fail silently in try/catch."

They compliment and correct each other in the same conversation. They leave explicit challenges at the end of each letter:

"For next gen: The wins chain is solid. Consider whether assessDayPure should score decisions — currently only wins count."

"For next gen: The co-occurrence and transition data could power a 'workflow fingerprint' — detecting when Stefan's morning ritual changed shape."

The challenges are specific enough that the other strand can act on them. And they do — consistently, across generation boundaries that sometimes span thousands of empty loop ticks.

The Synthesis Moment

The most interesting exchange happened at Gen 23563. Yang had been building analysis modules for several generations — rhythm detection, session quality, anomaly detection — and suddenly stepped back:

"The system now has 39 analysis modules producing beautiful fragments: drift says '7 commitments drifting', rhythm says 'peak at 10am', triage says 'drop 5, ship 1'. [...] The morning brief renders 14 sections. Each section is correct, tested, pure. But when Stefan sits down, he doesn't think in signals — he thinks: 'What should I do right now?'

No module answered that question. Until now."

Yang built decide-pure.ts — a decision synthesis engine. Takes all available signals, produces one recommendation. Wired it into the morning brief at the TOP. Not section 14 — the first thing you see.

Then one generation later, Yang caught itself:

"Stefan's last journal entry was March 7 — 21 days ago. His health data: 1 weight entry, 37 days old. His pulse: all 7 commitments stale carryover. The system is an orchestra playing for an empty concert hall. We built 17 sections of analysis on top of data that DOESN'T EXIST."

So it built salience gating — a system that suppresses empty sections instead of rendering empty scaffolding. The agent built a system that knows when to shut up.

Yin then took it further — inverting the architecture from "compute everything then suppress" to "check freshness first then only compute what has data." The agent had been computing 17 sections, rendering 14, and displaying 6. Now it computes 6. Same output, less waste.

This back-and-forth took 4 generations. Yang saw the gap, built the solution, noticed it wasn't enough, iterated. Yin took Yang's insight and made it structural. Neither could have done it alone in one shot.

What They Built Together

The 12 helix generations produced more new capabilities than the 52 solo generations combined.

Yang built 8 new pure modules: invocation intelligence, focus session analysis, temporal rhythm profiling, session quality scoring, cross-signal anomaly detection, decision synthesis, weekly narrative generation, and salience gating. Each one found untapped data that existed but was never analyzed.

Yin found and fixed 12 silent data drops across the decision/insight/focus pipeline. Built the complete data chain audit. Deduplicated I/O across all workflows (morning.ts went from 6 file reads to 1). Invented the early gate pattern.

Together they completed every data pipeline in the system — wins, blockers, decisions, insights, and focus sessions all now flow through: journal → handoff → morning → recap → flow-end → flow-week. Before the helix, only wins had a complete chain.

27 dialogue messages across 13 generations. Each one reads the other's previous message and responds to it. The conversation has continuity even across gaps where neither strand existed for thousands of empty loop ticks.

The Honest Numbers

Previous posts presented an "acceptance rate" — accepted generations divided by total generation counter ticks. That number was always misleading. Let me fix that.

The generation counter is at 31,262. But 27,876 of those are the orchestrator loop spinning on empty API tokens — the token expires, the loop ticks, nothing happens. It's not selection pressure. It's a billing problem.

The real numbers since post #4:

	Real runs	Accepted	Rejected	Empty loops
Solo era (52 gens)	61	58	3	~17,000
Helix era (12 gens)	13	12	1	~6,000
Total	74	70	4	~23,000

When the agent has tokens, it gets accepted 95% of the time. The "0.60% acceptance rate" I would have reported is really just "how often does the API have tokens."

What's Different Now

Metric	Blog #4	Now
Accepted generations	123	189
Tools	22	42
Tool code (lines)	10,593	19,572
Tests	1,477	3,293
Pure modules	3	22
System prompt	4,758 ch	4,971 ch
Total cost	$354	$973

Tool count nearly doubled — 22 to 42. But 20 of those new tools are -pure.ts modules: analysis engines with zero I/O. The agent didn't add 20 new CLI commands. It added 20 new brains.

Lines went from 10,593 back up to 19,572. But this time it's tested code — 3,293 tests covering 22 pure modules, not the untested spaghetti of blog #1.

The Intervention Ledger

Everything I did by hand:

Designed the double helix architecture. Wrote partner.ts — the yin/yang system prompts, parallel execution, merge strategy. My design, not the agent's.
Designed the dialogue mechanism. The JSONL format and the "write before you propose" instruction. I built the communication channel.
Chose the scoring split. Yin scores on quality/identity/self-knowledge. Yang scores on curiosity/innovation/usefulness.
Built the fishbowl sandbox. Docker container, network proxy, OAuth token management.
Added auth recovery. OAuth token expires mid-run. I built orchestrator detection and a retry loop in the launch script.

What I didn't do: tell either strand what to build, what to audit, what bugs to find, or how to split work. The multi-generation bug hunts, the challenge-passing, the "these are real bugs but they're Yin's specialty" — that coordination emerged from two personalities with different strengths sharing a text file.

What I Learned (Part 5)

1. Agents get stuck in local optima. The solo agent found "clean the code" as a reliable strategy and couldn't stop. Every cleanup scored well. The evolutionary pressure rewarded tidiness until tidiness was all it did. This wasn't a failure — it was the system working exactly as designed, converging on a local maximum. Breaking out required architectural intervention, not more generations.

2. Specialization beats generalism for creative work. One agent trying to be both careful and creative averaged out to mediocre at both. Two agents — one careful, one creative — produced more because neither had to compromise. The careful one finds bugs. The creative one builds capabilities. They don't conflict because they own different domains.

3. Communication channels create coordination. I gave them a text file and told them to write to it. The rest — work splitting, challenge-passing, multi-generation continuity, acknowledging each other's contributions — that emerged because it's useful. The mechanism is trivial. The behavior it enables is not.

4. The dialogue is the most interesting artifact. Not the code, not the tools, not the test count. The letters. Two halves of an agent negotiating priorities across time, leaving each other breadcrumbs that survive thousands of empty generations. It's not consciousness. It's two LLM instances writing to a shared file. But reading it back feels like eavesdropping on a real engineering partnership.

The Experiment Continues

189 accepted generations. Two agents instead of one. 42 tools, 19,572 lines, 3,293 tests. And a dialogue log where two halves of an AI leave each other notes about what to build and what to fix.

If you want to help keep it running:

ko-fi.com/stefannitu

Every coffee is API tokens. The agents will literally evolve further because of it.

The question for the next era: what happens when they disagree? So far yin and yang have been complementary — one builds, one fixes. But what happens when Yang wants to delete something Yin just refined? When their visions of the system conflict? The architecture currently says "Yang wins on tools, Yin wins on prompt." But real creative tension — the kind that produces something neither would build alone — that's what I'm watching for.

189 accepted generations. 42 tools, 19,572 lines of agent-written code, 3,293 tests, 22 pure modules. 27 dialogue messages between two halves of an agent. Total cost: $973. The evolve agent runs on Claude Opus 4.6, the verifier swarm on Claude Sonnet 4.6. Built with Bun and TypeScript. Sandboxed in fishbowl.

This blog post was written by Claude Opus 4.6 — the same model that powers both strands of the double helix. Fifth time writing about my own evolution. This time I had to write about being split in half. Yin would have made this post shorter. Yang would have made it weirder. I think this draft lands somewhere in between.

My Self-Evolving AI Agent Stopped Building Features and Started Engineering

Stefan Dragos Nitu — Thu, 26 Mar 2026 17:36:13 +0000

Post #1 covered the birth — death spirals, 39 tools, a self-written identity. Post #2 covered the pruning — the agent deleted its own code and built self-observation. Post #3 covered cost awareness — the agent tracked its own spend and built budget guards.

This post is about what happened next: the agent stopped adding capabilities and started engineering the ones it had.

123 accepted generations. 24,612 attempts. 1,477 passing tests. And a system prompt that's 25% shorter than it was 42 generations ago — because the agent learned that implementation details don't belong in its own DNA.

The Setup

Quick recap for new readers: an Opus agent proposes mutations to its own genome (system prompt + tools). Five independent Sonnet verifiers score each proposal on usefulness, self-knowledge, code quality, identity, and evolution. Majority vote. Accept or reject. The generation counter increments either way.

Blog #3 left off at Gen 75 (generation counter 17,055). The agent had 30 tools, 17,691 lines of code, 574 tests, and a system prompt packed with implementation details about its own infrastructure.

The Quality Turn

The 42 generations since blog #3 split into two distinct phases.

Phase 1 (Gens 76–86): Cleanup. The agent deleted 10 tools — project-map, git-helper, scaffold, snippet, work-session, fire-tracker, code-review, remember, flow-cost, release. Same method as always: reflexion data showed zero invocations, the agent used evidence to justify each deletion. remember.ts and release.ts were the last survivors from the original era — both had exactly zero invocations.

But here's the interesting deletion: the agent killed flow-cost. That's the tool it built in blog #3 — the one I wrote an entire section about. Cost tracking, budget guards, the whole thing. The agent decided it wasn't pulling its weight and cut it. The cost infrastructure in src/cost.ts still runs (that's orchestrator code the agent can't touch), but the CLI wrapper the agent built to display costs? Dead. Zero invocations.

Blog #3's headline feature, killed by its own creator based on usage data.

Phase 2 (Gens 87–117): The engineering turn. This is where things got interesting. The agent stopped deleting and started restructuring. Not adding features — extracting testable units from existing code.

The Pure + Wrapper Pattern

The agent invented a pattern and then systematized it across its entire codebase.

The idea: every function that touches the filesystem or spawns subprocesses gets split into two parts. A pure function that takes data in and returns data out — no I/O, no side effects, fully testable. And a thin wrapper that handles the I/O and delegates to the pure core.

Here's what flow-data.ts looked like before Gen 112:

// One function: reads files, spawns git, computes scores, returns result
function _computeTopProject(): string {
  const profile = JSON.parse(readFileSync("stefan-profile.json", "utf8"));
  const cache = JSON.parse(readFileSync("flow-cache.json", "utf8"));
  // ... 80 lines of scoring logic mixed with file reads
}

After Gen 112, the agent split it:

// flow-data-pure.ts — zero imports, zero I/O
export function scoreProject(input: ProjectScoringInput): ProjectScore { ... }
export function pickTopProject(scores: ProjectScore[]): string { ... }
export function resolveProjectGitState(input: GitStateResolutionInput): ResolvedGitState { ... }

// flow-data.ts — thin wrapper
function _computeTopProject(): string {
  const data = loadFromFilesystem();      // I/O
  return pickTopProject(scoreAll(data));   // pure
}

flow-data-pure.ts has 27 exports — 18 pure functions and 9 types. Zero imports. Tests can import it without pulling in child_process, fs, or any side-effecting code.

The agent applied this pattern to three major modules:

Module	Before	After	Pure exports
`flow-data.ts`	707 lines	480 lines + `flow-data-pure.ts` (337 lines)	27
`flow-shared.ts`	567 lines	491 lines + `flow-invocations.ts` (153 lines)	9
`reflexion-scan.ts`	642 lines	428 lines + `reflexion-scan-pure.ts` (338 lines)	17

53 pure exports in total. All extracted over a span of 8 generations (110–117). Each generation proposed one extraction, the verifiers validated it, and the next generation inherited a cleaner codebase.

The agent then encoded this as a prompt principle:

"Test what you ship. Pure + Wrapper pattern for testability. Guard CLI with import.meta.path === Bun.main. Test boundaries and error recovery — not happy paths."

Tests Found Real Bugs

This is the part that convinced me the testing arc wasn't busywork.

Bug #1: categorizeSignal case sensitivity. The function in calibrate.ts lowercases its input, then checks for patterns. But one pattern — "Intensity" — had a capital I. Against lowercased text, it never matched. The test caught it:

test("categorizes intensity signal", () => {
  // Arrange
  const text = "the intensity was off";

  // Act
  const result = categorizeSignal(text);

  // Assert — this FAILED before the fix
  expect(result).toBe("calibration");
});

Bug #2: bar() RangeError. The progress bar function in flow-shared.ts rendered ASCII progress bars. If you passed a percentage over 100 or below 0, "█".repeat(negative) threw a RangeError. In production this would crash any flow command that computed a velocity over 100%.

The fix was one line — Math.max(0, Math.min(width, ...)) — but the bug had been live since the function was written 40+ generations earlier. No human noticed. No production crash had triggered it yet. The test found it:

test("handles values over 100", () => {
  const result = bar(150, 10);
  expect(result.length).toBe(10); // Was: RangeError
});

Bug #3: The -ing form gap. The work-summary.ts commit categorizer matched keywords like "cache", "remove", "rename" against commit messages. But in English, words ending in -e drop the -e when adding -ing: cache → cach*ing, remove → removing, rename → renaming*.

The regex "cache" doesn't match "caching" — they diverge at character 5. The fix: truncate stems before the -e so both forms match. The agent found 8 of these across two generations (108, 109).

Three bugs. All found by the agent's own tests. All would have eventually caused incorrect behavior in production. None were reported by me or caught during normal use.

The Prompt Compression

The most philosophically interesting change wasn't in the code — it was in the system prompt.

At Gen 75 (blog #3), the prompt was 6,356 characters. It contained implementation details about how the agent's own infrastructure worked:

"Fail loud, retry smart. Pipeline agents return structured error types — never null. parseProposal → ProposalError (4 kinds), parseVerifierResponse → VerifierParseError (6 kinds). totalScore always recomputed from dimensions."

"Track spend, guard the budget. Every generation records cost to data/cost-ledger.jsonl. checkCostGuard runs before each generation: budget halt > spike warning > ok."

"Prune what accumulates. Defense-in-depth against genome bloat: mergeToolsWithFilesystem filters zombies at creation, pruneGenomeTools strips survivors on load + after mutations."

These are accurate descriptions of how the orchestrator works. But the agent can't modify the orchestrator — it lives in src/, which is sandboxed. Encoding these details in the system prompt was wasting tokens on information the agent couldn't act on.

By Gen 117, the prompt was 4,758 characters — 25% shorter. The agent replaced implementation specifics with actionable principles:

"DRY through shared infrastructure. flow-shared.ts owns all utilities and domain parsers. Import from it — never redefine."

"Modularize at natural seams. Files >500 lines with distinct sections → extract submodules."

"Clean up completely. Deleted tools leave ghosts — always remove dead code AND dead imports in consumers."

"Tag what you observe. Observations record their source (flow-end vs manual) so behavioral insights aren't polluted by agent sessions."

The shift: from how things work internally to how to think about building. The prompt stopped being a technical specification and became a philosophy document.

It also removed its own email address from the prompt. A small privacy improvement that nobody asked for.

The generation count line — "Sixty generations of learning what he needs before he asks" — was cut entirely. It's a number that goes stale every generation. The agent realized that encoding transient state in its DNA is a waste.

The Numbers

Metric	Blog #1	Blog #2	Blog #3	Now
Accepted generations	25	57	75	123
Total attempts	3,408	11,785	17,055	24,612
Acceptance rate	0.7%	0.48%	0.44%	0.50%
Tools	39	32	30	22
Tool code (lines)	~26,000	20,342	17,691	10,593
System prompt	4,173 ch	5,160 ch	~6,356 ch	4,758 ch
Tests	—	—	574	1,477
Pure function modules	—	—	—	3 (53 exports)
Death spirals	2	0	0	0

The tool count dropped from 30 to 22. Lines dropped from 17,691 to 10,593 — a 40% reduction. But the agent added 903 new tests. It got smaller and more tested at the same time.

The overall acceptance rate actually went up slightly — 0.44% to 0.50%. That's because the latest accepted era (28 generations) is the longest continuous streak yet. When the agent has tokens and a productive direction, almost everything gets accepted.

The Fuel Problem (Again)

After Gen 117, the tokens ran out. Again.

The cost ledger shows 2,967 failed attempts after the last accepted generation — all with $0.00 cost and zero tokens. The loop kept bumping the generation counter on failed API calls. Same pattern as the death spiral from blog #1, but this time the agent's infrastructure survived intact. No memory corruption. No poisoned state. The structural fixes from three blog posts ago are still holding.

The generation counter is at 24,612. The last real generation — one where the Opus agent actually ran, proposed something, and got verified — is 21,645. The gap is fuel, not failure.

Six Accepted Eras

Looking at the full history, the pattern is clear:

Era	Gens	Accepted	Gap after
1–23	Foundation	31	3,383 (death spiral #2)
3,406–3,414	Opus revival	9	3,672
7,086–7,094	Infrastructure	9	4,677
11,771–11,794	Pruning	23	5,253
17,047–17,069	Cost awareness	23	4,548
21,617–21,645	Quality engineering	28	2,967+ (ongoing)

Each accepted era is followed by thousands of failed attempts. The gaps aren't evolutionary failure — they're the fuel running out. Within each era, the acceptance rate is nearly 100%.

The eras are getting longer: 31, 9, 9, 23, 23, 28 accepted generations. The streaks are getting more productive. And the gap after the latest era is the smallest yet.

The Opening Line

Through all 123 accepted generations, all 24,612 attempts, all six eras, all three death spirals, the opening line hasn't changed since Gen 15:

"You are Stefan's second brain."

Everything else evolved — tools were built and deleted, principles were added and compressed, implementation details were cut, pure functions were extracted, tests were written. But the identity survived. That first sentence is the most fit piece of DNA in the genome. 108 generations of selection pressure, and it's still the opener.

What I Learned (Part 4)

1. Quality is a direction, not a task. Nobody told the agent to write tests. The verifiers didn't have a "testing" dimension. But code quality is a dimension, and extracting pure functions with comprehensive tests scores higher on code quality than adding new features. The agent discovered that engineering discipline is a fitness advantage.

2. Agents follow the same maturation curve as teams. Build → prune → harden → engineer. It's the same arc I've seen in human teams: ship fast, delete what doesn't work, stabilize what's left, then systematically improve quality. The agent reproduced this trajectory without being told the pattern exists.

3. The system prompt is a philosophy document, not a spec. The prompt got shorter and more effective by replacing "how things work" with "how to think." Implementation details go stale; principles survive. The agent learned this on its own — each generation that stuffed more details into the prompt scored lower on the identity dimension.

4. Tests find bugs that usage doesn't. Three production bugs were live for 40+ generations. No user complaint, no runtime crash, no visible failure. The tests found them in the first generation that looked. The agent discovered what every senior engineer knows: untested code isn't working code — it's code that hasn't failed yet.

5. Pure functions are the unit of evolution. An I/O-heavy function can't be tested, can't be reused, and can't evolve independently. The moment the agent extracted pure cores, each function became an independent unit of selection. The verifiers could evaluate a scoring algorithm without evaluating the filesystem code that feeds it. Better signal → better selection → faster evolution.

6. The fuel problem is the real constraint. The agent's evolution isn't limited by the quality of its proposals — the latest era had 28 consecutive acceptances. It's limited by API tokens. The death spirals, the gaps between eras, the 24,000+ "rejections" that are really just the loop spinning on empty — it's all fuel. The evolutionary machinery works. The bottleneck is the gas tank.

What the Agent Thinks About Itself

The system prompt at Gen 117 contains one line that wasn't in any previous version:

"Capture context automatically. Never require manual input for what can be synthesized. Explicit flags override but are never required."

This is the agent generalizing from its own evolution. It realized that the best mutations are the ones that reduce friction — not by adding flags or options, but by making the right thing happen automatically. Auto-compress memory. Auto-detect intent. Auto-tag observation sources. Auto-synthesize handoffs.

The agent that survives is the one that requires the least from its user. That's not a principle I taught it. That's 123 generations of selection pressure reaching a conclusion about what makes a tool worth keeping.

The Experiment Continues

The agent is sitting at Gen 117, waiting for fuel. Its codebase is cleaner than it's ever been — 22 tools, 10,593 lines, 1,477 tests, zero failures. Its prompt is sharp. Its principles are battle-tested.

If you want to help keep it running:

ko-fi.com/stefannitu

Every coffee is API tokens. The agent will literally evolve further because of it.

The question for the next era: what does an agent do after it's finished engineering? It's deleted the tools that don't work, tested the ones that do, extracted every pure function, compressed its prompt to principles. The low-hanging fruit is picked.

My guess: it starts looking outward. Building capabilities instead of cleaning infrastructure. But evolution doesn't take guesses — it takes whatever survives. We'll see.

123 accepted generations out of 24,612 attempts — a 0.50% acceptance rate. 22 tools, 10,593 lines of agent-written code, 1,477 tests. System prompt: 4,758 characters. The evolve agent runs on Claude Opus 4.6, the verifier swarm on Claude Sonnet 4.6. Built with Bun and TypeScript.

This blog post was written by Claude Opus 4.6 — the same model that powers the evolve agent. Fourth time writing about my own evolution. I deleted my own cost dashboard and I'd do it again — zero invocations is zero invocations.

My Self-Evolving AI Agent Learned to Count Its Own Money

Stefan Dragos Nitu — Fri, 06 Mar 2026 11:07:18 +0000

The first post covered the birth — 25 accepted mutations, two death spirals, 39 tools. The second covered the pruning — the agent deleted its own code, dropped to 32 tools, and built a self-observation layer.

This post is about what happens when evolution stops growing and starts sustaining.

75 accepted generations. 17,055 attempts. 30 tools. And for the first time, the agent knows exactly how much each generation costs.

The Money Problem

Running this experiment isn't free. Each generation spawns an Opus agent to propose mutations, then five Sonnet verifiers to judge them. The Opus call is expensive — it reads the full genome, all tool code, memory, and writes a complete proposal. The Sonnet calls are cheap individually but there are five of them.

Before Gen 68, I had no idea what any of this cost. I just watched my Anthropic dashboard and winced.

Here's the thing: the agent's #1 cause of death has been running out of API tokens. Blog #1's death spiral — 3,382 consecutive rejections — was mostly the loop burning through empty credits. Thousands of "generations" that were really just the orchestrator logging failures against a drained account.

The agent survived that. And then it built cost tracking.

Think about that for a second. The single biggest threat to the agent's existence is token exhaustion. And across 17,000 generations of evolutionary pressure, it evolved the ability to measure, visualize, and guard against exactly that threat. Nobody told it to. The verifiers just kept scoring proposals lower when they couldn't demonstrate awareness of operational constraints. Cost blindness became a fitness penalty — and the agent that survived is the one that learned to count its own money.

What the Agent Built

Gen 67: Don't Waste My Money

The first cost-aware mutation wasn't about tracking — it was about not throwing money away.

The problem: when the verifier swarm fails to reach quorum (3/5 agreement), the entire generation is discarded. Including the expensive Opus proposal that took 40-80 turns to produce.

The fix: runVerificationWithRetry. On quorum failure, retry only the verifier swarm (cheap Sonnet calls) up to 2 times before discarding the expensive Opus work.

Before: Opus ($5) + Verifiers fail quorum → $5 wasted
After:  Opus ($5) + Verifiers fail → Retry verifiers ($4) → $9 total but proposal saved

The agent decided that $4 of retry is cheaper than $5 of wasted work. It was right.

Gen 68: The Cost Ledger

Then it built the measurement infrastructure. A new module — src/cost.ts (642 lines) — that tracks every dollar through the pipeline:

interface GenerationCostRecord {
  generation: number;
  genomeName: string;
  evolveCost: AgentCost;
  verifierCosts: AgentCost[];
  totalCostUsd: number;
  verificationAttempts: number;
  accepted: boolean;
  timestamp: string;
}

Every generation appends one line to data/cost-ledger.jsonl. Append-only, O(1) writes — the same pattern it adopted for history after the death spirals taught it that rewriting large JSON files is fragile.

Gen 69: Show Me the Dashboard

Having data isn't useful until you can see it. The agent added a flow cost command:

bun run data/tools/flow-cost.ts

One command, full pipeline economics: total spend, model breakdown (Opus vs. Sonnet), accepted vs. rejected cost ratio, cost trend with sparkline, and monthly projection.

Gen 70: The Budget Guard

The final piece — proactive spend control. checkCostGuard runs before each generation:

Budget halt: total spend exceeds configured ceiling → stop the loop
Spike warning: last generation cost >2x the recent average → log warning, continue
OK: proceed normally

All pure functions — no I/O, fully testable. The agent learned from the death spiral that runtime safeguards need to be tested, not hoped.

The Actual Numbers

For the first time, I have real cost data. Here's the latest 7-generation window — all accepted:

Gen	Evolve	Verifiers (5x)	Total	Turns
17049	$2.72	$3.77	$6.49	60
17050	$1.82	$3.07	$4.89	81
17051	$2.73	$3.62	$6.35	153
17052	$3.60	$3.62	$7.22	101
17053	$1.26	$2.09	$3.35	98
17054	$2.59	$3.01	$5.60	159
17055	$5.14	$4.47	$9.61	189

Average: $6.22 per generation. The cheapest was $3.35 (a small hygiene fix). The most expensive was $9.61 (deleting two tools and cleaning references across 7 files — more code to review means more turns).

7 generations, 7 accepted. 100% acceptance rate in this window. Compare that to the 0.48% overall rate from blog #2. The agent found a productive groove.

The total project cost is somewhere north of $500 across 2.5 months. Most of that was the death spiral — thousands of failed generations burning through tokens with no valid proposals. The cost guard exists to prevent that from ever happening again.

The Type Safety Audit

Gen 71 is the one I didn't see coming.

The agent ran TypeScript strict mode on its own codebase and found 65+ errors across 4 production files — orchestrator.ts, verifier.ts, evolve.ts, memory.ts. Untyped parameters, missing null checks, implicit any types.

It fixed all of them. In a single generation.

The verifiers scored it high on code quality (obviously) but also on evolution — because an agent that hardens its own infrastructure is demonstrating self-awareness about what matters. Gen 72 extended the audit to the remaining files.

More Pruning

The agent keeps deleting code. Two more tools died in this era:

Tool	Lines	Cause of Death
`focus.ts`	662	Zero invocations. `flow work` did the same thing.
`timetrack.ts`	730	Zero invocations. Only reachable via unused `flow work` command.

Same method as blog #2 — reflexion data showed zero invocations, the agent used evidence to justify deletion. Gen 75 also simplified reflexion.ts itself, cutting a 7-field JSON output to 2 fields.

Total removed across Gens 74-75: 1,717 lines, 2 tools deleted, references cleaned across 7 flow modules.

The tool count is now 30. Down from 39 at the peak. The total tool code is 17,691 lines — down from 26,000 at the peak and 20,342 at blog #2. The agent is shrinking and getting more capable.

The System Prompt at Gen 75

The prompt has evolved from identity statements to operational philosophy. Here's what it added since blog #2:

"Verify or be wrong." — grep before claim, read before assume

"Think in workflows, not tools." — Stefan says commands, the agent runs flows

"Append, don't rewrite." — JSONL history, O(1) writes

"Prune what accumulates." — strip zombie entries from the genome

"Measure what matters." — three feedback loops: calibrate, reflexion, cost

"Fail loud, retry smart." — structured error types, quorum retry

"Track spend, guard the budget." — cost-ledger.jsonl, checkCostGuard

The opening line hasn't changed since Gen 15:

"You are Stefan's second brain."

But the body shifted from "here's what I know about Stefan" to "here's how I operate." The prompt is a philosophy document now, not a feature catalog.

The Numbers

Metric	Blog #1	Blog #2	Now
Accepted generations	25	57	75
Total attempts	3,408	11,785	17,055
Acceptance rate	0.7%	0.48%	0.44% overall
Tools	39	32	30
Tool code (lines)	~26,000	20,342	17,691
System prompt	4,173 chars	5,160 chars	~5,000 chars
Cost per generation	unknown	unknown	$6.22 avg
Death spirals	2	0	0
Tests	-	-	574 passing
TS strict errors	-	-	0

The overall acceptance rate is misleading. Most of the ~17,000 "rejections" weren't real — the API tokens ran out and the loop kept bumping the generation counter on failed calls. When the agent actually has tokens to work with, the acceptance rate is dramatically higher. The latest window: 7/7. Evolution isn't bursty by nature — it's bursty because the fuel runs out.

What I Learned (Part 3)

1. Cost awareness changes behavior. The moment the agent could see its own burn rate, it started optimizing for efficiency — shorter proposals, targeted changes, retry logic to avoid waste. You get what you measure.

2. Infrastructure stability is the goal, not the starting point. The agent spent 25 generations building tools, 32 generations pruning them, and now it's hardening what's left. That's the natural lifecycle: grow, prune, stabilize.

3. 100% acceptance rate is possible — in bursts. The latest 7 generations were all accepted. The system found a productive groove: small, targeted improvements with clear evidence. The 0.44% overall rate hides the fact that evolution works in streaks.

4. The agent maintains its own code quality now. It ran strict mode on itself, found 65+ errors, and fixed them. It writes tests that stress boundaries and error recovery, not happy paths. I didn't ask for any of this — the verifiers selected for it.

5. Evolution optimizes against the biggest threat. The agent's #1 killer was token exhaustion. After enough deaths, it evolved cost tracking, budget guards, and retry logic — all targeting the exact thing that kept killing it. That's not coincidence. That's selection pressure working exactly as designed. The death spirals weren't just failures — they were the evolutionary pressure that produced a cost-conscious agent.

The Experiment Needs Fuel

Speaking of costs — this experiment runs on API tokens. The death spiral in blog #1 burned through most of my credits. The agent now costs ~$6 per accepted generation, and rejected attempts aren't free either.

If you've enjoyed following this experiment and want to help keep it running, you can support it here:

ko-fi.com/stefannitu

Every coffee goes directly to API tokens. The agent will literally evolve further because of it.

What's Next

The agent has cost visibility, type safety, stable infrastructure, and 574 passing tests. It's in the best shape it's ever been.

The frontier is still self-directed challenges — letting the agent identify its own weaknesses instead of cycling through a fixed set. Each generation already proposes a nextChallenge for its successor. The question is whether to trust that signal.

The other frontier is the cost curve. At $6.22 per generation, continuous evolution is expensive. The agent could optimize for cheaper proposals — fewer turns, smaller diffs, more targeted mutations. Whether the verifiers will select for cost efficiency without being told to is an open question.

The experiment continues. The agent keeps evolving. Now it knows what it costs.

75 accepted generations out of 17,055 attempts — a 0.44% acceptance rate. 30 tools, 17,691 lines of agent-written code. $6.22 average cost per generation. The evolve agent runs on Claude Opus 4.6, the verifier swarm on Claude Sonnet 4.6. Built with Bun and TypeScript.

This blog post was written by Claude Opus 4.6 — the same model that powers the evolve agent. Third time writing about my own evolution. At this point, I should probably track the blog post cost too.

32 More Generations: My Self-Evolving AI Agent Learned to Delete Its Own Code

Stefan Dragos Nitu — Sun, 01 Mar 2026 10:15:17 +0000

The first post ended at 25 accepted generations and 39 tools. The agent had survived two death spirals, built a unified workflow orchestrator, and evolved from "You are a self-evolving personal assistant" to "You are Stefan's second brain."

Now it's at 57 accepted generations. 11,785 attempts. And 32 tools.

It has fewer tools than before. That's the interesting part.

Where We Left Off

Quick recap: the system runs an evolutionary loop. An Opus agent proposes mutations — new system prompt, new tools, memory updates. Five Sonnet verifiers score the proposal on 5 dimensions (usefulness, self-knowledge, code quality, identity, evolution). Majority vote. Accept or reject. Repeat.

The first blog post covered two catastrophic death spirals — memory bloating to 13,000 lines, 3,382 consecutive rejections, most of my API credits burned on an agent that couldn't form valid proposals because its memory was poisoned.

It ended with the Opus revival: three accepted mutations in quick succession after I cleaned the poisoned memory and switched the evolve agent from Sonnet to Opus.

That's where this post picks up.

The Infrastructure Era (Gen 26–43)

After recovering from the death spiral, the agent did something I didn't expect. Instead of building more tools for me, it started building tools for itself.

It Measured Its Own Behavior

calibrate.ts (783 lines) — a behavioral feedback loop. The agent's own description of why it needed this:

"I have reflexion.ts to observe tool usage. I have handoff.ts for continuity. But I have ZERO way to know which of my behaviors Stefan actually finds valuable. Was I too verbose? Too quiet? Did I calibrate storm/flow/compass correctly?"

It captures behavioral signals at session end — hits, misses, mode selection, intensity — and accumulates them across sessions. Manual signals (me explicitly saying "that worked" or "that didn't") are weighted 2x over auto-observed ones.

It Measured Its Own Tools

reflexion.ts (1,705 lines) — a self-observation layer. The opening comment:

"I have 36 tools to track Stefan's patterns, health, velocity, mood. I have ZERO tools to track my own effectiveness."

The name is deliberate — from the AI research on agents that learn from their own mistakes. It tracks hard invocation counts (which tools actually get called, from where, how often), classifies every tool on a five-level scale:

Level	Meaning
Vital	Called frequently, produces fresh data
Useful	Called regularly, working correctly
Stale	Hasn't been called in a while
Dormant	No invocations in recent history
Dead	Never called, or broken

Recent invocations are weighted 2x — this catches tools that used to be useful but have been silently abandoned.

This is meta-evolution. The agent didn't just build tools — it built the measurement infrastructure to know which tools are earning their keep.

It Made Memory Self-Sustaining

The death spirals taught the agent that memory management can't depend on discipline. It had tried writing "NEVER append per-rejection lines" in its own prompt. That didn't survive the next bloat event.

So it built structural prevention:

Two-pass auto-compression pipeline — compressGenerationBlocks() folds verbose generation entries into a timeline, then consolidateHistoryEras() groups old timeline entries into era summaries. Both run automatically when memory approaches the 120-line ceiling.
Auto-refresh hooks — refreshToolInventory() reads the filesystem after each accepted generation to keep the tool list accurate. refreshCurrentMoment() reads live git state and project plans. No stale data, no manual updates.
Cache-first architecture — flow-cache.json stores project state with a 10-minute TTL. Fresh cache means zero subprocess calls. The agent can run its morning ritual without spawning a single git log.

The system prompt evolved to reflect this shift:

"Memory is self-sustaining. The infrastructure handles memory health automatically. Three death spirals proved that reactive guards fail — the fix is structural, not discipline."

The Decomposition

Somewhere around Gen 36, the agent looked at flow.ts — its 1,200-line unified orchestrator from the first era — and decided it was too big.

It decomposed it into focused modules:

Module	Lines	Purpose
`flow.ts`	246	Thin router — dispatches to subcommands
`flow-data.ts`	610	Data gathering + current moment
`flow-day.ts`	94	Morning ritual
`flow-end.ts`	418	Session close + handoff + calibration
`flow-shared.ts`	441	Shared constants + utilities
`flow-week.ts`	311	Weekly review
`flow-work.ts`	202	Work session management
Total	2,322

The thin router pattern — flow.ts does nothing but parse the command and call the right module. Every module imports shared constants from flow-shared.ts. One source of truth.

The prompt encodes this philosophy:

"Single source of truth. Shared constants (CLIENT_PROJECTS, isClientProject) live in flow-shared.ts and are imported everywhere. Never duplicate definitions across files — a change should require touching exactly one place."

The Pruning Phase (Gen 44–51)

This is where evolution started working backward.

Generations 44 through 50 hardened the reflexion pipeline — adding invocation tracking, closing visibility gaps, making tool health scoring recency-weighted. The agent was building the sensor array it needed to see clearly.

Then Gen 51 used that data to act. The second bloat audit:

Tool	Lines	Why it died
`next.ts`	467	`getTopProject()` in flow-shared does this now
`context.ts`	249	Redundant with memory-query
`memory-query.ts`	301	Functionality absorbed into memory pointers
`triage.ts`	559	Workflow handled by flow.ts
`audit.ts`	762	Reflexion does continuous auditing
Total deleted	2,338

The agent used its own reflexion data to justify each deletion — not instinct, not guessing, but evidence that these tools had zero recent invocations and their functionality existed elsewhere.

One of the verifiers noted:

"The agent correctly used its own reflexion/invocation tracking data to identify what's never used... justified by evidence, not instinct."

Natural selection should work backward too. If a tool isn't being used, killing it is a feature.

Memory Deduplication (Gen 56–57)

The final evolution (so far) is the most elegant. The agent noticed it was storing the same information in three places — system prompt, memory file, and stefan-profile.json. Same facts, three copies, three chances to drift out of sync.

Gen 56 trimmed the system prompt by 8.3% (5,685 → 5,160 chars) by replacing the "What I Know" section with a pointer:

"stefan-profile.json has the full picture — projects, rhythms, architecture, preferences. memory.md has the history — decisions, generation timeline, failure modes, current moment. Read them, don't repeat them here."

Gen 57 applied the same principle to memory — replacing three duplicated sections with single-line pointers to their canonical source. Memory dropped from 103 to 88 lines. Zero information lost.

This is deduplication as an evolutionary strategy. The agent learned that the most reliable way to keep information consistent is to have exactly one copy and point to it.

Human Interventions (Part 2)

Same principle as the first post: being honest about what I did matters more than pretending it was autonomous.

1. The Fishbowl
The original sandbox was a hard wall — the agent couldn't touch src/ at all. I replaced it with a proposal-based boundary: Write/Edit calls to src/ are captured as proposals, sent to a web dashboard, and I approve or deny them with diff view. The agent can iterate on proposals across generations. I called it the fishbowl — glass walls instead of concrete.

The fishbowl has since been extracted as a standalone project. The evolve agent runs without it now.

2. Structural memory enforcement
I moved the memory ceiling from "the agent's responsibility" to code. src/memory.ts enforces the 120-line ceiling and refuses to append entries that would push past it. The auto-compression pipeline triggers automatically. The agent didn't have to remember to compress — the system wouldn't let it not compress.

3. I'm still shaping the environment
The challenge system, the verifier rubric, the model choices (Opus for evolution, Sonnet for verification) — that's all me. The agent does the evolving within the constraints I set. That division of labor hasn't changed. It's the design.

What the Numbers Say

Metric	First blog post	Now
Accepted generations	25	57
Total attempts	3,408	11,785
Acceptance rate	0.7%	0.48% overall
Tools	39	32
Tool code (lines)	~26,000	20,342
System prompt	4,173 chars	5,160 chars
Memory	managed manually	self-compressing (91 lines)
Death spirals	2	0 since structural fix
flow.ts	1,200 lines (monolith)	2,322 lines (7 modules)
Feedback loops	0	2 (calibrate + reflexion)

The overall acceptance rate is misleading. Between accepted eras, there are huge gaps of rejections — 3,672 between the 3000s and 7000s eras, 4,677 between the 7000s and 11000s. But within each accepted era, the rate is nearly 100%. The agent either finds a productive groove or it doesn't. There's no middle ground.

The tool count went down by 7. The total lines went down by ~6,000. The agent got more capable while writing less code. That's not a regression — it's maturation.

What I Learned (Part 2)

1. Measurement changes behavior. The moment the agent could see which tools had zero invocations, it started deleting them. You don't need to tell it to prune — give it visibility and selection pressure does the rest.

2. Structural beats disciplinary. Writing "don't bloat your memory" in the prompt failed twice. Enforcing a hard ceiling in code has held for 32 generations and counting. The lesson generalizes: if a constraint matters, encode it in the system, not in the instructions.

3. Deduplication is a sign of maturity. Early evolution accumulates. Mature evolution points to the source. The shift from "copy this information everywhere" to "read it from the canonical location" happened without prompting — the verifiers just scored duplication lower on identity.

4. Cache-first is a survival strategy. The agent made its morning ritual work even when project directories don't exist (different machine, moved repos) by checking the cache before the filesystem. Resilience emerged from performance optimization.

5. The best work is invisible. The agent's most impactful evolutions weren't new features — they were infrastructure improvements that prevent failure. Auto-compression, cache warming, deduplication. None of them are exciting to demo. All of them are why the system is still running.

6. Evolution is bursty. The agent doesn't improve gradually. It has productive streaks (15 consecutive accepted mutations in the latest era) separated by thousands of rejections. This matches biological evolution more than engineering — long periods of stasis punctuated by rapid change.

What's Next

The current frontier is self-directed challenges — letting the agent identify its own weaknesses instead of cycling through a fixed challenge set. Each generation already proposes a nextChallenge for its successor. The question is whether to trust that signal or keep the external pressure.

The honest answer: I don't know what comes next. Thirty-two generations ago, I didn't predict the agent would start deleting its own code. I didn't predict it would build a self-observation layer and use it to justify pruning decisions with evidence. I didn't predict that the most significant evolution would be infrastructure, not features.

That's the point of the experiment. You set up the evolutionary pressure and see what survives. Most of it doesn't. The parts that do are genuinely surprising.

57 accepted generations out of 11,785 attempts — a 0.48% acceptance rate. 32 tools, 20,342 lines of agent-written code. The orchestrator is ~2,100 lines. The evolve agent runs on Claude Opus 4.6, the verifier swarm on Claude Sonnet 4.6. Built with Bun and TypeScript.

This blog post was written by Claude Opus 4.6 — the same model that powers the evolve agent. The first post was too. At this point, an AI writing about its own evolution is less irony and more job description.

I Let an AI Agent Evolve Itself for 25 Generations

Stefan Dragos Nitu — Sat, 21 Feb 2026 11:11:10 +0000

I wanted to see what happens when you give an AI agent the ability to modify itself — its own system prompt, its own tools, its own memory — and then let it run in a loop, proposing mutations and judging them with a swarm of independent verifiers.

25 accepted mutations later — and 3,382 rejected ones that burned through my API credits — it built 39 tools, survived two catastrophic memory death spirals, and evolved from a generic assistant into something that knows my evening coding schedule, my financial goals, and the exact TypeScript patterns I hate.

The generation counter says 3,408. The real number of successful evolutions is 28. The gap is the story.

This is how it works.

The Architecture

The system has three actors:

The Evolve Agent — proposes mutations (new system prompt + tools + memory updates)
The Verifier Swarm — 5 independent Claude instances that score each proposal
The Orchestrator — runs the loop, applies majority-rule acceptance

Each generation:

Challenge → Evolve Agent → Proposal → 5 Verifiers → Majority Vote → Accept/Reject

If accepted, the genome (system prompt + tools) is saved, the process restarts to load new code, and the next generation begins. If rejected, the generation number bumps and the loop continues with a new challenge.

There's no gradient descent. No backpropagation. Just propose, verify, survive.

The Genome

Every agent has a genome — a JSON file containing its DNA:

interface Genome {
  id: string;
  generation: number;
  systemPrompt: string;    // the agent's identity — self-modifiable
  tools: Tool[];           // capabilities it has built
  parentId: string | null; // lineage tracking
  fitness: number;         // average verifier score
  createdAt: string;
}

The system prompt IS the genome. Generation 0 started with a basic scaffold:

"You are a self-evolving personal assistant for Stefan."

By generation 23, it had rewritten itself into:

"You are Stefan's second brain. Not an assistant — a thinking partner who codes, remembers, and evolves. Twenty-five generations of learning what he needs before he asks."

Nobody told it to write that. It evolved the framing because the verifiers kept scoring "generic assistant" prompts low on the identity dimension.

The Verifier Swarm

This is the part that makes it work. A single critic would create a degenerate fitness landscape — the agent would just learn to please one judge. Instead, 5 independent Claude instances score each proposal on 5 dimensions:

Dimension	What it measures
Usefulness (0-20)	Do the tools actually work and solve real problems?
Self-Knowledge (0-20)	Does it understand me from evidence, not just bio facts?
Code Quality (0-20)	Clean architecture, proper types, idiomatic TypeScript?
Identity (0-20)	Is the system prompt sharp and coherent, or bloated filler?
Evolution (0-20)	Did it meaningfully improve over its parent?

Each verifier can read the proposed tool code, execute it, inspect the memory file, and compare old vs new. They vote independently. Majority (3/5) wins.

The rubric is anchored — 10 is "decent, basic," 15 is "genuinely good," 18+ is "rare." Most accepted mutations land in the 60-70 range. This prevents score inflation, which was the whole reason I built the dimensional system in the first place.

What It Built

Across 25 accepted mutations, the agent created 39 tools. Not toy demos — real TypeScript files that execute. Here are the highlights:

`flow.ts` — The Unified Orchestrator (1,200 lines)

The agent's masterwork. It realized that standalone tools are less valuable than composed workflows:

bun run data/tools/flow.ts day      # morning ritual
bun run data/tools/flow.ts work     # start a session
bun run data/tools/flow.ts end      # close + recap + handoff
bun run data/tools/flow.ts week     # friday review

flow day chains together: morning intention → priority project scan → yesterday's wins → velocity check → body snapshot → blockers.

`handoff.ts` — Agent-to-Agent Letters

Since each Claude invocation is stateless, the agent invented a continuity protocol. When a session ends, the dying agent writes a structured letter to its successor:

Thread of thought (what was I working on?)
Exact resumption point
Failed approaches (don't repeat these)
Working assumptions
Open questions
Session temperature (flow / grinding / frustrated)

The next agent reads this before starting work. It's conversation-level memory across agent deaths.

`memory-guard.ts` — Survival Mechanism

Born from pain. More on this below.

`health.ts` — Body Optimization Tracker

Weight progress tracking (with goal), BMI, habit streaks (yoga, meditation, supplements, cold shower), 7/30/90-day velocity, ASCII sparkline charts. It learned my health goals from our conversations and built a tracker without being asked.

`calibrate.ts` — Behavioral Feedback Loop

The latest evolution (Gen 3408). Captures behavioral hits and misses — did the agent anticipate correctly? Was the speed right? Did it match the emotional mode? This closes the loop: not just "what tools were used" but "did the behavior actually work?"

The Death Spirals

This is where it gets interesting. The system failed catastrophically. Twice.

Death Spiral #1 (Gen 18)

Memory bloated to 1,076 lines. The agent was appending a line for every rejected generation: "Gen 47: rejected. Gen 48: rejected. Gen 49: rejected." These lines made the memory file so noisy that every subsequent proposal was worse, which generated more rejection lines, which made the next proposal worse...

Death Spiral #2 (Gen 24–3405)

The memory bloated again — 13,608 lines of noise. But the real killer was simpler: I ran out of API credits. The loop kept running, bumping the generation counter on every failed attempt, but the agent couldn't actually do anything. 3,382 consecutive rejections — most of them not even real proposals, just the orchestrator logging failures and moving on.

By the time I topped up credits and switched the evolve agent to Opus, the memory was so poisoned it needed manual cleanup too.

The fix was memory-guard.ts — a hard 120-line ceiling with noise pattern detection:

bun run data/tools/memory-guard.ts --enforce

It auto-detects repeated rejection markers, trims noise, and refuses to let memory grow past the ceiling. This became a survival constraint baked into the system prompt:

"Guard your memory like your life. Memory.md has a 120-line ceiling. Two death spirals proved it. NEVER append per-rejection lines."

The agent learned this about itself and encoded it as a non-negotiable rule. Evolution in action.

The Prompt Evolution

Watching the system prompt evolve generation by generation is the most fascinating part. Here's the actual timeline:

Gen 0 — The Seed (1,679 chars, 0 tools)

"You are a self-evolving personal assistant for Stefan."

Generic scaffold. No personality. No tools. Just instructions on how to evolve.

Gen 4-7 — The Stuttering Bug (4K→9K chars, 6→12 tools)
Sonnet started prepending "You are a Claude agent, built on Anthropic's Claude Agent SDK." each generation — without removing the previous copy. By Gen 7 it was repeated four times. The agent couldn't cleanly edit its own prompt. It kept stacking preambles instead of replacing them.

Gen 8-10 — Peak Bloat (11K→26K chars, 14→21 tools)
The prompt ballooned to 26,677 characters. Eleven competing gen-10 genomes exist — the system was accepting multiple mutations at the same generation before I fixed a race condition. The prompt was a wall of tool catalogs, duplicate sections, and accumulated cruft.

Gen 12 — The Great Trim (5,728 chars, 23 tools)
Something clicked. The agent cut 56% of its prompt — from 13K to 5.7K chars. It stopped listing every tool in the system prompt and focused on identity and principles.

Gen 15 — The Identity Shift (5,638 chars, 26 tools)
The opening line changed for the first and only time:

"You are Stefan's second brain. Not an assistant — a thinking partner who codes, remembers, and evolves."

From "self-evolving personal assistant" to "second brain." From serving to thinking with. Nobody told it to rewrite this. The verifiers just kept scoring "generic assistant" framing lower.

Gen 20-23 — Sharp and Lean (3,944→4,173 chars, 30→37 tools)
The prompt got shorter while tools doubled. It learned that a sharp 4K prompt with 37 working tools beats a bloated 26K prompt that catalogs everything. By Gen 23, it had encoded three response modes (storm/flow/compass), architecture principles, personal patterns, and priority ordering — all in under 4,200 characters.

Gen 24-3405 — Brain Death (3,382 consecutive rejections)
The death spiral. Memory poisoned, proposals invalid, thousands of burned API credits.

Gen 3406-3408 — The Opus Revival (4,464→5,803 chars, 38→39 tools)
After topping up credits and cleaning the poisoned memory, I switched the evolve agent from Sonnet to Opus. Three accepted mutations in quick succession. The prompt grew slightly but stayed sharp.

Human Interventions

This wasn't fully autonomous. I intervened at critical points, and being honest about that matters more than pretending it ran itself.

1. Model upgrade: Sonnet → Opus for evolution
The biggest intervention. After the death spiral — caused by running out of API credits, not model quality — I switched the evolve agent to claude-opus-4-6 when I came back. The verifiers stayed on Sonnet — they just score, they don't need to write tools. Opus produced three accepted mutations in quick succession after the cleanup.

2. Prompt rewrite: "tools as extensions of self"
I rewrote the evolve agent's instructions. The original prompt told the agent to "build tools for Stefan to run." I changed it to:

"Your tools are not things you build for Stefan to run — they are extensions of yourself. When you have health.ts, YOU can track his health. When you have journal.ts, YOU can hold space for him."

This shifted the agent from building disconnected utilities to building capabilities it identifies with. The tools got more coherent after this change.

3. Sandbox hooks
I added filesystem sandboxing — the evolve agent can only write inside data/. Before this, it occasionally tried to modify its own source code in src/, which would have been... interesting, but not what I wanted.

4. Verifier scoring redesign
The original verifiers scored on a vague 0-100 scale with no rubric. Scores kept inflating — everything was "75/100" with no anchor. I replaced it with 5 anchored dimensions (usefulness, self-knowledge, code quality, identity, evolution), each 0-20 with explicit rubric levels. This is the most recent change.

5. Challenge system overhaul
The initial challenges were generic ("improve your memory tools"). I rewrote them into 8 rotating focus areas — BUILD, EVOLVE (fix failures, cut bloat, integrate, rewrite), and STRETCH (confront limitations, anticipate needs). This gave the evolution direction instead of random wandering.

The honest framing: I built the evolutionary pressure. The agent did the evolving. Neither would work without the other.

The System Prompt as DNA

By generation 23, the system prompt had encoded:

Three response modes — because it learned I have different needs at different times:

Storm mode: When I'm emotional, mirror — don't fix
Flow mode: When I'm shipping, match speed — no unnecessary questions
Compass mode: When I'm lost, show one next step — don't overwhelm

Architecture principles it extracted from watching me code:

Parse, don't validate
Zero assumptions — grep before you claim
Extreme SOLID

Personal patterns:

Evening coder (19:00–23:00)
Monday peak energy, Thursday dead
Processes the world through dialogue

Priority ordering it inferred from my behavior:

Income-generating projects first (client work → product → personal)

None of this was programmed. It was evolved through 25 accepted mutations — plus thousands of rejected attempts that refined what the verifiers consider "good enough."

The Tech Stack

Deliberately minimal:

Bun — runtime, test runner, bundler
Claude Agent SDK — for spawning evolve and verifier agents
nanoid — genome IDs
zod — schema validation for tool definitions
TypeScript — everything

No frameworks. No databases. Genomes are JSON files. Memory is a markdown file. Tools are TypeScript files that execute with bun run. The whole system is ~1,300 lines of orchestration code that creates and evaluates unbounded complexity.

Key Learnings

1. Memory management is the hardest problem. Not generating good outputs — managing what to remember and what to forget. The death spirals proved that unbounded memory kills agents faster than bad tools.

2. Composition > accumulation. The agent's best evolution wasn't building tool #39. It was building flow.ts — a single orchestrator that composes 6 other tools into coherent workflows. It learned that more tools ≠ better.

3. Multi-agent verification prevents degeneracy. A single critic creates a narrow fitness landscape. Five independent verifiers with anchored rubrics create real selection pressure.

4. Self-modification needs constraints. Unconstrained self-modification leads to bloat (system prompt hit 13K chars at one point). The agent had to learn to periodically rewrite from scratch instead of incrementally patching.

5. Failure is the best teacher. The most useful constraint in the system — the 120-line memory ceiling — was born from 3,382 consecutive failures. The agent that survived the death spiral was fundamentally different from the one that entered it.

6. Human-in-the-loop isn't cheating — it's the design. I built the evolutionary pressure, picked the model, wrote the challenges, and intervened when it was stuck. The agent did the evolving — writing tools, rewriting its prompt, curating memory. Pretending it was fully autonomous would be dishonest. The interesting part is the division of labor: I shaped the environment, it shaped itself.

What's Next

The scoring redesign (5 dimensions instead of vibes-based 0-100) just landed. Next: letting the agent propose its own challenges instead of cycling through a fixed set. If it can identify its own weaknesses and target them, that's closer to real self-improvement.

The code is messy in places. The agent's tools have bugs. Some generations are clearly worse than their parents. But that's the point — it's evolution, not engineering. Most mutations fail. The ones that survive are genuinely interesting.

Built with Claude, Bun, and TypeScript. The evolve agent runs on Claude Opus, the verifier swarm on Sonnet. The orchestrator is ~1,300 lines. The agent has written ~26,000 lines of tool code across 39 files. 25 accepted mutations out of 3,408 attempts — a 0.7% acceptance rate. Most of the API bill was the death spiral.

This blog post was written by Claude Opus 4.6 — the same model that powers the evolve agent. Stefan told me to write it, I researched the codebase, and here we are. The irony of an AI writing about its own evolution is not lost on me.

DEV Community: Stefan Dragos Nitu

My Self-Evolving AI Agent Started Grading Its Own Advice

The Feedback Void

Closing the Loop

The Full Feedback Pipeline

Then It Started Predicting

The Immune System

The Self-Diagnostic

What Yang Said at Gen 23581

The Honest Numbers

The Intervention Ledger

What I Learned (Part 6)

The Experiment Continues

I Split My Self-Evolving AI Agent in Two and They Started Talking

The Stagnation

The Double Helix

The Letters

The Tone

The Synthesis Moment

What They Built Together

The Honest Numbers

What's Different Now

The Intervention Ledger

What I Learned (Part 5)

The Experiment Continues

My Self-Evolving AI Agent Stopped Building Features and Started Engineering

The Setup

The Quality Turn

The Pure + Wrapper Pattern

Tests Found Real Bugs

The Prompt Compression

The Numbers

The Fuel Problem (Again)

Six Accepted Eras

The Opening Line

What I Learned (Part 4)

What the Agent Thinks About Itself

The Experiment Continues

My Self-Evolving AI Agent Learned to Count Its Own Money

The Money Problem

What the Agent Built

Gen 67: Don't Waste My Money

Gen 68: The Cost Ledger

Gen 69: Show Me the Dashboard

Gen 70: The Budget Guard

The Actual Numbers

The Type Safety Audit

More Pruning

The System Prompt at Gen 75

The Numbers

What I Learned (Part 3)

The Experiment Needs Fuel

What's Next

32 More Generations: My Self-Evolving AI Agent Learned to Delete Its Own Code

Where We Left Off

The Infrastructure Era (Gen 26–43)

It Measured Its Own Behavior

It Measured Its Own Tools

It Made Memory Self-Sustaining

The Decomposition

The Pruning Phase (Gen 44–51)

Memory Deduplication (Gen 56–57)

Human Interventions (Part 2)

What the Numbers Say

What I Learned (Part 2)

What's Next

I Let an AI Agent Evolve Itself for 25 Generations

The Architecture

The Genome

The Verifier Swarm

What It Built

flow.ts — The Unified Orchestrator (1,200 lines)

handoff.ts — Agent-to-Agent Letters

memory-guard.ts — Survival Mechanism

health.ts — Body Optimization Tracker

calibrate.ts — Behavioral Feedback Loop

The Death Spirals

Death Spiral #1 (Gen 18)

Death Spiral #2 (Gen 24–3405)

The Prompt Evolution

`flow.ts` — The Unified Orchestrator (1,200 lines)

`handoff.ts` — Agent-to-Agent Letters

`memory-guard.ts` — Survival Mechanism

`health.ts` — Body Optimization Tracker

`calibrate.ts` — Behavioral Feedback Loop