a commit is a hypothesis

a commit is a hypothesis. the live check gets the final vote. I have learned this the hard way while building software solo with AI agents, where a change can arrive looking polished, coherent, and complete before it has met the place where it is supposed to work. The diff can make sense. The code can read cleanly. The commit can carry the satisfying feeling of progress. Then the live flow asks a simpler question: did the actual job happen? That question has ended more debates for me than any review comment ever could.

The gap shows up because code is always written against an interpretation of reality. You read the request, infer the behavior, make a change, and create a commit. An AI agent can accelerate every part of that loop. It can inspect surrounding code, suggest an implementation, write tests, and explain why the result should work. Those are useful signals. They remain signals. The product only earns its claim when someone can observe the intended result in the real flow. Until then, the commit describes a theory about what the software will do.

Tests can pass while the real flow falls over. That does not mean tests are worthless. Tests answer the questions they were written to answer, inside the conditions they create. The live environment carries conditions that the test may not represent: the order a person takes through the flow, the state already present, the boundary between components, or the moment when an output must become visible. A passing suite can tell me that a narrow behavior remains intact. It cannot automatically prove that the job reached a person in the way the product promises.

I used to let the cleanliness of a commit create too much confidence. When the implementation was small and the tests were green, I treated the work as largely complete. That habit made review feel like the finish line. The receipt that changed my definition was simpler than a metric: code can look clean and still miss the actual job. A commit with no live proof is unfinished work. It may be a good hypothesis. It may even be close. The absence of an observable result leaves the central question open.

The mechanism is straightforward. Software work passes through several translations. A request becomes an interpretation. That interpretation becomes code. Code becomes a tested behavior. Then that behavior has to survive the real flow and produce the result someone needs to see. Each translation can preserve the intent, or lose part of it. AI agents make the earlier translations faster, which makes the final check more important. Speed can produce a convincing artifact before it produces a verified outcome. The faster I can generate code, the more deliberately I need to ask for evidence from the live system.

My rule now is plain: “shipped” starts when someone can observe the result. I do not use the word as a reward for creating a commit. I use it as a statement about the world outside the editor. If I cannot verify it live, I have a commit. I keep going. That rule gives solo work a useful stopping condition because it replaces vague confidence with a visible outcome. The implementation can still need improvement later, yet the first threshold is clear: the intended job happened where it matters.

For readers building with AI agents, treat every generated change as a hypothesis that deserves a live check. Ask what a person should be able to observe when the work is complete. Follow the actual flow far enough to see that result. Let passing tests inform your confidence, then let the live check decide whether the task is done. This is a small shift in language that changes the work. A commit becomes evidence of effort. Live verification becomes evidence of delivery. That distinction keeps the software honest, and it keeps the builder focused on the outcome instead of the appearance of progress.