El contexto técnico
Vi la presentación de Matt Pocock no como un espectador más, sino como alguien que se enfrenta constantemente al mismo problema: la implementación de IA en el desarrollo no falla por el modelo, sino por el proceso. Y es aquí donde su conjunto de técnicas da en el clavo.
Lo primero que noté fue /grill-me antes del Plan Mode. En esencia, no lo veo como un «prompt secreto», sino como un modo de validación estricta de la tarea. A menudo me encuentro con que el asistente de código está demasiado dispuesto a aceptar todo, y luego arrastra suposiciones incorrectas a lo largo del proceso.
/grill-me es eficaz porque obliga a la IA a debatir, encontrar lagunas y aclarar restricciones y casos extremos antes de empezar a escribir un plan o código. Para el desarrollo real, esto es más barato que tener que arreglar después una implementación bien formateada pero incorrecta.
El segundo punto fuerte que me hizo asentir casi automáticamente fue el TDD como requisito mínimo. No como una ideología por sí misma, sino como un seguro contra las fantasías del modelo. Si obligo al asistente a formalizar primero el comportamiento con una prueba, «crea» menos y se adhiere mejor al contrato.
Otro patrón útil que se discutió fue /domain-model. La descripción se asemeja a un resumen conciso del modelo de dominio, acumulando conocimiento en CONTEXT.md y ADR. Me gusta este enfoque por su moderación: sin un enorme altar DDD, pero con un registro de decisiones para que la siguiente pasada de la IA no empiece con amnesia.
Y sí, tampoco consideraría /improve-codebase-architecture como un botón mágico. Es más bien una forma de guiar al asistente en una revisión de la arquitectura, pero aun así no le confiaría por completo el diseño de interfaces a una máquina. Cuanto más simple sea la interfaz, menos probable es que el modelo la «optimice» hasta convertirla en un monstruo.
Impacto en el negocio y la automatización
Para los equipos, la conclusión práctica es muy realista. Ganan los que construyen la automatización con IA en torno a validaciones, pruebas y un contexto explícito. Pierden los que piden «hazlo bonito» y luego se sorprenden de la complejidad innecesaria.
El segundo efecto que veo en los clientes es el ahorro en rehacer trabajo. Cuando el modelo de dominio y las decisiones arquitectónicas se documentan de forma concisa, la integración de la IA en el pipeline se vuelve más estable: menos explicaciones repetidas, menos deriva en las decisiones entre iteraciones.
Y la conclusión principal no me parece en absoluto alarmante para los desarrolladores. No, esto no parece un «la IA nos reemplazará a todos». Parece un amplificador para quienes saben establecer límites, no un sustituto del pensamiento de ingeniería.
Si su equipo ya escribe código con Claude, Cursor o herramientas similares, pero los resultados varían de excelentes a extraños, yo empezaría con barandillas como estas. Y si quieren convertir esto en un flujo de trabajo adecuado sin improvisaciones, en Nahornyi AI Lab ayudamos a estructurar la automatización con IA para que el negocio obtenga una velocidad predecible, no otra fuente de caos.