Why do we keep letting LLMs make architectural decisions by

I've been looking into a specific prompt pattern called "grill-me" that flips the script. Instead of the AI being a "yes-man" that just executes, this approach forces the AI to act as a skeptical architect. It interviews you, one question at a time, to kill ambiguities before a single line of code is written.

The logic behind the "Grilling" process

The biggest mistake in prompt engineering for development is asking the AI to "plan and implement" in one go. You get a wall of text, you skim it, you say "looks good," and then you spend three days fixing the edge cases the AI ignored.

A sequential interview is better because it handles dependencies. If you're building a membership system, you can't talk about API endpoints until you've decided if roles are global or organization-scoped. By forcing the AI to ask one question, wait for a response, and then move to the next, you create a chain of explicit commitments. It turns a "vague feature" into a technical spec.

Practical tutorial for the "Grill-me" prompt

To make this work, you can't start with a blank page. You need to give the agent a target to attack. You provide the goal and the constraints, then tell it to interrogate you.

Here is the prompt structure I use for this. I recommend using this with an agent that has access to your local files (like Claude Code or a similar LLM agent) so it can actually check your existing schema instead of guessing.

Grill this proposal before implementation.
Goal: organization owners can invite members by email.
Constraints: existing RBAC model, no public workspace enumeration, 
and invitations must be revocable.
Inspect the relevant auth and membership code first.
Ask one question at a time. Recommend an answer, explain the trade-off, 
and record settled decisions and open risks.

Why this beats a standard spec

If you're doing a deep dive into your AI workflow, notice the difference in output. A standard agent says, "I will create an invitations table and an API endpoint." A "grilling" agent says: "I see your current auth logic uses JWTs with a 24-hour expiry. If we allow invitations, should the invite token expire independently of the session, or follow the global auth TTL? I recommend a separate 48-hour window for invites to reduce support tickets, but that requires a new expiration column in the DB."

That is where the actual value is. It identifies:

• Domain Model Gaps: Does "pending" mean the same thing as "expired"?
• Scope Creep: Is this a small feature or a platform redesign?
• Technical Debt: Does this change break existing RBAC logic?

The goal isn't to get a "correct" answer immediately, but to ensure that when the coding starts, the decision tree is already resolved. It's a high-friction process upfront to avoid high-cost refactoring later.