Questions we research, with the answer we build on. Every note rests on a real experiment in production or on public code. We describe the kind of experiment, not a score.
Yes. It writes for the gates, not just for the prompt.
A coding agent answers a prompt. A builder that knows the tests, the security assessment and the review ahead of it, and remembers what earlier builds in the same repo needed, writes differently from the first line.
Read the noteNo. Focus beats a longer checklist.
We gave our build agent a longer set of instructions with more rules. On easy tasks nothing changed. On the hardest one, it finished faster and left part of the job undone.
Read the noteA verdict. Yes or no holds steadier than zero to a hundred.
A reviewer that scores from zero to a hundred drifts, even on unchanged code. Asking it yes-or-no questions per criterion made its judgement steadier and brought it much closer to the expected outcome.
Read the noteAsk. A question is cheaper than rework.
The same real issues from a large open-source code base, built twice. Once the DayStorm Factory sharpened specs against the code and asked about open intent first, the rework disappeared.
Read the noteThe one that reports green.
Our own pipeline had stages that stopped working while still reporting success. They were easy to fix and hard to notice, because nothing made a sound.
Read the noteNot reliably. Separate the builder from the judge.
An independent reviewer, run repeatedly over past builds with known human fixes, caught most error classes consistently without flagging clean builds.
Read the noteNo. The spec is.
When we measured where effort and money actually went, the model was not what held a build back. Understanding the codebase and pinning down intent was.
Read the note