AI makes it dangerously easy to build the wrong thing. I can point agents at a problem and have a mountain of code before I have proven the idea underneath it.
So before I build too much, I try to kill the idea first.
Not the whole project. The claim hiding inside the decision.
Most decisions are secretly a bet that something is true. Name the bet out loud and you can test it.
If I think we need a bigger model, that is not just a preference. It is a claim that the failure is caused by insufficient reasoning capacity.
If I believe a new retrieval technique will improve memory, I am claiming that the current method is the bottleneck.
If I assume the normal installer flow should work here, I am claiming that the environment behaves like a conventional writable Linux system.
Sometimes, once you check, the answer is just no.
The useful failures
On ShrekOS, I assumed the standard installer approach would work. It did not, because /etc is sealed and read-only, and the normal recipe quietly depends on writing there.
Finding that early instead of three layers of code later saved me from an architectural mess.
On Mycelium, I tested an associative-memory approach that sounded great and performed worse than what I already had. Another promising retrieval technique improved zero out of six benchmark cases.
Both died there.
A prototype should not just prove something works. It should give the idea a cheap, honest chance to fail.
It worked when I tried it isn't proof. It's a story about something that happened once.
Define PASS before you run it
Decide what success means before the experiment, not after.
If you skip this, you will get a mediocre result and immediately narrate why it is secretly encouraging. It is much harder to move the goalposts once you wrote them down.
For a security boundary, I define what must never happen.
For a retrieval change, I define what specifically has to improve.
For a new capability, I want a regression test before I trust it.
Without a hard definition of failure, you are just playing with toys.
When you write down the criteria for death, you stop lying to yourself. You stop tweaking parameters until the graph looks pretty, and you take the result you actually got.
Test the assumption that can hurt you most
I do not treat every unknown as equal.
Not knowing what a button looks like can wait forever.
Not knowing whether the security boundary underneath it is real gets tested now.
The question is always: which assumption, if wrong, invalidates the most work?
That one goes first.
- Turn the idea into a claim that can be wrong.
- Find the assumption that would invalidate the most work.
- Build the cheapest thing that could kill it.
- Decide what PASS means before running it.
- Let bad results actually kill ideas.
This is not about being pessimistic. It is about being efficient.
AI makes implementation cheaper every month, and it makes building the wrong thing cheaper at exactly the same rate.
So I have stopped being impressed by how fast I can turn an idea into code.
What I care about now is whether the idea survives long enough to deserve the code.
Top comments (1)
The cheapest failure on ShrekOS was finding that /etc is sealed before the installer recipe had three more layers stacked on it. Mycelium's associative-memory idea dying on 0 of 6 cases is the same move. Agent coding dropped the cost of the false path at the same rate as the true one. The pre-registered kill test is what keeps a week of GPU time and review from landing on a claim that was already false. I write the PASS line down first and treat the experiment as a small, bounded premium.