Writing code is now cheaper than auditing it. I recently had an agent build a password reset flow—routes, token logic, email integration, and UI—all in under five minutes. It looked perfect during the demo, but there was a critical flaw: the reset link didn't expire after one use. Because my prompt didn't explicitly state "single-use only," the AI didn't implement the token invalidation. It’s a detail that usually goes without saying until you ship a security hole.
The inversion of development costs #
In a traditional workflow, the bottleneck is the human writing the syntax. Now, the bottleneck is the human verifying the logic. If an agent generates a feature in five minutes, but I spend 45 minutes in manual testing and code review to ensure it doesn't break the database or leak data, the total dev time is still 50 minutes. We've just shifted the weight.
Auditing code you didn't write is mentally more taxing than auditing code you did. You have to reconstruct the AI's "intent" while hunting for edge cases it missed. Generating more code doesn't fix this; it actually compounds the problem by increasing the surface area for bugs.
Specifications are the only durable artifacts #
Implementation is becoming disposable. In six months, I might switch frameworks or refactor the entire DOM, but the business requirement remains the same. For example, the core requirement for a password reset is:
- User requests reset.
- User receives email.
- User sets new password.
- New password works; old password fails.
- Reset link expires immediately after use.
When code is cheap to rewrite, the specification—not the codebase—is what you actually maintain. I've found it's far more efficient to write a rigid, behavioral specification as a standalone artifact before letting the agent touch the IDE.
Moving from implementation to behavioral testing #
I tried a different approach with a standard business app using Claude Code and testRigor to see if I could automate the verification gap. Instead of reviewing the generated TypeScript or Python, I focused on observable outcomes.
The goal was to see if independent end-to-end (E2E) verification could act as the "judge" for the AI's output. Since the agent can implement the feature rapidly, the only way to scale is to have a test suite that doesn't care how the code is written, only what it does.
If you're using these tools, stop focusing on the "prompt for the feature" and start focusing on the "prompt for the test." If you can define the expected behavior in a way that a verification tool can check, you stop being a manual auditor and start being a system architect. My current stack for this:
- **Implementation:**[Claude](/en/tags/claude/) Code (via CLI for fast iteration)
- **Verification:** testRigor (for natural language E2E tests)
- Result: I spend less time reading diffs and more time refining the requirement list.
Next Vibe coding with Claude 3.5 is a trap if you stop reading the diffs →
a library of Claude prompt techniques, with plenty of directly applicable cases.
All Replies （3） #
Finally some clarity. I want to try this tonight, but will it work with Python 3.12?
I want to try this tonight. Which model are you using for the audit, or is it just manual review?
This burned me last week. I spent three hours hunting a logic flaw in a generated Stripe webhook that passed every test. Use Pydantic?