The New Problem Is Not The Prompt
The old AI coding workflow was simple: paste a bug, paste a file, ask for help, copy the answer, regret one variable name. The new workflow is different. A coding agent can inspect a project, read files, run commands, edit code, and sometimes continue across multiple steps while you supervise from a suspicious distance.
That is useful. It is also how a small request quietly turns into a large context upload. The prompt may say, “fix this auth test.” The agent may decide it needs the auth module, routing, package config, test helpers, previous errors, project instructions, and a few files that looked emotionally relevant at the time. Now the job is no longer just “write code.” It is “select and transmit context.”
That selection step deserves a preflight budget. Before the agent starts, it should be clear how much context it is allowed to gather, which folders are in bounds, which files are off limits, and what evidence it must leave behind. Without that, you are not really delegating a coding task. You are giving a very fast intern a badge, a corporate card, and the keys to the document closet.
A Context Budget Is A Real Engineering Control
A context budget is not a motivational poster about being concise. It is a concrete limit on what an AI coding agent may read or send before it asks for approval. Good budgets usually include four things: file scope, token scope, command scope, and time scope.
- File scope: the exact directories or files the agent may inspect first.
- Token scope: the approximate input budget for the investigation phase.
- Command scope: the read-only commands it may run without asking, such as tests, grep, type checks, or dependency inspection.
- Time scope: the point where the agent must stop exploring and summarize what it found.
Claude Code, for example, documents token usage as an OpenTelemetry metric and describes audit events for tool calls, MCP activity, permission decisions, Bash commands, and file edits when monitoring is configured. That matters because token use and tool use are not vibes; they can be measured and reviewed in real systems. Anthropic’s Claude Code monitoring documentation is a good example of the kind of operational surface teams should expect from coding agents.
The practical move is to make the preflight instruction boring and repeatable: “First inspect only these files. Spend no more than about 8,000 input tokens before reporting. Do not read secrets, generated files, build artifacts, lockfiles, logs, screenshots, or environment files unless asked. Run only read-only diagnostics. Then produce a context receipt.” This will not make the agent perfect. It will make the session reviewable, which is the actual bar.
The Receipt Should Say What The Agent Read
The output you want before edits is not a poem about the codebase. It is a receipt. A useful context receipt should name the files read, commands run, assumptions made, and missing information. It should also say what the agent chose not to read.
That last part is important. “I did not inspect billing, production secrets, analytics exports, or unrelated admin pages” is more useful than a heroic summary of everything the agent noticed. A receipt turns context selection into something you can challenge. If the agent read the wrong files, you can stop early. If it skipped the file that obviously matters, you can redirect it before it starts manufacturing confidence out of lint dust.
Here is a simple receipt format worth reusing:
- Task understood: one sentence restating the requested change.
- Files inspected: exact paths, not “the auth layer.”
- Commands run: exact commands and whether they changed state.
- Context not inspected: sensitive, generated, unrelated, or blocked areas.
- Likely edit targets: the smallest set of files the agent expects to modify.
- Approval request: what it wants to read or change next.
This is also where Notavello’s broader AI coding advice connects. If the agent can edit files, run tools, and pass context between systems, it belongs inside a controlled workflow, not a casual chat tab. For the larger supply-chain angle, see AI coding CLIs as supply chain tools.
Do Not Let Project Memory Become A Junk Drawer
Many coding agents support project instructions, memory files, rules files, skills, or similar mechanisms. These are helpful when they contain sharp constraints: “use pnpm,” “never edit generated API clients,” “tests live under this directory,” “production migrations require a separate review.” They become harmful when they turn into a junk drawer of stale preferences, abandoned architecture notes, and seven paragraphs about how the previous team felt about semicolons.
A bloated project memory file creates two problems. First, it burns context before the task has even started. Second, it can outrank the actual job. The agent may follow an old instruction because it was loaded automatically, not because it still reflects the project. That is a delightful way to preserve yesterday’s bug in tomorrow’s pull request.
Keep project instructions short enough that a human reviewer would actually read them. Put hard rules at the top. Mark optional preferences as optional. Delete old migration notes when the migration is over. If a rule only applies to one folder, keep it near that folder instead of forcing every session to inhale it.
The preflight budget should include these memory files by name. If the agent automatically loads a project instruction file, the receipt should say so. Hidden context is still context. “It was in memory” is not a satisfying incident report.
Separate Exploration From Execution
The safest agent workflow has two phases: exploration and execution. In exploration, the agent reads limited context, runs read-only checks, and proposes a plan. In execution, it edits files, runs tests, and reports diffs. Mixing those phases is where sessions get messy.
Plan-first mode is not just for nervous teams. It is a speed feature. A short investigation often reveals that the requested change is underspecified, the failing test is stale, or the bug lives in a different layer than expected. Better to find that out before the agent edits six files and leaves behind a confident explanation of a wrong theory.
A good plan should include the smallest credible change. If the agent proposes a broad refactor for a narrow bug, make it justify the blast radius. If it wants to read more files, ask which files and why. If it wants to run commands that touch external services, package registries, containers, or databases, require a separate approval. Nobody needs a surprise integration test against production because the robot was feeling thorough.
This is where local policy beats vendor promises. Different agents expose different permission modes, logs, and privacy controls. Some tools are open source. Some are hosted. Some connect to several model providers. OpenCode, for instance, describes itself as an open source coding agent for terminal, IDE, or desktop use, while hosted tools may have their own telemetry, account, and provider behavior. The control you need is not a brand preference. It is a repeatable boundary around context and actions.
A Practical Preflight Template
Use a saved prompt. Do not improvise this every time. The point is to make the default session safer without turning every bug fix into a governance festival.
Preflight prompt: “Before editing anything, inspect only the files I list plus directly imported local files if necessary. Do not read .env files, secrets, generated files, build artifacts, logs, vendor folders, screenshots, exports, or unrelated directories. Keep the investigation under roughly 8,000 input tokens unless you ask first. Run only read-only commands. Then provide a context receipt with files read, commands run, assumptions, files not inspected, and the smallest proposed edit plan. Wait for approval before making changes.”
For a tiny bug, lower the budget. For a large migration, raise it and split the work into phases. For sensitive repos, require allowlisted paths only. For enterprise teams, pipe agent events into normal logging, not a separate mystery dashboard that only one platform engineer remembers exists.
The budget should also appear in pull request notes when AI materially helped. Not because anyone needs theater. Because reviewers need to know whether the agent inspected the right area, ignored the risky area, and tested the actual change. “AI assisted” is too vague. “Agent read these five files, changed these two, ran these commands, and did not inspect secrets or production config” is usable.
The Best Agent Is The One You Can Interrupt
Fast coding agents make bad defaults expensive. If the agent can read too much, it can leak too much context. If it can run too much, it can mutate the workspace before the human understands the plan. If it can spend too many tokens, it can turn a cheap question into a surprisingly large bill with a beautifully formatted explanation attached.
The fix is not to stop using AI coding agents. The fix is to stop treating the first prompt as a magic spell. Treat it like a job ticket. Define the scope. Cap the context. Require a receipt. Separate planning from edits. Review what happened.
That sounds less glamorous than “agentic software engineering.” Good. Glamour is how teams end up with a bot reading half the monorepo to rename a button. A preflight context budget is dull, enforceable, and easy to teach. In developer tooling, that is usually what adulthood looks like.