Questions I Ask Before an Agent Touches Code

Before I let an agent touch a project, I ask what it might break, what it cannot know, and how I will notice if it is wrong. “Make the code better” is not a specification, and a confident response is not a review.

I start by asking which parts of the project carry the most risk. That usually points to authentication, data writes, integrations, and the places where a small change can affect many screens.

Then I ask what the agent would simplify, and what it would leave alone. I want it to explain the trade-off instead of turning every unfamiliar pattern into a refactor just because a cleaner-looking version is easier to describe.

I ask what will fail as the project grows, too. A solution that works for ten records or one request may become the bottleneck at a thousand, but the agent needs the workload and the assumptions before that answer means anything.

The most useful question is probably the least glamorous: what test would prove this change is safe? If the answer is vague, I would rather spend time making the behaviour observable than accepting a neat patch I cannot verify.

These questions turn an agent from an autocomplete box into a second pair of eyes. It can still be wrong, but it has to show me its assumptions, its proposed boundary, and the evidence I should check before I trust the change.