What Should the Coding Agent Build?

“Build me a CRM for freelancers” is an idea. It is not a build brief.

An AI coding agent can turn a clear product decision into code. It cannot know which version of “CRM” you mean unless you tell it.

Do you mean a client list? A sales pipeline? Contracts? Invoices? Email sequences? A full agency operating system?

That is why the first product decision is not the tech stack. It is the boundary.

Describe the outcome in one sentence

Start with this format:

Build a [product] for [specific user] so they can [complete a useful job] without [current pain].

Example:

Build a lightweight client tracker for freelance designers so they can see which leads need a reply without digging through email.

That sentence already rules out a lot. You are not building accounting software. You are not building a marketing platform. You are building a way for one person to keep leads moving.

Choose the first useful promise

Your product may eventually do ten things. V1 needs one promise a user can understand.

For the client tracker, the promise could be:

Never forget which potential client needs a follow-up.

Then the build becomes clearer:

• add a lead;
• save contact details;
• set a follow-up date;
• mark the lead won, lost, or still active; and
• see overdue follow-ups.

That is a product. “Add a dashboard” is not.

State the decisions the agent must not make

Put product rules in plain English:

• This is for one freelancer, not teams.
• Users sign in with email.
• A lead has one owner.
• Follow-up reminders appear inside the app; email reminders can wait.
• The product stores contact details, but does not send campaigns.

These rules are not technical chores. They stop an agent from making product calls on your behalf.

Separate requirements from ideas

Your PRD can have both. Just label them.

Required for V1: add leads, schedule follow-ups, view overdue leads.

Possible later ideas: email reminders, contact imports, templates, team access, AI-written follow-up messages.

This keeps a useful idea from becoming an accidental requirement.

Check the brief with a plain-English test

Show the one-sentence outcome to someone who does not know the product. Can they repeat who it helps and what it helps them do? If they cannot, the brief is still too broad.

Then ask what a user would do in the first five minutes. If you cannot describe that path, you probably have a collection of features rather than a product. Tighten the promise until the first useful action is obvious.

Ask for a plan before code

Once the brief is clear, ask the agent to inspect the existing project and propose an implementation plan. Review that plan for missing user flows, risky assumptions, and features that slipped beyond V1.

OpenAI documents how Codex reads project instruction files such as AGENTS.md before it starts work. Put repository conventions and test requirements there. Keep the product outcome and scope in your PRD.

Your goal is simple: the agent should be able to explain what it is building, for whom, and what it is intentionally leaving out.