Before Asking an AI Agent to Implement, Write Task Boundaries

When you ask an AI coding agent to implement something, a longer prompt is not always safer.

What matters more is whether the agent knows the boundary of the task: what should change, what should not change, and what proves the work is done. I call this a task boundary note.

It is not a full specification. A few lines are enough. The point is to remove the parts where the agent would otherwise guess.

Why task boundaries matter

AI agents fill in missing context. That is useful, but it can also create unwanted changes.

If you write only this:

Fix the article list.

the agent has to infer the actual problem:

• Is the visual layout wrong?
• Is the sort order wrong?
• Is the content loader returning the wrong articles?
• Is the route wrong?
• Should tests or build scripts change too?

Several interpretations may be valid from the codebase alone. A task boundary note narrows the search space before implementation starts.

Write goal, scope, and done

For most small implementation tasks, start with three lines:

Goal: Show only Japanese articles on the /ja page, sorted newest first.
Scope: Read src/app/ja/page.tsx and src/lib/content.ts.
Done: npm run typecheck and npm run build pass, and /ja shows the expected articles.

This tells the agent what success means. It also discourages unrelated improvements such as redesigning cards, changing navigation, or editing article content.

If there are sensitive areas, add them explicitly:

Do not change: content/*.md, mcp-server/, package dependencies.

This is especially important around monetized pages, authentication, payments, licensing, SEO, and deployment settings. Those areas usually have business consequences beyond the immediate bug.

Verification should be concrete

Avoid vague completion criteria:

Done: It looks good.

Use checks the agent can run:

Done:
- npm run typecheck passes
- npm run build passes
- /ja/articles/<slug>/ is generated and does not 404

Concrete verification changes the agent's behavior. It will know which commands matter, and failures can be reported as implementation-complete but verification-failed instead of being hidden.

Do not over-lock the file list

There is a trade-off. If you lock the write scope too tightly, the agent may work around the symptom in the wrong file.

For example, if the real bug is in src/lib/content.ts but the prompt says "only edit src/app/page.tsx", the agent may add display-side filtering that leaves the root cause in place.

A better pattern is to separate read scope from write scope:

Read: src/app/, src/components/, src/lib/content.ts
Write: src/app/ja/page.tsx only, unless root cause requires a content loader fix

This gives the agent enough context to diagnose the issue while still keeping the implementation small.

Split ownership when using multiple agents

If more than one agent is working in the same repository, boundaries become more important.

Do not let two agents edit the same file or run the same build against the same output directory at the same time. Shared build artifacts such as .next/, dist/, and target/ can be corrupted by concurrent writes.

For the specific Next.js failure mode where .next/routes-manifest.json disappears during parallel builds, see Next.js routes-manifest.json Missing? Check for Parallel next build First.

Use ownership notes:

Agent A: investigate only, no file edits.
Agent B: edit src/components/ArticleCard.tsx only.
Main thread: run the final build once after both finish.

This makes review easier and avoids build failures that look like framework bugs but are actually artifact races.

A reusable template

For small tasks, this template is enough:

Goal:
Scope:
Read:
Write:
Do not change:
Done:
Risk:

You do not need to fill every field. Empty fields are a signal that the request may still be ambiguous.

Summary

AI implementation requests need boundaries more than they need long prose.

Write the goal, scope, do-not-change areas, and verification commands before the agent starts editing. The agent will still have room to solve the problem, but it will be less likely to widen the task, touch unrelated files, or skip the final checks.