Reach a Shared Design Concept Before Requesting a Plan

The first objective in a new feature is not to produce a plan. It is to establish a shared design concept between the human participants and the agent. A brief request such as "add gamification" contains too many hidden decisions to be implemented safely. The agent should expose those decisions through a structured interview before it creates a specification or writes code.

A focused interviewing skill can instruct the agent to question the user relentlessly about every branch of the design. The important behaviors are:

• Ask one question at a time.
• Walk through dependencies in a deliberate order.
• Continue until the participants have a shared understanding.
• Provide a recommended answer for each question rather than placing the entire reasoning

burden on the human.

• Explore the repository when codebase knowledge is required to ask better questions.

For a gamification feature, a useful interview might surface questions such as:

• Which actions earn points?
• Should passive or gameable activity be excluded?
• Should existing completion records receive points retroactively?
• How should level thresholds progress?
• Do streaks award points or remain a separate mechanism?
• Where should the new information appear in the interface?
• Which behaviors are explicitly outside the first release?

These questions are valuable because they uncover decisions that may not have been considered by the person who requested the feature. The agent's recommendations also accelerate the process. The human can accept a recommendation, reject it, or ask for more repository context before deciding.

The interview can be long. A substantial feature may require dozens of questions. That is not wasted effort when the questions are resolving real ambiguity. The conversation itself becomes a record of the design concept: the set of assumptions, choices, and exclusions that all participants now understand.

This is a human-in-the-loop activity. It cannot be reduced to an autonomous loop because the purpose is to obtain human judgment. When the current participant cannot answer a domain question, bring the relevant domain expert into the session. When an implementation question is uncertain, include another developer. The agent can function as a third participant in pair programming or as a persistent questioner in a larger group.

Existing human discussions can also become input. Notes or a meeting record can be supplied to the interviewing agent, which then challenges unresolved assumptions and identifies gaps that the meeting did not settle.

An eager planning agent often produces a plausible plan before it has enough information. That speed creates a false sense of progress. The plan may be internally coherent while solving the wrong problem, missing a critical edge case, or embedding a decision nobody consciously made.

Shared understanding reduces this form of silent misalignment. It also changes the role of later documents. A product requirements document no longer has to create the design from nothing. It only has to summarize a design that has already been discussed.

Begin each meaningful feature with a small interviewing skill. A suitable instruction set is conceptually simple:

1. Inspect the request and the relevant parts of the repository.
2. Identify the first unresolved decision.
3. Ask one precise question.
4. Give a recommended answer and the reasoning behind it.
5. Let the human accept, reject, or modify the recommendation.
6. Continue down the design tree until the remaining uncertainty is small enough to define

the destination.

During the interview, do not merely answer "yes" to move quickly. Use the questions to check the effect on existing data, user behavior, system boundaries, testing, and scope. When the agent asks a question that requires knowledge of the codebase, ask it to explain the relevant existing implementation before deciding.

In a team, treat this phase as collaborative design work. Share the conversation, involve the people who own the domain, and allow prototypes or research to feed back into another round of questions.

A relentless interview can become exhausting or repetitive. The skill should be tuned when it routinely asks low-value questions. Useful controls include explicit stopping points, a narrower scope, or an instruction to group recommendations when time is constrained.

The interview does not eliminate the need for later review. It reduces uncertainty, but the code can still expose new information. The design process may need to loop back when research, prototyping, implementation, or QA reveals a flawed assumption.

The agent's recommended answer is not authoritative. It is a decision aid. Accepting recommendations solely to move faster would recreate the same misalignment the interview is intended to prevent.

Do not ask an agent to plan an ambiguous request. First use it to expose decisions, recommend options, and reach a shared design concept with the humans who own the product and implementation choices.