“Did You Check It?”

The most valuable AI skill I have built does not write code, research markets, or generate content. It asks one question: “Did you check it?”

I learned the question from a real Eastern European boss. “Vlad” is not his real name, and the face above is deliberately fictional. I changed both before making the skill public.

To my American ear, the question initially sounded like: I don’t trust you. What he meant was: do not trust your assumptions; check the thing itself.

This is not a theory about every American or every Eastern European. It is a lesson I learned from one person’s directness — and one I badly needed.

AI agents are very good at producing plausible declarations of success: tests passed, the deployment succeeded, the feature is live, permissions are configured, the worker completed the task.

Every sentence can be technically true while the user still experiences a broken product.

My prior work kept exposing the same pattern. A health endpoint was green while the service’s real function was dead. A deployment succeeded while the old version remained active. CI was green because the relevant suite never ran. An administrator could see a feature the affected user could not.

The failure was usually not a lack of intelligence. It was unchecked assumed state — the same agent judging the work through the same path, with the same context and the same optimism.

This is where Vlad turns around and audits the article about Vlad.

I launched the formal skill on August 3. Its persisted record contains one smoke matrix against known false-green patterns and four live handoff gates. Those four gates produced 12 formal findings or receipt issues.

The three most recent gates found 10 real defects before the handoff was accepted. Four were fixed before a PASS. Six stopped a production-readiness claim with a FAIL.

They included a capability disabled at the vendor account, a public webhook blocked before it reached the application, a deployed workflow whose latest version was not active, green tests that never crossed the real integration boundary, notification failures swallowed after “complete,” and a promised workflow absent from runtime code.

The most important number is not 10. It is when those 10 were found. Before this discipline, that class of mistake often became a user report, a production incident, or a second round of work after “done.” Vlad moved discovery to the handoff — the last cheap place to catch it.

I do not yet have enough longitudinal volume to claim a credible percentage reduction across all of my work. Inventing “Vlad reduced errors by 43%” would violate the premise. The honest claim is narrower: 10 defects that could have survived my previous success signals were caught before acceptance, and no unresolved handoff received a PASS.

Vlad is useful after the work, but his bigger effect happens before it.

Once you know the Final Boss will ask for the user-visible probe, you run it yourself. Once you know “CI is green” will be challenged, you check whether the test actually ran. Once you know a deployment receipt is not proof of a live feature, you stop presenting it as one.

Vlad also turns each new failure pattern into a cheap repeatable probe. The goal is not to become better at performing the same long investigation. It is to convert every scar into a check that catches the next instance in under a minute.

That is what “Did you check it?” finally came to mean for me: not distrust of the person. Distrust of unmeasured state.