Split a Feature Before Your Agent Burns Tokens
Turn “add CSV export” into a bounded change
The expensive part of agent-assisted development is often not the first implementation. It is the fourth attempt, after the agent has reread half the repository and changed three unrelated modules. A big prompt leaves too many decisions open. Every correction buys another round of exploration.
Take a feature like CSV export for an orders dashboard. “Build CSV export” bundles authorization, filtering, serialization, delivery, interface work, and tests. Before opening an agent session, spend ten minutes turning that bundle into independently verifiable changes. The goal is not more tickets. It is fewer expensive guesses.
Map the export path before assigning implementation
Start in your terminal. Use rg to locate the orders query, authorization checks, dashboard actions, and existing download handlers. Ask an agent for a narrow repository map if needed, but request file paths and relevant symbols, not an implementation. Save the useful findings in a short task document.
Then define the shared contract: exported columns, column order, timezone, escaping rules, maximum row count, and authorization behavior. Decide whether exports use the current filters. These decisions are cheap to write once and costly to rediscover across several sessions.
- Extract an authorized query helper without changing existing dashboard behavior.
- Implement a CSV serializer against fixed fixtures and explicit escaping rules.
- Add an export endpoint using the approved query and serializer contracts.
- Connect the dashboard button and verify loading and failure states.
Give each agent a budget-shaped task packet
Each task needs an outcome, relevant files, constraints, acceptance checks, and a stopping condition. Small does not mean “twenty lines.” A useful task fits within one coherent decision boundary and can be reviewed without reconstructing the whole feature.
For the serializer, my packet would read: “Implement the agreed CSV format in the serialization module. Read the export contract and existing test conventions. Cover commas, quotes, newlines, empty values, and Unicode. Do not touch routes, dependencies, or dashboard components. Run the serializer tests. Report changed files, test results, and unresolved questions, then stop.”
Add an explicit escape hatch: if the contract conflicts with existing behavior, report the conflict before broadening scope. That sentence can prevent a cheap utility task from becoming an unsolicited architecture migration.
Route uncertainty, not file count, to the model
Use a more capable model where ambiguity is expensive: identifying authorization boundaries or reviewing the integration contract. Try Claude Sonnet 5.5 for that planning pass, then evaluate Claude Haiku 4.5 on a well-specified serializer task. Those are candidates, not guarantees; compare actual usage and review effort on your repository.
Fluxo lets me keep one key and one base URL, https://api.fluxorelay.com, across Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok, and more. It works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK, so changing the model need not mean rebuilding the workflow.
Keep context small without destroying useful continuity
Start each task with its packet, shared contract, and relevant paths rather than the entire previous conversation. Preserve concrete discoveries in a handoff note: changed symbols, commands run, known failures, and decisions made. Do not paste thousands of lines of exploratory output into the next session.
Keep stable instructions consistent when your tooling supports caching, but inspect usage instead of assuming cached context is free. Fluxo bills per real token, including cache reads and writes, with no monthly fee. Repeated context still belongs in the cost calculation.
Merge on evidence and measure accepted work
Run focused tests after each task and integration checks after connecting the pieces. Parallelize genuinely independent work, not two agents editing the same endpoint. Use separate branches or worktrees, and review every diff before merging.
Track total token cost, retries, and review time per accepted task. A cheaper attempt that needs three repairs may not be cheaper overall. Tighten the next packet around whatever caused the rework.
If you want to try this workflow, create a Fluxo account and measure one bounded feature first. Fluxo also offers a referral share when people you invite pay; keep that separate from your engineering cost measurements. The useful saving is less context churn and fewer rejected changes.