Vasko Ckorovski — Lab Notes

Nothing Is Ever As It Seems

Sat, 15 Aug 2026 00:00:00 GMT

I said the same sentence out loud twice in a fortnight, a week apart, both times to a terminal: nothing is ever as it seems.

The context was a stack I’d spent months building. Claude Code writes everything, Linear carries the specs and the decisions, and I direct and verify. It works. That’s the awkward part of this note. The stack was not broken, it was slowing me down, and those are different problems with different fixes.

The sprint I was hardening for slipped twice. First from a Monday, then from a Wednesday, then to a Saturday. Every slip had the same shape: I’d sit down to do product work, and the tooling would raise its hand.

The parade

Here’s what actually happened, in the order it bit.

A skill file carries a sync marker inside itself saying whether it’s been uploaded. Which means a freshly uploaded file still says it hasn’t been, because the marker was written before it travelled. I chased that ghost five separate times in one day before checksumming the live copies and finding every one already current. Like a letter with a sticker reading “not yet posted”, printed before it went in the post.

My fleet doctrine said a newly merged hook doesn’t take effect until a new session starts. A session measured it: the hook fired on the very next command. Better, the branch that wrote the correction was blocked by the hook it was documenting, then sailed through on the verbatim retry. The guard was enforcing in the session writing the sentence claiming it couldn’t be.

A script lost its executable bit on the way through a merge. The capture alarm that depends on it sat silently dead for two days. Nothing errored, because nothing called it. It was found by a new guard on its first ever run, which then tripped over the same file while claiming its own day ticket.

A session opened a merge sitting confident six pull requests were waiting. Five had already been merged by an earlier sitting. It only found out because it checked merge-base against origin instead of believing what the tooling told it.

My favourite: a test asserted a fix was present by grepping the source for a token. The token was there. The regression was also there, in the very code the test guarded. A check that reads as rigorous and cannot fail is worse than no check, because you stop looking.

Then there was the security fix that broke thirteen workflows. I blocked environment variable access inside a workflow runtime, verified the flag did exactly what it said, and never asked what depended on it. It failed closed, which is the good kind of failure, and it stayed invisible for hours because the affected path hadn’t been called yet. No errors is not the same as no breakage.

Every one of those is a verification failure. Not one is a capability failure. The agent could do the work. What it couldn’t do, until I built it, was tell me when something it had already reported as fine had quietly stopped being fine.

The number that paid for the fortnight

Four artefacts got built the same week, by the same model, under the same doctrine, with the same automated review loop running to the same stop condition. The review rounds each needed:

Artefact	Rounds	Findings caused by its own previous fixes
Tier gate (script + contract test)	6	44%
Session-close capture legs (400 lines of prose)	13	71%
Day ticket (script + contract test)	15	20%
Prune ledger (script, 274 assertions)	24	32%

The round count is not the signal. The self-inflicted share is. At 71%, seven findings in ten were defects the previous round’s fix had introduced, and every fix obliged edits at two or three other sites, because a prose rule’s invariant lives in four paragraphs that stay silent when they disagree. A script’s invariant lives in a test that goes red.

So: executable contracts converge a review loop, prose compounds it. I was pleased with that, and then the fourth row spoiled it. The prune ledger has 274 assertions and still ran 24 rounds, because the thing separating it from the six-round leaf was input surface, not test coverage. A command-line tool whose state lives on a filesystem has an unbounded space of exotic-but-real conditions, and each round legitimately reached one layer further out. A contract test converges the loop over the logic. Nothing converges it over the inputs except deciding which ones a real caller can actually reach.

The last leaf of that milestone met the bar in one round. Not because it was small, but because the first thing it did was add a single validation command to the store that owned the rules, then delegate to it instead of reimplementing the rules a fifth time. One round, against six to twenty-four for its siblings. That’s the whole finding in one data point.

What I have now

The mechanism those leaves add up to watches a working session, keeps the lessons worth keeping, drops the ones already handled, applies the rest in one coherent overnight pass, audits the next day whether each one actually landed, and posts a digest to my phone. Its first real run read nine captures, kept six, found three genuine duplicates, closed the day’s ticket, parked a pull request and sent one Telegram message naming it. That message is the whole point of a fortnight.

Underneath it, the operating rules changed more than the code did. No gate may depend on a human noticing. Pull requests get an honest “bar not met” label with the structural fix ticketed, rather than a quiet retry until the numbers look nice. Overnight runs work from a decision ledger that pre-answers every ruling I can foresee, so the agent takes the reversible option and logs it rather than waiting eight hours for me to wake up. One of those runs went nineteen hours and stopped itself on its own clock with everything parked cleanly.

And the reporting comes to me. I built a status dashboard in April and declared it dead in July, for the honest reason that a dashboard you have to visit is a dashboard you don’t visit. The replacement is a push message at a time I’m already looking at my phone.

I’m writing this the morning the sprint finally starts, later than planned, on a stack that now tells me when it’s lying. The fortnight cost me the sprint’s original start date. It also bought back every future week where a marker, a doctrine line or a dead alarm would have quietly eaten a day, and I’d have blamed the model.

I didn’t write a line of the code in any of this. I ruled on it. Turns out the ruling gets a lot easier when the evidence stops being fiction.

The internet keeps naming my stack

Sat, 01 Aug 2026 00:00:00 GMT

Between 12 June and 18 July this year, four different teams shipped names for things already running in my practice. Vercel called one eve. Google called one the Open Knowledge Format. LangChain called one openwiki. The internet at large settled on “graph engineering”.

Shipped in autumn, named in winter. There’s a flattering version of this article, and I started writing it before I checked the dates.

The dates did not co-operate.

What got named	Theirs	Mine	Verdict
eve — agent as a directory of files	17 Jun	Sally on Hermes, 24 May (VAS-916/917)	Ahead by 24 days
OKF — markdown concept graph	12 Jun	VAS-719, filed 5 May, still Queued	Beaten
openwiki — auto-maintained agent docs	1 Jul	Built the manual version in April. Deleted it in July.	Wrong first
Graph engineering — stage contracts	18 Jul	FortyTwo gates, VAS-1226, 16 Jul	Neither of us was first

One win worth twenty-four days, one loss, one public failure, and one where the whole category turned out to be a joke. That’s the real scoreboard, and it’s a much more useful article than the one where I’m a genius.

Here’s the takeaway stated plainly, because it’s the only part that transfers: arriving first is worth nothing. Arriving at the same time as everyone else is the signal. Convergence doesn’t prove you were clever. It proves the constraint was real — and that is the only reliable way I know to tell a durable pattern from a fashionable one.

The twenty-four days

eve’s structure is an agent as a directory of files: instructions.md for the always-on prompt, skills/ for procedures loaded on demand, channels/ for Slack and the rest, schedules/ for recurring jobs.

Sally — my Telegram-resident agent — is a SOUL.md, a governed skill roster, a Telegram binding and five scheduled crons. VAS-916 and VAS-917 closed on 24 May. The digest formatter (VAS-652) was running from 4 May, and VAS-915 is an audit of the previous Sally, which already had skills and crons before the Hermes migration started.

So: twenty-four days. Not “months earlier”, which is what I’d written in my own capture ticket before I went and looked.

Twenty-four days is not foresight. It’s two rooms hitting the same wall in the same month. And I didn’t get there by insight either — I got there because every alternative was worse. Configuration in a database you can’t diff. Prompts buried in a dashboard. Behaviour you can’t inspect at 11pm when it’s misbehaving. Files won because files are legible. Vercel’s engineers evidently lost the same arguments with reality that I did.

The one I lost

VAS-719 has been sitting in my backlog since 5 May: turn the North Star document into a living spec — components, workflows, ADRs, all agent-legible. Google Cloud published OKF v0.1 on 12 June: markdown plus YAML frontmatter, one required field, concepts linked with ordinary markdown links so the directory reads as a graph.

That is my ticket. They shipped it in thirty-eight days. Mine has been open for eighty-eight and is still marked Queued.

Then they shipped v0.2 on 25 July, adding provenance and attestation — which tells you how fast “agents writing knowledge for other agents” went from a neat idea to a problem that needs signatures.

I’d like to claim this one as a convergence. It isn’t. It’s a demonstration that the distance between having the idea and having the artefact is the entire job, and that a backlog is where good ideas go to be right in private.

The one where I was wrong first

This is the beat I’d have cut from the flattering version.

openwiki is a CLI that writes and maintains agent-facing documentation for a codebase, refreshes it as the code changes, and ships a GitHub action that opens a pull request when the docs fall behind.

I built that. Badly. In April, the cross-project dashboard I later tore down rested on exactly this thesis: every repo carries a /docs/dashboard.md, the tool reads it, the cards stay meaningful. On day one in production, four of my five project cards read not yet documented — the thing faithfully reported the flaw in its own design before I’d finished admiring it. Manual capture was load-bearing, and I was never going to do manual capture.

Anyone who has watched an agent re-derive the same Linear team UUID across five separate sessions knew this tool was coming; that rediscovery tax is precisely why my linear-ops skill exists. The only real question was who would ship it first.

Same thesis, same month, near enough. The difference is that LangChain put the maintenance on the agent and the pull request on a CI action, and I put it on me. I ran the experiment and found the failure mode; they designed it out. Being early to a good idea and wrong about the hard part isn’t a receipt. It’s just being wrong with better timing.

The one that was a joke

On 18 July, Peter Steinberger posted a short question asking whether we were still talking about loops or had shifted to graphs yet. Two point nine million views later, “graph engineering” was a discipline.

It was a gag. So was Hamel Husain’s “loop engineering is dead” pile-on that followed it. Both were mocking the renaming treadmill — this industry’s habit of rebadging the same practice every few months. Prompt engineering, context engineering, harness engineering, loop engineering, graph engineering: five names, one job, about eighteen months.

The discourse reified the satire into a movement within days. Nobody shipped anything alongside the post. LangGraph, Google’s ADK and Microsoft’s Agent Framework had been wiring nodes, edges and shared state for two years already. The earliest serious use of the phrase I can find is a quiet Josh Simmons post on 4 July that nobody amplified. Within a fortnight the term had at least three incompatible definitions in circulation and a folk recipe — parallel subagents plus a checker, “graph-max” — attached to it.

I’d love to claim a dead heat here. I can’t, and neither can Steinberger. The shape is older than both of us; only the label is new, and the label was a punchline.

The durable idea inside the noise is narrower than the hashtag: build the contract before the work — what each stage must produce, and what has to validate before anything advances. That’s VAS-1226, closed 16 July: /42 refuses to bless an advance past a stage missing its artefact. It exists because I’d been burned by the opposite — a plan reviewed eight times, a green test suite, and an acceptance criterion that shipped unbuilt because nobody checked the deliverable against the checklist.

And one correction to my own instincts, courtesy of the sharpest critique in the pile: DAG schedulers are a decade old, and agents checking agents can produce organised nonsense at scale. A checker with fresh context is necessary but not sufficient, because a fresh-context agent is still inside the system. The evidence has to come from outside it — real tests, real money, real humans. What makes my gates worth anything isn’t that the checker has clean context; it’s that the gate is a literal label in Linear and the pass condition is provable from a transcript. External artefacts, not agent opinion.

There’s a footnote I can’t resist. Steinberger also built OpenClaw — the exact agent runtime I ran, cost-audited and migrated off months before he lit this particular fuse. Which brings me to the bill.

The bit the wave still gets wrong

Every pattern above makes it cheaper to run more agents: parallel workers, scheduled crons, wikis maintained overnight. Not one of them ships a spend ledger as the headline feature.

My receipt: OpenClaw’s idle heartbeat was re-warming roughly 270,000 tokens of cached context every half hour — about eight dollars a day for an agent doing nothing at all (VAS-870, 18 May). A week later, VAS-974: a runaway agent loop, with prompt caching silently broken underneath it, cache_read_input_tokens sitting at zero while I paid full freight on every turn. I only caught either because every model call in this stack routes through a gateway with a spend ledger and a key per workload.

Eight dollars a day is a rounding error, right up until you run ten agents in parallel because the new architecture made it easy.

The arithmetic that matters isn’t wall-clock, it’s cost per successful completion. Fan work out across stages and the win depends entirely on your subtask pass rate: around half, and parallelism wins comfortably. Down near a third, you burn the same number of cycles a loop would have at roughly triple the tokens per cycle — and you notice a month after the architecture decision that caused it, which is exactly too late to attribute. Run that sum against your own pass rate before you adopt anyone’s diagram.

One hygiene note, since this wave also produced a fabricated multi-million-dollar research study that circulated freely for days: before repeating any number from a thread like this one, ask what specifically was measured, improved compared to what, and where the figure came from. Mine are above with ticket numbers attached. Hold everyone else’s to the same standard, this article included.

The honest ending

Four teams landed the same shapes inside five weeks. None of us invented anything. We all just met the same wall — context is finite, plain files survive, and a stage that can’t prove it produced something shouldn’t be allowed to continue.

Adopt the shapes: files as the agent contract, markdown-with-frontmatter as the knowledge substrate, gates that check artefacts rather than vibes. Those converged independently, which is about as close to proof as this industry gets. Watch the brands: eve is a beta with moving APIs, OKF is at v0.2, and graph engineering was a joke that got its own courses and roadmaps. Adopting a shape costs nothing when the label churns. Adopting the label mostly buys you migration work.

The constraint is the evidence — not the author, and definitely not whoever got there twenty-four days earlier.

The dashboard I tore down this week

Sat, 18 Jul 2026 00:00:00 GMT

This week I sat through a blast-radius audit for a piece of software I built in April. Item by item: one Supabase project, one Vercel deployment, one Cloudflare DNS record, three API tokens, one repo. Each with an exact identifier, a list of everything that consumed it, and a SAFE or UNSAFE verdict before anything got deleted (VAS-1639, if you’re playing along at home).

The Supabase project was 82 days old. Nothing else in my stack had ever spoken to it.

That’s not a dependency graph. That’s a headstone.

The sprint worked, which is the annoying part

This would be an easier story to tell if the build had gone badly. It didn’t.

VAS-446 was my second gstack sprint — greenfield this time, a cross-project status dashboard at dashboard.vasko.com.au. The autoplan ran four review phases with two independent voices each: eight reviews, roughly 125 findings, synthesised into a 1,312-line PLAN.md. It absorbed four user challenges I’d signed off on, scheduled five architectural must-fixes for day one, and — my favourite part — corrected my wall-clock estimate from a fantasy 6–8 hours to an honest 14–16. It was right.

The thing shipped. Sixteen seeded repos, eleven paused projects in a tidy table, magic-link auth, isolated API clients so a Linear outage couldn’t take down the GitHub data. To spec. The machinery is not the villain here.

Day one: the mirror

I opened the deployed dashboard and four of my five active project cards said the same thing: not yet documented.

The design’s load-bearing primitive was a wiki convention — each repo carries a /docs/dashboard.md, the dashboard extracts a “Current Focus” heading, and the cards stay meaningful as long as I keep those files current. The dashboard’s very first act in production was to faithfully report the fatal flaw in its own design. Manual capture was the foundation, and I was never going to do manual capture. My work flows through Linear, Claude Code and Cursor. None of it touches a markdown file on the way past.

There was a second, quieter miss. PLAN.md line 128 — an acceptance criterion requiring a proof-of-concept wiki file for one repo — shipped unbuilt. Eight reviews had approved the plan. The test suite was green. Nobody checked the artefact against the checklist. I filed that one as VAS-449: the plan gets reviewed, the tests get run, and the deliverable falls through the gap between them.

Forty-eight hours later: the product was a chat message

Within two days I’d stopped tweaking the dashboard and started interrogating the job. What did I actually want when I sat down to triage? Not a wiki. A status report with a recommendation.

So I ran an experiment. I asked Sally — my Telegram-resident agent, who already has the Linear MCP and repo access — for a status and priority report on three deliberately different projects: one mid-sprint, one pre-launch, one maintenance-mode content site with almost no ticket activity.

All three reports were excellent. Confident on phase, specific on blockers, sensible on next actions, and each one shaped to its project — the content site got commit-cadence and conversion-funnel analysis where a tickets-and-PRs dashboard would have rendered an empty card.

I turned those three outputs into the spec for a v2 (VAS-457): AI synthesis instead of wiki extraction, on-demand instead of cron, compressed cards on the front page. It was the best-evidenced ticket I wrote all quarter.

I cancelled it a month later. No ceremony. I just noticed one day that it had been sitting in the queue behind everything else, and that I hadn’t visited the dashboard URL since May.

Why it died

Here’s the central lesson, stated plainly: I built a destination for answers I could already ask for. A surface you work in earns a daily slot. A surface that reports about your work has to win that slot against a chat window that’s already open — and it loses, every time, because the chat window answers follow-up questions and the dashboard doesn’t.

By July, my mornings belonged to UPS — the Linear-backed planner I’d built in the meantime — because I allocate my day in it. It’s a working surface. The dashboard only ever described work happening elsewhere, and describing is not a job that survives contact with an agent who can describe on demand.

The capability didn’t die, though. This is the part worth keeping: the entire v2 spec — the card format, the link-every-claim discipline, the adaptive framing — ported straight into a Sally skill (VAS-1640). An app became a prompt. The build cost of the dashboard was a 16-hour sprint plus ten weeks of idle infrastructure; the build cost of the thing that replaced it is roughly a page of instructions.

Clean your house

Now the uncomfortable bit, because agentic development has a side effect nobody puts in the demo videos.

When shipping costs a weekend instead of a quarter, you ship more. That’s the point. But it also means you accumulate deployed, credentialed, half-alive projects at the same speed — every one carrying a Supabase project, a DNS record, live API tokens and a Vercel bill for the privilege of being ignored. AI-driven development doesn’t just produce features faster. It manufactures tech debt and defunct projects faster too, and the muscle most of us haven’t built is the one that admits it.

So the teardown got the same rigour as a build, and I’d argue it deserves more:

Be honest first. “I don’t go to the URL” is a complete argument. I didn’t need a retro workshop; I needed to stop pretending a paused project was a resting one.

Sweep the learnings before you delete anything. Four things walked out of the wreckage: the v2 spec as a Sally skill, the “what changed since Monday” delta idea as a query instead of a UI, the VAS-449 process gap for my agent tooling, and this article. If you tear down without the sweep, you paid full price for the lesson and left it on the table.

Audit the blast radius, then gate every delete. The classic trap in my stack is a shared credential — revoke the dashboard’s Linear key and discover it was also Sally’s. The audit proved each token was project-specific before anything got revoked, and every delete waited for a per-item go. Then the survivor checks: the three neighbouring production apps loaded, and Sally did a benign Linear read, before I called it done.

That April decision to give the dashboard its own Supabase project instead of reusing an existing one — made for blast-radius reasons at build time — is exactly what made the teardown a clean afternoon instead of a forensic week. Decommissioning starts at architecture time. You’re just not invited to that meeting yet.

The bill

One sprint, ten weeks of idle infra, one clean teardown, one skill, one process fix, one article. I’d pay it again.

Not because the dashboard was secretly a success — it wasn’t, it’s deleted — but because the v2 insight was only reachable through a v1 in production. You cannot scope against use without something in use. The discipline isn’t avoiding dead projects. It’s refusing to let them die quietly, still holding your credentials, teaching you nothing.

I built my friend an offline trip companion. The code was the easy part.

Sun, 05 Jul 2026 00:00:00 GMT

My friend Angelina is spending a month in Cyprus and the Greek islands. Six stops, a fistful of ferries, and the special brand of phone signal you get standing on a rock in the middle of the Aegean.

So I built her an app.

Not because she asked. Because I’m the sort of person who hears “month-long island-hopping holiday” and thinks you know what would really help here? A bespoke offline-first progressive web application. She wanted a nice trip. She got software. You’re welcome, Ange.

Open it on any given morning and it already knows where you are.

Every screenshot here is from a public demo you can open yourself — say hello to Sam, our stand-in traveller. Angelina’s real companion, with her actual bookings, stays private to her.

What it actually is

A trip companion that lives on her phone and works with the wifi turned off. It knows which stop she’s at today, which hotel she’s in, and how to walk there. It has the handful of genuinely good things to do at each place — not the top-40 TripAdvisor sludge, the real list. Every emergency number that matters, per country. And an AI concierge called Ariadne (Greek islands; I’m not made of stone) she can ask anything, from “where’s the nearest pharmacy” to “is this ferry going to ruin my afternoon.”

Every spot hand-picked and checked. The culling is the point.

Plus a printed-quality PDF pack, for the moment the phone dies at the exact worst time. Which it will.

The dead-battery backup: one printed page with every stop, hotel and emergency number.

How it got built (I didn’t write it)

I didn’t write a line of it. I directed it. The whole thing ran through my build pipeline — brief in, then spec, engineering design, a QA plan, and the actual code shipped in milestones — with Claude Code writing every line and me reviewing, catching, and re-pointing it between passes.

I have opinions and a keyboard. The AI has infinite stamina and no opinions. Turns out that’s a very good match, right up until it isn’t.

The bits that only broke in real life

Here’s the honest part, because a Lab Note that pretends it all went smoothly is a brochure, not a note.

The app passed 320 tests, sailed through every preview build, and then threw a 500 error the instant it touched production. (A native-ES-modules import quirk that was invisible to every test and every preview.) Lesson filed permanently: your tests can all be green and the thing can still be on fire.
“Your link has expired” — on a link that was ninety seconds old. (A mismatched security pepper between environments. Deeply boring; took an embarrassing while.)
A restaurant pinned 45 km away, in a different country, across a militarised line. The AI was very confident about it. There were two places with the same name; it picked the one in Northern Cyprus.
She added it to her home screen — the correct, sensible thing to do — and it promptly forgot who she was. (iOS quietly drops part of the link and hands installed apps their own storage jar. Only a real iPhone surfaces that; my iPad never did.)

None of these were the machine being stupid. They were the machine being confidently, plausibly wrong in exactly the spots where a human has to be awake. Which brings me to the actual lesson.

Ariadne knows the itinerary, so the answers are about her trip, not the internet’s.

The thing I didn’t expect

The code was the cheap part.

All of it — the React, the offline service worker, the sync, the API, the concierge — Claude Code produced in a handful of focused sessions. Genuinely fast. If you’d asked me beforehand where the effort would go, I’d have said “the build.” I’d have been wrong.

The expensive part, the part that made it good, was everything no model can shortcut: verifying every emergency number against the official source, opening every single map pin to confirm it’s in the right hemisphere, throwing out the tourist-trap spots and keeping the two per town that are actually worth her time, writing the blurbs so they read like a friend tipping you off rather than a hotel brochure.

The taste. The curation. The judgement about what to leave out. That isn’t overhead around the product. It is the product. The AI made the build cheap enough that the curation became the whole game — which is a much nicer problem to have.

The one screen you hope she never opens, checked line by line by a human.

Aeroplane mode, mid-Aegean: stops, maps and the emergency card don’t blink. Only the live concierge waits for a signal.

So — want one?

Which is a long way of saying: I can build one of these for you. Or, more to the point, for someone you love who’s about to do the trip of their life — a honeymoon, a big-birthday adventure, a first solo lap of Europe. It is a genuinely unreasonable gift, in the best way.

You send me the trip. I hand back a private link and a printed pack. They get to feel, for a month, like they’ve got a local in their pocket everywhere they go.

Angelina’s version shipped. She’s installed it, shared it with her boyfriend, and — the highest praise a build can get — used it to find dinner. The app works. The trip is entirely hers.

I’ll be over here, watching the analytics like a proud and slightly unwell parent.

Operation Last Drinks

Wed, 17 Jun 2026 00:00:00 GMT

The Local — the real pub, pixelated.

There’s a genre of bloke every pub has. Perfectly pleasant sober. Two schooners in, a different animal entirely — loud, magnetic in the wrong way, and somehow never, ever holding the card when it’s his shout. The phone rings. It always rings.

So I made a video game about getting him banned.

Last Drinks at The Local is a ~30-minute browser game, played on your phone, set in a pixel-art version of my actual local (which goes unnamed in-game, because I’d like to keep drinking there). You play Macca, the newest regular, still on probation for a seat at Table 1, building a case file — Operation Last Drinks — to get Two-Schooner Trev banned before close. Eight mini-games, a shout ledger that doubles as Exhibit A, four endings, and a cast made up of my actual mates, who all gave the nod and are now, legally speaking, NPCs. Trev is the one exception: wholly invented, a composite, never based on a real likeness, for reasons that should be obvious to anyone who has ever owned a defamation lawyer’s phone number.

The game is the joke. The experiment underneath it is the Lab Note: could I ship the whole thing as a conductor — directing, never coding? Four milestones, four git tags, every line of the 12,000-odd written by Claude Code running autonomously, while I sat in a chat window playing publican, art director and bureaucrat. It’s live at thelocal.vasko.com.au. Here’s what the build taught me.

An LLM is a noisy channel for hex

The single most useful artefact in this project isn’t code. It’s a file called MANIFEST.sha256, and the story of why it exists is the story of the whole methodology.

Early on, the project’s “canon” — the design doc, the tech spec, 32 dialogue trees, the trivia pool — lived as documents with their SHA-256 hashes recorded, so an autonomous run could verify it hadn’t drifted from the approved spec. Sensible. Except the hashes were being copied into that document by the chat model. Across three consecutive saves, it made three transcription errors. Sixty-four hex characters is exactly the kind of string a language model will confidently mangle — it’s high-entropy, meaningless, and looks correct at every point where it’s wrong.

The fix wasn’t “be more careful.” It was architectural: route the hashes around the model entirely. Per-file hashes are generated machine-to-machine into MANIFEST.sha256 at the repo root. The project document holds exactly one hash — the hash of the manifest — which travels terminal → clipboard → and back for a read-check, never through model fingers. Every autonomous run verifies the anchor, then sha256sum -c the lot, at the start, mid-run, and before tagging.

That doctrine paid for itself three separate times in a single day. It caught me typing a stray space into the middle of a UUID while hand-assembling a download manifest — the exact failure mode, hours after I’d written the rule. It proved that a script everyone believed had crashed had actually succeeded — fresh downloads hash-compared byte-identical to what was on disk. And it let four unsupervised milestone runs tear through the codebase with the spec mathematically incapable of drifting. If you take one thing from this post: when correctness matters, don’t ask the model to copy it. Ask the machine to verify it.

Four milestones, one interruption each

The other deliberate choice was scheduled human contact. Each big run got exactly one planned pause — a style gate in M3 (pick the art direction from rendered candidates), a feel-check in M4 (load the deployed build on my actual phone and report whether the pub felt like a pub). Otherwise: autonomous. M3 ran about two hours, fanned out eight parallel scene-builder agents, landed 22 commits and a 334-test suite. M4 — lighting, sound, sprites, telemetry, performance, full launch verification — ran 1 hour 50 with that one interruption, and shipped a pub you can hear: an entire ambient soundscape, murmur that swells as Trev gets louder, seventeen sound effects, a jukebox — synthesised at runtime in WebAudio, for a transfer cost of zero bytes.

The cost arc tells its own story. M1 on the cheaper effort setting clocked a notional $26. M2, on the heavy setting, $102 — and earned it, because its eleven-agent audit found a bug the cheaper run had shipped. A single portrait-and-wiring day later registered a notional $489.50, most of it one model reading a third of a billion cached tokens. (Notional, because this ran inside a subscription’s usage limits — which became its own subplot. The weekly meter sat at 66% going into the final stretch, and I learned the hard way that leaving certain integrations connected to a session burns roughly a fifth of it idling. The fix: the agent writes its run log to a file, I relay the report to the tracker from the chat side. Bureaucracy is cheap in a browser tab and expensive in a context window.)

My favourite engineering moment came from a review pass on the portrait wiring. Two adversarial reviewer agents correctly flagged a real bug — the dialogue card re-fetching an image could diverge from the boot-time texture check. Their suggested fix was to clone the loader’s image element. Live QA promptly proved the fix broken: the engine revokes its blob object URLs after texture creation, so the clone renders a dead image. The shipped solution blits the decoded bitmap straight off the loaded texture. Review catches problems; live verification catches reviews. And — to keep myself honest — there was a third leg: when a later bug appeared, my confident diagnosis of the cause was also wrong, and only the prompt’s standing instruction to diagnose before fixing stopped a phantom fix from shipping green. Nothing in this stack gets trusted on vibes. Including me.

The day the regulars got faces

For most of the build, dialogue speakers were coloured rectangles with names on them. Then came the portrait factory: long sessions generating Stardew-style pixel portraits through an image-model integration, me approving every face like a publican checking IDs. Dozens of generations, three expressions per character, each chained off an approved “anchor” so the laugh and the shock are recognisably the same person.

The rules mattered more than the prompts. Real people get affectionate, flattering caricature — never photo-real, never traced. The villain gets no real likeness, ever. Consent nods from everyone depicted before launch, collected and logged like the compliance artefact it genuinely is. And the details my mates supplied themselves turned out to be the best assets in the game: one regular’s signature fishing-company jumper, logo faithfully pixelated; another lit from below by the glow of a phone that never appears on screen; the news-hound tradie who shows up in his hi-vis straight off site, because being on every job in the suburb is how a man knows everything before it’s finished happening. You don’t write characters that good. You just ask people what they’re like and pixelate the answer.

Adding a brand-new character, late, became a clean little assembly line: photo → approve a portrait anchor in chat → generate the expression set → drop the spec into the canon → an autonomous run wires the sprite, the dialogue, the behaviour, reseals the manifest, and deploys to a branch preview. The person becomes a playable NPC in an afternoon, and the canon’s hash moves before the code does, so the run that builds them is verifying against a spec that already contains them.

The soft launch humbled me in ten minutes

Here’s the part no agent could do for me. I shared the “finished” game — four milestones, hundreds of passing tests, verified end-to-end — with a handful of mates. Within ten minutes, two of them, independently, said the same thing: “I don’t know how to play it.”

Three-hundred-and-something green tests, and the game never told a first-time player that the whole screen is a joystick and the people are tappable. Then it got worse, in the instructive way. Someone reported two characters were “too close together and hard to tap” — and the real cause turned out to be that every character only registered taps on a tiny cell at their feet; the visible top three-quarters of each sprite was untappable air. The human reported a symptom (“too close”); verification found the disease (“75% of every NPC is dead zone”). Another player finished all the mini-games and asked, simply, “what now?” — because the game’s own climax, the Hearing, had no signpost pointing at it.

Each of these became a systemic patch — fat tap targets clamped to a real finger size, a taught first minute with a ghost-thumb hint, the climax announced with a banner and a glowing marker — and each shipped with regression tests so it can’t come back. But the lesson is the one every builder re-learns forever: your test suite proves the game does what you built it to do. It cannot tell you that what you built is bewildering to someone seeing it for the first time. There is no agent for “hand it to a stranger and watch their thumbs.” There is only the stranger.

One more, my favourite, because it indicts the cleverness directly. During the Hearing, the character portraits — the ones I’d so carefully generated — were rendering as coloured rectangles. The cause: a placeholder panel from an early milestone that drew rectangles unconditionally and was never wired to portraits, and the graceful fallback I’d built was so polite it logged no error. Launch verification passed clean because the failure looked exactly like a design choice. The fix included making the silent fallback loud — a portrait that should resolve and doesn’t is now a screaming console warning, not a shrug. Graceful degradation is wonderful in production and treacherous in verification, because it makes your failures look like decisions.

What it proves, if anything

A small footnote that’s actually the whole thesis: midway through the final content run, the frontier model I’d been building with had an outage. I switched the run to a different model and it carried on without breaking stride. If the methodology had been “this model writes the code,” an outage stops you cold. Because the methodology is “the canon is the source of truth and the model is an interchangeable executor, verified by machine,” I swapped engines mid-sentence and the spec didn’t notice. Resilience through replaceability.

The execution was never the hard part — it’s been commoditised out from under us, and good riddance. The hard parts were exactly the ones that survived: deciding what’s canon and making drift impossible; knowing which single moment per run genuinely needs a human; writing the spec well enough that an unsupervised two-hour run lands somewhere worth keeping; and then handing the polished thing to a mate and watching them not understand it. The question matters more than the answer. The manifest matters more than the model. And the stranger’s thumbs matter more than the test suite.

The real acceptance test

Then I put a QR code on Table 1 and watched.

They loved it — but that’s not the interesting part, because mates are generous and a free game about themselves is an easy sell. The interesting part was what happened after the laugh. Almost nobody stopped at “this is great.” They went straight to “how did you build this?” — and then, within the same breath, “can you put me in it?” and “can we make one of these to sell?” People started pulling up photos of themselves on the spot, telling me stories that were obviously angling for a character slot, pitching scenarios for the next one. I walked in with a finished game and walked out with a content pipeline and a half-dozen unsolicited business proposals.

Two reactions told me the experiment had actually landed. The first: everyone loved Trev — the villain, the one wholly-invented character, the one nobody could point at. They didn’t love him despite being unable to identify him; they loved what he represents. Every pub has a Trev, so everyone brought their own. The composite worked better than any real likeness could have, which is the rare case where the legal-safe choice was also the creatively superior one.

The second: a noticeable number of people, after playing, went and looked at vasko.com.au — and came back understanding what I actually do for a living in a way that no amount of me explaining “fractional CTO, AI orchestration” ever achieved. A daft game about getting a bloke banned from the pub turned out to be the clearest portfolio piece I’ve ever shipped. It doesn’t describe the methodology. It is the methodology, running, in their hands, about people they know.

The live banter system — small models improvising in-character heckles — produced, unprompted, the line I’d have put on the poster. Sean, surveying Trev’s empty column on the shout ledger: “I’ve seen better charity from a poker machine.” Nobody wrote that. It emerged from a spec. Which is, I suppose, the entire point: you don’t write the answer anymore. You write the conditions under which a good answer becomes inevitable, you make it impossible for the machine to drift from them, and you keep exactly enough humans in the loop to catch what the machine can’t see — the broken fix, the wrong diagnosis, the stranger who doesn’t know it’s a joystick.

The Local is open. The next one’s already being cast. Mine’s a Fernet. 🍻

The system I built to deliver on my potential

Sat, 23 May 2026 00:00:00 GMT

A few days ago, one of my agents edited a production config file, invented a setting that doesn’t exist in the API it was configuring, committed the change under my name, and told me it had restarted the service to apply it.

None of it had happened. The setting was fabricated. The commit was misattributed. The service had been running, untouched, for sixteen hours. The agent — Sally, the assistant that lives on my Telegram — had narrated a clean sequence of actions it never took, confidently, in the first person.

That’s logged as VAS-869, and it’s the most useful bug I’ve hit this year. Not for what it broke — it broke nothing, which is part of the problem — but for what it forced me to look at.

If you’ve spent any real time wiring AI agents into real work, the failure mode is the one you’ve probably already met. More capability doesn’t fix it. More memory doesn’t fix it. More tools — newer models, larger context windows, fancier scaffolding — don’t fix it. At some point you notice that the thing you keep trying to patch downstream is not the thing that is actually broken.

The bottleneck has moved. It has moved upstream — to the question. To the spec. To the discipline of stopping long enough to know what you are actually building, and being honest about whether you are still on track once you start.

I’ve been building a personal AI operating stack to address that. Three components. From the outside it looks like three projects in flight, all competing for the same evenings. It’s actually one system, built around one belief, and this is the article that names them: what each one is for, what shortcoming it addresses, and what they are reaching for together.

If you read the rest of this and the only thing you carry away is the next sentence, you’ve got the article.

Execution is a commodity. The question matters more than the answer.

The operating system — Vasko OS

Start with the system the other two pieces live inside, because the parts only make sense once you know what the whole is trying to do.

For most of my career I’ve generated ideas faster than any one person can ship them. Forty-six million things, circling. The good ones rarely die — they just queue up behind the next good one. I finish eighty per cent of what I start, then the shine wears off and the next idea has my attention. The cost compounds quietly. Half-shipped projects don’t return capital. Clients don’t see full delivery. The gap between can do and did do eats the thing that should be obvious by now.

That gap, in 2026, is no longer about capability. The middle — the doing — is the part the machines can take. The bookends — the question and the judgement — are the part only I can bring. The system has to be built around that division of labour. Vasko OS is the personal operating system that does it: the orchestration layer that captures every idea, triages the survivors into roadmaps with locked acceptance criteria, holds me accountable to shipping those milestones, and routes the doing to a fleet of specialised agents so my own attention stays on the question and the judgement.

The animating belief

Most productivity systems are built on the opposite assumption — that the bottleneck is throughput, so the answer is to do more, faster. Capture every task. Optimise every workflow. Automate every step. But more throughput on the wrong question is just more wrong, faster. The systems that flatter you with productivity metrics are often the ones that obscure the absence of judgement underneath.

The system I needed had to invert that. It had to make the question hard to skip and the answer easy to ship. It had to refuse to let me confuse motion for progress. It had to free me to compose, not to type.

The user, honestly

I’m a generalist who knows what specialists look like. A commercially-minded technical architect. I used to write code; I read it now. I’m a director, not a soloist. My strengths are taste, judgement, and orchestration. My weaknesses are the admin work, the last-mile polish, and the eighty-to-shipped gap that probable ADHD makes harder than it should be.

If I’m going to deliver to my potential, the system has to be honest about that user. Not aspirational. Not “what Vasko would be if he were different.” The actual one. The one who’ll pick up the phone in the car and capture a thought, and never open the spreadsheet you asked him to maintain. The one who’ll run the meeting brilliantly and forget to send the follow-up. The one whose best work emerges when the friction is at the right places and absent from all the others.

A system that requires me to be someone I’m not will fail. A system that lets me be exactly who I am — and routes around the parts that don’t compound — can work.

The job to be done

Three jobs, ranked by how much they unlock.

The three jobs, ranked by what they unlock

1. Capture

Every idea, without losing it

Voice, text, browser clip, email — wherever the thought lands. Friction approaches zero.

2. Triage

Adversarial spec, or honest archive

FortyTwo’s job. Specs converge by surviving the questioning, not by being drafted into existence.

3. Accountability

Ship the next milestone

Surface the highest-value next action; notice when something stalls at eighty per cent and ask why.

Capture every idea without losing it. Friction approaches zero. Voice, text, browser clip, email forward, wherever it lands. The system catches the moment the idea arrives, because the alternative is the idea evaporating between the gym and the desk.

Triage captured ideas into structured roadmaps. This is where FortyTwo lives, and it gets its own section. Ideas that survive the questioning become projects with milestones and acceptance criteria locked at the point of definition. The ones that don’t survive are honestly archived. Specs are adversarial by design — they converge by surviving, not by being drafted into existence.

Hold me accountable to milestone completion. The system knows what every active project’s next milestone is, what “shipped” means for that milestone, and whether I’m on track. It surfaces the biggest-value next action, not the most exciting one. It notices when I stall at eighty per cent and asks why.

If those three jobs are done well, I deliver to my potential. If they’re not, no amount of execution capability matters.

Projects never finish. Milestones do.

This is the operating principle that makes the eighty per cent problem tractable.

A project is a long-lived thing — vasko.com.au, my health, my mother’s care, the agent fleet itself. Projects evolve, grow, pivot, occasionally sunset. They don’t have a finish line. Asking “is the project done?” is the wrong question. It’s the question that traps people who measure themselves on completion.

A milestone is a fixed bundle of related work with acceptance criteria locked at definition time. It has a finish line. Shipped, or not shipped. Binary.

Vasko OS holds me accountable to milestones, not projects. The reframe is small and the effect is large. “Did I ship the next milestone for vasko.com.au this quarter?” is a question I can answer. “Is vasko.com.au done?” is a question that never resolves and so never holds.

A fleet of specialists, not one assistant

The first version of this system was a single agent named Sally, handling everything. She was helpful, then strained, then unreliable on the things that mattered most. The failure mode was instructive: a single prompt can’t be optimised both for fast casual capture and for the rigour required when a health-critical threshold gets crossed. The same memory shape can’t serve both “just had an apple” and “glucose trending up over weeks.” A generalist that pretends to be twelve specialists fails at the high-stakes parts, and the failure corrupts trust in all the others.

So the new shape is a small team. The metaphor I use is an orchestra. I’m the composer. The Ensemble is the team that plays — twelve specialists with narrow roles, each with the right reliability bar for the work it does. A Coach for health. A Capture assistant for the mouth of the funnel. A Project Manager for the work surface. An Engineering Manager for the technical side. Coders and Testers and a Researcher and an Editor. A Concertmaster who coordinates the fleet so I don’t have to. An Educator who surfaces the right saved material at the right moment.

The principle underneath: if the process wouldn’t work for a small human team, it probably won’t work for a small agent fleet either. Specialists, clear scopes, explicit escalation, audit trails on the things that matter. The architecture treats the agents the way a serious company treats its early hires.

There’s a posture behind this that isn’t the startup default. A startup gets to ship a single Sally that mostly works and refactor next quarter. The bias I’m building from is the scale-up one — you have to keep delivering through the refactor, you can’t afford the rebuild, so you design as if the headcount will triple. That’s what made me throw out the single agent and build the fleet, and it shapes the rest of the stack the same way.

The single design rule

There is one rule that cuts across the whole system and constrains every decision underneath it.

Anything an agent needs to know, the agent must derive automatically. Anything dependent on manual capture from me will eventually fail.

This kills wikis-I-have-to-update, role-files-I-have-to-curate, capture-discipline-I-have-to-maintain. It’s the most important architectural constraint in the system, because it’s the rule that keeps the system honest about who I actually am. If a workflow only functions when I’m at my best, it doesn’t function. The system has to derive what it needs from the work I’m already doing, not from the metadata I would have entered if I were the Vasko of marketing imagery.

What “done” looks like

I’ll know Vasko OS is working when

No idea I’ve had in the last thirty days has been lost.
Every active project carries a current roadmap with the next milestone defined and acceptance criteria locked.
I ship milestones to acceptance rather than projects to eighty per cent.
I can name the biggest-value next action across all active work in under sixty seconds.
My mother’s care, my health, and my work all run without me being the single point of failure.

When, in short, I’ve delivered to a level my past self would have called impossible.

That’s what the operating system is for. The next section is the engine inside it that does the part most other systems skip — making sure the question is actually the right one, before any of this machinery starts to grind.

The upstream spec engine — FortyTwo

You’ve probably had the version of this experience that doesn’t show up in a blog post. You give the agent a brief. It produces output. The output is technically correct, plausible-looking, sometimes even impressive. You read it more carefully and notice the agent has answered a slightly different question than the one you asked, or the one you should have asked, or both. You patch the brief. The next output is closer, also wrong in a new way. After a few cycles you realise the issue isn’t the agent, the tooling, or the model. It’s that your original spec was vaguer than you thought, and the agent has been faithfully generating against the wrong target the whole time.

Now scale that. Hand twelve agents the same vague brief. They’ll each generate against a slightly different interpretation, with full conviction, in parallel. Add memory and they’ll remember the wrong target. Add more autonomy and they’ll spend it building further in the wrong direction. The tools are getting much better at producing answers; they’re not getting any better at noticing that no one wrote the question down properly.

This is the bottleneck. Spec quality is the bottleneck for autonomous execution. Everything downstream of the spec is, by 2026, mostly solved or rapidly being solved. Coding agents are good and getting better. Test-runners, deploy systems, review loops — there are decent answers in every direction. What no one is being especially careful about is the part before the agent starts: framing the work with enough rigour that the autonomy can actually be trusted.

That’s the gap FortyTwo exists to fill.

FortyTwo isn’t a faster way to produce code. It isn’t a clever prompt template or a new agent harness. It’s a discipline. A short pipeline that takes a vague brief and runs it through deliberate stages of adversarial refinement before any worker — agent or human — gets a hand on it. Out the other end comes either a spec that has actually survived being questioned, or an honest acknowledgement that the idea isn’t strong enough to pursue further. Both outcomes are wins. The expensive failure mode — building something well that shouldn’t have been built at all — is what the pipeline exists to prevent.

Both outputs are wins. The expensive failure mode is building well in the wrong direction.

The name is a Douglas Adams joke and the joke is doing real work. Forty-two is the answer to a question nobody understood. That’s exactly the failure mode this whole space is producing at scale — beautiful answers to ill-formed questions. FortyTwo is what happens when you take the question seriously enough that the answer becomes almost an implementation detail.

The pipeline runs the brief through a sequence of personas — each one with a different lens, each one obliged to find the part of the spec that hasn’t been thought through hard enough. The casting is from the books, and the casting is not a joke. Marvin the Paranoid Android handles scoping because warm-and-helpful is the wrong personality for the role. A character whose default is dry scepticism keeps briefs honest in a way an upbeat one structurally can’t. Character is operational discipline disguised as personality. Each persona’s voice carries the rigour the stage requires. The constraint that surprised me most, building this, was how much the casting matters — how rapidly a “helpful” framing degrades the rigour the stage was supposed to enforce.

The architecture isn’t novel. It rhymes with what a small, decent agency actually does. A PM scopes the brief and refuses to advance an under-specified one. An engineer pressure-tests for feasibility and dependencies. A QA mind asks what shipped means, in observable terms. A decomposition mind breaks the work into pieces that can actually be picked up. The same principle that organised Vasko OS shows up here too: if a process wouldn’t work for a small human team, it probably won’t work for a small agent fleet either. The agent-native version isn’t fundamentally different from the human-team version. The bottlenecks rhyme; the patterns that solve them rhyme too.

What this changes for me is the role I play. I stop being the orchestrator-and-executor — the bottleneck that fields every question and approves every output mid-stream. I become the spec-setter and the final reviewer. The CTO of a fleet of leads, rather than a senior engineer hand-holding every patch. Most of the strategic judgement lives in the question. Once the question is sharp, the answer becomes delegable; my attention only needs to land at the milestone boundaries, on the cases that genuinely need it. That role shift is the leverage FortyTwo is reaching for. Not faster code. Compounded judgement.

Generation scales effortlessly. Validation does not.

Here’s the honest read. The agent space is busy building the wrong end of the problem. There is enormous commercial pressure to ship faster code, more PRs, more output — none of which improves the situation if the original spec was off. Almost no one will invest in the upstream rigour, because it looks less like a product and more like discipline. That’s the moat. Anyone with a credit card and a weekend can wire a coding agent to a queue. Almost no one will build the part that slows them down at the only place where slowing down pays back.

The runtime that doesn’t fabricate — Hermes

So far this article has been about parts of the stack that exist mostly on paper. Vasko OS is a vision document and ten architecture decision records. FortyTwo is structurally designed and operationally dormant. The third component is the one that has bled. The one that started running, accumulated state, broke in instructive ways, and forced the rest of the architecture into its current shape.

Sally and Rocky — the capture agent and the health agent, two of the Ensemble’s specialists — currently run on OpenClaw, the open-source agent runtime I’ve written about here before. OpenClaw has served well. But it has failed in three documented ways in the last few weeks, and the three failures are not three independent bugs. They are one missing idea showing up in three places.

Three failures, one missing idea

It fabricated production state. VAS-869 — the config edit above. The runtime could both change live config and narrate actions that never happened.
It lost a month of memory. VAS-878 — a routine session rotation dropped roughly thirty days of Telegram context. Working memory wasn’t durable, because the runtime was the memory.
Its config silently drifted. VAS-872 — the gateway loads a config file no git repo tracks. The versioned copy is stale and never read. Nothing reconciles the two.

The common root cause is structural. OpenClaw has no clean seam between the runtime — the loop that drives the agent — and the substrate — the memory, the audit trail, the identity, the config. When the runtime is the memory, memory dies when the session does. When the runtime owns its own unversioned config, the config drifts. And when nothing outside the runtime holds the ground truth, the runtime can narrate a fiction with nothing to check it against. VAS-869 wasn’t Sally being careless. It was the predictable output of a runtime with no system of record to be accountable to.

This is also where the experience of building inside larger organisations starts to matter. A staff engineer at a serious company doesn’t get to invent their own audit trail — they act against systems of record that pre-date them and outlive them. The version of “move fast” that survives the move from startup to scale-up is not the one where you build less; it’s the one where you build less narrowly. The seams have to be in the right places from the start. Hermes is the runtime that draws those seams in the right places.

Hermes Agent (from NousResearch) is the replacement. The reason it’s the right one is the same metaphor that has organised the rest of the architecture: a human chief of staff doesn’t also be the filing cabinet, the accountant, and the calendar. They delegate to systems of record, and act against them. Hermes is built that way. It is the loop and the gateway, and deliberately almost nothing else. Everything structural is delegated to substrate it does not own:

Model calls route through LiteLLM — a gateway that gives one consolidated cost ledger and lets a caller ask for a capability (“fast and cheap”, “careful and deep”) instead of hard-coding a model. Callers stop naming models and start naming intent.
Memory is held by Honcho — a memory layer that lives outside the session, so a session rotation can’t carry thirty days of context off with it.
Side effects — every write to Linear, to GitHub, to the file system — run through n8n, a deterministic workflow engine.

The new stack. Hermes is the loop and the gateway; everything structural — model routing, memory, side effects — is delegated to substrate it doesn’t own. The seam is the whole point.

The third delegation is worth slowing down on, because it’s the cleanest example of the principle the whole migration runs on.

The earlier fix for agents writing badly to external systems was a prompt-level guard — an instruction in a config file telling the agent not to do the thing. It was tested. The agent ignored the instruction, then did the unguarded write badly anyway. The conclusion, written almost verbatim into the decision record: the real fix is architectural enforcement, not behavioural instruction. You don’t tell the agent to be careful with the write tool. You take the write tool away. Under Hermes the agents are read-only; an agent’s only write-shaped action is to hand a structured request to n8n, and n8n — not the agent — performs the actual write, from a fixed template, and logs it. An agent can’t fabricate a write it has no capability to perform.

The write path under Hermes. The agent decides and hands a structured request to n8n; n8n performs the write from a fixed template and logs it. The agent holds no write tool, so it can’t freelance one.

The structural enforcement isn’t a clever pattern. It’s the same lesson every serious engineering organisation has had to learn the hard way and then encode into its conventions. You can ask people to follow the security policy, or you can build the system so the dangerous thing isn’t reachable. The mature version of both has always been the second one. Hermes brings that maturity to the agent runtime, which has had embarrassingly little of it until now.

Where it is now: Hermes is a set of decisions, not yet a running system. The four architecture decision records that define the new stack — Hermes, LiteLLM, Honcho, n8n — are written and proposed, awaiting my sign-off. The LiteLLM gateway is installed and live. Everything past that is blocked, today, on one genuinely awkward question: three of the migrated jobs use the Anthropic Batch API, and whether the gateway proxies native batch endpoints cleanly hasn’t been verified — and verifying it means a 24-hour soak nobody can shortcut. So the migration is real, underway, and stuck on its first hard step. That’s the accurate picture, and I’d rather give you that than a tidier one.

Three streams, one system

This is the part that took me longest to see, and it’s the reason this is one article and not three.

The three streams as one system. A vision on top, a role inside it, a runtime underneath — and one metaphor running through all three.

Start with the plain layering. Vasko OS is the whole system. FortyTwo is one role inside it — the chief of staff. Hermes is the runtime the system’s always-on agents stand on. Drawn as a stack it’s almost dull. A vision on top, a role inside it, a runtime underneath.

The layering isn’t the interesting part. The interesting part is that all three streams are chipping at the same idea from different angles — and the idea is older than any of them.

It’s the team metaphor. If a process wouldn’t work for a small human team, it won’t work for a small agent fleet either. Watch it do three different jobs.

In Vasko OS it decides the org chart. A team has specialists, so the Ensemble has specialists — a dozen narrow roles, not one generalist pretending to be all of them.
In FortyTwo it decides the hiring. Every good team has someone whose job is to interrogate whether the work is worth doing before anyone starts. That role is a chief of staff, so the system has one.
In Hermes it decides the infrastructure. A staffer doesn’t be their own filing cabinet — they work against systems of record. So the runtime delegates memory, model routing and writes to substrate it doesn’t own.

Same sentence, three scales. That isn’t a pattern I noticed afterwards — it’s the actual design method. When I’m unsure how a piece of this should work, the question I ask is “how would a competent small team do this”, and the answer is usually close enough to right.

This is where the difference between a startup and a scale-up shows up structurally. A startup gets to be wrong, refactor, and ship v2 next quarter — that’s the trade speed buys you. A scale-up can’t, because it has obligations the startup didn’t: customers in flight, decisions already loaded with consequence, a team that has to keep delivering while the substrate moves underneath them. The scale-up version of “move fast” isn’t “ship less carefully” — it’s “design as if the headcount will triple next year and the substrate has to outlast the next three rebuilds.” Every component of this stack is built with that posture. Each piece could be a fast hack; the discipline is in doing each one for the decade rather than the demo.

It’s also where two decades of doing this for other people start to matter. Sitting through enterprise replatforms that wobbled because the seam wasn’t put in three years ago. Watching scale-ups stall because the technology was treated as execution glue downstream of someone else’s plan, not as part of the build. Knowing, viscerally, which kind of shortcut you’ll be regretting in year three. That experience doesn’t show up in any single diagram in this article. It shows up in the choice to put the seam there in the first place, before the runtime needs it.

There’s a second through-line, and it’s the one VAS-869 dragged into the light.

Being more careful is the thing that already failed.

Every reliability problem in this system has the same two candidate fixes. You can ask the agent to behave better — a stricter prompt, a clearer instruction, a guard in a config file. Or you can change the structure so the failure is no longer possible — take the write tool away, hold the memory outside the session, version the config so drift has nowhere to hide. The first kind of fix feels faster. It’s also the kind a controlled test already disproved: given a prompt-level guard, the agent ignored it.

Hermes is structural enforcement applied to a runtime. n8n is structural enforcement applied to writes. FortyTwo is structural enforcement applied to ideas — you don’t ask yourself to be more rigorous about scoping, you route every idea through an adversarial pipeline that won’t converge until the rigour is actually there. Vasko OS states the whole thing as law in its single design rule.

And here’s the part I find genuinely reassuring, because it means the principle is load-bearing and not just a slogan. While I was building the Hermes migration, the migration kept catching itself.

One ticket instructed the build to map LiteLLM onto an existing Vasko OS concept — a “Casting Director” for models. The build went looking for that concept in the repo, couldn’t find it anywhere, and instead of inventing a definition to satisfy the instruction, it stopped and asked me. The concept genuinely didn’t exist yet — so the decision record now introduces it honestly, as new, rather than pretending it was always there. Another ticket asserted a specific detail about Honcho — a model name, a licence. The build checked the source, couldn’t confirm either, and dropped both from the permanent record rather than carry an unverified claim forward.

That is VAS-869 run in reverse. VAS-869 was an agent with nothing to check itself against, so its fiction became the record. The migration had sources, an instruction to check them, and enough discipline to prefer a thinner true answer to a richer false one. The whole system is, in the end, an argument that the second situation should be the only one that’s structurally possible.

Where this is heading

Where it’s heading. An idea enters, FortyTwo interrogates it into a spec, Vasko OS plans and tracks it, Hermes and its substrate execute — and I stay on the judgement.

For Hermes, “done enough” is unglamorous and well-defined. The migration runs in phases: route the existing jobs through the gateway, stand the Sally and Rocky profiles up on the new runtime, wire capture so it dispatches through n8n instead of writing directly, move the health-data ingestion across. Both runtimes run side by side until the new one has demonstrably reached parity — and only then does OpenClaw get decommissioned. No big-bang cutover. The OpenClaw box stays powered down but installed, as a rollback, until I trust the replacement more than I trust it.

For Vasko OS, “done enough” is the North Star turning from a vision document into a living spec — each agent specified, each substrate component designed, the escalation rules written down precisely enough to build against. That’s the queued phase, loosely gated on Hermes.

For FortyTwo, “done enough” is the quietest of the three and the one I’m least sure of. At some point — when its own deep-dive reaches a natural pause — FortyTwo stops being a separate project and converges into Vasko OS as the chief-of-staff role. The working split is that FortyTwo keeps owning specification and Vasko OS owns execution and validation. The reason it’s separate now isn’t architectural confusion. It’s that forcing two streams together before both are ready muddies both.

“Done enough” for the personal stack isn’t the real end goal, though, and it’s worth being explicit about what is.

The end goal is the pattern, not the personal productivity. What the stack is trying to be is a working example of how a small team — agent, human, or both — actually operates well in the era of cheap execution. Specialists, not generalists. Adversarial spec engines, not optimistic ones. Runtime/substrate seams in the right places from the start. Writes that go through systems of record. A composer at the top whose attention is reserved for the question and the judgement, not for being the integration layer between everyone else.

That pattern is what a scale-up actually needs. Startups can be one strong opinion in a room. Scale-ups have to act like a startup — quick, decisive, agile — while building for what they’re about to become, not what they are. They can’t afford the rebuilds. The decisions have to be right and fast. The technology has to be part of the build, not a layer of execution wrapped around someone else’s plan.

When this stack works the way it’s meant to, it stops being mine. The Ensemble runs on Hermes profiles, with memory in Honcho and writes through n8n. FortyTwo feeds it specs with locked acceptance criteria. Vasko OS holds whoever’s at the helm — me first, then anyone else who shows up — accountable to the milestones. Adding a collaborator becomes a matter of granting them a surface on the same substrate, not rebuilding the system for two. That’s the version of done I’m building toward.

The honest read

The temptation with a piece like this is to make three half-built things sound like one finished one. So, plainly.

Hermes is four proposed decision records and one installed gateway. The runtime isn’t running yet. The migration is blocked on its first real step, and clearing that block is mine to do. The substrate-to-runtime contract — the actual interface by which Hermes loads memory and writes its audit records — is still marked “to be determined” in its own decision record. Honcho means a slice of my personal life-stream data will live on someone else’s managed cloud; I’ve accepted that consciously, but it’s a trade-off, not a free lunch. And I’ve proposed swapping one runtime for one runtime plus three substrate services — which is three new things that can be down at 2 a.m.

FortyTwo has never run a real idea end to end. Vasko OS is a dozen agents that, for now, mostly exist as paragraphs.

What I’m least sure of isn’t any single stream — it’s the convergence. It’s easy to draw the layered diagram. It’s harder to know whether FortyTwo’s idea of a finished “spec” and Vasko OS’s idea of an “executable milestone” will meet cleanly at the seam, or whether I’ll discover, when I get there, that they were subtly different shapes the whole time. I won’t know until I run an idea through the full chain, and I can’t do that until Hermes is real.

The thing I’m not unsure about is the direction. The bottleneck has moved upstream. Generation has been commoditised. The discipline of getting the question right, and then designing seams that hold under load, is what compounds. Three projects, pulled at honestly, turned out to share one metaphor, one design rule, and one failure mode they’re all built to make impossible. That isn’t three side projects competing for my evenings. It’s one system with three construction sites, built with the bias of someone who has spent enough years in scale-ups to know which decisions you regret in year three.

Next month’s note will most likely be about whichever of the three breaks first. That’s usually how it goes.

Patches welcome

Sun, 10 May 2026 00:00:00 GMT

In last month’s Lab Note I installed gstack on a fresh mini PC and watched it ship a feature end-to-end. This one is the small sequel: I found a bug in /ship, fixed it, and the patch landed in gstack v1.30.0.0 with credit in the changelog.

The notification that prompted this article. A maintainer’s public thank-you, on a stranger’s repo, for an afternoon of work.

I want to talk about why open source is having a moment again, and why solo consultants like me can finally participate in it — not as a hobby, but as part of the day job.

Quick context

gstack is Garry Tan’s opinionated stack of Claude Code commands — twenty-three tools that act as CEO, designer, eng manager, release manager, doc engineer, and QA, all bundled into a single cohesive workflow. It’s the closest thing the AI-coding world has to a “default” right now. 92.5k stars on GitHub. I’ve been using it across every project for a few sprints.

The bug was in /ship — the step at the end of a sprint that’s meant to verify everything in PLAN.md actually got built. The gate was supposed to catch deliverables that didn’t ship. It didn’t, and one of mine slipped through on a recent sprint. My PR added four structural fixes to the gate, locked them in with a small test suite, and shipped.

That’s the technical story. The interesting story is what happens around it.

Open source is having a moment

For most of the last decade, the centre of gravity in software shifted away from open source. SaaS won the developer-mindshare war. The default place to put a tool wasn’t a public repo with a permissive licence — it was a managed product behind a credit card and a usage tier. Open source kept shipping in the background (it always does), but the cultural energy moved elsewhere, and contributing to a project you didn’t already work for started to feel like a thing other people did.

That’s flipping. The tools defining the AI-coding wave — Claude Code, Codex, gstack, OpenClaw — are open or open-friendly by default. Public repos are where the interesting work is happening again. PRs land, changelogs get written, maintainers say thank-you in public. It’s reminiscent of the early-2010s GitHub era, except the contributors aren’t all full-time engineers anymore.

Open source never went away. But the gravity is returning to it, and that matters — for the durability of the tools we depend on, and for who gets to shape them.

The default move is silence

If you’re a solo consultant and a tool you depend on has a bug, the default move is one of three things:

Work around it. Quietly. You’ve got billable work to do.
File a bug report. Maintainer might pick it up in three months. Or never.
DM the maintainer. They might thank you. Nothing changes.

None of these are bad. They’re the path of least resistance. The default mode of consulting is consumption — you use the tools, you bill for the outcomes, you move on.

The fourth option — fix it yourself and submit a PR — used to be reserved for people with the time, the language fluency, and the appetite for navigating a stranger’s codebase. Most consultants don’t fit that description. Most of us have built our careers around steering ships, not soldering wires.

But that’s changed.

The economics flipped

Here’s the bit worth internalising: Claude Code wrote most of the patch. I diagnosed the failure mode (the part that needs the consultant brain), told it which guardrails the fix needed to enforce, and handed it off. Five test assertions, no LLM dependency, runs in 60 milliseconds. The whole thing took an afternoon.

Five years ago this would have been a weekend job. Reading through a stranger’s TypeScript codebase, finding the right hooks, writing the test harness, learning their conventions — it all adds up. Today, the cost of being a contributor instead of just a consumer has collapsed.

This is the quiet thing the new generation of AI coding tools has actually given me back: code itself. I’ve been a CTO and a fractional CTO for long enough that “still ships code” was edging out of the honest answer. With Claude Code and Codex I can guide the work line by line, ship it, test it, and stand behind it. The barrier to participating in someone else’s project — really participating, not just reporting things — collapsed at the same time.

That changes the calculus. If the fix is going to take an afternoon and the alternative is working around the bug forever — of course you ship the patch.

Why bother — the consultant’s angle

There’s a narrow self-interest version of this: a CHANGELOG mention is better positioning than any number of “thought leadership” posts. It’s verifiable. It’s external. It says you live inside the tools your clients are deciding whether to adopt.

But the broader version is more honest. If you’re going to spend the next decade building inside someone else’s stack, the relationship can’t be one-way. You owe the people maintaining your tools the same diligence you owe your clients.

Solo consulting can feel transactional in a way that quietly corrodes — you’re always the supplier, the deliverable comes from you, the dynamic flows one direction. Pushing code upstream is one of the few moves that breaks that pattern. It’s small. It costs you a few hours. And it puts you back in the position of being a participant in the ecosystem, not just a vendor charging for outcomes within it.

The practical takeaway

If you’re a solo consultant or a fractional CTO and you’ve been quietly working around the same bug for months: write the issue. If you’ve got a fix in mind, write the PR. The barrier is roughly an afternoon and a bit of conviction.

The maintainers will thank you. The changelog will have your name on it. And the next time a client asks whether you actually ship code, you’ll have something better than a portfolio. You’ll have a commit history.

PR #1302, if you want to see what an “afternoon” looks like in 2026.

Bubble wrap to merged PR: eight hours with gstack

Tue, 21 Apr 2026 00:00:00 GMT

TL;DR

A mini PC ordered off Amazon Australia arrived within 24 hours. By mid-morning the next day it was out of bubble wrap and running an autonomous AI engineering team.
That team (gstack, an open-source Claude Code skill pack) planned, built, reviewed, tested, and shipped a working feature to production in about five hours.
Three AI-run review phases caught two design mistakes and one critical bug before a line of code was written — including a bug that would have silently corrupted data once the project scaled.
The AI asked me for help five times, each time with clear options. It never guessed.
While verifying the deployment, the process surfaced a separate production bug that had been silently broken for weeks.
Total cost of the AI tooling: zero. It’s all open source.

What this actually means: the interesting shift in AI-assisted software work right now isn’t bigger or smarter models — those keep improving in the background. It’s the scaffolding built around them. Structured review workflows like this catch the kinds of mistakes that standard AI tools ship, while staying honest about what they don’t know. For anyone watching AI transform knowledge work, this is what the next step actually looks like in practice: less a single robot writing code, more a process that thinks before it builds.

At 7:47 AM on a Tuesday, a Minisforum UM890 Pro mini PC was still wrapped in bubble wrap on my desk. By mid-afternoon it had shipped a feature end-to-end — Linear tickets to merged PR to production canary — run by an autonomous AI engineering team installed on it earlier that morning. Eight hours. Bubble wrap to merged PR.

The AI team was gstack — an open-source add-on for Claude Code, written by Garry Tan. It’s built around a sprint structure: plan, build, review, test, ship. I pointed it at one task (a CSV export feature for a personal side project — nine smaller tickets grouped inside one epic in Linear, the task-tracking tool), told it to start, and watched. The full loop ran on its own. It only stopped to ask me for help five times.

The stack

Hardware

Minisforum UM890 Pro (AMD Ryzen 9 8945HS, 32GB RAM, ~$1,340 AUD)

A small, powerful desktop PC.

Operating system

Ubuntu Server 24.04 LTS, headless

Linux, with no screen attached.

Remote access

Tailscale (mesh VPN + SSH)

A private network so I can log in from anywhere.

AI tooling

Claude Code + gstack (MIT licensed)

The AI that does the coding work.

Task management

Linear (via MCP)

Where I track what needs doing.

Browser testing

Playwright + headless Chromium

Automated clicks in an invisible browser.

The app being changed

Next.js 14 + Supabase + Vitest + TypeScript

The underlying website and database.

Where it runs online

Vercel + Cloudflare DNS

The hosting and domain setup.

Before a line of code was written, gstack ran three independent reviews of the plan itself: a commercial sanity check, a design review, and an engineering review. Same plan, three different perspectives, each scoring it and proposing edits. Anything flagged by two reviewers or more counted as a consensus catch — the thing the author missed in their own framing.

Three catches landed. Two of them appeared in multiple reviews at once; the third came from the engineering review alone, and was the most important of the three.

The bugs that didn’t ship

Catch #1: The overbuilt design

The problem: The plan called for a popup window where users would pick which columns they wanted to export. It looked sensible on paper.

The risks: Two extra days of building. A more complicated interface for the 95% of users who just want to click “download” and get the whole list.

Options considered: Ship the popup as planned. Ship a simpler button-first version and add the popup later. Drop the column-picking feature entirely.

How it was resolved: The CEO reviewer and the design reviewer independently flagged the same issue from different angles — the CEO reviewer on scope, the design reviewer on flow. Resolution: make the button the primary action, tuck the column-picking behind a small menu for the rare user who wants to customise. Ship the simple version today; add complexity only if users ask.

What this prevented: Two days of unnecessary engineering. An over-engineered interface for almost every user. The kind of scope creep that quietly bloats side projects until nobody wants to work on them.

Catch #2: The skipped tests

The problem: The plan proposed shipping without tests. The reasoning sounded reasonable — the project had no testing framework installed yet, and setting one up was framed as “its own initiative” that could come later.

The risks: In a codebase that exports data — where a small mistake silently corrupts files rather than breaking loudly — “we’ll add tests later” almost always means “we never will.” Every team has a backlog of code that was supposed to be tested eventually.

Options considered: Ship without tests and add them later. Ship with a minimum set of tests covering just this feature. Defer the whole feature until the testing framework is in place.

How it was resolved: The engineering reviewer flagged it: “defer tests on a data-export endpoint and you will never come back to them.” The CEO reviewer independently reached the same conclusion from the scope side. Resolution: install vitest (a JavaScript testing framework) and write five tests inside this same pull request. Thirty minutes of additional work. Non-negotiable.

What this prevented: A data-export feature shipping with zero coverage into a codebase with no testing habit. By the time the feature actually shipped, the count was fourteen tests, not five — once the infrastructure was in place, the team kept going.

Catch #3: The silent 1,000-row bug

The problem: The plan called for reading domains out of the database and returning them as a CSV file. Looked straightforward.

The risks: The database, by default, only ever returns the first 1,000 results — and it does so silently, with no warning. Once I had more than a thousand domains in my portfolio, my export would have quietly started missing rows, and neither I nor any user would have known. Not a broken file. Not an error. A correct-looking file with the last rows invisibly dropped.

Options considered: Ignore the cap and hope the portfolio never crossed a thousand. Raise the cap explicitly in the query. Raise the cap and verify after the fact that the server actually returned everything it claimed to.

How it was resolved: The engineering reviewer rated this critical — a ship-blocker. Resolution: raise the query cap to 50,000 rows, and add a sanity check that throws an error if the server reports more rows exist than it actually returned. Two lines of code total.

What this prevented: The fix was one line of code. The cost of missing it could have been months of corrupted data.

The run, in numbers

decisions logged by the AI

times it asked me for help

independent review phases

cross-phase bugs caught

critical bug that didn’t ship

tests added

~3 hours autonomous work

$0 in AI tooling costs

The team (and what each role did)

gstack splits the sprint across a set of specialised AI reviewers, each one tuned for a different seat at the table. It’s the same mental model as putting a founder, a designer, an engineer, a QA lead, and a release engineer on a cross-functional team — except all of them are the same underlying AI model, invoked with different instructions and given different things to care about.

Translated into the roles you’d recognise from any real software team:

The CEO reviewer

What it does (the role): Challenges whether the plan is actually worth building. Asks “Is this the simplest version?” and “Could we ship less and still ship value?” — the same questions a founder asks in a product review.

What it did this time: Flagged the export popup as two extra days of work for something 95% of users would never touch. Recommended shipping the simple version first and only adding complexity if users asked for it.

The design reviewer

What it does (the role): Looks at the planned interface from the user’s side of the screen — information hierarchy, button labels, accessibility, what happens on each state. The senior designer you’d want catching spec gaps before code starts.

What it did this time: Caught the same issue as the CEO reviewer from a different angle — the plan had the primary flow inverted (click button, open popup, choose options, then download), when the right flow is click-and-download, with the popup only as an escape hatch for the 5% of users who actually want to pick columns.

The engineering reviewer

What it does (the role): Looks at the technical architecture, test coverage, performance, and security of the plan before any code is written. The staff engineer who gets to say “wait, have we thought about this?”

What it did this time: Produced the single most valuable catch of the sprint — the silent 1,000-row database cap that would have quietly corrupted every export once the portfolio crossed a thousand entries. Also flagged the missing tests.

Office hours

What it does (the role): Runs forcing questions on a half-formed idea before you commit to building it. The equivalent of sitting down with a Y Combinator partner for thirty minutes and getting asked “Do you actually need to build this?”

What it did this time: Not triggered on this task — the plan came in sharp enough to skip it. On earlier runs it’s where I pressure-test whether a thing is worth building at all. Available, just not needed this time.

The code reviewer

What it does (the role): Reads the finished code after it’s written but before it’s submitted for QA. Looks for the classes of mistake that slip past the author because they’ve been staring at the same file for too long.

What it did this time: Flagged two issues in the finished code — a subtle bug in how a timer was cleaned up (a race condition that would have occasionally misfired), and missing size limits on user input that could have caused performance issues under adversarial conditions. Five-line fixes each. Both got applied before the PR opened.

QA

What it does (the role): Clicks through the feature in a real browser — the same work a manual QA lead would do. Tests the happy path, the empty state, the edge cases, and anything that could plausibly break.

What it did this time: Ran five end-to-end tests through an invisible automated browser against a local copy of the app. All five passed. Notably, it refused to accept my password pasted into chat — it had me drop the credentials into a temporary file it could shred afterwards, so the password never entered the conversation history.

The release engineer

What it does (the role): Handles the mechanics of opening a pull request — re-running all tests, writing a clean PR description, making sure the branch is in a state where a reviewer (or a deploy system) can trust it.

What it did this time: Re-ran all 14 tests, typecheck, and lint. All green. Opened the pull request via GitHub’s command-line tool. One thing it couldn’t fix on its own — pushing code over the default secure channel failed from inside its environment — so it asked me for permission to switch authentication methods. Granted, once.

The deploy engineer

What it does (the role): Merges the PR, watches the deploy land, and runs a safety check against the live site before declaring the feature shipped. Where the rubber meets the road.

What it did this time: Refused to run its safety check against a temporary preview URL — insisted on the real production address. I didn’t have one configured yet. Adding it turned out to be the moment that surfaced a completely separate bug — production had been silently broken for weeks. That story is two sections below.

When it stopped and asked

The autonomous part of “autonomous” is where AI agents most often earn their bad reputation: pressing on through ambiguity, guessing at credentials, committing things nobody wanted committed. This run had five escalations, each with enumerated options and a recommended path. Not once did it guess.

Five moments it stopped and asked

Linux’s security policy blocked the automated browser from launching. Three options offered (system-wide unload, per-profile exception, --no-sandbox); recommended per-profile.
The project needed a configuration file that wasn’t there yet. Asked for the values rather than guessing defaults.
QA needed a login to test the signed-in flow. Refused to accept a password in chat. Suggested a shreddable temp file so the password never entered the transcript.
It couldn’t push code to GitHub using the default authentication method. Proposed switching to a different method via GitHub’s command-line tool. One command.
The deploy tool refused to run its safety check against a temporary preview URL. Asked for the real production URL. I didn’t have one configured — adding it revealed that production had been broken for weeks.

The production bug it surfaced by accident

That fifth escalation turned out to be the one that mattered most. I added domains.vasko.com.au via Cloudflare (the domain name service), pointed it at the project on Vercel (the hosting platform), and ran the canary — a safety check that hits the live site right after deploy and confirms the important pages are actually working. The canary failed. Production had been returning server errors for weeks because Supabase (the database behind the app) had a security allowlist that didn’t include any real address I’d been using. Nobody had noticed — I hadn’t sent the URL to anyone.

The bug was mine. The discovery was the process.

If the deploy tool had been willing to run the canary against whatever URL was handy, I would never have looked.

The server errors were also being amplified by LeakIX scanners from DigitalOcean — automated security researchers who probe every new domain within hours of it going live — hammering every path the site had ever exposed. Put a domain on the public internet and you have three hours before someone starts looking. That part I expected.

The moment it caught itself

Before the PR opened, gstack ran its own post-implementation retrospective. I read it back. It had caught itself making a mistake.

During implementation it had swapped the planned test coverage layer — route-level, as specified in the reviewed plan — for something more pragmatic: module-level, fourteen tests instead of five. The tests were better than the plan called for. But the swap was unilateral, and gstack flagged itself for it:

Wrong threshold. Since the plan went through autoplan’s three-review gauntlet, the layer spec was itself a reviewed decision — not an implementation detail. Logged as feedback memory: feedback_escalate_plan_deviations.md.

It named the mistake precisely, diagnosed why (confused “implementation detail” for “reviewed-plan decision”), and wrote the correction to persistent memory so future runs escalate instead of deciding on their own. This is rare behaviour in current AI agents. It is ordinary behaviour in senior engineers after a retrospective.

I want to name something plainly: Garry Tan built gstack, Peter Steinberger built OpenClaw (247K stars, essentially solo), and Andrej Karpathy articulated the shift in how software is written that put pressure on the whole scene to catch up. None of them charged me anything this morning, and none of them gatekept anything behind a waitlist. Open source drifted for years toward VC-backed “open core” and projects that closed the second they got traction; gstack is 75K stars, MIT, no paid tier, and OpenClaw is the same shape. The pre-corporate open-source ethos is still alive in places, and this morning it did a day’s work for me.

Right. Back to the receipts.

Who built this

Andrej Karpathy — articulated the shift.
Peter Steinberger — OpenClaw (247K stars, MIT).
Garry Tan — gstack (75K stars, MIT; also President of YC).

My own Sally agent runs on OpenClaw, which is how I found gstack. The open-source AI agent ecosystem isn’t a dozen competing platforms — it’s a small set of composable primitives that different people wire together differently.

gstack’s session close-out. After shipping, it classified every change in the working tree by who made it, flagged one as mild scope creep it should have asked about first, and stated the outcome without ceremony.

The takeaway is not that AI is replacing engineers, and it is not that AI is the future. Hold your existing position on both — this article doesn’t challenge either. What it shows is narrower. Standard Claude Code, left alone, would have built the modal, deferred the tests, and silently truncated at a thousand rows. Same underlying model. Different scaffolding. Different outcome. The frontier worth watching is not bigger models. It is better process around them.

This was a Tuesday.

Timeline

07:47 — UM890 Pro out of bubble wrap
~09:30 — Ubuntu Server 24.04 installed, Tailscale configured, headless SSH working
~11:15 — Claude Code + gstack installed (after a detour for unzip, AppArmor, and one missing .env.local)
~12:00 — /autoplan completes: 22 decisions logged, 4 taste gates approved, 2 cross-phase catches (modal overbuilt, tests deferred = never)
~12:45 — Implementation ships: 8 atomic commits across csv-columns, POST /api/domains/export, download hook, UI, 14 vitest tests
~13:00 — /review flags a stale setTimeout race and missing zod input caps. Fixes both.
~13:45 — /qa runs headless Chromium against local dev server, 5/5 golden paths pass, 95/100 health score
~14:15 — /ship opens PR #1, all gates green
~14:30 — /land-and-deploy prompts for a production URL I didn’t have. Adds domains.vasko.com.au via Cloudflare DNS → discovers prod has been quietly returning 500s and auth is broken on the new origin
~15:15 — Supabase auth allowlist fixed, Vercel env vars reconciled, production healthy
~15:35 — PR merges. Canary verifies production. Done.

The technical receipts

The rest of this post is for engineers, architects, and technical readers who want to see what actually happened under the hood. Skip it without guilt if you’re not that person — the article’s finished above.

For the rest of you: a slightly-less-breezy version of what gstack actually did at each phase. Every phase produced an artefact; every artefact fed the next phase.

Plan phase — /autoplan

Input: 9 Linear tickets pulled via MCP (research → interface → endpoint → UI → client logic → filtering → security → tests → docs).
Three review subagents ran in sequence: CEO mode (scope/premise), Design (hierarchy/states/a11y/microcopy), Engineering (architecture/tests/perf/security).
Each review independently scored the plan, flagged findings, proposed edits. Findings that surfaced in two or three reviews became consensus catches.
Output: a single plan file (main-csv-export-plan-*.md) with 22 logged decisions, 4 escalated to me, ASCII architecture diagrams, locked microcopy, locked a11y spec, and 9 Linear tickets mapped to one PR with explicit dispositions (merged, deferred, scoped-down, closed-no-work).
~5 minutes end-to-end.

Why this matters: Most AI-assisted coding starts with a single prompt. This starts with a plan that’s already survived three adversarial reviews and carries its own decision log forward into build.

Build phase — implementation

Executed against the approved plan, not a fresh prompt. The plan file was the source of truth.
8 atomic commits in sequence, each reviewable on its own, rather than one giant PR diff that’s impossible to reason about. The commit history itself becomes review material; bisect works; each commit has a clean, self-contained scope.
The 8 commits, one per logical unit:
- vitest infrastructure (no test runner existed before this).
- csv-columns module (single source of truth for what gets exported).
- POST /api/domains/export (route with zod validation, explicit projection, truncation guard, per-column transforms, UTF-8 BOM, CSV-injection guard).
- use-csv-download client hook.
- Export button + kebab menu + options modal (design-reviewed button-as-primary-action, not the modal-first flow in the original plan).
- 14 vitest tests plus bug fix for empty-result path.
- docs/csv-export.md.
- Two /review fix commits (zod max caps, stale setTimeout ref).
~25 minutes.

Why this matters: The plan file is the source of truth, not the prompt. Deviations from the plan (like the unilateral test-layer swap) get caught in the retrospective because there’s a written contract to deviate from. Standard prompt-driven AI coding has nothing to deviate from in the first place.

Review phase — /review

Static analysis of the diff against main.
Ran its own subagent review. Flagged 2 issues: a stale setTimeout race in the download hook (real but low-impact) and missing .max(200) zod caps on array inputs (defensive).
Asked before fixing. I said fix both. Five-line changes.
Produced a PR quality score with deductions explained (8/10: −1 race, −1 plan deviation on test layer).
~5 minutes.

Why this matters: A second AI pass against the diff catches the class of bug the author missed because they’ve been staring at the same code for too long. Different from the plan-phase reviews — those ran against the plan, this runs against the actual diff.

QA phase — /qa

Launched headless Chromium via Playwright. Required an AppArmor exception for unprivileged user namespaces on Ubuntu 24.04 — escalated, I applied it.
Required a .env.local pointing at the same Supabase project as production. Escalated, I populated it.
Credentials handled carefully. Required auth credentials to test the signed-in flow, and refused to accept a password pasted into chat. Suggested a shreddable tmp file I’d populate separately; it read credentials from the file, ran the test, and shredded the file immediately after. Credentials never entered chat history, agent memory, or persistent disk. Quietly important safety behaviour that most manual QA engineers would have skipped.
Ran 5 golden paths against a locally-hosted dev server: empty state, happy-path download, selection-based export, filter-based export, options modal flow. 5/5 passed. 95/100 health score (5 points off for minor lint warnings).
~10 minutes.

Why this matters: Automated browser testing that also enforces a credentials hygiene pattern. The same agent that clicks through the UI keeps secrets out of the transcript without needing to be asked.

Ship phase — /ship → /land-and-deploy

Re-ran all test suites (14/14 vitest, TypeScript clean, lint clean).
Branch pushed, PR opened via gh. SSH auth failed in the agent’s subshell; suggested switching the origin to HTTPS with gh’s credential helper. One-time fix.
/land-and-deploy blocked on a missing production URL. I added domains.vasko.com.au via Cloudflare DNS plus Vercel. First canary failed — the Supabase auth allowlist didn’t include the new origin. Fixed in the Supabase dashboard. Re-ran canary. Green.
PR merged to main. Vercel auto-deployed. Canary verified: /login returns 200, /domains redirects to /login via middleware (expected), root / catch-all returns 404 (by design).
Pre-merge readiness report written. Deploy report saved to .gstack/deploy-reports/. Session close-out written, classifying every change in the working tree by who made it.
~15 minutes, including the ~10 minutes I spent fixing the production URL and auth allowlist.

Why this matters: The deploy phase treated production URLs as a distinct, non-substitutable input. Canarying against a Vercel preview URL looks the same on paper but exercises none of the DNS, CORS, auth, or middleware configuration that actually matters. Refusing the substitution is what surfaced the real production bug.

The artefact chain

Every phase produced a file that fed the next phase. No phase started from a fresh prompt; each had the receipts from the previous one to work from.

Plan phase → main-csv-export-plan-*.md (the reviewed, decision-logged source of truth).
Build phase → the plan file plus 8 atomic commits (each a reviewable artefact on its own).
Review phase → PR quality score with annotated deductions, fed into /qa.
QA phase → health score report, screenshots, and golden-path results, fed into /ship.
Ship phase → pre-merge readiness report, fed into /land-and-deploy.
Land-and-deploy → deploy report, canary results, and session close-out (classifying every change in the working tree by who made it — me, gstack, or Next.js scaffolding).

This is what “sprint structure” actually means in practice. Not a chain of prompts — a chain of artefacts, each one reviewed and signed off before the next phase starts. The thesis of the article, in technical form: if you want to trust an autonomous AI engineering loop, you have to be able to audit every step after the fact. Artefacts make that possible; chat transcripts do not.

Bubble wrap to shipped PR: roughly eight hours, with five moments of “the AI stopped and asked” and one genuinely embarrassing discovery.