How an engineer reads AI-written code

AI code usually looks tidy and confident, whether or not it is right. The skill is not to trust the look. The engineer who commits the change owns it, and has to understand it as well as if they had typed every line.

A reading routine

1. 1

   1. Start from the requirement

   Read the story and its acceptance criteria first. Then ask what the code should do, before reading what it does.

2. 2

   2. Read it as a stranger's code

   Do not skim because it looks neat. Follow the logic path, including the failure paths.

3. 3

   3. Look for what is missing

   AI often leaves out edge cases, error handling, permission checks and input validation. Check each deliberately.

4. 4

   4. Check what it relies on

   Make sure every library and function it calls exists, is the version in use, and is approved. Do not accept invented names.

5. 5

   5. Test the tests

   Break the code on purpose and confirm the tests fail. A test that cannot fail proves nothing.

6. 6

   6. Explain it back

   Write the change description in your own words. If you cannot, you do not yet understand it enough to ship.

Warning signs

• Code much larger than the problem needs
• Tests that repeat the implementation, or that never fail
• Dependencies nobody asked for
• Secrets, keys or customer data anywhere in code or prompts
• Comments or names that sound sure but do not match what the code does