AI can build a working application faster than ever.
Give an AI coding agent a prompt, and it might generate a frontend, connect an API, create da...
For further actions, you may consider blocking this person and/or reporting abuse
"Passing tests means the tested scenarios passed" is the line every team shipping AI code should pin somewhere visible. The /projects/:id example is spot on: IDOR bugs are the ones AI writes most confidently, because the happy path looks perfect.
My #1 check before shipping: I write the abuse tests myself (user A requests user B's data, same webhook fired twice, price tampered in the request) before letting the agent touch the implementation. If the agent writes both the code and the tests, they tend to share the same blind spots.
The "don't claim an issue unless you can support it with evidence" line in your review prompt is a great touch too. It cuts a lot of noise. Bookmarking the checklist.
Really appreciate this! Writing abuse tests before implementing the feature is a great approach, especially when it comes to authorization and payment handling. I also agree that having the same AI write both the implementation and tests can leave gaps. Independent verification makes a real difference when production data is involved.
Exactly. Auth and payments are where “it works” and “it’s safe” drift furthest apart. Curious: do you run a separate agent or model for the review pass, or keep that step fully human?
I'm not directly involved in development now, but before joining my current project I built things using only AI. My coding knowledge is just the basics I picked up a little in school. You described what I felt back then, and how to fix it, really well. When I was vibe coding, I was so focused on solving the feature in front of me and moving on to the next one that I leaned on the AI and ignored bugs. This is something I'll keep in mind for my own personal projects. Thanks for the good advice.
Thanks for sharing your experience! I think many developers have gone through the same thing, especially when AI makes it so easy to move from one feature to another. The important part is learning to slow down and question the code, not just trust that it works. I'm glad the article was helpful for your personal projects!
Good checklist. The IDOR example in section 1 is the one I see most often in AI-generated endpoints — the agent optimizes for “query returns the right shape of data,” not “query is scoped to the right principal.” It’s a subtle distinction that’s easy to miss if you’re only validating against the happy path.
One thing I’d add to your list under “Configuration and secrets”: AI agents are also prone to weak or predictable patterns in anything crypto-adjacent — session tokens, API keys, password reset tokens, signing secrets. They’ll happily generate something that “looks random” (e.g. Math.random()-based IDs, or a JWT signed with a hardcoded dev secret left in from scaffolding) without flagging that it’s not cryptographically safe for production. That’s a failure mode that won’t show up in functional tests at all — it only surfaces under adversarial review, which is exactly the kind of review most teams skip because “it passed the tests.”
Your point about writing abuse tests before letting the agent touch the implementation (per the comment above) is the right instinct — same logic applies to anything involving tokens/secrets: define the threat model first, then let the agent fill in code against it, not the other way around.
That's a really practical approach! Testing data routes from outside the UI and checking for exposed secrets are simple but valuable checks before deployment. I especially like the idea of keeping evidence for every check instead of relying on a general review. I think automating these checks would make the process even more reliable. Thanks for adding this perspective!
Forget whether you trust it. Production data does not care how you feel about the agent. A demo gets built against an empty database, so the schema has never held a real row and nothing in it has met a deleted parent or a duplicate that should never have existed. That is the gap worth closing first, before anyone argues about the agent's competence. Put the app on a copy of production and watch what it does when the data misbehaves.
The project-by-id example is a good one because the code works exactly as written and still fails the only rule that matters for real users. Working and correct are not the same question.
For founders shipping agent-built apps, the most useful next step is usually a short pre-production list tested from outside the UI: call every data route without a session, change an ID and see whose records come back, search the built JavaScript for secrets. Each item has a clear pass or fail, so it can be re-run after the next big generation.
If someone brings in help for that pass, it is worth asking for that list as the deliverable, with evidence for each item, rather than a general review. Have you turned those checks into an automated suite yet, or are they still manual?
That's a really practical approach! Testing data routes from outside the UI and checking for exposed secrets are simple but valuable checks before deployment. I especially like the idea of keeping evidence for every check instead of relying on a general review. I think automating these checks would make the process even more reliable. Thanks for adding this perspective!
In the past, putting anything into production without rigorous testing was considered foolhardy. With the advent of DevOps, though, the emphasis shifted toward shipping earlier and more often, sometimes with the attitude that 80% good was good enough to ship. Perhaps now, with AI-generated code making it easier than ever to produce more code faster, it's time to revisit some of the rigor we practiced in those earlier days. After all, generating code faster doesn't necessarily mean we've gotten any better at knowing whether it's correct. 🧐
This checklist is a great starting point for getting people to think more critically about how we test AI-generated code in real-world scenarios. The more easily we can generate code, the more important it becomes to think carefully about how we validate it. 🙂
Excellent point! Security issues involving tokens and secrets can easily go unnoticed because everything appears to work normally. I like your suggestion of defining the threat model before implementation. AI can generate the code, but we still need to understand what could go wrong and verify that the security measures are actually strong enough for production.
The missing ownerId check on /projects/:id is the bug I keep finding in agent-written code: the query works, the JSON looks fine, and any logged-in user can read anyone's project. Your duplicate webhook question is the other one I'd add to every review checklist. Do you have the agent write the authorization tests first, or do you review them after?
Hi Robert :-) what data‑encryption safeguards does the AI‑built app use for production?
Great question! Personally, I think defining what an endpoint must protect before implementation is much better than waiting for something to break. It gives both the developer and the AI a clear target and makes testing more meaningful. Discovering security requirements early can save a lot of debugging and rework later.
Thanks! 😀
A green test suite only proves the scenarios you remembered to test. Retries, duplicate webhooks, and partial failures are where generated features meet production reality.
"Because when real users depend on your software, the quality of the result matters more than the speed at which the code was generated." so true!