Start by asking an agent to explain a small part of a repository you are allowed to share. Reading a codebase, editing it and running its commands are different permissions. A useful first exercise separates them so you can see whether the agent understands the task before it can alter your work.
This does not require a dramatic autonomous coding demo. Explaining how one request reaches a handler, identifying the tests that cover it and noting what remains uncertain can be useful on its own. The result should point to real files and behavior, rather than describe an architecture the project does not have.
Choose a task with an observable answer
Use a public sample repository or an authorized disposable copy. Choose a narrow question: where is input validated, which code writes a record, or what happens when a required field is missing? Avoid asking for a general cleanup of a large codebase before you know its conventions.
Write a success check before the agent begins. For an orientation task, you should be able to open the referenced files and follow the described path. For a small fix, the relevant behavior should change, the existing expectations should still hold, and the diff should contain only necessary work.
The Responsible use of GitHub Copilot features links product-specific responsibility and limitation guidance. Use the guidance for the actual coding feature you choose; a general AI subscription does not describe its repository access, command execution or review gates.
A proposed read-only exercise
- Confirm that the repository and any configuration files may be provided to the chosen service.
- Give the agent the repository instructions and a single question about behavior. Ask it to read before suggesting a change.
- Require a path-based explanation with the relevant function names and a list of assumptions.
- Open the cited files yourself. Check that the references exist and that the data moves in the order described.
- Ask which existing test exercises the behavior and what it does not prove.
- Save the explanation with the repository revision so the next person can tell what code it describes.
A suitable request is: “In this sample repository, trace how a missing email field is handled. Read the repository instructions first. Do not edit files, install dependencies or run commands. Cite the files you relied on and distinguish observation from inference.”
Move from explanation to a change
After the explanation holds up, create an isolated branch or disposable worktree for a small requested change. Preserve the starting state and inspect any existing uncommitted work before allowing edits. An agent should not reset someone else’s work merely to make its task easier.
Define the allowed files and the reason a change is needed. Ask for the smallest implementation that changes the relevant behavior. Review dependencies separately: installing a package or running a setup script may execute code and require network access beyond editing a source file.
For a meaningful check, test the behavior that motivated the change, including one plausible failure case. A test that merely mirrors the new implementation can pass without protecting the user-visible contract. Ask the agent what each result establishes, rather than accepting “tests passed” as a complete answer.
Understand the execution boundary
Determine where commands run, what folders they can read and write, and whether they can reach network services. A sandbox can limit some actions; its existence does not tell you that every connected tool shares the same boundary. An external deployment tool may operate outside the repository process.
Keep secrets out of sample inputs and logs. Review the model provider’s data handling separately from the machine hosting the agent. A locally installed coding tool can still send source context to a remote model. Employer and customer agreements can impose requirements the tool’s default configuration does not satisfy.
Review evidence, not just a confident summary
Inspect the complete diff. Look for unrelated formatting, removed checks, broadened permissions and changes to configuration or lockfiles. Open the test output and confirm it belongs to the revision being reviewed. A successful command from an earlier build does not verify a later edit.
Ask for the exact commands run, actual results and checks that were not run. Distinguish build success from runtime correctness. For an interface change, inspect the rendered behavior. For a data operation, use an authorized test environment and exercise its failure behavior before considering real records.
When the agent gets stuck
Keep a record of the failing command and output. Narrow the task to the cause you can reproduce instead of letting it repeatedly replace dependencies or weaken assertions until the build turns green. If the explanation depends on unavailable services, mark that part as unverified.
Recovery should be a normal part of the plan. Preserve a branch or patch you can inspect, know how to discard the experimental change, and avoid touching production data. A reviewed pull request is a useful handoff; automatic merge or deployment is a separate decision.
Choosing an agent for this work
Use the agent directory to compare documented execution, hosting and access models. A source-reading assistant may handle orientation. An agent with terminal tools may help with a bounded patch, but it also requires more deliberate permissions. Choose by the task and environment you can supervise, not by a universal coding score.
