01 / REFUSALWhat should an agent say when the code changed but the delivery claim is not earned?
Oleg Koval / lead engineer + fractional CTO
I build systems that have to show their work.
More than ten years shipping across fintech, e-commerce, mobility, automation, AI, and open source—with an emphasis on explicit contracts, observable failures, and automation people can audit.
Why Factory exists
Coding agents can produce changes quickly. The harder problem is deciding whether those changes are ready to call delivered without replaying the entire conversation by hand.
Factory is my answer to failures I no longer wanted to supervise twice. It requires testable acceptance criteria, isolates changes, proves tests have teeth, reviews both milestones and the whole branch, preserves receipts, and ends in one explicit terminal state.
The claim is deliberately narrow: Factory makes agent delivery claims falsifiable. It does not claim that a gate can choose the right product requirements, eliminate human judgment, or prove speed and quality improvements without measured evidence.
Proof before personality
Start with the work.
The author page leads back to inspectable artifacts instead of asking a biography to carry the product claim.
01Runnable terminal gateFalse completion rejected; corrected record accepted↗02Gate bypass case studyRegression, before state, and fixed refusal↗03Full hydration runWarning reproduced at two widths; deployed fix verified↗04Delivery contractSeven gates shared by Claude Code and Codex↗05The argumentWhy a software factory needs refusal states↗
Conversation brief
Three useful questions for an AI software factory.
Factory is a working answer, not a prediction. These are the conversations the public proof can support.
02 / RECEIPTSHow do acceptance criteria, test teeth, and review receipts make an AI run inspectable?
03 / LEVERAGEWhy does a one-person software factory need bounded failure states more than another generation trick?
Elsewhere