An agent can now write a feature, run its own review pass, and hand you a diff that looks finished. The bottleneck moved. It is no longer writing the code, it is deciding whether the code that came back is safe to merge.
Three things are worth checking every time, and they map to three distinct failure modes rather than one general sense of unease.
The Review Pass Is A Separate Step
The single biggest quality difference between coding agents is whether generation and review are the same step or two different ones. When the model that wrote the code also signs off on it, you get the same blind spot every developer has reviewing their own work: it sees what it intended, not what it wrote.
A real review pass runs with a different objective. The writing step is trying to implement the feature. The review step is trying to break it. Often it is a different model entirely, which is what makes the second opinion worth anything.
So the first thing to check is whether a review actually happened, and what it looked at. How AI reviews its own code for bugs covers what that pass catches and, more usefully, what it structurally cannot catch. If your agent has no separate review step, you are the review step, and you should budget your time accordingly.
Edge Cases Are Decided At Planning Time, Not Patch Time
Here is the counterintuitive part. Whether the code handles the empty list, the null value, the million-row input and the record that does not exist is mostly determined before a single line gets written.
An agent that identifies boundary conditions during planning builds the handling in from the start. An agent that writes the happy path first and patches edge cases afterward produces code where error handling is bolted onto the outside, and the seams show up later as the bugs that only appear in production.
When you read the diff, look at where validation lives. Validation at system boundaries, on the way in, is a sign the failure cases were considered up front. Validation scattered through the middle of the logic usually means they were discovered one at a time. How coding agents handle edge cases and error handling goes through the patterns that hold up and the ones that do not.
Security Review Catches The Common Ten, Not Your Business Logic
Agent-generated code generally does pass standard security audits, and that is worth saying plainly because the assumption usually runs the other way. A decent agent scans its own output for the OWASP Top 10: unparameterized queries, unescaped output, command injection, missing authentication on protected endpoints, hardcoded credentials, error messages that leak internals. It traces data flow from input to sensitive operation. It catches the mistakes that automated scanners flag.
What it does not catch is anything that requires knowing your business. That a support agent should not be able to read another tenant's records is not a pattern in a vulnerability database, it is a fact about your product. The agent has no way to know that rule exists unless you told it.
So the split is clean: trust the agent on the known categories, keep human review on authorization logic and anything touching money or personal data. Does AI generated code pass security audits breaks down which standards this covers and where the boundary sits.
The Practical Version
Before you merge, three questions:
Did a separate review pass run, and against what criteria? Were edge cases handled at planning time, or patched in afterward? Does anything here encode a business rule that only you know?
The first two are mostly about picking an agent that works this way. The third one stays yours permanently, and it is the reason review does not go away no matter how good the generation gets.
More on building and shipping software this way at AI development.
Top comments (0)