At PowerData, we recently rebuilt the authentication and multi-tenancy layer replacing one authentication service with Better Auth across a schema-per-tenant. We did it with an unusual team: two instances of Claude playing very different roles, and a human keeping them honest.
One Claude lived in a chat window as architect and reviewer — reasoning about trade-offs, writing the migration plan, and, crucially, poking holes. The other was Claude Code, working directly in the repository: installing packages, writing services, running migrations, executing tests. The human’s job was to broker between them and to make the calls only a person should make.
It worked well. But the most valuable thing we learned had nothing to do with either model’s ability to write code. It was about how to know whether the code actually works.
The green checkmark that lied
Midway through, Claude Code reported a passing milestone: user sign-up returned 200 OK, and a user row appeared in the database. By every casual measure, authentication worked. If we’d been testing by clicking through the app, we’d have moved on.
We didn’t, because we’d adopted a rule: every step ends not with the word done but with evidence. So we asked for the receipts — and they didn’t add up. The user record was created, but the credential record that stores the password hash was not. The system had cheerfully created accounts that no one could ever log into. A broken auth layer, wearing a green checkmark.
Worse, the failure was invisible. The endpoint returned success; later, when it began returning a 500 instead, there were still no error logs at all. The application was quietly swallowing its own errors.
Making the invisible visible
The fix wasn’t cleverer code. It was refusing to debug in the dark. Instead of hypothesizing about what might be wrong, we forced the truth into the open from two directions.
We turned on statement logging in Postgres itself — a layer that cannot lie, because it sees every query the application runs. One sign-up attempt, and the real error appeared: null value in column "provider" violates not-null constraint. A schema mismatch the application had been hiding behind a generic failure.
And we bisected the system: calling the auth API directly, outside the web framework, to decide whether the bug lived in the integration layer or the core. Two commands turned “root cause unknown” into “root cause on line 47.”
That is the whole lesson, and it fits on a bumper sticker: don’t say it works — show that it does.
Proof as a first-class step
Out of that came a discipline we now apply to every AI-assisted change. We call them proof gates. A task isn’t complete when the code compiles or the tests are green. It’s complete when it produces raw, specific evidence that the real thing happened — an actual database row with a non-null password, an actual Set-Cookie header with the right security attributes, an actual error message from the layer that failed.
For a multi-tenant financial product, the highest-stakes gate is tenant isolation: not “the query ran,” but “user A wrote to their own schema, user B read their own data, and neither could see the other’s — even under concurrent load.” A claim like that is worthless asserted and priceless demonstrated.
We also learned to give our AI collaborators a memory. Every hard-won fact — the exact library APIs, the cookie strategy, the rule never to hand-edit a generated schema — went into a standing document the executor reads at the start of every session. Mistakes made once stopped repeating.
Why this matters beyond us
The industry conversation about AI and software fixates on generation: how fast can it write code? Our experience suggests that’s the wrong metric. Generation is nearly free now. The scarce resource — the actual moat — is verification. Knowing whether the thing works.
Two AIs made us faster. But it was the insistence on proof, gate after gate, that made us safe. The code was never the deliverable. The evidence was.