AI-assisted coding without losing the plot

Why you need a routine

An AI assistant can write code faster than you can read it. That's the risk. If you accept changes you don't understand, you end up with a program that works until it doesn't, and no idea where to start fixing it.

The fix isn't to become an expert first. It's a routine that keeps each change small enough to check, and lets a test, not the assistant's confidence, decide whether it worked.

1. 11. One small change at a timeAsk for one thing: fix this bug, add this option. Big requests produce big changes you can't review.
2. 22. Give it the evidencePaste the code involved and the exact error. Don't describe the error from memory.
3. 33. Let a test be the refereeWrite or keep a test that fails before the change and passes after it. The assistant saying "this should work" isn't evidence.
4. 44. Read the change before you keep itLook at exactly what changed. If you can't explain it in a sentence, ask, or don't keep it.
5. 55. Save a working versionKeep a copy (or a commit, if you use Git) each time the tests pass, so you can always go back.

Reading an error message

Python's own tutorial gives the two things to know. "The last line of the error message indicates what happened." And "the preceding part of the error message shows the context where the exception occurred, in the form of a stack traceback": which file and line the problem passed through.

So read from the bottom up. The last line tells you the kind of problem. The lines above it point to where. That's usually enough to know which part of your code to show the assistant.

Worked example: a real bug, a real fix

Here's a small function that averages star ratings, with a mistake we put in on purpose. It works for a normal list but fails when there are no ratings yet, which is exactly what happens with a new product.

def average_rating(ratings):
    """Return the mean of a list of 1-5 star ratings, rounded to one decimal place."""
    return round(sum(ratings) / len(ratings), 1)

Python's unittest module is built in. In its words, "A test case is the individual unit of testing. It checks for a specific response to a particular set of inputs." We wrote two: a normal list, and an empty one that should give no average at all.

import unittest
from ratings import average_rating


class AverageRatingTest(unittest.TestCase):
    def test_typical_ratings(self):
        self.assertEqual(average_rating([5, 4, 4]), 4.3)

    def test_no_ratings_yet(self):
        self.assertIsNone(average_rating([]))


if __name__ == "__main__":
    unittest.main()

E.
======================================================================
ERROR: test_no_ratings_yet (test_ratings.AverageRatingTest.test_no_ratings_yet)
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../test_ratings.py", line 10, in test_no_ratings_yet
    self.assertIsNone(average_rating([]))
                      ~~~~~~~~~~~~~~^^^^
  File ".../ratings.py", line 3, in average_rating
    return round(sum(ratings) / len(ratings), 1)
                 ~~~~~~~~~~~~~^~~~~~~~~~~~~~
ZeroDivisionError: division by zero

----------------------------------------------------------------------
Ran 2 tests in 0.001s

FAILED (errors=1)

def average_rating(ratings):
    """Return the mean of a list of 1-5 star ratings, rounded to one decimal place."""
    if not ratings:
        return None
    return round(sum(ratings) / len(ratings), 1)

Its explanation: "The function now returns None for an empty list before attempting the division, so no ZeroDivisionError is raised." Two lines were added and nothing else changed, which is easy to review. Then the referee: we ran the tests again.

test_no_ratings_yet (test_ratings.AverageRatingTest.test_no_ratings_yet) ... ok
test_typical_ratings (test_ratings.AverageRatingTest.test_typical_ratings) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK

Keep your environment and secrets safe

Two habits prevent most beginner trouble. First, use a virtual environment for each project: Python's venv module "supports creating lightweight “virtual environments”, each with their own independent set of Python packages", so an assistant's suggested install can't break your other projects.

Second, never paste a secret into a prompt or a file you share: API keys, passwords, tokens. Leaked keys get misused; GitHub runs secret scanning precisely to catch "exposed credentials before they can be exploited". Keep secrets in environment variables or a file your tools are told to ignore, and if you ever paste one by mistake, cancel it and make a new one.

Try it

What to remember

• Small changes, real evidence, a test as referee, and a review before you keep anything.
• Our example is one run on one model with a deliberately simple bug. Real bugs are messier, which is why the routine matters more, not less.
• Coding tools that run commands for you are agents. Read what they're about to do before you approve it.