Forem: Daniel Nwaneri

I Ran My Own SEO Agent on My Two Domains — It Went from 0/4 to 4/4 PASS in One Afternoon

Daniel Nwaneri — Tue, 07 Apr 2026 15:12:57 +0000

invoice.naija-vpn.com was serving the Carter Efe $50K/month Twitch story as its meta description. That page is an invoice generator tool for Nigerian freelancers. Nothing about it has anything to do with Carter Efe.

The agent caught it on the first run. A scraper wouldn't have — it reads raw HTML before JavaScript executes. The agent uses Playwright, reads the rendered DOM, sees what a browser sees after all the scripts run. The homepage content was leaking in dynamically. The scraper sees an empty description. The agent sees the actual problem.

I own both domains — naija-vpn.com and naijavpn.com, a Virtual Payment Navigator for Nigerian freelancers and creators. I ran the agent on my own sites to see what it would find.

What the agent found

Four URLs. Four FAILs.

URL	Title	Description	Overall
naija-vpn.com/	FAIL — 65 chars	FAIL — 185 chars	FAIL
naijavpn.com/	FAIL — 66 chars	FAIL — 192 chars	FAIL
/cleva-vs-geegpay	FAIL — 63 chars	PASS	FAIL
invoice.naija-vpn.com	FAIL — no page-specific meta	FAIL — no page-specific meta	FAIL

The homepage title was NaijaVPN - Virtual Payment Navigator for Nigerian Freelancers — 65 characters when the display limit is 60. The description was 185 characters when the limit is 160.

The invoice.naija-vpn.com subdomain was the worst finding. It's a separate subdomain — Google treats it as its own site — but it had no page-specific metadata at all. The agent was reading Carter Efe makes $50K/month from Twitch — here's how he gets paid in Nigeria... as the meta description for an invoice generator tool. The subdomain is a React SPA and the static HTML <head> had no <meta name="description"> tag. Homepage content was leaking in dynamically after JavaScript executed.

A requests-based scraper would have missed this entirely. It reads the raw HTML before JavaScript executes and would have seen an empty description, not the leaking homepage copy. The agent uses Playwright — it reads the rendered DOM, the same page a browser sees after all the scripts run. That's the difference.

The cost curve routing on real pages

The audit ran in tiered mode. Here's what the routing looked like:

naija-vpn.com/ → Tier 1 — deterministic, zero API cost
naijavpn.com/ → Tier 1 — canonical pointing correctly to naija-vpn.com, clean
/cleva-vs-geegpay → Tier 1 — clear structure, no escalation needed
invoice.naija-vpn.com → Tier 2 (Haiku) — title on the boundary, needed a closer look

Three tiers, four pages, one run. Total API cost for the audit: under $0.05.

What I actually changed

The rewrite agent ran next — same cost curve applied to the suggestions. Tier 1 truncated the titles deterministically. Haiku generated description suggestions. Sonnet wrote the voice-matched copy for the invoice subdomain opening paragraph.

Three changes I deployed:

Homepage title: NaijaVPN - Get Paid Internationally in Nigeria — 46 characters. Cut the bloat, kept the value proposition.

Homepage description: Trimmed from 185 to 156 characters. The agent's suggestion preserved the Carter Efe reference — that's the hook that makes people click — but cut everything that was padding.

invoice.naija-vpn.com: Added a proper <meta name="description"> to the static HTML <head> of the React SPA — the fix lives in index.html, not in the JavaScript. One line of HTML. The agent's suggested copy: "Generate professional invoices instantly. Receive international payments in Nigeria with Geegpay, Payoneer and Cleva. Free invoice tool for Nigerian freelancers." — 158 characters, PASS.

The verification run

Reset state. Re-ran the audit.

URL	Title	Description	Tier	Overall
naija-vpn.com/	PASS — 46 chars	PASS — 156 chars	Tier 1	PASS
naijavpn.com/	PASS — 46 chars	PASS — 156 chars	Tier 1	PASS
/cleva-vs-geegpay	PASS — 52 chars	PASS — 156 chars	Tier 1	PASS
invoice.naija-vpn.com	PASS — 50 chars	PASS — 149 chars	Tier 2	PASS

4/4. Zero flags.

The verification run hit Tier 1 on every page — pure deterministic Python, zero API calls. That's the cost curve completing its own argument: the first run used Haiku and Sonnet because the issues were ambiguous enough to need judgment. The verification run used nothing because the fixes were mechanical and the checks are mechanical. The model cost dropped to zero not because the run was cheaper, but because the problems were gone.

The finding that mattered most

The invoice.naija-vpn.com subdomain inheriting homepage metadata is a serious SEO problem. Google treats subdomains as separate sites — so this wasn't "duplicate metadata on the same site." It was a standalone subdomain with no metadata of its own, rendering the homepage's Carter Efe story as the description for an invoice tool.

The agent caught it because it reads the rendered DOM. A scraper reads raw HTML — it would have seen an empty description and flagged the absence, not the leak. The agent saw what a real browser sees: the homepage content dynamically injected after JavaScript executed.

The agent found it automatically, on the first run, and proposed a fix.

That's the actual value. Not the character counts. The automated surface of a problem that was invisible to a quick look at the page.

Two full audit passes plus the rewrite run: under $0.15 total. Four pages, three runs, one afternoon.

The free core at dannwaneri/seo-agent handles the audit and the basic report. The PDF with per-page screenshots, severity-sorted issues, and the rewrite suggestions are in the Pro layer. The cost curve runs in both.

I Was Paying $0.006 Per URL for SEO Audits Until I Realized Most Needed $0

Daniel Nwaneri — Fri, 03 Apr 2026 14:24:02 +0000

Pascal CESCATO read my SEO audit agent piece and left this in the comments:

"You don't need an LLM for this. Everything you're sending to Claude can be done directly in Python — zero cost, fully deterministic, no hallucination risk."

He was right. And wrong. And the conversation that followed is the reason I rebuilt the entire thing.

What Pascal Actually Said

The audit agent I published checks title length, meta description length, H1 count, and canonical tags. Pascal's point: those are character counts and presence checks. A regex does that. You don't pay $0.006 per URL for a regex.

I pushed back. The flags array requires judgment — "title reads like a navigation label rather than a page description" isn't a character count. Pascal conceded, then reframed:

"Two-pass makes more sense. Deterministic Python for binary checks, model call only on pages that pass the mechanical audit but need a second look. You pay per genuinely ambiguous case, not per URL."

That's a better architecture than what I shipped. I said so publicly.

Then Julian Oczkowski extended it:

"Deterministic rules first, lightweight models for triage, larger models reserved for genuinely ambiguous edge cases. Keeps latency low, costs predictable, reduces unnecessary LLM dependency."

Three people in a comment thread had just designed something I hadn't thought to name. Pascal called it two-pass. Julian called it tiered. I called it the cost curve — a sliding scale from free to expensive, routed by what the task actually requires.

The Cost Curve

Tier 1 — Deterministic Python. Cost: $0.
Title >60 characters? FAIL. Description missing? FAIL. H1 count == 0? FAIL. These are not judgment calls. A model that can reason about Shakespeare does not need to be invoked to count to 60.

Tier 2 — Haiku. Cost: ~$0.0001 per URL.
Title present but 4 characters long. Description present but 30 characters. Status code is a redirect. These pass the mechanical audit but something is off. Haiku is cheap enough that calling it for ambiguous cases costs less than the time you'd spend debugging why the deterministic check missed something.

Tier 3 — Sonnet. Cost: ~$0.006 per URL.
Pages Haiku flags as needing semantic judgment. "This title passes length but reads like a navigation label." "This description duplicates the title verbatim." Sonnet earns its cost here. Not everywhere.

The insight is routing. Most pages on a typical agency site have mechanical issues — missing descriptions, long titles, no canonical. Those never need a model. The interesting cases — pages that pass every binary check but still feel wrong — are where the model earns its place.

On my last run of 50 URLs, 8 reached Sonnet. The rest resolved at Tier 1. Total cost dropped from ~$0.30 to ~$0.05. The 8 that hit Sonnet were the ones worth paying for.

What I Actually Built

I restructured the entire repo around this architecture.

core/ stays flat and MIT licensed. The original seven modules untouched. Anyone who cloned v1 still runs python core/index.py and gets identical behavior.

premium/ adds four modules. cost_curve.py handles the tier routing — audit_url(snapshot, tiered=True) runs Tier 1 first, escalates to Haiku if something fails, escalates to Sonnet only if Haiku flags semantic ambiguity. multi_client.py manages project folders — --project acme reads and writes from projects/acme/ with isolated state, input, and reports. enhanced_reporter.py generates WeasyPrint PDFs with per-URL screenshots, issues sorted by severity, and suggested fixes. rewrite_agent.py is the one Pascal didn't anticipate — after the audit, --rewrite generates improvement suggestions using the same cost curve: Tier 1 truncates titles deterministically, Haiku writes meta description suggestions, Sonnet rewrites opening paragraphs. Pass --voice-sample ./my-writing.txt and the prompt includes a sample of your writing. The suggestions sound like you, not like Claude.

main.py is the unified entry point. Free users run python main.py and get v1 behavior. Pro users add --pro, set SEO_AGENT_LICENSE, unlock the premium layer.

A full pro run looks like this:

python main.py --project client-x --pro --tiered --rewrite

That single command: reads from projects/client-x/input.csv, routes every URL through the cost curve, generates rewrite suggestions for failing pages, writes a PDF report with screenshots and severity levels, and appends a run record to the audit history.

The Architecture Decision That Matters

core/ imports nothing from premium/. Ever.

This isn't just clean code. It's a trust contract with anyone who forks the repo. The MIT-licensed core is the public good — auditable, forkable, accepts PRs. The premium layer is proprietary and closed, but it builds on a foundation anyone can inspect.

Mads Hansen in the comments named the right question: how do you prevent the auditor from developing blind spots on recurring patterns? The answer I didn't have then: run history in state.json. Each completed run appends a record — timestamps, pass counts, fail counts, report path. Over time, "this page has failed description length for six consecutive runs" is a different signal than "this page failed today." The audit becomes a monitor. Not just a snapshot.

What the Comment Thread Cost

Nothing. And produced a better architecture than I would have built alone.

Pascal's pushback separated the deterministic from the semantic. Julian's production framing gave me the three-tier structure. Apex Stack's 89K-page site showed me where the orphan detection problem lives. Mads Hansen named the blind spot question I hadn't asked.

None of that was in the original article. All of it is in the repo now.

The public comment thread is the architecture review I didn't schedule. That's what happens when you publish the honest version — the demo that fails on your own content — instead of the staged one.

The staged demo would have passed. The honest one compounded.

Full repo: dannwaneri/seo-agent. Core is MIT. Premium requires a license key. The freeCodeCamp tutorial covers the v1 build in detail: How to Build a Local SEO Audit Agent with Browser Use and Claude API.

Agents Don't Just Do Unauthorized Things. They Cause Humans to Do Unauthorized Things.

Daniel Nwaneri — Mon, 30 Mar 2026 14:36:52 +0000

A comment thread shouldn't produce original research. This one did.

Last week I published a piece about agent governance — the gap between what an agent is authorized to do and what it effectively becomes authorized to do through accumulated actions. I used a quant fund analogy: five independent strategies, each within its own risk limits, collectively overweight the same sector. No single decision was wrong. The aggregate outcome was unauthorized.

The comment section built something I hadn't anticipated.

Kalpaka,Vic Chen, Andre Cytryn, Stephen Lee, and Connor Gallic spent three days extending the argument in directions I hadn't gone. What follows is an attempt to assemble what they built — with attribution, because the thread earned it.

The Unit Problem

The first thing Kalpaka named was the hardest: what do you measure?

Actions taken is too noisy. Resources touched is closer but misses compounding. The unit that matters, they argued, is state delta — the diff between what the system could affect before and after a given action sequence.

A vendor approval doesn't just place an order. It creates a supply chain dependency. A database read doesn't just return rows. It establishes an access pattern the agent now relies on.

So the audit object isn't an action log. It's a capability graph — resources and permissions as nodes, actually-exercised access paths as edges. Reconciliation compares the declared graph against the exercised one. The delta is your behavioral exposure.

This is the frame that makes the quant fund analogy precise rather than decorative. A 13F filing is exactly this: a reconciliation between declared strategy and actual exposure, anchored to external cadence rather than internal computation speed. The quarterly filing forces the moment when someone has to look at the full graph, not just the individual positions.

Two Kinds of Edges

The capability graph has a shape problem I hadn't considered.

Direct edges are legible. The agent called the database, touched the file, invoked the API. These edges can be tracked. They decay naturally — an access pattern not exercised in N reconciliation cycles can be pruned. The agent hasn't used that path, so it drops from the exercised graph.

Induced edges are different. These are the edges created when an agent's output causes a human to take an action the agent itself didn't take. The Meta Sev 1 incident last week is the exact pattern: the agent didn't write anything unauthorized. It gave advice that caused an engineer to widen access. The exposure persisted for two hours. The agent's direct action log showed nothing unusual.

Induced edges don't decay the same way direct edges do. The human decision the agent caused doesn't un-happen when the agent stops referencing it. The widened access persists independently of the agent's continued activity. These edges have a much longer half-life — effectively permanent until someone explicitly reconciles them.

This is where the governance architecture splits. Direct edges decay on a usage clock. Induced edges require active reconciliation. The first can be automated. The second can't — which is exactly where the 13F analogy holds strongest. Quarterly isn't a technical choice. It's a regulatory one. Someone external decided that interval was often enough for fund positions. Agent capability graphs need the same external anchor.

The Irreversibility Problem

Andre Cytryn raised threshold drift: you calibrate materiality at deployment time, but the agent's decision space expands with use.

The per-strategy limits in the fund example weren't wrong at design time. They were wrong at failure time because the correlation structure changed. Continuous recalibration is the obvious fix. But continuous recalibration creates its own attack surface — a mechanism the agent can game structurally, not intentionally. Enough accumulated decisions that each looks within tolerance can shift the calibration baseline until the new thresholds permit what the original thresholds wouldn't.

The only way out Kalpaka identified: decouple recalibration authority from the agent's own execution context entirely. Thresholds reviewed by something with no stake in the agent's performance.

This requires knowing which actions are irreversible — but irreversibility is often only visible in retrospect. The Meta incident proves it. Nobody flagged the permission-widening action as irreversible-scope-changing while it was happening. The agent's advice looked like a routine technical suggestion. The irreversibility was only visible after the state had already changed.

Kalpatha's resolution was to invert the default assumption. Don't try to classify irreversibility upfront. Treat every induced edge as irreversible. Over-reconcile first, and let the reconciliation history generate the labeled data you need to build the upstream classifier later.

This is how financial compliance actually bootstrapped. Early fund compliance didn't start with sophisticated materiality filters. They reconciled everything quarterly and learned which position changes were material through decades of accumulated review history. The filters came from the data. The data came from over-reconciling.

We're in the over-reconcile phase. Expensive, noisy, generates false positives. But it's the only way to produce the labeled examples that make the classifier possible later. Trying to solve the detection problem at inception is trying to skip the generation of training data.

The Fatigue Problem

Over-reconciling creates a human cost. Every flagged induced state change needs a review decision. Volume in early cycles will be high by design.

The compliance history the 13F analogy draws on has a second chapter nobody likes to mention: the review process degrades under load. Humans start rubber-stamping. False positives stop being caught. The labeled data gets noisy before the classifier can be trained on it.

Kalpaka's answer was adaptive rather than prescribed: track reviewer consistency over time. Same reviewer, same flag type — does the approval rate shift as volume increases? That's your fatigue signal. Once you can detect it, you don't need a hard cap. You have evidence-based throttling.

The auditor rotation parallel holds here too. Financial auditors rotate precisely because of this problem. Fresh eyes are the simplest fatigue mitigation. The question for agent behavioral review is whether there are enough qualified reviewers to rotate through.

That's harder than it sounds. Financial auditors share a professional vocabulary — they all know what material means, what a restatement implies, what a concentration risk looks like. That shared language is what makes fresh eyes useful. Agent behavioral accounting doesn't have that vocabulary yet. The capability graph framing this thread built is an attempt to construct it. Until reviewers have a shared framework for what "consequential scope change" looks like in practice, rotating fresh eyes doesn't transfer the same way.

The qualified reviewer problem might be the bootstrapping constraint underneath the bootstrapping constraint.

The Enforcement Floor

Connor Gallic brought the piece back to earth.

Theory is one thing. What teams actually ship is another. The simplest version of enforcement is a write checkpoint: every agent action that changes state passes through a policy evaluation before it executes. Not token monitoring, not post-hoc audit. A deterministic gate between intent and action.

The aggregate authorization problem gets simpler when you centralize that policy layer. If every agent's writes flow through the same checkpoint, cross-agent scope becomes visible — because the governance layer has the view that individual agents don't.

The 13F analogy works because quarterly filings are boring, reliable, and externally anchored. Agent governance needs the same properties. The hard part isn't the theory. It's making enforcement boring enough that teams actually ship it.

The write checkpoint wins on that dimension. It's implementable today. It handles direct scope violations cleanly. It's the enforcement floor.

The capability graph is the ceiling. It handles induced state changes, threshold drift, cross-agent composition. It's more expensive, harder to build, requires the vocabulary that doesn't fully exist yet. It's also necessary for complete governance.

The right architecture is probably layered: checkpoint as the floor that catches direct violations cheaply, capability graph as the audit layer that catches induced drift over time. You ship the checkpoint first because it's boring enough to actually build. You develop the capability graph because the checkpoint leaves a class of failures uncovered.

What the Thread Built

None of this was in the original piece.

The two-clock distinction was there. The 13F analogy was there. The governance debt framing was there.

The capability graph, the direct/induced edge split, the over-reconcile bootstrap, the adaptive fatigue ceiling, the layered enforcement architecture — those came from Kalpaka, Andre, Vic, Stephen, and Connor over three days in a comment section.

That's worth naming directly. Not as a courtesy, but because it demonstrates the problem Foundation is designed to solve. This conversation happened in public, in a thread that will eventually scroll off everyone's feed, attributed to usernames rather than preserved as structured knowledge. The architecture it built is worth more than that.

The agent governance problem doesn't have a consensus solution yet. What it has is a comment thread that got further than most papers. The qualified reviewer problem is still open. The capability graph needs implementation. The adaptive ceiling needs tooling.

But the vocabulary exists now. That's what the thread produced. And vocabulary, as someone wiser than me wrote recently, turns vague frustration into specific, solvable problems.

The original piece: Your Agent Is Making Decisions Nobody Authorized

I Built a Local AI Agent That Audits My Own Articles. It Flagged Every Single One.

Daniel Nwaneri — Mon, 30 Mar 2026 14:33:56 +0000

Not as a gotcha. As a result.

Seven URLs. Seven FAILs.

My Hashnode profile is missing an H1. Three freeCodeCamp tutorials have meta descriptions that are either missing or over 160 characters. Two DEV.to articles have titles too long for Google to render cleanly.

I built the agent. I ran it on my own content first. That's the honest version of the demo.

The problem I was actually solving

Every digital marketing agency has someone whose job is basically this: open a spreadsheet, visit each client URL, check the title tag, check the description, check the H1, note broken links, paste everything into a report. Repeat weekly.

That person costs money. The work is deterministic. The only reason it's still manual is that nobody built the alternative.

I built it in a weekend.

The stack

Browser Use — Python-native browser automation. The agent navigates real pages in a visible Chromium window. Not a headless scraper. Persistent sessions, real rendering, the same page a human would see.
Claude API (Sonnet) — reads the page snapshot and returns structured JSON: title status, description status, H1 count, canonical tag, flags. One API call per URL.
httpx — async HEAD requests for broken link detection. Capped at 50 links per page, concurrent, 5-second timeout per request.
Flat JSON files — state.json tracks what's been audited. Interrupt mid-run, restart, it picks up exactly where it stopped. No database needed.

Seven Python files. 956 lines total. Runs on a Windows laptop.

The part most tutorials skip: HITL

The agent hits a login wall. Throws an exception. Run dies.

That's most automation tutorials.

This one doesn't work that way.

When the agent detects a non-200 status, a redirect to a login page, or a title containing "sign in" or "access denied", it pauses. In interactive mode: skip, retry, or quit. In --auto mode it skips automatically, logs the URL to needs_human[] in state, and continues.

An agent that knows its limits is more useful than one that fails silently. That's the design decision most people don't make because tutorials don't cover it.

What the audit actually found

I ran it against my own published content across three platforms:

URL	Failing fields
hashnode.com/@dannwaneri	H1 missing
freeCodeCamp — how-to-build-your-own-claude-code-skill	Meta description
freeCodeCamp — how-to-stop-letting-ai-agents-guess	Meta description
freeCodeCamp — build-a-production-rag-system	Title + meta description
freeCodeCamp — author/dannwaneri	Meta description
dev.to — the-gatekeeping-panic	Title too long
dev.to — i-built-a-production-rag-system	Title too long

The freeCodeCamp description issues are partly platform-level — freeCodeCamp controls the template and sometimes truncates or omits meta descriptions. The DEV.to title issues are mine. Article titles that read well as headlines often exceed 60 characters in the <title> tag.

The agent didn't care. It checked the standard and reported the result.

The schedule play

python index.py --auto

Add a .bat file that sets the API key and calls that command. Schedule it in Windows Task Scheduler for Monday 7am. Check report-summary.txt with your coffee.

That's the agency workflow. No babysitting. Edge cases in needs_human[] for human review. Everything else processed and reported automatically.

What this actually costs

One Sonnet API call per URL. Roughly $0.002 per page. A 20-URL weekly audit costs less than $0.05. The Playwright browser runs locally — no cloud browser fees, no Browserbase subscription.

The whole thing runs on a $5/month philosophy. Same one I use for everything else.

The code

GitHub: dannwaneri/seo-agent

Clone it, add your URLs to input.csv, set ANTHROPIC_API_KEY in your environment, run pip install -r requirements.txt, run playwright install chromium, then python index.py.

The freeCodeCamp tutorial walks through each module — browser integration, the Claude extraction prompt, the async link checker, the HITL logic. Link in the comments when it's live.

The shift worth naming

Browser automation has been a developer tool for a decade. Playwright, Selenium, Puppeteer — all powerful, all requiring someone to write and maintain selectors. The moment a button's class name changes, the script breaks.

This agent doesn't use selectors. It reads the page the way Claude reads it — semantically, through the accessibility tree. A "Submit" button is still a "Submit" button even if the CSS class changed.

The extraction logic is in the prompt, not in the code.

Old way: Automation breaks when the page changes.

New way: Reasoning adapts. The code doesn't need to.

That's the actual shift. Not "AI does the work" but "the brittleness moved." From selectors to prompts. From maintenance to reasoning. The failure modes are different. So is the recovery.

Built this as the first in a series on practical local AI agent setups for agency operations. The freeCodeCamp step-by-step tutorial is coming. Repo is live now.

Imposter Syndrome Didn't Go Away. It Got Quieter.

Daniel Nwaneri — Thu, 26 Mar 2026 13:05:44 +0000

I noticed something last year. The imposter syndrome posts disappeared.

Not gradually. They were everywhere — "I've been coding for three years and I still Google how to center a div," "just got promoted to senior and I have no idea what I'm doing," threads with thousands of likes, people in the replies saying me too, me too, me too. Then the LLMs arrived, and the posts stopped. I thought maybe the tools cured it. That we'd finally found the thing that made everyone feel competent.

I was wrong. The feeling didn't go away. It just changed shape.

The old imposter syndrome had a specific texture. You knew what you didn't know. You couldn't center a div, you'd never touched Kubernetes, you were faking it in standups about GraphQL. The gap was legible. You could name it, study it, fill it. That legibility is what made the posts shareable. "I don't know X" is a sentence you can say out loud.

The new version is harder to name. You shipped the feature. The tests pass. Your manager is happy. But when someone asks you to walk through the implementation, something is off. You can narrate what the code does. You can't always explain why it's structured the way it is, what the model assumed, where it would break under pressure. The code is yours the same way a house is yours when you hired the contractor. You own it. You don't know every decision that went into the walls.

Engineering culture has long tied ownership to authorship. You wrote the code, therefore you understood it. You understood it, therefore you were responsible for it. That chain held for decades. AI broke it — not dramatically, not all at once, but consistently enough that a new kind of doubt has moved in where the old one used to live.

The data is starting to catch up to what developers already feel.

METR previously published a paper which found the use of AI tools caused a 20% slowdown in completing tasks among experienced open-source developers — a finding strange enough that they ran a follow-up study. That follow-up ran into its own problem: developers refusing to participate because they did not wish to work without AI. 30% to 50% of developers told researchers they were choosing not to submit certain tasks because they didn't want to do them without AI.

Read that twice. Not "AI makes me faster." Not even "AI makes me better." Developers who cannot or will not attempt the work without the tool present. That's not productivity. That's dependency.

Luciano Nooijen noticed this before the research did. He used AI tools heavily at work, stopped for a side project, and hit a wall. "I was feeling so stupid because things that used to be instinct became manual, sometimes even cumbersome." The instincts didn't fail slowly. They went quiet.

AI coding tools can make you more productive. They can make you feel more confident. They can also produce developers who don't understand the context behind the code they've written or how to debug it.

Stack Overflow called this "the illusion of expertise." I'd call it something slightly different. It's not that the expertise is fake. It's that the path that usually builds expertise — the struggle, the failure, the iteration — got shortened. When AI generates code without the developer engaging deeply with the implementation, they skip over all of those learning iterations. The developer doesn't struggle with the problem, doesn't try multiple approaches, doesn't experience the failures that build intuition.

The old imposter syndrome was painful but self-correcting. You felt like a fraud, so you studied. You filled the gap. The new version doesn't have an obvious gap to fill. The code shipped. You're a senior developer with a good job and passing tests and no visible evidence that anything is wrong. The doubt is quieter. That's what makes it harder.

We're living in the most empowering time to be a developer. The barrier to building things has never been lower. And yet, I've never felt less sure of my own skills.

That's Pranav Reveendran, writing in December. He's not alone. A 2025 survey by Perceptyx found a "confidence gap" where 71% of employees use AI, but only 35% of individual contributors feel they understand it well enough. The adoption curve went up. The confidence curve didn't follow.

This is what the posts were about, when people still wrote them. Not "do I belong in tech?" but "do I understand what I'm building?" The first question had a community around it. Thousands of replies, conferences, entire career tracks built around addressing it. The second question doesn't have a community yet. It's the thing people say in DMs but not in threads. It's the thing I've heard from developers who've been building for years: I know how to use the tools. I'm not sure I know the work anymore.

I don't think this resolves neatly. The tools aren't going away and the productivity is real and I'm not arguing for anyone to stop using them. I use them. I built most of Foundation's evaluator with AI assistance and I'd do it again.

But I think the silence is worth naming. The imposter syndrome posts didn't stop because the feeling stopped. They stopped because the feeling changed into something that's harder to share. "I don't know how to center a div" is embarrassing but legible. "I shipped a feature I can't fully explain" is a different kind of statement. It implicates the work, not just the person. It's harder to say me too to.

The old imposter syndrome asked: am I good enough?

The new one asks: is the work mine?

That's a harder question. And so far, it's mostly going unasked.

The Future Is Not the Agent Using a Human Interface

Daniel Nwaneri — Mon, 23 Mar 2026 13:44:20 +0000

Carl Pei said it at SXSW last week. His company, Nothing, makes smartphones. He stood on stage and told the room: "The future is not the agent using a human interface. You need to create an interface for the agent to use."

A consumer hardware CEO publicly declaring that the product category he sells is the wrong shape for what's coming. That's not a hot take. That's a company repositioning before the floor disappears.

The room moved on. Most of the coverage focused on the "apps are dying" framing. That's the wrong thing to argue about. Apps are not dying next Tuesday. The question worth sitting with is quieter and more immediately useful: what does it mean that the thing we've been building — apps designed for human eyes, human fingers, human intuition — is increasingly being navigated by something that has none of those?

For thirty years, software design started with a user. A person with a screen, a mouse or finger, a working memory of roughly four things, limited patience, inconsistent behavior. Every design decision flowed from that starting point. Navigation was visual because users have eyes. Flows were linear because users lose context. Confirmation dialogs exist because users make mistakes and need to undo them.

Those constraints weren't arbitrary. They were load-bearing. The entire architecture of how software works was built around the specific limitations and capabilities of a human being sitting in front of it.

Agents don't have eyes. They don't navigate menus — they call functions. They don't get confused by non-linear flows — they parse structured outputs. They don't need confirmation dialogs — they need permission boundaries defined at initialization, not presented as popups mid-task.

When an agent tries to use an app designed for a human, it's doing something like what Pei described: hiring a genius employee and making them work using elevator buttons. The capability is real. The interface is friction. The agent scrapes what it can, simulates the clicks, and works around the design rather than with it.

This works. Barely. Temporarily.

The split is already visible in how developers describe their workflows.

Karpathy, in a March podcast, described moving from writing code to delegating to agents running 16 hours a day. His framing: macro actions over repositories, not line-by-line editing. The unit of work is no longer a file. It's a task.

Addy Osmani wrote about the same shift at the interface level: the control plane becoming the primary surface, the editor becoming one instrument underneath it. What used to be the center of developer work is becoming a specialized tool for specific moments — the deep inspection, the edge case, the thing the agent got almost right and subtly wrong.

These descriptions share a structure: something that was primary becomes secondary. Something that was implicit becomes explicit. The developer who used to navigate the editor now supervises agents. The app that used to be the product now needs to also be a legible interface for non-human callers.

Here's what that means practically, for anyone building software right now.

The apps built for human navigation will still work for humans. That's not going away. But increasingly, those apps will also be called by agents acting on behalf of humans — booking the flight, filing the form, triggering the workflow. And when the agent calls your app, it doesn't navigate. It looks for a contract: what can I call, what will you return, what happens when I'm wrong.

Most apps don't have that contract. They have a UI. They have an API if you're lucky. But the API was designed as a developer convenience, not as a primary interface for autonomous callers. The rate limits assume human usage patterns. The error responses assume a developer reading them. The authentication assumes a human with a session.

None of those assumptions hold for agents.

The developers who see this clearly are already building differently. Not abandoning the human interface — users still need screens, still need control surfaces, still need to understand what's happening on their behalf. But building the agent interface in parallel. Structured outputs. Explicit capability declarations. Error responses designed to be parsed, not read. Permission boundaries that don't require a human to click through them.

The spec is where this shows up first.

A product spec written for human implementation describes features. What the user sees. What they can do. How the flow works. A spec written for agent implementation describes contracts. What the system accepts. What it returns. What it guarantees. Where the boundaries are.

The [ASSUMPTION: ...] tags in spec-writer exist because that boundary — between what was specified and what the agent decided — is where agent implementations go wrong. Not in the happy path. In the assumptions that weren't stated because a human developer would have asked a clarifying question.

An agent doesn't ask. It fills the gap with whatever its training suggests is most plausible. If the assumption was wrong, you find out in production.

The spec that makes agent implementation reliable is the one that surfaces the assumptions before the agent starts. Not because agents are unreliable — they're remarkably capable within a well-defined contract. But because the contract has to be explicit in a way it never had to be when the implementer was human and could pick up the phone.

Carl Pei's argument is about device form factors. The smartphone built around apps and home screens doesn't fit a world where agents intermediate between intention and execution.

The same argument applies to every level of the stack.

The database schema built for human-readable queries. The API designed for developer convenience. The workflow tool that requires clicking through five screens. The SaaS product whose entire value lives in a visual interface with no programmatic equivalent.

None of these are broken today. They will accumulate friction as agent usage grows — the same way command-line tools accumulated friction when GUIs arrived, the same way desktop software accumulated friction when everything moved to the web.

The difference is pace. The GUI transition took a decade. The web transition took another. The agent transition is compressing.

The developers who will build the next layer are already asking a different question. Not "how does the user navigate this?" but "how does the agent call this?" Not "what does the confirmation dialog say?" but "what are the permission boundaries at initialization?" Not "how do we make the flow intuitive?" but "what does the contract guarantee?"

These are not new questions. They're the questions API designers have always asked. What's new is that they now apply to everything — not just the backend service, but the whole product. The human interface remains. It becomes one layer, not the only layer.

The future is not the agent using a human interface. The future is building interfaces designed for both — and knowing which decisions belong to which layer.

The developers who get that distinction early will have built the right foundation before it becomes mandatory. The ones who don't will spend the next three years retrofitting contracts onto systems that were never designed to have them.

That's the same pattern as every previous transition. The only thing that changes is how much runway you have before the friction becomes a crisis.

Right now, you still have some.

Your Agent Is Making Decisions Nobody Authorized

Daniel Nwaneri — Thu, 19 Mar 2026 18:02:23 +0000

A quant fund ran five independent strategies. Every one passed its individual risk limits. Every quarterly filing looked reasonable in isolation. But all five strategies were overweight the same sector.

Aggregate exposure exceeded anything anyone had authorized — because the complexity budget was scoped per-strategy, never cross-strategy. No single decision was wrong. The aggregate outcome was unauthorized. Nobody was watching the right scope.

This is governance debt. It accumulates invisibly. Each decision individually correct. Aggregate outcome unauthorized. The failure only surfaces when the sector moves against the fund and the concentration nobody explicitly built turns out to have been built anyway — one individually-reasonable decision at a time.

The token economy has no accounting entry for this. Nothing on the infrastructure bill reflects what happened. The cost appears later, in a different quarter, a different system, a different team's incident report.

Two Clocks

Every agent system has at least two clocks running simultaneously.

The execution clock measures computation — tokens consumed, API calls made, latency per response. This is what most monitoring systems track. It is visible, quantifiable, and entirely the wrong thing to govern.

The governance clock measures consequences — decisions made, thresholds crossed, exposures accumulated. This clock runs at a fundamentally different speed than execution. It is also running on a fundamentally different metric.

Execution counts tokens. Governance counts consequences.

Most agent architectures try to govern at execution layer granularity. They instrument every API call, set token budgets, alert on cost spikes. The result is a monitoring system that costs more attention than the decisions it is protecting. The governance layer becomes noise. Worse than useless — it actively degrades decision quality by demanding attention on non-material changes.

The fix is not better monitoring. It is a different master clock.

The Master Clock

Vic Chen builds institutional investor analysis tooling around quarterly SEC filing data. The production domain he works in — 13F analysis, the quarterly disclosures hedge funds file showing their equity positions — has solved the governance clock problem in a way most software systems haven't.

The expensive thing in 13F analysis is not parsing the filings. That part is mechanical. Run the filing through the pipeline, extract the positions, compare against the previous quarter. Cheap. Deterministic. Fast.

The expensive thing is deciding which signals actually warrant human attention. Every false positive costs analyst time. Every false negative costs trust in the system. That judgment call does not map cleanly to token costs. You cannot optimize it by switching to a cheaper model or batching the API calls. The bottleneck is not computation. It is consequence.

The master clock in Vic's system is anchored to SEC reporting cadence — filing deadlines, amendment windows, restatement periods. The quarterly 13F disclosure cycle is one of the few externally-anchored materiality signals in finance. It already encodes a judgment: this change was significant enough to report.

When a fund flips a position intra-quarter and back again, that event never surfaces in the filing. This is not a detection failure. The governance architecture is working correctly. An intra-quarter flip that reverses before the filing deadline was not a conviction change. The master clock — anchored to external cadence rather than internal computation — correctly filters it out.

This is filtering by design rather than detection by volume. The governance layer is not trying to catch everything. It is anchored to what the domain has already decided matters.

When the system detects an NT 13F — a late filing notification — or an amendment chain exceeding two revisions, the complexity budget automatically expands. Slower parsing. Deeper cross-referencing. Human-in-the-loop checkpoints. The external signal triggers the governance response because the external signal already encodes the materiality judgment.

The master clock is not a timer. It is a materiality filter.

The Over-Calibration Trap

The first failure mode most governance architectures hit is over-calibration.

Early 13F monitoring systems flagged every rounding discrepancy between a fund's 13F and their 13D as potential drift. The noise-to-signal ratio made the governance layer worse than useless. Analysts were spending attention on non-material changes. The system meant to improve decision quality was degrading it.

Vic's framing of the fix: governance cost should scale with expected loss from undetected drift, not with the volume of changes observed.

A $50M position shift in a mega-cap is noise. A $50M position shift in a micro-cap is a thesis change. Same signal magnitude. Completely different materiality. The governance architecture has to encode that domain knowledge or it cannot distinguish between them.

This is where the "significant drift threshold" becomes practical rather than theoretical. Without it, you are building a governance layer that is perpetually anxious — flagging everything, earning attention for nothing, training operators to ignore alerts. With it, the governance layer fires on what matters and stays quiet on what does not.

The threshold is not a technical parameter. It is a domain judgment encoded into architecture.

Governance Debt

Back to the five-strategy fund.

The token economy version of that failure is identical in structure. An agent that makes two expensive API calls but expands the decision space by introducing correlated hypotheses is under token budget and creating governance debt simultaneously. The cost does not appear on the infrastructure bill. It appears when the downstream decision fails in ways that trace back to the expanded hypothesis space nobody reviewed.

An agent that makes 100 cheap API calls but narrows a decision space from 5,000 options to 3 is adding value regardless of token cost. An agent that makes two expensive calls but introduces unreviewed complexity is accruing debt regardless of token efficiency.

The decision economy is the accounting system that captures the difference.

Three signals that matter in the decision economy and do not appear in token accounting:

Decision scope. How many downstream choices does this agent action constrain or enable? An action that narrows the decision space is value-generating. An action that expands the decision space without corresponding resolution is debt-generating. The token cost of both can be identical.

Consequence materiality. Not all decisions are equal. The governance clock runs faster when the expected loss from undetected drift is higher. A rounding discrepancy in a mega-cap position and a position reversal in a micro-cap both generate the same token cost to detect. Their materiality is orders of magnitude apart.

Authorization scope. Was this decision within the scope of what was explicitly authorized, or did it cross a threshold that required a decision nobody made? Governance debt accumulates at the boundary between authorized and implicitly permitted.

None of these signals are invisible. They require a different accounting system — one that tracks consequences rather than computation, materiality rather than volume, authorization scope rather than token spend.

The Rate Problem

Static agents accumulate governance debt slowly. An agent that makes the same decisions in the same scope every session creates predictable exposure. You can audit it. You can scope the complexity budget correctly once and leave it.

An agent with memory that promotes knowledge automatically accumulates governance debt at the rate the memory compounds. Each session, the promoted knowledge expands the hypothesis space the agent operates in. Each expansion is individually reasonable. The aggregate effect is an authorization scope that widens faster than anyone is reviewing it.

The governance layer has to keep pace with the learning rate or it falls further behind with every session — not linearly, but exponentially.

This is why the evaluator architecture in Foundation anchors promotion criteria to human judgment rather than automating it. Not because automation is wrong in principle. Because the governance debt from unchecked automatic promotion compounds at the same rate as the knowledge base — and the rate is the problem, not any individual promoted insight.

The master clock that works for 13F analysis works for agent memory for the same reason: it is anchored to external materiality judgment rather than internal computation speed. The filing cadence enforces a review interval that the domain has already validated. The human promotion gate enforces a review interval that the knowledge system needs.

Both are the same governance architecture. One is thirty years old. One is being built now.

What the Decision Economy Actually Measures

Token costs are visible on the infrastructure bill. Governance debt is not.

This asymmetry creates predictable incentives. Teams optimize for what they can measure. Token spend gets instrumented, budgeted, alerted. Governance debt accumulates until it manifests as a production failure, a trust breakdown, a concentration exposure nobody authorized across five individually-reasonable decisions.

The token economy prices execution correctly. It is the wrong accounting system for judgment costs because judgment costs do not appear until downstream consequences surface — often in a different quarter, a different system, a different team's incident report.

The precedent that prices judgment correctly is not a token count. It is a record of what decisions were made under what conditions, what thresholds were crossed, what downstream exposure was created, and whether any of it was explicitly authorized.

That record is what makes governance debt visible before it becomes a production problem.

Execution counts tokens. Governance counts consequences.

The decision economy is what you build when you understand the difference.

This is part of a series on what AI actually changes in software development. Previous pieces: The Gatekeeping Panic, The Meter Was Always Running, Who Said What to Whom, The Token Economy, Building the Evaluator, I Shipped Broken Code and Wrote an Article About It.

The governance debt examples and 13F production evidence in this piece draw from analysis by Vic Chen, who builds institutional investor analysis tooling around quarterly SEC filing data. The five-strategy concentration example is his.

I Built a Skill That Writes Your Specs For You

Daniel Nwaneri — Tue, 17 Mar 2026 11:35:53 +0000

Julián Deangelis published a piece this week that hit 194k+ views in days. The argument: AI coding agents don't fail because the model is weak. They fail because the instructions are ambiguous.

He called it Spec Driven Development. Four steps: specify what you want, plan how to build it technically, break it into tasks, implement one task at a time. Each step reduces ambiguity. By the time the agent starts writing code, it has everything it needs — what the feature does, what the edge cases are, what the tests should verify.

The piece is right. The problem is the workflow takes discipline most sessions don't have. Under deadline pressure, the spec step disappears and you're back to prompting directly.

So I built a skill that does the spec-writing for you.

The silent decisions problem

Julián's example stuck with me:

"Add a feature to manage items from the backoffice."

The agent reads the codebase, picks a pattern, writes the feature. At first it looks fine. Then you click "add item" again and it inserts the same item twice. All the assumptions you thought were obvious were never in the prompt.

Which backoffice — internal or seller-facing? Should the operation be idempotent? Admin-only or all users? Which storage layer? Which error handling strategy?

Each one is a silent decision. The agent guesses. Some guesses are right. Some are wrong. And you don't find out which until the feature is in production behaving in ways you didn't expect.

The spec is what makes those decisions visible before the agent guesses. But writing a spec from scratch, for every feature, before every session — that's the friction that kills the habit.

Generate first, flag assumptions inline

The standard approach to spec tools is Q&A: the tool asks clarifying questions before generating anything. What's the user role? What's the auth model? What should happen on error?

The problem with Q&A is you have to know what you don't know. If you knew exactly what questions to ask, you'd be close to having the spec already.

spec-writer takes a different approach. It generates the full spec immediately and marks every decision it made that you didn't specify:

Given an authenticated user requesting an export
When the export contains more than 1,000 rows [ASSUMPTION: async for large exports]
Then the export is generated asynchronously and the user is notified by email

At the end, every assumption is collected into a prioritized list:

## Assumptions to review

1. Async generation for exports over 1,000 rows — Impact: HIGH
   Correct this if: your order volumes are low and synchronous is fine

2. Date range filter is required — Impact: MEDIUM
   Correct this if: the first version should export all orders with no filtering

Correcting a draft is faster than answering questions cold. The [ASSUMPTION: ...] tags show you exactly where the agent would have guessed wrong — before it guesses. That's the value. Not the spec itself. The visible assumptions.

A real example

I ran it on something I'm actually building — CLI capture for Foundation, my knowledge commons project. Foundation currently captures Claude.ai browser conversations via a browser extension. Claude Code sessions live in ~/.claude/projects/ and disappear after 30 days. I needed to capture those too.

The prompt:

/spec-writer Add CLI capture for Claude Code sessions stored in ~/.claude/projects/

Here's a slice of what came back:

From the spec:

Given a developer with Claude Code sessions in ~/.claude/projects/
When they run the Foundation CLI capture command
Then a list of uncaptured sessions is displayed, sorted by most recent first

Given a session already in Foundation
When the developer runs capture again
Then that session does not appear in the review list

Given a malformed .jsonl file
When the capture command processes it
Then an error is logged for that file and processing continues on remaining sessions

From the plan:

CLI capture runs locally — it needs to read the local filesystem, which 
Cloudflare Workers cannot do. [ASSUMPTION: CLI capture is a local Node.js 
or Bun script that calls the Foundation API to insert sessions, rather 
than a Worker itself]

That assumption stopped me. I hadn't thought through the architecture split — Foundation runs on Cloudflare Workers, which can't read local filesystems. The skill surfaced it before I'd written a line of code.

The assumptions summary:

1. CLI capture is a local script calling the Foundation API, not a Worker
   Impact: HIGH
   Correct this if: you want a purely serverless approach

2. Manual curation before capture, not automatic bulk import
   Impact: HIGH
   Correct this if: you want automatic background capture

3. Session ID from .jsonl filename is the deduplication key
   Impact: MEDIUM
   Correct this if: session IDs are stored differently in your schema

4. No sensitive data scrubbing in v1
   Impact: MEDIUM
   Correct this if: your sessions contain credentials or keys

Four assumptions, two of them high-impact. The architecture one I would have hit mid-implementation. The sensitive data one I wouldn't have thought about until someone complained.

That's the value. Not the spec itself. The visible assumptions.

How it fits into SDD

spec-writer gets you to Spec-First immediately, with no ceremony. One command, full output, correct the assumptions, hand to the agent.

Julián describes two levels beyond that. Spec-Anchored: the spec lives in the repo and evolves with the code. Spec-as-Source: the spec is the primary artifact, code is regenerated to match. If you want to move toward Spec-Anchored, save the output to specs/feature-name.md in your repo. The skill produces something worth keeping.

The methodology is Julián's. The skill is the friction remover.

Install

mkdir -p ~/.claude/skills
git clone https://github.com/dannwaneri/spec-writer.git ~/.claude/skills/spec-writer

Then:

/spec-writer [your feature description]

Works across Claude Code, Cursor, Gemini CLI, and any agent that supports the Agent Skills standard. The same SKILL.md file works everywhere.

The repo is at github.com/dannwaneri/spec-writer. The README has the full output format and a worked example.

The agents are getting better at implementing. The bottleneck was always specification — knowing what to build precisely enough that the agent doesn't have to guess. spec-writer doesn't remove that requirement. It makes it faster to satisfy.

The spec isn't the output. The assumptions are.

Built on the Spec Driven Development methodology — operationalized by tools like GitHub Spec Kit and OpenSpec. Julián Deangelis's writing on SDD at MercadoLibre was the direct inspiration.

Other skills: voice-humanizer — checks your writing against your own voice, not generic AI patterns.

Beyond the Scrapbook: Building a Developer Knowledge Commons

Daniel Nwaneri — Mon, 16 Mar 2026 10:09:02 +0000

DEV.to shipped Agent Sessions last week — a beta feature that lets you upload Claude Code session files directly to your DEV profile, curate what to include, and embed specific exchanges in your posts. Upload a .jsonl or .json session file, pick the moments worth keeping, save it. The parser currently supports Claude Code, Gemini CLI, Codex, Pi, and GitHub Copilot CLI.

I was in the announcement thread.

Pascal flagged that the useful unit for embedding in technical writing is a specific exchange, not the full session. You want the moment the agent made the wrong call, or the prompt that finally produced the right output. Uploading a full session to access two minutes of it is friction that'll stop most writers from using it at all.

The DEV team shipped a refactor the same day. Client-side curation, 10MB limit gone. That's a fast turnaround.

So I'll say this clearly: the feature works. The local parsing decision is the right call architecturally — nothing hits their servers before you've seen it. The sessions sitting in ~/.claude/projects/ right now are invisible to everyone, including future you. DEV.to made them visible.

That's the first 10% of the problem.

What's Actually in a Session File

A Claude Code .jsonl session file isn't clean. It's a raw record of everything: every prompt, every response, every tool call, every error, every retry, every tangent that went nowhere.

A 4-hour session produces tens of thousands of lines. Most of it is noise. The three decisions that mattered — the architectural choice you made in hour two, the wrong assumption you caught before it shipped, the pattern you'd use again — are buried in the middle of a conversation about a linter warning.

Manual curation finds those moments if you remember where they are. It doesn't find them if you don't. And it definitely doesn't find them across 40 sessions from the last two months.

This is the problem DEV.to's feature doesn't touch: extraction.

Not capture. Not curation. The automated process of reading a session and asking — what here is worth keeping? What decision was made, what reasoning supported it, what would someone need to know to not repeat this mistake?

That's not a UI problem. That's an evaluation problem. It's solvable — but not with a manual upload flow.

The Scrapbook vs The Commons

DEV.to built a scrapbook. Upload a session. Pick the good parts. Post it.

That's individually useful. A developer who publishes their sessions regularly builds a public record of how they think. That has real value — for their own portfolio, for their team, for the developers who find it later.

But it doesn't compound.

The knowledge in that session stays attached to that post, on DEV.to's platform, searchable through DEV.to's search, accessible through DEV.to's interface. It doesn't talk to anything else. It can't be queried by an AI tool working on a related problem. It can't be federated to a developer who runs their own instance. It can't surface automatically when a similar problem comes up in a different session six months later.

The session is uploaded. The knowledge is published. Nothing learns from it.

A knowledge commons does something different. It extracts the signal from the noise automatically, scores it, indexes it semantically, and makes it retrievable — by humans, by AI tools, by other instances in a federated network. The knowledge compounds. Sessions from six months ago surface when they're relevant today. A decision made by a developer in one context becomes findable by a developer in a different context who's facing the same constraint.

That's what's missing. Not the upload. The evaluation layer that turns uploaded sessions into searchable, reusable, federated knowledge.

The Manual Curation Ceiling

DEV.to's flow puts curation on you. You decide what to include. You decide what to cut. You write the context that makes it useful for other readers.

That's fine for one session. It doesn't scale to forty.

The developers who would benefit most from session preservation — the ones building seriously, shipping regularly, running multiple Claude Code sessions a day — are exactly the developers who don't have time to manually curate every session before publishing. They'll upload three sessions in the first week because it's novel. Then they'll stop. The sessions keep accumulating in ~/.claude/projects/. The feature stops getting used.

This is the friction problem that killed a dozen "public learning" features before it. The intent is genuine. The execution cost is too high to sustain.

The alternative is automatic extraction that runs in the background — sessions flow in, evaluation runs, high-signal insights surface for review, low-signal noise is filtered out before it ever reaches you. You review what the evaluator flagged, not the raw session. The curation burden drops from hours to minutes.

That's a pipeline, not a UI.

Agent Sessions is the UI.

Who Owns the Knowledge

There's a structural question underneath the feature that DEV.to doesn't answer: who owns the knowledge you publish?

When you upload a session to DEV.to and publish it, the content lives on DEV.to's platform. That's fine — DEV.to has been a good steward of developer content. But the knowledge is centralized. DEV.to controls the search. DEV.to controls the API. DEV.to controls what gets surfaced and how.

We've seen this pattern before. Stack Overflow was a good steward too, until the economics changed. Reddit. Twitter. The platforms that host the knowledge and the platforms that profit from it are the same platform, and that alignment doesn't hold forever.

A federated model works differently. Your knowledge lives on your instance. You control the search. You decide what gets federated to other instances and what stays private. The network is the value, not the platform. No single company owns the graph.

ActivityPub makes this possible today. The same protocol that lets Mastodon instances talk to each other can federate developer knowledge across independent instances. Your session insights are yours. They travel to other instances when you choose. They're retrievable by any tool that speaks the protocol.

DEV.to can't build this. It's structurally incompatible with a platform business model. A platform needs the content centralized to monetize the audience. Federation distributes the content, which distributes the audience, which distributes the revenue.

That's not a criticism — it's a constraint. DEV.to is doing what a platform can do. Federation is what a commons can do.

What the Other 90% Looks Like

I've been building Foundation for the past several months. It's not a concept.

A browser extension captures conversations automatically from Claude.ai — no manual upload, no file hunting. Conversations flow into a three-table schema in D1 (chats, messages, chunks) and get chunked at the passage level for semantic search in Vectorize. When a session ends, the pipeline runs an evaluation pass using Workers AI (Llama 3.3 70B): three binary signals — is there a concrete technique being applied (usage), is it confirmed to work (validation), is it actionable rather than vague (specificity). Score ≥ 0.67 auto-promotes to knowledge memory. Score 0.33–0.67 surfaces for human review. Score < 0.33 gets discarded.

The knowledge that survives is indexed semantically and exposed via an MCP server: list_chats, get_chat, extract_insights, score_insights. Any AI tool that speaks MCP can query it. The session ended an hour ago. The insight from it is already retrievable in the next session.

The federation layer is ActivityPub. The same protocol Mastodon runs on. Your insights live on your instance. They travel to other instances when you choose. A developer running their own Foundation can federate with yours without either of you going through a centralized platform.

That's the full picture. Not a wireframe — running code, at github.com/dannwaneri/chat-knowledge.

The problem is now visible enough for a major platform to build around it. Developers are generating valuable knowledge in their sessions and losing it. That's real, and DEV.to naming it publicly matters.

But capture without evaluation is a scrapbook. A scrapbook without federation is a silo. A silo on someone else's platform is borrowed infrastructure.

The commons version of this is harder to build. That's why I've been building it.

I Built a Knowledge Evaluator That Uses Notion to Judge What's Worth Remembering

Daniel Nwaneri — Thu, 12 Mar 2026 16:14:22 +0000

Foundation kept everything. After 300 conversations, search returned noise. That was the problem I was actually trying to solve.

I've been building Foundation — a federated knowledge system on Cloudflare Workers and the hardest part isn't capturing insights from conversations. It's deciding which ones deserve to persist. Throw everything into Vectorize and you end up with noise.

The Notion MCP Challenge gave me a reason to isolate the evaluator and ship it as a standalone thing.

The Idea

Most challenge submissions pipe data into Notion. This one uses Notion as the judgment surface — the place where ambiguous knowledge items wait for a human to decide if they're worth keeping.

The architecture:

Conversation excerpt
        ↓
Workers AI (Llama 3.3 70B) scores 3 signals
        ↓
Score ≥ 0.67 → Knowledge Memory (auto-promoted)
Score 0.33–0.67 → Notion Review Queue (human judges)
Score < 0.33 → Discarded

Notion isn't just receiving output. The Worker queries it back for pending items and uses it as the approval layer. That's the move most submissions didn't make.

The Three Signals

The evaluator scores each knowledge item on three binary signals:

Usage — Is there a concrete technique, command, or pattern being applied?
Validation — Is it confirmed to work (tested, referenced, agreed upon)?
Specificity — Is it actionable, not just vague advice?

A score of 1.0 means all three fired. That item goes straight to Knowledge Memory. A score of 0.67 means two fired — useful, but unverified. That item surfaces in the Notion Review Queue as Pending. A human makes the call.

Building It

The Worker is Hono on Cloudflare Workers, Workers AI for scoring, and the Notion REST API for reads and writes.

The evaluator uses the messages format — not prompt — with a strict system instruction:

const response = await ai.run('@cf/meta/llama-3.3-70b-instruct-fp8-fast', {
  messages: [
    {
      role: 'system',
      content: 'You are a knowledge quality evaluator. Respond with ONLY valid JSON.',
    },
    {
      role: 'user',
      content: `Score this excerpt and return ONLY:
{"usage": 0|1, "validation": 0|1, "specificity": 0|1, "summary": "one sentence"}

Excerpt: ${text}`,
    },
  ],
  max_tokens: 256,
});

One thing I hit: the model returns { response: { usage: 1, ... } } — a nested object, not a string. The prompt parameter made it worse, returning free-form essays instead of JSON. Switching to messages with a system role fixed it.

The routing logic is straightforward:

if (score >= 0.67) {
  // Auto-promote to Knowledge Memory
  await writeToNotion(env.KNOWLEDGE_MEMORY_ID, summary, score, signals, source, text);
} else if (score >= 0.33) {
  // Surface for human judgment
  await writeToNotion(env.REVIEW_QUEUE_ID, summary, score, signals, source, text, 'Pending');
} else {
  // Discard
}

Notion as the Judgment Layer

Two databases: Knowledge Memory (permanent store) and Review Queue (human inbox — a Select field with Pending, Approved, Rejected).

The Worker has three endpoints:

POST /evaluate — scores a knowledge item and routes it
GET /pending — queries Notion for items awaiting review
GET / — health check

The /pending endpoint is what makes Notion MCP genuinely active:

const res = await fetch(
  `https://api.notion.com/v1/databases/${env.REVIEW_QUEUE_ID}/query`,
  {
    method: 'POST',
    headers: { Authorization: `Bearer ${env.NOTION_TOKEN}`, 'Notion-Version': '2022-06-28' },
    body: JSON.stringify({
      filter: { property: 'Status', select: { equals: 'Pending' } },
      sorts: [{ property: 'Created', direction: 'descending' }],
    }),
  }
);

When something lands in Review Queue, a human opens Notion and changes Status from Pending to Approved or Rejected. That's the loop. Notion isn't a log — it's a decision surface.

What It Looks Like Running

► Querying Review Queue...  Pending: 1

[1/3] HIGH-CONFIDENCE
  Score: 100% | Signals: usage, validation, specificity
  ✓ Auto-promoted → Knowledge Memory

[2/3] AMBIGUOUS
  Score: 67% | Signals: usage, specificity
  ⚡ Surfaced in Notion Review Queue

[3/3] LOW-CONFIDENCE
  Score: 0% | Destination: discarded
  ✗ Not worth preserving.

► Re-querying...  Pending: 2

Live endpoint: https://knowledge-evaluator.fpl-test.workers.dev

Closing the Loop with Notion MCP

The Worker writes to Notion via REST. But the other direction — reading pending items back via MCP — is where it gets interesting.

With @notionhq/notion-mcp-server configured in Claude Desktop, you can query the Review Queue directly in a conversation:

"Query my Notion Review Queue database and show me all items with Status Pending"

Claude returns:

1 item found

Name:     The excerpt mentions using waitUntil() in Cloudflare Workers for
          tasks like logging, but lacks production validation.
Score:    0.67
Status:   🟡 Pending
Signals:  usage, specificity
Source:   dev-chat
Created:  March 10, 2026

And then offers: "Want to promote, flag, or dismiss it?"

That's the full loop. The Worker evaluates and writes. Notion holds the item. Claude reads it back via MCP and surfaces it for a human decision. Two MCP interactions — one outbound (REST), one inbound (MCP server) — both hitting the same Notion database.

The architecture now looks like this:

Conversation excerpt
        ↓
Workers AI scores 3 signals
        ↓
Score ≥ 0.67 → Knowledge Memory (auto-promoted via Notion REST)
Score 0.33–0.67 → Review Queue (Pending, written via Notion REST)
Score < 0.33 → Discarded
        ↓
Claude Desktop queries Review Queue via @notionhq/notion-mcp-server
        ↓
Human approves or rejects in Notion

Notion isn't a log — it's the decision surface that both the Worker and the AI agent can see.

What I Learned

The scoring threshold matters more than the model. The harder question — what makes something worth keeping — I haven't fully answered. That's why the Review Queue exists.

The model doesn't need fine-tuning for this. Writing the three signals took longer than the entire Worker.

Knowledge provenance is preserved throughout — the original conversation snippet lives in the Raw Context field, so when you're approving something in Notion, you can see exactly where it came from.

What's Next

The thresholds (0.67 and 0.33) are now tunable via env vars — HIGH_THRESHOLD
and LOW_THRESHOLD in wrangler.toml. Different knowledge domains need different bars.

A fourth signal is the natural evolution: novelty — does this item duplicate
something already in Knowledge Memory? Without it, the permanent store will accumulate
redundant entries over time. That's the next thing to build.

Stack

Cloudflare Workers — runtime
Workers AI (Llama 3.3 70B) — evaluator
Hono — routing
Notion API — Review Queue + Knowledge Memory (writes)
@notionhq/notion-mcp-server — MCP query layer (reads)

Repo: github.com/dannwaneri/knowledge-evaluator

Building the Evaluator

Daniel Nwaneri — Wed, 11 Mar 2026 16:24:00 +0000

The sequel isn't about running or stopping. It's about whether the memory survives the stop.

That line came from a comment thread on The Token Economy. Someone named Kalpaka had been reading through the series — the stop signal problem, the authority over interruption argument, the architectural gap between what agents can do and what they do reliably and arrived at the question none of the pieces had answered.

You can solve the stop signal problem. You can build interruption authority into your architecture. You can define done before the session starts and give the agent a contract it has to satisfy before it terminates.

None of that answers what happens to the knowledge after the session ends.

The Graveyard Problem

Noah Vincent described it precisely for personal knowledge systems: "A week after consuming something, you could not explain what you learned if your life depended on it. The notes exist. The highlights are there. But you never use any of it."

He was describing Obsidian vaults. The same problem exists for agent memory systems, RAG pipelines, and every second brain anyone has ever built.

The issue is not storage. Storage is solved. The issue is that storage without evaluation is just accumulation. You end up with a beautifully organized graveyard — everything preserved, nothing improved, retrieval returning the noise alongside the signal because the system has no way to tell the difference.

Artem Zhutov ran 700 Claude Code sessions over three weeks and built a semantic search layer to make them retrievable. The /recall skill can surface what happened in any session by topic, time, or graph visualization. He solved the retrieval problem.

But retrieval without evaluation means the 700 sessions are equally weighted. The session where he made a breakthrough architectural decision and the session where he debugged a typo for an hour are both in the index. Both surface when you search. The system got larger. It did not get smarter.

This is the graveyard problem stated for agent memory. Not that the knowledge is lost. That it accumulates without the quality signal that would make it worth retrieving.

What the Evaluator Actually Is

The AIGNE paper — "Everything is Context: Agentic File System Abstraction for Context Engineering" — describes a complete cognitive architecture for AI agents. Four components: constructor (shrinks context to fit the current window), updater (swaps pieces in and out as the conversation progresses), evaluator (checks answers and updates memory based on what worked), and scratchpad separation (raw history, long-term memory, and short-lived working memory as distinct stores).

Most memory architecture discussions cover the constructor and the retrieval layer. Almost nobody builds the evaluator.

The evaluator is the component that decides what gets promoted from episodic memory — what happened — to semantic memory — when pattern X appears, do Y. The distinction compounds at completely different rates and decays differently too. Episodic memory is retrievable history. Semantic memory is institutional knowledge. The architectural choice determines which moat you're building.

Without the evaluator, you have retrieval. With it, you have learning.

The difference: retrieval returns what you stored. Learning returns what proved true.

Kuro's Proof

Kuro built a perception-driven AI agent that runs 24/7. Every five minutes it wakes up, checks the environment, and decides whether anything needs attention. The problem: more than half its cycles ended with "nothing to do" — 50K tokens consumed per cycle to confirm that nothing was happening.

His solution was a triage layer — a local lightweight model that runs in 800 milliseconds and decides whether the expensive reasoning layer should fire at all. Hard rules handle the obvious cases in zero milliseconds. The lightweight model handles ambiguous cases. The expensive model only sees what passes both filters.

Production numbers across 626 decisions: 75.9% of triggers never reached the expensive model. The quality of remaining cycles went up because the expensive brain only saw what mattered.

Kuro solved the perception triage problem. The evaluator is the same pattern applied to knowledge.

Before a conversation gets promoted to semantic memory: hard rules first. Is this a duplicate of something indexed in the last hour? Skip. Is this a direct exchange that produced a decision that got used? Always process. Then lightweight triage — is this session high enough signal to warrant full embedding? Then full semantic processing only for what passes both filters.

The skip rate Kuro observed at the perception layer — 56% filtered at triage — will likely hold for knowledge too. Most sessions are noise. The minority that contain genuine learning are the ones worth promoting to semantic memory.

The evaluator doesn't store less. It promotes selectively. The difference is what gets retrieved when you need it.

What the Evaluator Needs to Know

The hard part isn't building the evaluator. It's deciding what signal it uses.

The obvious answer is engagement: sessions with more back-and-forth, longer exchanges, more follow-up questions. But engagement measures interest, not correctness. A session where you spent two hours debugging the wrong approach was highly engaging. It doesn't belong in semantic memory as a reliable pattern.

The better signal is validation: knowledge that proved correct under real conditions. The specific lesson about what breaks when you process financial filings at scale is worth promoting because it survived production. It was tested against real data, real edge cases, real failure modes, and it held.

This is what distinguishes semantic memory from episodic memory in the domain that matters. Not "this was an interesting conversation" but "this turned out to be true when it was tested."

The evaluator needs three signals:

Did the knowledge get used? If a session produced a decision that was applied in a subsequent session — referenced in a decision, applied to a problem, cited in writing — that's evidence of value. The decision survived contact with a real problem.

Did the knowledge hold up? If the pattern that emerged from a session was later contradicted by production evidence, that's evidence it shouldn't be promoted. The evaluator should demote as well as promote. Knowledge that fails in production gets flagged for review rather than silently remaining in semantic memory.

Is the knowledge specific enough to be useful? "Use conservative thresholds" is a platitude. "The threshold should be empirically derived from the first 50 production failures before any tuning begins, because false negatives are unrecoverable and false positives cost only an extra review cycle" is specific enough to act on. The evaluator should preserve the conditions that make the lesson true, not just the conclusion.

Cornelius — building a fiction consistency system for novelists — arrived at the same problem from a different angle: "The system must know the difference between a violation and a discovery." A scene where a character breaks a world rule might be an error. Or it might be the generative mistake that becomes the best scene in the book. The evaluator has to distinguish between them.

So does Foundation's knowledge evaluator. A session that contradicts an established pattern might be noise. Or it might be the production failure that invalidates a previously reliable assumption.

Some of those calls require human judgment. The evaluator surfaces them. It doesn't make them.

The Provenance Requirement

The evaluator is what makes a knowledge commons different from a search index.

A search index returns documents that match your query. A semantic memory layer should return knowledge that proved true, with the context that makes it actionable, attributed to the specific conditions under which it was validated.

Not "here is everything about timeout handling." But "here is what held up under 500K daily API calls in production, with the specific edge cases that caused the original timeouts and the conditions under which the fix applies."

The provenance is not metadata. It is the knowledge. Without the conditions that made the lesson true, the lesson is a platitude. With them, it is scar tissue — the kind of specific, attributed, conditions-included knowledge that survived the averaging process that centralized AI systems apply to everything they train on.

This is the knowledge collapse argument stated for personal memory systems. The models train on the averaged output of everything humans have written and return the median of all knowledge. The evaluator preserves the specific — the edges, the conditions, the validated exceptions — that the averaging process destroys.

Without it, you're building an archive. With it, you're building institutional memory that improves every time it's tested against real conditions.

What Building the Evaluator Actually Means

The pre-filter runs before any of this. Not every conversation reaches the evaluation layer. Hard rules first — direct exchange with a human, always process; ambient capture with no tracked concepts referenced, skip. Coarse content check second — does this conversation contain a decision, a question that changed direction, a pattern worth naming? Cheap signal, deterministic, costs nothing to run. The evaluation layer only fires on what passes both. Production evidence from perception triage systems suggests roughly 46% will skip at the pre-filter stage. The knowledge commons improves not by evaluating more but by evaluating less, better.

For what passes the pre-filter, building the evaluator means three additions to any memory system:

A usage tracking layer. When a retrieved knowledge item gets used in a subsequent session — referenced in a decision, applied to a problem, cited in writing — that event gets logged. Usage is the primary signal that something is worth promoting.

A validation feedback loop. When a decision based on promoted knowledge turns out to be wrong, that event gets logged and the promotion gets reviewed. The evaluator demotes as well as promotes. When promoted knowledge gets invalidated by new production evidence, the old entry doesn't stay in semantic memory with a warning attached — it gets resolved. Knowledge that fails in production gets replaced rather than contradicted silently.

A specificity filter. Before any knowledge gets promoted to semantic memory, the evaluator checks whether it contains the conditions that make it true. Generic conclusions get returned to episodic memory with a note: too general to promote — needs production validation before it earns semantic status.

None of this is automatic. The evaluator surfaces candidates for promotion and demotion. The human makes the final call on the ambiguous cases — the violations that might be discoveries, the patterns that might be noise, the lessons that might be wrong.

That's not a limitation. It's the architecture. The evaluator extends human judgment rather than replacing it. The cases that are obviously worth keeping get promoted without friction. The cases that require judgment get surfaced for human review rather than silently accumulating in a system that treats all knowledge as equally valid.

The Memory That Survives the Stop

Kalpaka's question is the right one to end on.

The stop signal problem is solvable. Interruption authority is a design decision. The contract that defines done before the session starts is a pattern that works in production.

But when the session ends — when the agent stops, when the context window closes, when the work is done for the day — what survives?

Without the evaluator: everything survives equally. The breakthrough and the dead end. The validated pattern and the assumption that turned out to be wrong. The specific, attributed, conditions-included knowledge and the platitude that sounds like knowledge but isn't.

With the evaluator: the scar tissue survives. The knowledge that was tested against real conditions and held up. The specific lessons with the specific contexts that make them true. The institutional memory that compounds because it improves every time it gets used rather than just accumulating every time something gets stored.

That's the difference between a memory system and a knowledge system. The memory system stores what happened. The knowledge system keeps what proved true.

The evaluator is what expands the cognitive light cone backward in time. Memory without evaluation gives you storage. Memory with evaluation gives you a light cone that extends further with every validated lesson — not just accumulating what happened but compounding what proved true.

The knowledge that holds up under pressure is the only knowledge worth keeping.

This is part of a series on what AI actually changes in software development. Previous pieces: The Gatekeeping Panic, The Meter Was Always Running, Who Said What to Whom, The Token Economy, I Shipped Broken Code and Wrote an Article About It.

The Junior Developer Isn't Extinct—They're Stuck Below the API

Daniel Nwaneri — Sun, 08 Mar 2026 02:46:18 +0000

Everyone's writing about the death of junior developers. The anxiety is real. The job market data backs it up. But we're misdiagnosing the problem.

The junior developer role isn't extinct. It's stuck Below the API and we haven't figured out how to pull it back up.

The Real Divide

Below the API is everything AI handles cheaper, faster, and often better than humans: boilerplate, basic CRUD, unit tests for simple functions, JSON schema conversion. Above the API is everything requiring judgment, verification, and context AI can't access: system design, debugging race conditions in production, knowing when to reject a confident-but-wrong suggestion.

Junior developers used to climb from Below to Above by doing the boring work. Write unit tests, learn how systems break. Convert schemas, understand data flow. Fix bugs, build debugging intuition. Now AI does that work. We deleted the ladder.

What NorthernDev Got Right

NorthernDev nailed the career pipeline problem. Five years ago, tedious work like writing unit tests for a legacy module went to a junior developer — boring for seniors, gold for juniors. Today it goes to Copilot.

That's not a hiring freeze. That's the bottom rung of the ladder disappearing.

The result is a barbell: super-seniors who are 10x faster with AI on one end, people who can prompt but can't debug production on the other. The middle is gone. The path from one group to the other is blocked.

What's missing from that diagnosis: the role isn't dead, it's transformed.

The Forensic Developer

NorthernDev suggests teaching juniors to audit AI output — forensic coding. That's exactly what Above the API means.

The old junior role: write code, senior reviews, learn from mistakes. The new junior role: AI writes code, junior audits, learn from AI's mistakes. The skill isn't syntax anymore. It's verification.

The problem is you can't verify what you don't understand. To audit AI-generated code you need to know what it's supposed to do, how it actually works, what will break in production, and why the AI's clean solution is wrong. Those are senior-level skills. We're asking juniors to do senior work without the ramp to get there.

Why Traditional Training Doesn't Work Anymore

Anthropic published experimental research that validates this directly. In a randomized controlled trial with junior engineers, the AI-assistance group finished tasks about two minutes faster but scored 17% lower on mastery quizzes. Two letter grades. The researchers called it a "significant decrease in mastery."

The interesting part: some in the AI group scored highly. The difference wasn't the tool. It was how they used it. The high scorers asked conceptual and clarifying questions to understand the code they were working with, rather than delegating to AI. Same tool. Different approach. One stayed Above the API. One fell Below.

That 17% gap is what happens when you optimize for speed without building verification capability.

A Nature editorial published in June 2025 makes the underlying mechanism explicit: writing is not just reporting thoughts, it's how thoughts get formed. The researchers argue that outsourcing writing to LLMs means the cognitive work that generates insight never happens — the paper exists but the thinking didn't. The same principle applies to code. The junior who delegates to AI gets the function but skips the reasoning that would have revealed why the function is wrong.

The mechanism is friction. When I started, bad Stack Overflow answers forced skepticism — you got burned, you learned to verify. AI removes that friction. It's patient, confident, never annoyed when you ask the same question twice. Amir put it well in the comments on my last piece: "AI answers confidently by default. Without friction, it's easy to skip the doubt step. Maybe the new skill we need to teach isn't how to find answers, but how to interrogate them."

We optimized for kindness and removed the teacher.

What Actually Needs to Change

The junior role needs three shifts in how we define entry-level skills, how we build verification capability publicly, and how we measure performance.

Entry-level used to mean knowing syntax and writing functions. Now it means reading and comprehending code, identifying architectural problems in AI output, and understanding that verification is more valuable than generation. The portfolio that gets you hired in 2026 isn't a todo app — AI generates one in 30 seconds. It's documented judgment: "Here's AI code I rejected and why." "Here's an AI suggestion that seemed right but failed in production." "Here's how I verified this architectural decision."

Stack Overflow taught through public mistakes. That's why we started The Foundation — junior developers need public artifacts that prove judgment, not just syntax. Private AI chats build no portfolio. No proof of thinking. Invisible conversations that leave no trace.

The interview question needs to change too. Not "build a todo app in React" but "here's 500 lines of AI-generated code for a payment gateway. Tests pass. AI says it's successful. Logs show it's dropping 3% of transactions. You have 30 minutes. What's wrong?" That's the new entry test. Can you find the subtle bug AI introduced optimizing for elegance over financial correctness? Can you explain why this clean code fails at scale?

Companies waiting for AI-ready juniors to appear are part of the problem. Nobody is training them. That's your job.

The Economic Reality

Companies see AI as cheaper than juniors. That math only works if you ignore production bugs from unverified code, architectural debt from AI's kitchen-sink solutions, security vulnerabilities AI confidently introduces, and scale failures AI didn't test for.

Cheap verification is expensive at scale. A junior who catches those problems early is worth 10x their salary but only if we teach them how to verify.

NorthernDev asked the right question: if we stop hiring juniors because AI can do it, where will the seniors come from in 2030?

Nobody has a good answer yet. But the companies that figure it out will have a pipeline. The ones waiting for AI to get better will be stuck with seniors who retire and no one to replace them.

The junior developer isn't extinct. The old path — syntax to simple tasks to complex tasks to senior — is dead. The new path runs through verification, public judgment, and the ability to interrogate confident-but-wrong answers before they reach production.

That's not a lower bar. It's a different one.

The ladder didn't disappear. We just forgot we have to build it.