AI-written tests, step by step: how Claude wrote 4,722 of my 5,247 tests — including the copy-paste prompt that generates a full test suite in 15 minutes.
You don't have to write tests to have tests. Treat testing like a feature: hand AI a structured brief, and it generates a comprehensive suite in about 15 minutes. My product has 5,247 tests. Claude wrote 4,722 of them — 90%. Here is the exact method, including the prompt you can copy.
In the previous post I told the story of the bug that approved 15 startup applications with one click — the bug that finally convinced me tests are insurance, not overhead. This post is the other half: how a solo, non-technical founder actually gets thousands of tests without spending a single evening writing them.
Treat tests like a feature, not a chore
The mistake most people make is asking AI, "write me a test for this function." That gets you shallow, decorative tests — the kind that pass no matter what.
The fix is to give testing the same treatment as feature building: a structured brief that spells out what to test, which patterns to follow, and how to verify the result. I use the same document format I use for features — the PRP method — pointed at tests instead. A Test PRP takes about five minutes to write and produces coverage a bored human never would.
A real example: 28 tests in 15 minutes
Last week I built a new service that manages success stories from accelerator alumni — creating them, publishing them, archiving them. Twelve distinct operations. Old me would have shipped it untested and debugged it in production. Instead:
| Step | Time |
|---|---|
| Write the Test PRP (the brief) | 5 minutes |
| Claude generates the test suite — 247 lines, 28 test cases | 10 minutes |
| Run the tests, review two failures | 2 minutes |
| Claude fixes both issues, all 28 pass | 3 minutes |
Here's the part worth reading twice. Of the two failing tests, one was a naming mismatch in the test setup — trivial. The other caught a real bug in my service: it allowed publishing a success story without its metrics filled in. The test suite found a production bug before production did, on day one of its existence.
Final coverage: 94.2% of the service. Writing those 28 test cases by hand would have taken 3.5–4.5 hours. The AI route took 15 minutes — 14–18x faster.
The copy-paste test prompt
This is the skeleton of every Test PRP I write. Fill in the brackets, paste it into your AI coding tool, and ask it to generate the suite:
Goal: comprehensive test coverage for [feature name]. Coverage target: 90%+.
Feature to test: [the file], and the list of its operations — every function you want covered, by name.
Patterns to follow: paste one or two well-written tests from your codebase, so AI copies your style instead of inventing one.
Scenarios to cover: the happy path; edge cases (empty inputs, missing values, boundary conditions); error conditions (invalid data, database failures, unauthorized access); and your business rules, written in plain language — "a rejected application can never be approved", "users can only see their own organisation's data".
Validation loop: the exact commands to run the tests and check coverage, so AI can verify its own work and fix failures before handing back.
Gotchas: anything that has bitten you before — irreversible status changes, fields that must exist before publishing.
The business-rules line is the one that earns its keep. Every plain-language rule you state becomes a test that guards it forever — that is exactly the kind of test that would have caught my 15-approvals bug.
Why AI out-tests humans
After generating thousands of tests this way, I'll say something uncomfortable: AI is better at testing than most developers. Not smarter — more thorough, for four reasons.
It doesn't get bored. Humans skip edge cases because "this is good enough". AI generates every case you specify, exhaustively.
It follows patterns perfectly. Show it one good test and it applies the pattern to all twelve operations. No copy-paste errors, no forgotten checks.
It finds cases you'd miss. On my success-story suite, Claude added edge cases I hadn't listed: empty text versus missing text, negative numbers in metrics, malicious input in search filters, two conflicting status changes at once.
It updates tests when the code changes. Refactor the service, re-run the brief, and the whole suite regenerates in minutes. "The tests are out of date" stops being an excuse.
Features require creativity. Tests require thoroughness. AI excels at thoroughness — which is why testing, not feature-building, might be its single best use for a solo founder.
Make it automatic
The end state is simple: every feature ships with tests, generated in the same session as the feature itself. No "later". No separate testing sprint. The brief takes five minutes, the suite takes ten, and the validation loop means AI fixes its own failures before you even look.
Since adopting this workflow I've shipped zero critical bugs to production in four months — with 82% coverage on a product where the industry standard for a funded startup is 60–70%. The insurance is nearly free now. The only decision left is whether you keep declining it.
Frequently asked questions
Are AI-written tests actually good?
With a structured brief, yes — often better than hand-written ones, because AI doesn't skip cases out of boredom. Mine hit 94.2% coverage on a new service and caught a real bug (publishing without required data) before the feature ever reached users. Without a brief, you get shallow tests — the brief is the difference.
What is a Test PRP?
A short structured document — five minutes to write — that tells AI what to test: the feature and its operations, an example test to copy the style from, the scenarios to cover (happy path, edge cases, errors, business rules), and the commands to verify the result. It applies the PRP method to testing.
How long does it take to get real coverage this way?
About 15 minutes per feature: five for the brief, ten for generation and verification. The same suite written manually would take 3.5–4.5 hours — 14–18x longer. That collapse in cost is why my product has 5,247 tests instead of the zero it had before.
How do I know the AI tests aren't garbage?
Two checks. First, the validation loop: the brief includes the commands to run the tests and the coverage report, so nothing is accepted on faith. Second, the business rules: state them in plain language and read the generated tests for them — if "only the clicked application gets approved" appears as a test, the suite is guarding what matters.