AI coding: context, verification, and costAI coding: context, verification, and cost

This article is for readers who have completed the initial setup and want to improve their AI coding workflow. For tool settings, see Omnigate’s advanced Claude Code guide. New users can begin with the quick-start guide.

These notes come from everyday development and troubleshooting. They focus on preparing information, dividing work, and verifying results. The details can be adjusted to the project, model, and tool configuration.

For a workflow where Claude generates code and Codex reviews it independently, see AI coding workflow: implementation, review, and decisions.

1. Prepare context relevant to the task

Model choice and context quality both affect coding results. Clear project conventions, errors, and relevant files make it easier for the model to work on the actual problem.

When adjusting a setup, start by checking whether CLAUDE.md contains the necessary project conventions, then consider whether a different model or another plugin is needed.

Before a bug fix, for example, collect the reproduction steps, complete error, and relevant file paths. This can reduce exploratory searches. The time and tokens saved need to be assessed for the actual task.

2. Choose /clear or /compact based on task continuity

Conversation length alone does not explain cost. Whether earlier input hits the cache, and how cached input is billed, also matter. Frequent use of /clear may require the model to read the project structure and task background again.

When switching to an unrelated task, /clear can remove the previous context. When the same task has accumulated a long history, /compact can preserve the main points while compressing the process.

I usually watch context usage in the status line and consider compaction at around 70%. That is an operating habit; the right point depends on the information the task still needs.

3. Match the model to the job

Task clarity, ease of verification, and the cost of rework can guide model selection. One approach is:

• For a small edit, tests, formatting, a commit message, or document translation, try a small model such as Haiku when the task is clear, then check the result.
• For everyday development, start with a middle tier such as Sonnet and assess whether its results and cost fit the work.
• For architecture decisions, complex refactors, difficult bugs, or performance work, consider a more capable model and assess whether reduced rework offsets the price difference.

Tasks that are easy to verify provide room to try lower-cost options. Complex judgments require attention to both model capability and review effort.

In configurations that use ANTHROPIC_DEFAULT_HAIKU_MODEL, check that setting too. Models used for background tasks such as session titles and summaries are another part of usage to examine.

4. Divide work into changes that can be verified

Combining unrelated requirements can make the scope and acceptance criteria unclear. It also makes it harder to connect each change to a requirement during review.

Separate those requirements and verify each part when it is complete. This makes problems easier to locate and helps identify which changes need further work.

5. Include verification in the workflow

Having the model run tests and type checks after an edit provides direct evidence about the result. Put the commands in CLAUDE.md, configure the necessary permissions in the settings.json allow list, and ask it to run the checks and address failures.

Test output helps the model locate and fix problems. The scope of verification still needs to match the task.

Steps that should run every time, such as formatting, can be defined in a hook.

6. Use plan mode to confirm larger changes

When a change touches more than three files, I usually start in plan mode. File count is a prompt to consider planning; the main question is whether the scope and approach are understood.

Ask the model to propose an approach, then clarify or correct specific steps. Resolving differences before implementation can reduce the work of revising a large diff later.

7. Turn repeated instructions into reusable commands

Prompts used repeatedly can be saved in files and refined with boundaries, output formats, and a clear scope. This makes them easier to reuse and maintain.

Common uses include reviewing the current diff, repairing failing tests, adding tests for a module, and explaining implementation choices.

8. Add tools for a specific need

Before adding an MCP server, plugin, or agent collection, identify the problem it addresses. Tool definitions consume context, and too many options may make tool selection harder. The execution permissions of third-party hooks and scripts also need review.

The setup described here uses context7 for documentation, with Playwright or Chrome DevTools enabled for frontend work.

For third-party agent collections, read the relevant files and select the parts needed for the task.

9. Match human review to the task

Boilerplate, tests, mechanical refactors across files, explanations of unfamiliar code or errors, and one-off scripts are all tasks to try with AI.

Business decisions, incomplete information, changes to systems with unwritten conventions, and performance investigations without profiling data call for more background and human judgment.

Check for code that appears reasonable but relies on a false assumption. A model might assume that a function is idempotent, for example. Review the assumptions behind critical paths as well as the code itself.

Reading tasks also require checking what the original supports. Conuo's source-reading and note workflow uses material with formulas and a graph to show how citation checks and explanation review lead into study notes.

10. Check costs against actual usage

Alongside model pricing, examine these sources of usage:

• rework caused by incomplete context
• conversations that mix unrelated tasks
• model tiers beyond what a simple task needs
• output longer than required because max_tokens was not set appropriately

Their share of the cost depends on the actual records. Review the Omnigate usage logs for requests with unusually high token counts and signs that complete files are being sent repeatedly.

Adjust the workflow as needs change

Tools and tasks change, so the setup needs to be assessed against actual results. Start with a common task and observe whether the context is sufficient, the checks are useful, and where the cost comes from.

For further discussion, get in touch.

Originally published in the Omnigate documentation.