The answer is almost always yes.

Effort used to be the evidence.

Software was slow to make, and the slowness did some of the work of proving quality. If a thing existed at all, somebody had spent weeks on it. You could reasonably infer care from the finished object, because carelessness rarely survived the distance.

That inference no longer holds. A convincing interface arrives before the meeting ends. A codebase looks substantial before anyone has formed an opinion worth trusting. Speed helps a considered decision and a careless one at exactly the same rate.

Which is where the work moved, rather than disappeared. A demo that handles the obvious path is now cheap. What is not cheap is finding the exception: the approval that loops back on itself, the customer who exists twice under two spellings, the hand-off nobody wrote down because everyone in the room already knew it. Those are not edge cases to a business. They are most of a business, and they are the difference between something that demonstrates well and something still standing on a Monday.

You can no longer tell a considered decision from a fast one by looking at it.

So the question a client is actually asking has changed. Not can this be built, which is now almost always yes. It is who looked closely enough to say it should be built this way, who went looking for the cases that break it rather than the ones that work, and who will tell you plainly what they did not check.

That is the difference between a draft and a decision. A generated answer is a possibility. A reviewed one is a position somebody is standing behind. What follows is about the distance between those two, because the distance is now the job.

A useful gate creates resistance.

Review is often described as polish, a gentle pass over something already complete. That description makes it sound optional. Good review is more structural. It asks the work to survive contact with the claims it makes.

This is not abstract. In a review of Study 08, a meter that claimed to be measuring visual drift turned out to be reporting a layout offset instead: a real number, precisely wrong, on a panel that looked authoritative. It was replaced with one that measures the thing it names. In a later session, a scan reported every file clean when the tool it was calling had never started and printed nothing; that check now fails loudly instead of silently passing. Study 11 is the longer account of that second kind of failure, because it happened four times in one day.

Both looked like success. Neither had checked anything at all. The corrections are the point: a claim of quality is worth something only when you can be shown the occasion it was wrong and what changed as a result.

So the habit is to distrust the surface. If a screen says a task succeeded, follow the failure path. If a panel shows a count, find out where the number comes from. If something is called verified, ask what was actually looked at, what was only inferred, and what is still unknown.

A gate is valuable when it can still say no.

The other half of that discipline is knowing the shape of your own ignorance. An uncertain question does not deserve a confident guess. It deserves the smaller true statement, followed by what it would take to say more: the source that is missing, the test not yet run, the condition nobody has seen the system meet. Hedging is not weakness when the hedge is specific.

That capacity matters more as production accelerates. When making another version is cheap, refusing the weak version becomes the scarce act. The gate protects the reader from a polished mistake, and it protects the builder from mistaking motion for progress.

This is why the review gate is not placed after the product. It is part of the product. The answer is not finished when the agent stops. It is finished when an engineer has enough evidence to stand behind it.

The signature carries the remainder.

No review produces certainty. Software meets devices, people and conditions that no studio can hold all at once. Honest verification does not pretend otherwise. It draws a clean line around what has been checked and keeps the unknowns on the page.

That line is a practical form of authorship. It says: this behaviour was exercised; this source was inspected; this capture was rendered; this limitation is still open. The words are modest, but they make responsibility legible.

To sign the work is to remain answerable after it ships.

A signature therefore means more than approval. It joins the result to a person who can explain the choices inside it. If the context changes, that person can revisit the judgement. If a failure appears, there is somewhere for the question to land.

This is the studio model: agents provide reach and speed; engineering provides the line of accountability. One expands what can be attempted. The other decides what can be released.

Together they produce something more useful than either performance of certainty or ritual caution. They produce work that moves quickly, shows its receipts and stays open to correction.