Context engineering beats prompt engineering.
A prompt is a single instruction. Context is everything the model is carrying while it answers: files, prior turns, tool definitions, project instructions, and the accumulated debris of the conversation.
Teams spend a lot of energy searching for a better prompt when the useful question is simpler: does the model actually need all of this? Good context engineering supplies the right files, the right instructions, the right tools and a clear scope — and nothing else.
Start a new chat far more often.
Long conversations get slower and more expensive because the model reprocesses decisions that stopped mattering hours ago. Worse, stale reasoning keeps influencing new answers.
Write progress into a Handover.md — decisions made, current state, what is next — paste that into a fresh conversation, and carry on. You keep the architecture and drop the history.
Edit the prompt instead of correcting it.
The accumulation pattern is familiar: build a login page, then “use Tailwind”, then “make it responsive”, then “ignore the Bootstrap bit”. Four rounds of context, and the model is still reasoning about instructions you have retracted.
Edit the original request instead. One well-written prompt is almost always cheaper and better than five corrections layered on top of each other.
Scope every task to named files.
“Build authentication” invites the model to read half the repository and rewrite things you did not want touched. Compare:
“Add JWT validation to the authentication middleware. Only modify AuthenticationMiddleware.cs and TokenService.cs.”
That gives an objective, a file boundary, an architectural constraint and an implicit success criterion. Scope is the single highest leverage habit on this list.
Stop pasting entire files.
A 1,500-line class pasted in to fix one method is 1,500 lines of context bought to solve a twenty-line problem. Name the file, the class, the method and the symptom, and let the model ask for more if it needs it. Modern tooling can read the repository; it does not need you to read it aloud.
Keep project instructions lean.
Conventions belong in an instruction file — AGENTS.md for Codex, CLAUDE.md for Claude Code — not repeated in every conversation. Architecture, coding standards, build commands, test framework, naming conventions, preferred libraries, folders to leave alone.
Then resist turning it into a knowledge base. These files load into every single request. Use progressive disclosure: keep the working set short and reference the long documentation separately, so it is fetched only when relevant.
Disconnect MCP servers you are not using.
Every connected MCP server adds tool definitions the model must read and reason about on each turn. Ten servers connected for a task that needs one is both a cost and an accuracy problem — a smaller toolset makes correct tool selection easier. Turn off GitHub, Slack and database servers when you are editing CSS.
Plan before you ask for code.
Separate thinking from typing. Ask which files change, what the recommended approach is, what the edge cases are, and how it will be verified — before a line is written. Planning is almost always cheaper than the rewrites that follow a wrong guess, and Claude Code’s plan mode exists precisely to force the gap.
Batch related work, and pick the right model.
Every message reloads the conversation. “Rename the class, update the unit tests, regenerate the XML comments and make sure the build passes” is one reasoning pass. The same four requests sent separately is four.
And stop forcing one model through every stage. In practice: research and brainstorming lean towards ChatGPT, architecture and planning towards Claude, very large document analysis towards Gemini, and repository-level implementation towards Codex. Use the tool that suits the stage.
Build skills, and verify before moving on.
A prompt you have written more than three times should be a reusable workflow: endpoint scaffolding, component templates, PR review checklists, unit test generation, documentation standards. Less repetition, more consistency.
Then extend every request past implementation: run the tests, fix what fails, check formatting, explain what changed, flag the risks. The model can catch its own trivial mistakes before a human spends attention on them. Human review still happens — it just stops being spent on missing semicolons.
Keep the repository AI-friendly.
Repository structure changes how efficiently any agent works in it. Group related features, delete obsolete and duplicated code, keep the README current, write down architecture decisions, and keep the instruction file honest.
None of that is AI-specific. It is the same tidiness that helps a new engineer in their first week — which is roughly the situation a model is in on every request.
The mistakes still worth naming.
- Conversations that have been running for weeks.
- Uploading a whole repository to fix one file.
- Leaving every MCP server connected all the time.
- Asking for a full file rewrite when a targeted change would do.
- Repeating project conventions in every conversation instead of writing them down once.
- Asking the model to “figure it out” with no scope and no constraints.
The working shape underneath all of this is unremarkable: research and requirements, architecture and planning, scoped implementation tasks, AI-assisted development, verification and testing, human review, pull request, deploy. AI accelerates the stages. It does not replace the sequence.
Common questions.
Does this actually reduce cost, or just token count?
Both, and the second-order effect is larger. Smaller, better-scoped context produces fewer wrong answers, which removes the rewrite cycles that consume the most budget. Teams usually notice the quality improvement before they notice the bill.
How long should a conversation last?
Roughly one coherent unit of work. When you notice yourself explaining something the model already agreed to two hours ago, write a handover note and start again.
Is a CLAUDE.md or AGENTS.md file worth the effort?
Yes, if it stays short. It removes the same paragraph of context from every future conversation. It becomes counterproductive when it grows into a manual, because it is then loaded in full on every request whether relevant or not.
Should engineers use one model or several?
Several, matched to the stage. The overhead of switching is small compared with forcing a single tool through research, architecture, implementation and large-document analysis when it is only strong at two of them.
Does AI-assisted development still need code review?
Yes. What changes is what review is for. Having the model run tests, fix failures and explain its own risks first means human review is spent on design and correctness rather than on mechanical defects.
What this means for a buyer.
If a team is hitting usage limits, the cause is almost never the model. It is unscoped tasks, conversations that never end, and context nobody curates. Simam Digital reviews how engineering teams actually use AI tooling and where the waste is — see also our guide to auditing a development workflow and agentic workflow in a real product team.
Sources and further reading
A version of this article was first published in Tech Alchemy, the Simam Digital newsletter on LinkedIn.
