The Work Starts When the Thought Does

Somebody asked me this week if what I'm running is self-healing software. It isn't, and the difference matters.

Self-healing means a system survives a fault without anyone touching it. Kubernetes restarts the dead pod, the circuit breaker trips, the autoscaler adds capacity. All useful, and all identical in one respect. When it's over, the source code is byte-for-byte what it was before. Nothing got fixed. Something got tolerated.

What runs against my projects changes the source. The thing running it is BlackOps.

There's no overnight batch job. Logging the defect is the trigger, so the work starts at the moment the thought does. An idea in the car or while I'm getting ready for work gets described, logged, and fired right then. Or I leave it in the queue and tell Claude later to pick up whatever's open. The running happens while I'm doing something else either way.

It helps to say what the old version cost, because the comparison is the whole point.

A personal project got whatever was left of me after work. Adding one feature meant a run of evenings at the keyboard, and a real share of each of those evenings went to reloading my own context, sitting there remembering where I'd stopped and what I'd been in the middle of. Three or four weeks of that and the thing might be in the app.

Now I talk about it in the morning and come home to it ready to deploy.

One MCP server, two consumers

BlackOps exposes itself over MCP, and that single decision is why the rest of this works. MCP is just a standard way to hand an AI model a set of tools it can call, so anything that speaks it can read and write my system without a bespoke integration.

The agents read and write through it. I read and write through it. There's no separate admin console where the human version of the truth lives apart from the machine version. When a sortie is running against the repo and when I'm talking to a Claude chat at a stoplight, we're both hitting the same server.

Everything in it is a note. Bugs, features, and content ideas all land the same way, with structured frontmatter and tags, and the tags are the queue. Tagged bug, status Open. That's the backlog. Jira, boards, and the ceremony where six people negotiate story points are all gone.

Agents are bad at reading dashboards and very good at reading structured text. So I stopped building a system for humans that agents have to scrape, and built one for agents that I happen to be able to read.

The notes are just files

The vault is Obsidian. Plain markdown on disk, in a folder I own, syncing to my phone like anything else.

BlackOps writes through MCP and the files land there. That connection is optional, and it's the piece I'd argue hardest for. If BlackOps went away tomorrow I'd still have every bug report, every feature spec, and every decision an agent made along the way, sitting in a directory I can open in any text editor. None of it is trapped in a database, including mine.

It also means I can work the queue from a phone in an airport with no tooling at all. Open the vault, type an answer underneath the question the builder left, and the next run reads it.

I file the work by talking

I don't open a tracker. I say what I want in a chat and a skill writes the note for me, with the right frontmatter and the right tags, into the right brain. A brain is a scoped set of notes on one subject, which is what keeps the fitness app's defects from sitting next to my wine tasting log.

The note is addressed, and that's the whole trick. Tagging it feature plus blackops is what the builder keys on. Filing the idea and starting the work are the same action, which is why there's no gap between having the thought and the machine owning it.

What that looks like on a Thursday

I talk through a feature over coffee, the way you'd describe it to another engineer. What it should do, where it goes wrong, what I don't want it turning into. Two minutes, out loud, no computer. It gets logged.

Then I go do the day job at a large consulting firm.

I come back around 5pm and it's built. Branch, tests, pull request, and a note updated with what got decided along the way. Some days there's a second one queued behind it.

The interesting hours were the ones where I wasn't there.

The bug fixer

Logging the defect is what fires it. The note lands, a sortie opens against the repo, and it diagnoses the bug, writes the fix, opens a pull request, and updates the note with what it did and why. A sortie is an autonomous Claude Code session, pointed at one job and left alone to do it.

It clears about ten a week. I read the PRs when I feel like it.

The feature builder is the one I'm proud of

A bug fix has a small blast radius. Features are where agent pipelines usually fall apart, because people build them as prompt chains and a prompt chain has no way to fail.

Mine is a gated DAG, a fixed graph of stages where each one has to clear before the next can start. Intake, plan, spec gate, test author, implement, verify gate, PR, document, caliber gate, ledger. The caliber gate is a quality bar on the work itself, separate from whether the tests pass. Gates mean stages can't be skipped and can't be faked. Tests get authored before implementation, on purpose, so the verify step isn't the model grading its own homework.

The graph a feature moves through. Gates cannot be skipped or faked, and any of them can drop into the blocked lane underneath. The dashed edge is the part that still needs me, and the section below explains why.

The part I like most is what happens when it doesn't know something. It doesn't guess, and it doesn't hallucinate a requirement and then build the wrong thing beautifully. It writes the open questions into the note, pushes the note to me, and exits clean as Blocked.

A real one. This run was told to audit before changing anything, so it audited, found two of my assumptions did not survive the data, and stopped without touching code. Q6 is it reading my own published FAQ and noticing the pricing change contradicts a promise on it. Stripe identifiers and four of the six questions are redacted.

I get an email. I answer in the note, usually out loud, usually not at a computer. The next run picks it up at RESUME, folds the answers back in, and continues from where it stopped. The agent doesn't need me awake, and I don't need to sit there watching it work.

There's a second email at the other end. When a feature completes, the report lands with what shipped, which decisions got made along the way and why, what tests were authored, where the pull request is, and anything it chose not to do. DOCUMENT and LEDGER are stages in the graph for exactly that reason, so the report gets written from the record instead of from the model's recollection of its own session.

Most days that email is the entirety of my involvement.

Except the return path isn't finished, and I found that out writing this paragraph.

The questions go out. Both answer channels work. I can fill the ANSWER slots in the note, or reply to the email with Q1: prefixes, and either one gets folded in and attached to the question it answers. The reply addresses are even tokenized per share and revoked once the question set closes.

What doesn't happen is the next run. The answers sit there, folded in and ready, until I open a session and fire the builder at the note. I'd been describing this loop as asynchronous while personally carrying the ignition, and I never noticed because answering and firing felt like one motion.

So I logged it, mid-paragraph. Here's what went in:

# Feature: Auto-fire the resume sortie when a blocked note's questions
# are answered

**Status:** Idea
**Priority:** High
**Effort:** Small

## Problem

Answer ingest already works. Note ANSWER slots and tokenized email replies
both get folded into the note and attributed to the right question, and the
reply addresses are revoked once the question set closes.

What is missing is the trigger. A fully answered note stays Blocked until I
open a session and fire the builder at it by hand. The ignition is the last
manual step in a loop I otherwise describe as asynchronous.

## Acceptance Criteria

- A complete answer set fires the resume sortie with no session from me
- A partial answer set leaves the note Blocked and does not fire
- Rapid successive edits debounce to a single sortie
- A note answered but unfired past a threshold surfaces on the dashboard

Tagged, synced to the vault under features/open/, queued. That took about as long as writing the sentence before it, and the open question at the bottom of the note is the kind of thing the builder will stop on rather than guess at.

I don't read every line, and I've stopped pretending I should

Santiago, who posts as @svpino, posted this week about giving up on reviewing AI-generated code. Two weeks without reading any of it. What moved him was noticing that his remaining objections were stylistic, that he wasn't catching real bugs anymore, and that his hours went further designing ways to verify the system works than auditing the lines inside it.

That's the honest answer for why I'm fine with a merge I didn't read.

The attention didn't disappear, it moved. It went into the graph. The spec gate, the tests authored before implementation, the verify gate, the caliber gate: those are where I spend the effort now, because they're what decides whether a change is allowed to survive. Reading every diff afterward is the weaker version of the same job, done by hand, after the fact.

The limit is real though, and Santiago names it too. None of this goes far without an experienced person pointing it. The gates encode judgment I already had from thirty years of shipping commerce systems. Hand the same setup to someone who hasn't built anything and it will produce the wrong thing very efficiently.

Real users are the error surface

A beta tester on my fitness app started sending field reports. Retired engineer, the kind of person who writes down what actually happened instead of "it's broken."

He surfaced two things. Writes were remote-first with no offline queue, so sessions logged in a gym basement evaporated. And with no persistent injury or goal context, the app kept pushing him toward movements he physically couldn't do, so he started entering fake numbers to make it stop nagging him.

Both went in as notes. The sorties picked them up.

Sit with the second one. The real defect wasn't a stack trace. It was a product gap severe enough that a user chose to lie to the software rather than argue with it, and no amount of self-healing infrastructure catches that.

Nothing ships in my voice unless a proofreader agent clears it

Mandatory gate, not an option. It pulls the canonical brand voice out of BlackOps and audits the draft line by line for the tells: the AI cadence, the hedge openers, the parallel-structure singsong, the buzzwords, and anything invented that wasn't in the source. It fixes what's mechanical and reports the judgment calls without deciding them.

Automation writes the code. What I sound like stays mine.

The last mile was never the expensive part

The industry spent a decade automating deploy and threw itself a parade about it. CI/CD, GitOps, one-click rollback, the whole conference circuit. Fine, solved.

Except deploy was never where the money went. The cost was always the human in the middle. Somebody has to read the ticket, understand the codebase, write the fix, and open the pull request. Every consultant selling you an AI transformation deck is still quietly assuming that human is in the loop, because their business model requires it to be.

That's the part that's gone from my stack. Not the deploy. The engineering.

---

Want more like this? Subscribe to my newsletter for weekly deep dives into frontend development, AI, and building systems that run without you.