A Practical Workflow for Coding With AI Agents

An AI coding agent is most useful when it is treated as a capable contributor with a narrow assignment, not as a slot machine for code. Give it a vague wish and it will fill in the gaps with guesses. Give it a clear outcome, boundaries and a way to prove the result, and the work becomes much easier to review.

The workflow below applies to Claude Code, Codex, Cursor and similar tools. Their interfaces change quickly, but the basic loop is stable: describe the result, let the agent inspect before editing, verify the change and keep judgment with a person.

A fictional task that is larger than it sounds

Imagine a small appointment-booking service. The request is “send a reminder before every appointment.” It sounds like one email function, but the real change crosses several boundaries:

• the database needs a reliable reminder state;
• a scheduled job needs to select due appointments without sending duplicates;
• the email template needs the correct locale and time zone;
• retries must not turn one reminder into three;
• tests need to cover cancellation and rescheduling.

Autocomplete can help inside any one file. An agent can trace the whole path and notice that a simple sent: true flag is not enough when two workers run at the same time.

This example is fictional, but the shape is common: the visible feature is small while the correctness rules live in several places.

Write a brief, not a wish

A useful prompt reads like a compact issue:

Goal: send one reminder 24 hours before a confirmed appointment.
Reuse: the existing scheduler, mail adapter and locale formatter.
Do not change: public API routes or the appointment status model.
Edge cases: cancellation, rescheduling and two workers claiming the same job.
Verification: add focused tests and run the existing test command.

Each line removes a different kind of ambiguity. The goal describes observable behaviour. “Reuse” points the agent toward the current architecture. “Do not change” prevents a local task from becoming a redesign. Edge cases name the failures that matter. Verification defines what evidence should exist at the end.

For a change spanning several files, ask for a plan before edits. Anthropic exposes this directly through Claude Code’s Plan Mode and project-memory workflow. A short plan makes a wrong assumption cheap to correct.

Let inspection happen before implementation

The first useful agent action is usually reading, not writing. It should find the entry point, nearby conventions, tests and the command the repository already uses. If the task touches stored data or a public API, it should trace readers as well as writers.

In the booking example, a sensible plan might reveal that reminders are already represented as jobs. The smallest change is then an idempotency key and a new job type, not a second scheduling system. That is the value of repository context: it turns an attractive greenfield answer into a compatible local one.

If an agent proposes a new dependency, background service or schema before inspecting the existing path, pause. The proposal may be valid, but it has not yet earned its cost.

Choose the tool by the shape of the work

Product names matter less than their working surfaces.

Claude Code is comfortable when the terminal is central: reading logs, running scripts and following a failure through real command output. Codex is useful for isolated, long-running work; the Codex app’s worktree model is designed to keep parallel tasks from colliding. Cursor stays close to the editor, where its diff review and checkpoint tools make small corrections and close reading convenient.

These are not permanent rankings. A model update can change the balance in a week. The durable choice is whether the tool gives the task enough context, keeps changes reviewable and makes risky actions explicit.

The review loop agents should not grade themselves on

“Tests pass” is a claim. The test command, exit status and output are evidence. A reliable loop looks like this:

npm test -- reminder
npm run typecheck
npm run build

The exact commands depend on the repository. What matters is that they existed before the prompt or were deliberately added for the behaviour. An agent should not quietly narrow a check, delete an assertion or turn an error into a warning just to make the result green.

After automation, read the diff for questions a test may not answer:

• Does the implementation match the requested behaviour rather than merely the test fixture?
• Can a retry or concurrent worker violate the invariant?
• Did a public contract or stored format change accidentally?
• Is the error useful to the person who will operate the system?
• Is the new abstraction simpler than the code it replaced?

For visual work, open the result at narrow and wide viewports. For configuration, check the real response or process state rather than trusting syntax alone.

Keep intent and approval human

Agents are good at turning a decision into consistent edits. They are weaker when the decision itself is unresolved. Keep these parts with a person:

• product intent and the trade-off being accepted;
• final wording, tone and factual claims;
• approval for deployment, credentials or destructive actions;
• decisions that change public URLs, stored data or security boundaries;
• the choice to accept, rewrite or discard generated work.

This is not ceremonial supervision. In the fictional reminder feature, someone still has to decide whether a late reminder should be sent, skipped or escalated. No amount of code context answers a product question that was never settled.

Where the workflow usually breaks

The common failure is missing context rather than broken syntax. An agent sees one file and creates a new pattern even though the repository already has one. It renames a public route because the new name looks cleaner. It repeats a confident product fact copied from an old article.

Repository instructions help with recurring conventions, but they should stay short. Put one-off constraints in the task. For unstable facts, provide a primary source and a date. For important work, end with a question that invites honesty: “What remains unverified?”

A good agent does not merely produce a patch. It leaves the limits of that patch visible.

The skill that lasts longer than a model release

The durable skill is not prompt magic. It is turning an idea into a bounded change with an observable result: define the outcome, show the constraints, name the checks and review what changed.

That loop makes agents more useful without pretending they are autonomous owners. It also happens to make specifications clearer for human collaborators. Faster execution is valuable; clear responsibility is what makes the speed safe to use.