Main idea

Asking "does it work?" of an application built with an assistant tells you nothing about how well it is mastered: screens that respond, a database that exists and an API that runs coexist perfectly well with hundreds of technical choices nobody can explain. The discriminating question is a different one: would you know how to rebuild this system elsewhere, in another technology?

Answering yes means knowing where the contracts between APIs are, where the business rules live, which tests describe expected behavior rather than the current implementation. Those three handholds aren't obtained after the fact: they are imposed during construction — insisting on contracts, having test suites and then the test pyramid produced before development starts, refusing to let business logic scatter across the endpoints, even without going all the way to a full DDD approach the project doesn't warrant.

The rebuild doesn't have to be undertaken. It serves as a control question, and its answer measures what the team can say about the system rather than what the system displays.

Why it matters

This gives an enforceable quality criterion where delivery speed no longer says anything. A functional demo passes whatever the state of understanding; "would I know how to rebuild it?" fails precisely when understanding is missing.

It also turns understanding into a design requirement rather than an individual virtue: what makes it possible is identifiable lines of separation, and they are decided at the moment of building.

Nuances and limits

Nobody rebuilds a system to check they would have known how. So the criterion remains a question asked in good conscience, exposed to the complacency of whoever answers it — a system can look rebuildable to the person who steered it and be rebuildable by nobody else.

And it says nothing about the value of the system: you can know how to rebuild, identically, an application that serves no one, or whose architecture is mediocre.

Open questions

• What short test — having someone else pick up a module, rewriting a component without the existing one in front of you — would give this criterion a verification that doesn't depend on self-assessment?