Grill Me vs. Grill with Docs: entrevistas con IA

Antes de programar, dejate interrogar

Matt Pocock creó /grill-me, una skill para Claude Code con una premisa incómoda pero útil: en vez de que la IA arranque a escribir código, te hace preguntas hasta que tu idea esté realmente definida. Funciona como un ingeniero de requisitos que te presiona un poco antes de que toques el teclado.

Cómo funciona la dinámica

El flujo es simple y conversacional:

• Vos decís: “Quiero agregar X al sistema”.
• La IA analiza la idea.
• Te hace una pregunta por vez.
• Te propone una recomendación concreta.
• Vos confirmás o corregís.
• Tu respuesta abre nuevas preguntas.
• Sigue hasta cerrar las principales ramas de decisión.

Ejemplo con un sistema de reservas. En lugar de crear modelos Django de una, la IA pregunta: ¿una reserva pertenece a un usuario o puede hacerse como invitado? Y recomienda: permitir invitados y asociarla opcionalmente a un usuario. Después: ¿puede modificarse una reserva ya confirmada? Y así va cerrando decisiones.

Dónde falla (y por qué apareció la evolución)

En codebases grandes surge un problema. Tu app ya tiene términos propios: Cliente, Cuenta, Reserva, Estado, Confirmada, Pendiente. La IA puede preguntar bien, pero cada sesión nueva tiene que volver a aprender qué significan esas palabras en TU proyecto. Eso cuesta tiempo y genera malentendidos.

De ahí sale la regla que plantea Matt:

Si no hay codebase → Grill Me. Si hay codebase → Grill with Docs.

Grill with Docs: mismo método, lenguaje compartido

No hace preguntas distintas: hace que la IA llegue a la conversación con un lenguaje compartido. En el repo puede existir un CONTEXT.md con el dominio documentado:

• Cliente: persona o empresa que contrata nuestros servicios.
• Cuenta: acceso del cliente al sistema.
• Reserva: solicitud de uso de un recurso en una fecha determinada.
• Estados de Reserva: pendiente, confirmada, cancelada.

Ahí entra el Ubiquitous Language (lenguaje ubicuo) de Domain-Driven Design. La idea: una palabra debería significar lo mismo para todos. Si el analista dice “cliente”, el programador dice “usuario”, la base dice account y el frontend dice customer, aparecen errores. Con documentación explícita queda claro que Cliente ≠ Usuario: el cliente es una entidad comercial; el usuario, una identidad que accede al sistema.

Los ADR: decisiones que no se repiten

La otra pieza son los ADR (Architectural Decision Record): archivos Markdown cortos que registran decisiones arquitectónicas sorprendentes para quien llegue después. Por ejemplo, docs/adr/001-reservas-no-se-eliminan.md: las reservas canceladas no se borran físicamente, se conserva el historial, y por consecuencia las consultas normales deben excluirlas.

No todo merece un ADR. Solo lo que:

• es difícil de revertir,
• resultaría sorprendente sin contexto,
• y nace de un trade-off real.