Build a Feature With AI Assistance

Core path: 35 minutes

The assignment is simple: add CSV export to a working Python application.

The harder part is preserving evidence of what the AI proposed, what you inspected, what you changed, and what you rejected.

The goal is not to prove you can make an AI write code. That is easy.

The goal is to prove you remained the developer responsible for the change.

Safety boundary first

Do not submit to an AI tool:

• passwords, credentials, tokens, or API keys;
• student records or personally identifying information;
• private repository content your teacher has not authorized;
• confidential or unpublished school information; or
• data you do not have permission to share.

Use course sample code or non-identifying test data.

Create a known-good checkpoint

Before asking for a change:

python -m pytest
git status

Commit the known-working state if your project workflow is ready for a checkpoint.

Now you have somewhere trustworthy to compare against.

Define the feature before generation

The request should include facts the candidate needs:

feature: CSV export
current player data shape:
required CSV columns:
files allowed to change:
standard-library-only constraint:
expected empty-roster behavior:
definition of done:

If your class has an approved managed AI environment, submit the bounded request there and save the exact prompt plus the unedited first response in ai_log.md.

If no approved AI tool is available, use this supplied candidate as the unedited response:

import csv


def export_csv(players, path="export.csv"):
    with open(path, "w", newline="", encoding="utf-8") as file:
        writer = csv.writer(file)
        writer.writerow(["name", "score"])
        for player in players:
            writer.writerow([player["name"], player["score"]])

The fallback is intentionally a candidate, not an answer key.

Inspect assumptions before integration

Ask:

• Does our project still use dictionaries, or are players objects now?
• Are name and score the correct access paths?
• Where should the export file go?
• What should happen for an empty roster?
• What should happen if one record is malformed?
• Did the candidate add imports or files we did not request?

Record at least:

one assumption discovered
one part accepted
one part revised
one part rejected or explicitly confirmed unnecessary

Make the candidate fit the actual project

If Week 12 changed players into objects, this:

player["name"]

may already be wrong for your architecture.

The candidate does not get credit for sounding plausible.

It has to fit the code that actually exists.

Verify the feature

Test at least:

1. two normal players;
2. an empty roster;
3. one malformed or unexpected record/state allowed by your test setup.

Open the produced CSV and inspect the file contents directly.

Do not stop at:

No exception happened.

Check that the output file contains the headers and rows you intended.

Inspect the final diff

Run:

git diff

Ask:

• Which files changed?
• Are all of them required for CSV export?
• Did tests change?
• Did any existing behavior get removed?
• Did the candidate quietly expand scope?

Then run the full relevant test suite.

Preserve the evidence trail

Your ai_log.md should contain:

prompt or supplied candidate
unedited first output
assumptions found
accepted changes
revisions
rejections
verification commands/results
diff summary

Working code without that evidence does not complete the lesson.

AI assistance changes how quickly a candidate can appear. It does not change who is responsible for proving the candidate belongs in the project.