Shipping While We Sleep

Written by Mike McGreal, Dendro Logic | Engineering | Published: 14 July 2026

One evening in June I pointed an AI agent at a product backlog, gave it the rules of engagement, and went to bed. By the time I woke up it had shipped four features.

Not four suggestions. Not four half-finished branches waiting for me to clean up. Four features: a full Outlook email integration, a guard that stops the AI fabricating quotes in legal answers, a freight liability calculator covering five international shipping conventions, and a human sign-off badge with a proper audit trail. Every one type-checked, covered by tests, reviewed by a second independent agent, committed, and deployed. It even left me a handover note explaining the one thing it could not finish, because that step needed a credential only I can provision.

I want to be precise about what this is and is not. It is not a demo. It is not a vendor pitch. It is a real run, on a real product, with a real commit log I can point at. And it is a long way past autocomplete.

The interesting question is not “how did the agent write the code”. Models have been able to write plausible code for a while. The interesting question is why the output was safe to ship unattended. That comes down to three things: a build discipline the agent cannot talk its way out of, a memory that stops it guessing, and a task breakdown that turns a vague business goal into work small enough to verify. This piece is about all three, and about what they do to the shape of a development cycle.

The one rule: the agent never marks its own homework

The discipline is a build loop I call do-it-right, now released as an open-source Claude Code skill. It exists because of a specific failure. In May, a piece of work on one of my products had passed everything a normal team calls “done”: the compiler was happy, and 118 unit tests were green. I handed it to an independent review agent anyway. It came back with seven real bugs. Not style nitpicks. Real defects, one of them a privacy leak that would have exposed one user’s data to another.

That is the lesson worth tattooing on any AI workflow. Green ticks tell you the code does what the tests ask. They tell you nothing about whether the tests asked for the right thing. When writing code becomes cheap, the value moves to the layer that catches the gap between “passes” and “correct”. So the loop is built around a single non-negotiable rule.

A unit of work is not done until all three of these are true.

1. An independent review comes back clean. Independent means a different context: a separate agent with fresh eyes, or a different model entirely. Never the same agent reading back its own output. A quick self-check first is fine because it is cheap and catches the obvious, but self-review is not the gate. Independence is the whole point.
2. The feature has an end-to-end test saved into the permanent suite, so it can never quietly break later.
3. For anything a user can see, someone has driven the actual flow in a browser against the deployed app and watched it behave. Deployed is not verified. Unit-tested is not verified. You confirm with your own eyes.

Everything else in the loop serves those three gates. The work moves through four phases: plan the change and get the plan reviewed before any code, build it test-first in small vertical slices, run it through a review panel that looks at the diff through security, privacy and correctness lenses until the reviewer is clean, then ship it with the end-to-end test crystallised into the suite. Bugs take a slightly different route: reproduce and minimise first, rank a few hypotheses, instrument, fix, add a regression test, then rejoin the review phase.

The reason an overnight run is safe rather than reckless is that this machinery runs on every single unit, whether I am watching or asleep. The agent cannot declare victory. It can only get past the gates.

The memory: an agent with no brain is a brilliant new hire on day one

The second ingredient is memory, and it is the one most people skip.

An agent with no memory starts every session as a brilliant graduate on their first morning. It knows the whole internet and nothing about us. It will cheerfully rebuild something we already have, or contradict a decision we made three months ago, because nobody told it. Worse, its training data is months stale, so its confident answer about “how we do X” is really an answer about how the world did X last year.

The fix is a shared, searchable brain. Every meaningful decision, every working session, every architectural gotcha gets captured into one place, automatically, as a by-product of the work rather than as extra admin. The agent I run sits on top of a second brain that has been accumulating my decisions, my architecture notes and my hard-won lessons for months.

The rule that makes it useful is simple: before the agent plans anything, it queries the brain. What have we decided about this? Has anyone tried it before? What went wrong last time? And every answer comes back with a citation to the source, so I can always check where a claim came from instead of trusting the model’s memory.

This is also what makes long sessions possible at all. A session that runs for hours will overflow any context window. The brain is the durable layer underneath: session capture writes the run to memory as it goes, so a fresh session can pick up exactly where the last one left off. The handover note the June run left me was not a nicety, it was the mechanism. The agent knew what it had done, what remained, and precisely why it stopped.

There is a compounding effect here that is easy to miss. Every session makes the next one smarter, because every session feeds the brain. The knowledge stops living in one person’s head. A new starter can ask the brain why the system is built the way it is and get a sourced, answered history instead of two weeks of tapping people on the shoulder.

The breakdown: from north star to a slice small enough to trust

The third ingredient is the least glamorous and the most important for unattended work: you cannot hand an agent a business goal. You have to hand it a slice.

Behind each of my products sits a north-star document (what we are building, for whom, and why) and a roadmap that turns that into concrete outcomes. On its own, that is far too big and too ambiguous for any agent to execute safely. So the work of a good session is as much decomposition as construction: take a strategic goal, atomise it into bite-sized vertical slices, each one a thing that can be built, reviewed and tested on its own, and each one traceable back up to the plan it serves.

This is why the June run could ship four independent features rather than one tangled mega-change. Each was a self-contained slice with its own tests, its own review, its own commit. If any one had failed its gates, it would have failed alone, and the other three would still have shipped. Small slices are what make the loop’s guarantees hold: a review is only trustworthy if the thing under review is small enough to actually reason about.

Alongside every build, the agent keeps a running set of implementation notes. Not a write-up at the end, but a live audit trail of the decisions it made, the places it deviated from the spec and why, the tradeoffs it weighed, and the questions it needs a human to answer. When the reviewer picks up the work, it reads the reasoning, not just the diff.

What this does to the development cycle

Put the three together (a loop the agent cannot bypass, a memory it works from instead of guessing, and slices small enough to verify) and the economics of building software change shape.

Most of how we plan software was designed for a world where writing code was the slow, expensive part. Sprints, story points, velocity: all of it is machinery for estimating and managing the cost of typing. That assumption is now wrong. In the run I described, implementation collapsed to hours, overnight, unattended. The typing was the cheap part.

What is expensive now is everything on either side of the code. Deciding precisely what to build (the specification, the decomposition, the “what does correct even mean here”) and verifying that what got built is actually right. Those are the two ends the humans and the machinery now own, and they are exactly the parts the loop and the brain are built to support.

I am not going to argue we should rip up every process tomorrow. But the honest question is worth sitting with: if code is no longer the expensive part, what should we be measuring, and where should humans spend their time? My own answer, from running this for months, is that the effort moves off “how long will this take to write” and onto two things: the quality of the specification going in, and the strength of the verification coming out. The licences for the agents are the cheap part. The loops and the memory are the investment.

The uncomfortable part

There is a version of this story that is pure hype, and I want to stay away from it. The agent is not magic. Left to its own devices it will confidently ship the privacy leak that passed 118 tests. Everything that makes an overnight run trustworthy is scaffolding we built around it: the rule that it cannot review its own work, the memory that grounds it in what we actually know, the discipline of slicing a goal down to something a review can hold in its head.

That is the real headline. Not that an agent shipped four features while I slept. It is that the interesting engineering has moved. It is no longer in the code the agent writes. It is in the machinery that decides what to ask for and proves that what came back is right. Build that machinery well, and yes, you can ship while you sleep. Skip it, and you are just automating the production of plausible mistakes.

Related Dendro Logic writing

• Agile Is the Bottleneck Now – why delivery doctrine built around the cost of writing code measures the wrong thing once that cost collapses.
• Team Context Is the Real Unlock – the grounded team-memory architecture that stops agents guessing from stale training data.
• do-it-right on GitHub – the build loop described in this piece, released as an open-source Claude Code skill: https://github.com/toshodin/do-it-right