AI can produce a large amount of working code in a few minutes. That changes the economics of software development, but it does not remove the need for careful review. As Kanwal Mehreen put it, “AI makes writing code cheap.”
The harder part remains deciding whether the code does the right thing. “Verifying it is still your job,” Mehreen wrote. AI-generated code can compile and pass tests while still being semantically incorrect, meaning it connects or handles things in a way that does not match the task.
As of October 19, 2026, Git warns that AI-generated code can be semantically incorrect and recommends reviewing and testing it before merging. These seven checks provide a practical way to do that.
Start With the Change Itself
1. Inspect the diff with Git
The first check is simple: look at what changed. AI agents sometimes modify more than a task requires when they can access an entire repository. The goal is to confirm that the AI solved the task you gave it, not a larger task it invented.
Start with git diff –stat to get an immediate picture of the change scope. Then review the full diff and look for files unrelated to the task, deleted tests, disabled validation, permission changes, dependency file changes, large refactors, hidden feature duplications, and error handling that ignores failures.
A small request should not quietly become a broad rewrite. The diff gives you a way to spot that before the code reaches a merge.
2. Run automated syntax and type checks
Humans are terrible compilers, so automated tools should check syntax. For Python, useful checks might include python -m compileall ., ruff check ., and mypy. For JavaScript or TypeScript, run npm run lint, npx tsc –noEmit, and npm run build.
Static type checking matters because models can connect values that look compatible but are not. Code may look sensible on the page while passing the wrong kind of value between functions. These tools can catch problems before normal testing exposes them.
Check What the Code Relies On
3. Verify every new dependency
Models sometimes invent package names that look plausible but do not exist. A 2025 study analyzed 576,000 large language model-generated code samples and documented package hallucinations across Python and JavaScript: 5.2% for commercial models and 21.7% for open-source models.
Hallucinated package names create an opportunity known as slopsquatting. Whenever AI adds a dependency, verify it independently. For Python, use pip index versions package-name. For npm, use npm view package-name.
Check whether the package exists, whether it is official, who maintains it, and when it was last updated. Also confirm that the project needs it, that its version matches the documentation, that the lockfile changed as expected, and that the package has no known vulnerabilities.
4. Confirm unfamiliar APIs in official documentation
AI can produce code built around an API detail that sounds right but does not match the real interface. Open the official documentation and confirm the class, method, parameters, return type, and supported version.
Every newly introduced package and unfamiliar external API should be traceable to an authoritative registry or official documentation. This check keeps plausible-looking guesses from becoming part of the application.
Test More Than the Happy Path
5. Run the existing test suite
Running the existing test suite is necessary, but it is not sufficient. A passing suite shows that existing checks still pass; it does not prove that the new behavior handles every important case.
AI often generates tests for only the happy path. That leaves gaps where normal input works, but unusual or failed input breaks the feature.
6. Test four types of input and failure
Test at least four categories: normal input, boundary input, invalid input, and failure condition. This approach checks both the expected result and the points where the software must reject, recover, or report a problem.
For an API endpoint, test a valid request, a missing field, a malformed field, an unauthorized request, and a database or service failure. These cases expose behavior that a basic successful request will not show.
7. Make sure AI did not weaken the tests
Review the test changes as carefully as the production code. Ensure that AI did not weaken or delete failing tests to make the suite pass. Deleted tests, disabled validation, and changes that hide failures belong on the warning list during diff review.
The broader lesson is clear: code is only one input into successful software. Luis Aburto said, “AI is lowering the cost of producing code, yet code is only one input into successful software.” Gopichand Mannava made the same point another way: “Reliability depends on more than model intelligence alone.”
These checks turn AI-generated code from something accepted on faith into something examined through changes, tools, dependencies, documentation, and tests. That review remains the developer’s responsibility before the code is trusted or merged.
Based on
