Use Adversarial Interviewing Before Implementation

Many implementation failures begin before any code is written. The idea is underspecified, consequential decisions remain hidden, and the agent fills the gaps with assumptions. An adversarial interview procedure addresses this by making the agent question the user until both sides share a sufficiently concrete understanding of the work.

The goal is not to generate a long plan immediately. The goal is to expose uncertainty, contradictions, missing constraints, and decisions that will shape the product or architecture.

The user begins with the vision and intended outcome. The agent then acts as an interviewer rather than an implementer. It asks questions, challenges vague statements, and introduces issues the user may not have considered.

A useful prompt pattern is to ask the agent to identify the most consequential decisions across product design, software design, and architecture, then interview the user about them. The process continues until the important ambiguities have been resolved and the agent can restate the intended system accurately.

This procedure can precede several downstream artifacts:

1. A shared description of the mission and constraints.
2. A product requirements document.
3. A set of individual issues or tasks.
4. An implementation sequence.

The interview is especially useful for planning, complicated implementations, and unscoped work. These are situations where the human should remain in the loop because each answer can change the next question and alter the eventual design.

A one-shot instruction often hides the decisions that matter most. "Build this app" may leave the agent to decide the target user, feature boundaries, architecture, and definition of success. Even a capable agent cannot recover product context that was never provided.

Adversarial questioning increases the quality of delegation. It converts implicit expectations into explicit constraints before implementation begins. This reduces the likelihood that the agent will produce a polished result that solves the wrong problem.

It also keeps the human's thinking active. The agent is not asked to replace judgment; it is used to pressure-test judgment. The procedure helps the user discover what must be decided and articulate why.

Use the following pre-implementation interview workflow:

1. Describe the vision in plain language. Include who the system is for, what problem it should

solve, and what success should look like.

1. Ask for consequential decisions. Have the agent list the product, software-design, and

architecture decisions most likely to shape the project.

1. Start the interview. Instruct the agent to continue asking focused questions and to challenge

answers that remain vague.

1. Resolve open decisions. Continue the interview until the consequential questions have clear

answers.

1. Ask for a shared-understanding summary. Have the agent restate the mission and the decisions that

have been resolved so the user can confirm them.

1. Convert the result into a requirements document based on the confirmed shared understanding.

1. Decompose the document into tasks. Each task should be small enough to delegate without reopening

major strategic questions.

For example, a person may begin with the intention to build a scheduling application. The interview should clarify who will use it, what information it stores, what the first useful workflow is, what success means, and which capabilities are beyond the first version. Only then should implementation tasks be created.

The interview requires active human participation. It is not a way to delegate the product vision. The user must answer questions, choose among alternatives, and take responsibility for the resulting decisions.

The procedure should also be proportional to uncertainty. A complicated or ambiguous project benefits from a deep interview. A small, already-scoped mechanical change may need only a brief confirmation of boundaries and tests.

Before asking an agent to build, use it to interrogate the idea. Resolve the decisions that shape the project, record the shared understanding, and only then decompose the work.