Constraints, Existing Systems, and Definition of Done: What an AI Coding Agent Needs to Know

The agent can write code. It cannot safely guess your constraints.

If it does not know that you already use Supabase, that guest users must be allowed, or that payment processing is out of scope, it may create work you have to undo later.

Put the important boundaries in your PRD before the build starts.

Name the systems already in play

Keep this practical:

• Existing repository or starter app
• Database and authentication provider
• Design system or component library
• Required third-party services
• Deployment environment
• APIs the product must use

For example: “Use the existing React app and Supabase project. Keep the current email sign-in flow. Do not add a new database or billing provider in V1.”

That is enough context to avoid a detour.

State product constraints, too

Technical constraints are only half the story. Add product rules such as:

• Web app only for V1.
• One workspace owner, not teams.
• English only.
• Guests can view a shared link but cannot edit.
• Do not collect card details or sensitive health data.

Constraints are not limitations to hide. They are how you keep a first version finishable.

Write a definition of done

“Done” means a user can complete the promised workflow, not that the agent has stopped generating files.

Use checkable statements:

• A signed-in user can create, edit, and delete their own project.
• A shared link shows only the project it belongs to.
• Another user cannot access private project data.
• The key workflow works on a phone-sized screen.
• Empty and error states explain what the user should do next.

OpenAI documents how Codex can read project-level AGENTS.md guidance before work. Put coding conventions and required tests there; keep the product acceptance criteria in the PRD.

Handle high-risk areas honestly

For payments, accounting, healthcare, security, tax, or compliance work, describe the boundary with extra care. A demo can be useful without pretending it is ready to handle regulated or sensitive work.

Say what the first version does and does not do. That makes review easier and prevents a UI from being mistaken for a trustworthy production workflow.