FRI, 17 JUL 2026
Live · Daily AI brief from inside the industry
14:14:36 UTC

CHAPTER 2 OF 7 · 8 min · 3 COPYABLE ASSETS

How to plan software features with an AI coding agent (before any code)

The Phase 1 planning method: brain-dump your ideas, make the agent ask clarifying questions, stay high-level, and build your AI layer of rules and commands.

TL;DW

Start feature planning as an unstructured conversation. Brain-dump everything you want to build (speech-to-text makes this fast), then flip the script and have the agent ask you clarifying questions one at a time. Twenty to thirty minutes of this kills the wrong assumptions that cause most bad agent output. Stay at requirements level; implementation detail comes later, per ticket. Then encode what works into a permanent AI layer of global rules, commands, and skills. Anything you have prompted three times becomes reusable.

Lesson · 7 parts

Organizations Cole trains bring their entire PM team into these sessions, because product managers are the first touch point with the coding agent. They plan the next sprint (these bugs, these features) with the agent's help. The process is identical for brownfield work, meaning a new sprint on an existing app, and greenfield work, meaning the scope of an MVP from nothing.

Open your coding agent and just talk. No template, no framework. The barrier to entry is deliberately near zero. Cole typically uses a speech-to-text tool and rambles about everything he wants to build. One rule applies: be as specific as you can about the application, the new features, and the bugs you want fixed.

The most important move in all of planning is to reduce the agent's assumptions. When a coding agent does a bad job, the code usually is not broken. It built the wrong thing, and that misalignment is on you. So end your brain dump by instructing the agent to ask you questions, and let that run 20 to 30 minutes when the stakes are real.

What good questions look like in practice: scope boundaries (does phase two include auth changes or not), priority order when two features conflict, data-shape decisions (one poll per session or many), and behavior at the edges (what an anonymous voter can see). Answer the ones that change the build. Delegate the rest with 'go with your recommendation'.

A useful habit from teams Cole trains: keep a running list of the assumptions the agent surfaces. That list becomes review ammunition later, because every wrong assumption you catch here is a ticket you do not have to rewrite.

The brain-dump closer. Paste it after your idea dump
Before you write anything, ask me clarifying questions ONE AT A TIME using the AskUserQuestion tool. Keep going until you have no meaningful assumptions left about what I want.

Resist the pull into the weeds. At this stage you are not deciding how to test things or which files to change. You are translating intent into requirements. A separate, per-ticket planning process handles implementation detail later. Keeping the layers separate is what keeps both of them clean.

Which layer does this detail belong to?

  • Feature behavior, priorities, constraints: layer one (now)
  • Files to change, patterns, test strategy: layer two (per ticket)
  • Business rules and edge-case behavior: layer one
  • Library and architecture trade-offs: layer two (unless a hard constraint)

Once the scope is agreed, invest in your AI layer if the codebase lacks one. Global rules hold the conventions the agent must always follow: coding style, testing strategy, logging. Commands and skills package your repeatable workflows so nobody re-types a process by hand. Cole's threshold is simple. Prompted it more than three times? It becomes a command.

What goes in the AI layer

  • Global rules: coding style, testing strategy, logging conventions the agent always follows
  • Commands: procedures you invoke with /name plus arguments
  • Skills: bigger reusable workflows the agent loads on demand
  • Rule of three: any prompt used 3+ times gets packaged and shared with the team

The first packaged workflow guides the agent from an unstructured conversation to a structured PRD, one document with all the core sections of a product requirements document. Exploration becomes structure. The messy chat you just had becomes a single reviewable source of truth for the sprint or the new application.

The same agent then splits the PRD into individual pieces of work and creates them as JIRA tickets through the MCP server. It parses the document, derives the phases, and does the administrative backstage work itself. The PM hands those tickets to developers, and each ticket becomes the input to the PIV loop you will run next.

Key terms

PRD
Product requirements document: states what is being built, for whom, and what is in scope, before implementation starts.
Global rules
Conventions the agent must always follow: coding style, testing strategy, logging approach.
Command
A packaged procedure invoked with /name plus arguments; a proven prompt stored as a file.
Rule of three
Any prompt you have typed three times becomes a command or skill.

Key takeaways

  1. Most bad agent output is not broken code. It is misalignment with what you actually wanted, and removing assumptions up front is your responsibility.
  2. Have the agent interview you. 'Ask me clarifying questions one at a time' is the single highest-leverage planning prompt.
  3. Layer-one planning stays at requirements level. No file paths, no test plans yet.
  4. The rule of three: any prompt you have typed three times becomes a command or skill.

Watch out

  • Resist code-level detail during this phase: which files to change, how to test. That belongs to the per-ticket planning layer, and mixing the two layers pollutes both.

Check your understanding

When a coding agent builds the wrong thing, where does Cole put the responsibility?

On you. The failure is usually misalignment, not broken code. Your job is to remove the agent's assumptions up front, chiefly by having it ask you clarifying questions one at a time.

What is the rule of three?

Any prompt you find yourself typing more than three times should become a command or skill: a reusable, shareable piece of your AI layer.