Checking the work · for software engineers
Checking AI output in software engineering
AI-written code usually looks correct. It is formatted well, it is named sensibly, and it often runs. The errors that matter are harder to see. They include an off-by-one at a boundary, a missing null check, a call to a function that does not exist, or a test that asserts nothing useful.
Checking the work means reviewing AI output as you would review a pull request from a new teammate. You read every line. You run it. You check that the tests fail when the code is wrong. And you look for what the change left out, such as error handling or a migration rollback.
Where it comes up
Reviewing a generated function
Read the code against the requirement, not against your sense of whether it looks right. Check boundary values, empty inputs, and error paths. Confirm that every imported function exists in the version you run.
Checking generated tests
Break the code under test on purpose and confirm that a test fails. Tests written by the same model that wrote the code can share its misunderstanding of the requirement.
Verifying an explanation of legacy code
Trace at least one path through the code yourself to confirm the explanation. A fluent summary can describe what the code should do rather than what it does.
What it looks like at each band
E1 · Foundational
Runs the code and checks that it compiles and the happy path works. Tends to trust code that looks idiomatic. May merge a change without reading every line or checking the edge cases.
E2 · Proficient
Reads every line before committing. Runs the full test suite, checks edge cases, and confirms that unfamiliar APIs exist. Removes code that cannot be explained rather than keeping it because it works.
E3 · Distinguished
Checks in proportion to risk. A logging change gets a read, and an authentication change gets line-by-line review and new tests. Looks for what is missing as well as what is wrong. Asks the model to list its uncertain assumptions, then checks those first.
E4 · Exceptional
Sets the review standard the team follows for AI-assisted changes, such as which areas need a second reviewer. Can explain why a change is wrong, not only that it fails. Catches subtle errors others miss, like a race condition or a time zone assumption.
Common mistakes
Treating passing tests as proof
A test can pass because it asserts the wrong thing or nothing at all. Confirm that each test fails when the behavior it covers is broken.
Trusting an API name that looks right
Models sometimes call methods or options that do not exist, or that exist in a different version. Check the documentation or the source for anything you do not recognize.
Reviewing only the diff you asked for
A change can affect callers, configuration, and data you did not mention. Search for other uses of anything the change modifies.
A worked example
Reviewing an AI-written database migration that splits a full name column into first and last name columns.
The migration runs on your laptop against an empty database. The test suite passes. You open the pull request.
An empty database cannot show what happens to real data. Names with one word, three words, or trailing spaces may be split wrongly or lost. Nobody checked whether the down migration restores the original data.
Run the migration against a copy of production-shaped data. Query for rows where the split produced an empty field or more than two parts, and decide how each case should be handled. Run the down migration and compare the result with the original column. Confirm that the application code reads the new columns before the old one is dropped.
The reviewer tests against realistic data, looks for the cases the code did not handle, and checks the rollback. The migration that ships is one the team can reverse if something goes wrong.
The full study guide for this skill, for every role, is Checking the work. The other five skills for software engineers are on the AI skills for software engineers page. A one-page summary is in the AI fact-checking checklist.
See where you stand
The free check grades checking the work and the other five skills in about fifteen minutes. Nobody sees the grade but you.
Then build the skills and prove it. The three steps for software engineers list the courses and templates that fit the work.