We Ship Dark
Almost everything important we built this quarter is turned off. Why every meaningful control ships behind a kill-switch that defaults to no - what shipping dark means, the four rules that keep it from rotting into dead code, and the honest cost of doing it.
Here is a sentence that sounds like an admission of failure: almost everything important we built this quarter is turned off.
The tamper-evident consent ledger — off. The vault-held signing keys — off. The hardware-key identity check — off. The agent discovery card at the front door — off. All of it real, all of it tested, all of it sitting behind a kill-switch that defaults to no.
We call this shipping dark, and it is the single most useful engineering habit we have.
What shipping dark actually means
A dark ship is code that is fully written, fully reviewed, fully tested, and merged into the main line — with its behavior gated behind a flag that is off in production. The feature exists. It runs in tests. It does nothing to a customer until somebody deliberately turns it on.
The distinction that matters is the one between built and planned. A planned control is a paragraph in a roadmap. A dark control is an artifact: you can read it, run it, attack it, measure it, and hand it to an auditor. It is one decision away from being live, and that decision is a human one made on purpose — not a side effect of a merge.
Why we do it
It separates two risks that usually get fused. Writing a security control is one risk. Turning it on in front of real people is a completely different one. Most teams take both at the same moment, under launch pressure, which is the worst possible time. Shipping dark lets you take the first risk calmly, in daylight, and the second one deliberately, later.
It forces the hard questions early.You cannot write a kill-switch without answering “what is the behavior when this is off?” That question is a gift. It makes you design the fallback, the failure mode, and the rollback before you have any incentive to hand-wave them.
It makes honesty cheap.When a control is dark, there is no temptation to describe it as live. Our own compliance posture says “in pursuit” precisely because the code says off. The flag keeps the marketing honest for free.
It makes review real. A reviewer can be genuinely rigorous about code that cannot yet hurt anyone. The same reviewer, staring at a change that goes live on merge, is quietly negotiating with their own fear.
The discipline that makes it work
Shipping dark degenerates into dead code unless you hold a few rules seriously.
Default off, explicitly. The flag reads as off when unset, not merely when someone remembers to set it to false. A half-configured environment must land in the safe state, never in a surprise.
The dark path is tested, not just the light one. Both branches get cases: what happens with the flag on, and the specific guarantee that with the flag off the behavior is unchanged. That second test is the one that lets you merge without holding your breath.
Fail-safe where the feature is additive.Our consent-receipt mirror can never break the consent write it is mirroring. If the chain append fails, it is logged and the operation proceeds — a detectable gap rather than a broken product. A control that can take down the thing it protects is not a control.
Write the unfinished edge into the code.Not the wiki — the file. Every dark control we shipped carries a docstring naming exactly what it does not yet do. The half-finished edge you document is a gift to the next engineer; the one you hide is a trap.
The honest cost
Dark code is not free, and anyone who tells you otherwise has not maintained it.
Flags accumulate. Each one is a branch in the behavior space, and the number of possible configurations grows fast. Dark code also rots: it is written against an understanding of the system that keeps moving, and a control that sits off for a year may not fit the system it wakes up into. And there is a subtler failure — the comfortable illusion of progress. Built-but-off is genuinely more than planned, but it is genuinely less than live, and a team can fool itself about which side of that line it is standing on.
So the rule we hold ourselves to is simple: dark is a staging state, not a destination. Every flag needs a named condition for flipping it and someone who owns that decision. A flag with no path to on is not discipline. It is procrastination with good posture.
Why this matters more for agents
This habit is not new — feature flags are older than most of the people reading this. What has changed is the stakes. When your software acts on someone’s behalf, holds their information, and talks to strangers’ software, the cost of shipping a control that is subtly wrong is not a bad release. It is a breach of trust that a person cannot undo.
In that world, the ability to build a security control completely, hold it inert, scrutinize it properly, and turn it on the day you actually understand it — that is not caution. That is the only responsible way to move fast.
Almost everything important we built this quarter is turned off. Ask us in a quarter how many of those switches we flipped, and whether we told you honestly when we did. That is the number that matters.
See what 🤫 Agent One does at /one, and our honest posture at /one/compliance.
The 🤫 hussh magazine
Written by Manish Sainani, and built to read beautifully here — and to travel to 🤫 One on your phone, your glasses, and visionOS, as one immersive magazine you own.