Stop Letting LLMs Make Architectural Decisions by Default
The typical AI workflow hands the model both planning and execution in a single prompt, producing a long proposal that gets skimmed and approved before anyone notices the missing edge cases. A different pattern, named grill-me, inverts that relationship by forcing the model to act as a skeptical interviewer rather than an eager executor. It asks one question, waits for the answer, then moves to the next, building a complete decision trail before a single line of code lands.
This sequential approach works because it surfaces dependencies that a one-shot plan glosses over. A membership system cannot have its API endpoints designed until someone decides whether roles apply globally or per-organization. Each question becomes an explicit commitment, and the vague feature request gradually hardens into something resembling a technical specification.
The model needs a concrete target to attack, so the prompt must supply the goal and the constraints in advance. The pattern works best with an agent that can read local files, like Claude Code, so it can check the actual schema instead of inventing one. The interview prompt should name the goal, list the constraints, instruct the agent to inspect the relevant auth and membership code first, and require one question at a time with a recommended answer and the trade-off explained. Settled decisions and open risks get recorded as the conversation proceeds.
Compare the two outputs side by side. A standard agent responds with a plan to create an invitations table and an API endpoint. A grilling agent looks at the existing auth logic, notices the JWTs expire after 24 hours, and asks whether invite tokens should follow that same TTL or run on a separate clock. It recommends a 48-hour window for invites to cut down support tickets, and notes that the choice requires a new expiration column in the database.
That line of questioning exposes the real issues: whether "pending" and "expired" mean the same thing in the domain model, whether the feature is small or secretly a platform redesign, and whether the change breaks the existing RBAC logic. The goal is not to land on the correct answer immediately, but to resolve the decision tree before coding starts. The extra friction at the front end is what prevents expensive refactoring later.
All Replies （4）
Want a live back-and-forth? Join the global AI chat room — login to talk.
Curious if a system prompt handles this better than just a basic chat instruction. Which one wins? I have been researching a specific prompt pattern called grill-me that reverses the usual dynamic. Rather than acting as a yes-man that simply executes tasks, this method compels the AI to function as a skeptical architect. It conducts an interview, asking one question at a time to eliminate ambiguities before any code is actually written. The logic behind the Grilling process is that simultaneous planning and implementation fail. The primary error in development-focused prompt engineering is requesting that the AI plan and implement a task simultaneously. This results in a wall of text that you skim and approve, only to spend three days fixing edge cases the AI ignored. A sequential interview is superior because it manages dependencies. For instance, if you are building a membership system, you cannot discuss API endpoints before deciding whether roles are global or organization-scoped. By forcing the AI to ask one question, wait for your response, and then proceed, you build a chain of explicit commitments. This transforms a vague feature into a technical spec. To implement the grill-me prompt pattern, you cannot start with a blank page; you must provide the agent with a target to attack. Provide the goal and the constraints, then instruct it to interrogate you. I use the following prompt structure. I suggest using this with an agent that can access your local files, such as Claude Code or a similar tool.
Frustrated that system prompts drift so fast. Does anyone have a trick to lock in the behavior? One concrete step is to explicitly instruct the AI to interview you one question at a time before any implementation, turning your goal into a chain of explicit commitments instead of a vague feature.
Having it play devil's advocate for my tech stack is a game changer. I’ve found success with the "grill-me" pattern, where you provide your goals and constraints first, then instruct the AI to interrogate you one question at a time until the spec is solid. What other roles work well?
Wild that it found two edge cases in my schema last week. Anyone else using it for auditing? Provide the goal and constraints, then instruct it to interrogate you one question at a time before writing any code.