A Task Spec Before the Next Agent Terminal Run
The expensive part is the second attempt
I write task specs for coding agents for the same reason I write reproduction steps for bugs: ambiguity creates work. A request like “fix the login flow” invites repository exploration, speculative edits, and a long explanation of changes I never wanted.
The bill is not just the final patch. It includes context ingestion, tool output, failed approaches, and follow-up turns. Spending five minutes defining the task often costs less than letting an agent discover the requirements through retries.
Capture the failing behavior before opening the agent
Start in the terminal. Reproduce the problem, save the smallest useful error, and identify the likely boundary. You do not need to diagnose the root cause. You do need to distinguish an observed failure from a proposed solution.
For example, “the login button is broken” is weak input. “Submitting an expired session redirects to login repeatedly; a fresh session succeeds” gives the agent something testable without prescribing a rewrite.
- Record the exact command or interaction that reproduces the failure.
- Include expected behavior alongside the actual result you observed.
- Paste only the relevant error excerpt, with secrets removed.
- Name likely files as starting points, not guaranteed diagnoses.
Paste a bounded spec instead of a wish
Here is the shape I use for a small repository change. The paths and commands below are illustrative; replace them with ones that actually exist in your project.
Task: Stop the expired-session redirect loop. Reproduction: Sign in, expire the session cookie, then open /settings. Expected: Redirect to /login once and show the existing session-expired message. Starting points: src/auth/session.ts and tests/auth/session.test.ts. Scope: Session handling only. Non-goals: No login redesign, dependency upgrades, or unrelated cleanup.
Acceptance: Add a regression test that fails before the fix and passes afterward. Preserve successful-session behavior. Run npm test -- tests/auth/session.test.ts. Report changed files, test results, and any remaining uncertainty. Stop and ask before changing public interfaces or adding dependencies.
This is not a miniature design document. It is a boundary around the work. The agent can still choose an implementation, but it cannot quietly redefine success as “I refactored authentication.”
Make uncertainty cheaper than implementation
When the task touches unfamiliar code, ask for a short inspection pass first: identify the relevant call path, propose the smallest patch, and list unanswered questions. Explicitly prohibit edits during that pass.
Use that checkpoint when uncertainty is expensive, not for every typo. An extra planning turn also consumes tokens. For a contained fix with a known failing test, implementation can start immediately. For an ambiguous migration, approving the approach first can prevent an expensive branch full of unwanted changes.
Match model spend to a stable task
Fluxo gives my editor and terminal tooling one key and one base URL, https://api.fluxorelay.com, for Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok, and more. It works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK, so the task spec can stay consistent across tools.
I might try Claude Haiku 4.5 for a tightly bounded test update and evaluate Claude Sonnet 5.5 for a change requiring broader reasoning. Those are candidates, not guarantees: compare accepted patches, retries, and actual spend rather than assuming a model label predicts value.
Fluxo bills per real token, including cache reads and writes, with no monthly fee. That makes context hygiene worth measuring. Keep stable repository instructions reusable, avoid pasting entire logs, and do not assume cached context is free.
Close the task with evidence, not reassurance
Require a compact handoff: changed files, commands executed, results, and unresolved risks. If tests cannot run, the agent should say so rather than treating plausible code as verified code. Review the diff before accepting the work.
If you want to measure this workflow, create a Fluxo account and track spend across a few comparable tasks. Keep referral earnings separate from that experiment: users earn a referral share when people they invite pay, but that is not evidence of cheaper implementation. The useful metric is cost per reviewed, accepted change.