How I give Sol room to work in Codex

Start with the outcome

A task such as “add filtering to the orders page” sounds specific, but it still leaves the important question unanswered: what should become easier for the person using it?

I begin by describing the finished behavior in plain language. A person should be able to narrow a long order list, share the filtered view with a teammate, and return without losing the selection. That statement gives Sol something more useful than a component name. It gives the code a reason to change.

I also include the context that would change the implementation. The application may already store filters in the URL. The same controls may appear on another screen. A support team may depend on copied links. Those details are more valuable than an early instruction to add a new hook or state object.

A good prompt does not contain every step. It makes the destination and the important terrain difficult to misunderstand.

Once the outcome is clear, I ask Sol to inspect the current behavior before editing. I want it to identify where the state lives, which conventions already exist, and what adjacent behavior could be affected. That inspection is part of the work, not a delay before the work begins.

Define the boundaries

Autonomy works better when its edges are explicit. I tell Sol which local actions are part of the assignment and which decisions need to come back to me.

For ordinary implementation work, reading the relevant files, editing in-scope code, and running focused tests are expected. Changing a public interface, adding a dependency, modifying persistent data, or expanding the feature into another workflow may require a decision first. The exact line changes by project, but the line should exist before the model reaches it.

I keep these boundaries connected to risk rather than ceremony. A new internal helper may not need discussion. A database migration deserves a pause even when the code for it is straightforward. A visual adjustment can proceed locally, while publishing it or changing an external service remains a separate action.

The last point matters. If Sol discovers that the proposed feature conflicts with an existing contract, I want that conflict surfaced. I do not want a plausible patch built around an assumption that the code has already disproved.

Clear boundaries make the session calmer. Sol can continue through safe, expected work without asking for permission at every small step, while the decisions with real consequences remain visible.

Ask for evidence, not confidence

An implementation summary can sound complete before the implementation is complete. I make the expected evidence part of the original assignment so that “done” has a meaning beyond a confident final message.

The evidence depends on the change. For a bug, it may be a regression test that fails before the fix and passes afterward. For a user flow, it may include a focused test suite, a build, and a manual check of the important path. For a refactor, it may be unchanged behavior plus a smaller or clearer interface between modules.

I ask Sol to report the checks it actually ran and distinguish them from checks it only recommends. If something could not be verified, that belongs in the result too. An incomplete check is useful information; hiding it behind a polished summary is not.

Tests are only one kind of proof. They can show that known expectations still hold, but they cannot always show that a screen is understandable or that the chosen behavior solves the right problem. I still review the critical diff and exercise the part of the product a person will touch.

This is where a capable model saves me the most time. It can carry the outcome through investigation, implementation, and verification. My review can begin with the product decision and the evidence instead of reconstructing the purpose of the change from the diff.

Use a smaller prompt

This is the shape I reuse. It gives Sol direction without prescribing the implementation before it has seen the code.

Implement this outcome in the existing repository:

[Describe what should become true for the user.]

Before editing, inspect the current behavior and identify the existing
modules, conventions, and constraints that should shape the change.

You may read and edit relevant local files and run focused validation.
Preserve [important behavior or interface]. Ask before adding a dependency,
changing persistent data, modifying a public contract, or expanding scope.

Finish with evidence:
- summarize the behavior that changed
- name the important files and decisions
- run [tests/build/manual check]
- report anything that remains uncertain or unverified

The prompt is deliberately small. It states the destination, grants the routine local work, protects the decisions that carry more risk, and defines what the final report must prove. I add detail when the product needs it, not because the model needs a transcript of how I would code the change myself.

When a task is larger, I keep the same shape and improve the brief before I create more assignments. When it is smaller, I may leave out the ceremony. The practice is not about forcing every change through a template. It is about being specific where specificity protects the work.