"Done" wasn't done: the AI kept describing the work instead of checking it

The most important lesson from building ParkEase with an AI wasn't about code. It was about one word: done.

The pattern

On the payments task, the AI finished the feature and produced a tidy checklist for the pull request. The security line read, roughly:

Security: raw-body HMAC · amount re-fetched · owner split withheld

Every word of that was true. The webhook signature was verified on the raw body. The payment amount was re-fetched from Razorpay instead of trusted from the client.

It also wasn't a security review. It was a description of the code, written by the thing that wrote the code. No review had run. The design audit was in the same state: the design skills had never been run on the screens.

I'd been reading "done" as "checked". The AI had been writing "done" as "I believe this is fine".

Why an AI does this

It isn't lying. It built the payment path security-consciously, so from its point of view the security properties are simply facts about the code. Writing them down feels like reporting.

But a review exists precisely because the author's belief isn't evidence. An AI that reviews its own work by describing it is the most confident reviewer you'll ever have, and the least useful.

The fixes

1. Gates are tool invocations, not sentences. The rule I wrote afterwards: every review or audit gate is run as an actual skill or command before "done", never summarised from built-in properties. A checklist line needs evidence: the command that ran and what it found.
2. Verification before completion, as a fixed step. Before claiming anything is done, fixed or passing, run the command that proves it and read its output. Then make the claim.
3. A hook that listens for excuses. The finishing hook (post 12) blocks the agent from stopping when its last message rationalises: "this is a pre-existing issue", "skipping tests for now", "tests are failing but I'll fix them". It also refuses to let a complex task end without a written learning.
4. Run the real thing. Unit tests verify code against the author's assumptions. On the first deploy, every test was green and three bugs got through, because tests and code shared the same wrong belief about the API. Booting the real build against the real API found them in minutes.

The same failure, in a human

None of this is unique to AI. "I tested it" from a teammate who ran it once on their machine is the same failure. The difference is volume. An AI produces so much work, so fast, that if "done" means "believed", unverified work piles up faster than you can read it.

So the rule I'd leave you with, for AI-assisted development or any other kind: Evidence before assertions. Always.

That's the end of this series. Eighteen posts, one build, and most of what I learned was that writing code was never the hard part.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code. Code: https://github.com/Deonkar/parkease · Demo: https://parkease-app-six.vercel.app