Why Alan has to prove his work
Writing code is no longer the hard part. Knowing it works is. Here's how Alan is built around that.
Most AI coding tools are judged by how much code they can write. We think that's the wrong measure. Code that looks right and code that runs are different things, and the gap between them is where most of the real work in software happens.
Done means tested
Alan has a dedicated step for proving his work. Before he can report a task as finished, he writes automated tests for what he built and runs them inside his own machine. A test only counts as passing if the command exits cleanly. If one fails, he reads the error, fixes the cause and runs the tests again.
When he does finish, his report says what he added, what he did and whether every test passed. The full record of each run, including the failures he fixed along the way, sits in the Tests tab.
What this does and doesn't guarantee
Tests written by the same engineer who wrote the code can miss things a person would catch. That's true for human engineers too. So we don't treat a passing test as the end of the story. We treat it as the minimum bar, and we show everything else so you can judge for yourself:
- The plan, before any code is written
- Every file, as it's written
- Every command and its output
- A live link to the running app
Where we're going
Proof is the part of software work that people trust least and check least. We think an engineer that treats it as the job, not an afterthought, is the one you'll want to hand real work to.