# Why do we keep letting LLMs make architectural decisions by

> Source: <https://promptcube3.com/en/threads/6698/>
> Published: 2026-08-17 16:45:24+00:00

# Why do we keep letting LLMs make architectural decisions by

## 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](/en/tags/claude%20code/) 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.

[Next Building a functional LLM agent takes a weekend →](/en/threads/6589/)