Prompt, Inspect, Verify

A prompt is not a spell. It is the beginning of a change request.

The safest mental model for AI-assisted coding is the same one you would use for a pull request from an unfamiliar contributor:

REQUEST
   ↓
CANDIDATE CHANGE
   ↓
INSPECT THE DIFF
   ↓
VERIFY BEHAVIOR
   ↓
COMPARE WITH REQUIREMENT
   ↓
ACCEPT / REVISE / REJECT

Interactive model

Prompt, inspect, verify — then decide

Pause motionReset layout

AI output is a candidate change. Human review and evidence determine whether it is accepted, revised, or rejected.

PROMPT goal + boundaries

CANDIDATE CHANGE AI proposal

INSPECT diff · scope · dependencies

VERIFY tests + behavior

DECIDE accept · revise · reject

React Flow

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

Drag nodes to inspect the relationships. Motion shows the active path; the plain background keeps attention on the relationships instead of graph-paper decoration.

View static diagram

Write boundaries another developer could review

Weak request:

Add CSV export.

The missing decisions are obvious once you ask what “done” means:

• Which records are exported?
• Which fields?
• Which filename/path?
• What happens for an empty list?
• Can dependencies be added?
• Which files may change?

A bounded request might be:

Goal: export player name and score to export.csv.
Current data: list of dictionaries with name and score keys.
Constraint: Python standard library only.
Allowed files: reports.py and tests/test_reports.py.
Required cases: multiple players and empty list.
Do not change storage.py or the Player data shape.

The stronger request is easier to review because it defines what should and should not move.

Ask for a plan when the blast radius is unclear

Before generating code, you can request:

Describe the files and functions you expect to change. Do not write code yet.

If the plan proposes a database migration for a two-function console feature, you can reject the architecture before it becomes a 500-line diff.

That is cheaper than repairing over-generation.

Inspect exact changes, not the summary

Suppose the tool says:

Added CSV export and tests.

That is a claim.

Use repository evidence:

git status
git diff

Ask:

Which files changed?
Which imports changed?
Were dependencies added?
Did existing interfaces change?
Were tests deleted or weakened?
Did formatting noise hide the functional change?
Is every changed line connected to the task?

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

A small requested feature that changes twelve unrelated files deserves investigation even if every test is green.

Verification has multiple layers

For a candidate feature, use more than one kind of evidence when appropriate.

Static inspection

Can you explain the code and imports? Does it follow project boundaries?

Automated tests

Run the existing relevant suite plus new tests.

python -m pytest

Manual behavior

Exercise the feature using a normal case and an edge/failure case.

Requirement comparison

Return to the original request. Did the implementation solve the requested behavior without inventing new scope?

A candidate can pass tests and still violate a dependency or privacy constraint.

Generated tests are candidates too

Consider the requirement:

Export name and score only.

Candidate implementation:

def export_players(players):
    fieldnames = list(players[0].keys())
    ...

Candidate test:

def test_export_players(tmp_path):
    players = [{"name": "Nova", "score": 10, "secret_note": "x"}]
    export_players(players)
    assert output_file.exists()

The test passes even if the private/unwanted field is exported.

The problem is not that the test is syntactically bad. It tests the wrong claim.

A stronger test inspects the actual fields:

assert rows[0] == {"name": "Nova", "score": "10"}

This is why requirement review cannot be delegated to the same generation loop without inspection.

A plausible solution can still violate the specification

Requirement:

Standard library only.
Export name and score only.

Candidate:

import pandas as pd


def export_players(players):
    pd.DataFrame(players).to_csv("export.csv", index=False)

That may create a CSV successfully.

It still fails review because:

• it adds an unauthorized dependency; and
• it exports every field in each record rather than the required two fields.

The correct decision is revise or reject.

Working output is necessary. It is not sufficient.

Use a rejection record

When you reject or revise a candidate, keep a short record:

CANDIDATE CLAIM:
EVIDENCE CHECKED:
PROBLEM FOUND:
DECISION:
NEW BOUNDARY / REQUIREMENT:

That turns “AI gave bad code” into a useful engineering history.

Privacy is part of the prompt boundary

Before sending context to any tool, classify it.

SAFE TO SHARE IN APPROVED TOOL
REDACT / REPLACE WITH FIXTURE
DO NOT SHARE

A traceback can contain local usernames or paths. A configuration file can contain tokens. A dataset can contain personal records.

Use minimal, sanitized context needed for the technical question.

No-tool path

If your environment does not provide an AI assistant, review the supplied candidate patch for this Unit.

Run the exact same loop:

read requirement
inspect candidate
run tests/checks
compare behavior
accept/revise/reject

The course is testing developer judgment, not access to a particular product.