Relájate. Planifica antes de escribir el prompt.

Hace poco comprendí algo sobre un antiguo jefe mío.

No dejaba de intentar convencerme de que usara Kiro.

«Bassel, usa Kiro».

Mi reacción inmediata fue sencilla:

«¿Qué demonios es Kiro?»

En aquel momento no entendía por qué insistía tanto. Yo ya sabía trabajar con IA. En voz baja, y suspendiendo temporalmente toda la humildad necesaria, admito que soy muy bueno escribiendo prompts.

Puedo echar un vistazo a un proyecto, comprender su estructura, darle un prompt detallado a un agente de IA y ver cómo implementa algo complejo a una velocidad sorprendente. A menudo no necesito responder veinte preguntas de seguimiento. Sé aportar suficiente contexto desde el principio.

El resultado aparece. Funciona. Quizá haya dos pequeñas alucinaciones escondidas por ahí, pero nada parece roto durante mi inspección rápida.

Así que lo publico.

Rápido. Limpio. Listo.

Al menos, eso me decía.

Mi jefe había detectado el problema

Un buen jefe hace algo más que celebrar tu rapidez. Detecta los hábitos que podrían acabar convirtiendo esa rapidez en un riesgo.

Mi antiguo jefe comprendía que yo podía hacer que la IA produjera resultados rápidamente. También comprendía algo que se me escapaba: generar código que funciona y entender la solución completa son dos logros diferentes.

Por eso seguía diciendo:

«Bassel, usa Kiro».

Kiro escribe código como muchas otras herramientas de IA. Su verdadero valor está en animarte a definir el trabajo antes de pedirle a la IA que lo ejecute.

Su flujo de especificaciones puede separar una funcionalidad en requisitos, diseño técnico y tareas de implementación antes de empezar a programar. Según la situación, puede partir del comportamiento deseado o de la arquitectura técnica. La documentación oficial de Kiro lo describe como un recorrido estructurado desde una idea hasta su implementación.

Dicho de forma sencilla, Kiro me obligaba a planificar.

Y, al parecer, necesitaba que me obligaran.

Escribir prompts y planificar son habilidades diferentes

Un buen prompt puede contener muchos detalles. Puede describir la base de datos, la interfaz, la validación, las pruebas, la seguridad y el comportamiento esperado.

Un prompt detallado puede seguir ocultando una reflexión débil.

Cuando todo se concentra en una instrucción enorme, es fácil pasar por alto las contradicciones. Puedes pedir dos funcionalidades que no pueden coexistir de forma coherente. Puedes describir el caso ideal y olvidarte de los permisos, los estados de fallo, las migraciones, la accesibilidad o la compatibilidad con versiones anteriores.

Entonces la IA empieza a implementar inmediatamente.

La velocidad parece increíble, pero puede ocultar incertidumbre. Ves aparecer archivos, ejecutarse pruebas y mostrarse componentes. Ese movimiento crea la impresión de que el problema ya se ha entendido.

A veces solo se ha interpretado.

Planificar crea una pausa entre querer algo y construirlo. Durante esa pausa, puedes preguntarte:

• ¿Qué problema estamos resolviendo realmente?
• ¿Qué comportamiento debe admitir el sistema?
• ¿Qué debe negarse expresamente a hacer?
• ¿Qué decisiones afectan a la arquitectura?
• ¿Qué podría romper las funcionalidades existentes?
• ¿Cómo sabremos que la implementación es correcta?

Kiro formaliza esa pausa. Su flujo que comienza por los requisitos produce requisitos, un diseño técnico y una lista de tareas de implementación para revisarlos antes de ejecutar. El diseño puede abarcar componentes, modelos de datos, interfaces, gestión de errores y estrategia de pruebas. La guía de Kiro sobre el enfoque que comienza por los requisitos explica esa progresión.

La IA sigue realizando gran parte del trabajo. La diferencia es que tienes varias oportunidades para detectar supuestos equivocados antes de que se conviertan en código.

El problema de la comida rápida

Piensa en escribir prompts sin planificar como si fuera comida rápida.

Tienes hambre. Pides algo. Llega casi inmediatamente. Sabe bien y el problema inmediato desaparece.

No has aprendido cómo se preparó. No sabes necesariamente qué lleva. Puede que ni siquiera notes lo que falta, porque tu atención está en lo rápido que ha desaparecido el hambre.

Así puede sentirse una implementación rápida con IA.

Pides una funcionalidad. Aparece. Haces clic un par de veces. Nada explota.

Publicado.

Pero ¿qué has aprendido?

¿Entiendes por qué la base de datos se estructuró así? ¿Puedes explicar el modelo de autorización? ¿Sabes qué supuestos hizo el agente? ¿Qué ocurre cuando otro desarrollador tiene que modificar la funcionalidad seis meses después?

La comida rápida tiene su lugar. A veces es exactamente lo que necesitas. Los prototipos, los experimentos, las herramientas desechables y las primeras ideas no siempre requieren una especificación formal.

El error empieza cuando comes comida rápida todos los días y lo llamas nutrición.

Las dos alucinaciones «inofensivas»

Antes trataba las pequeñas alucinaciones de la IA como ruido de fondo.

¿La IA entendió mal dos detalles? Bien. La funcionalidad sigue funcionando.

Una alucinación puede superar una prueba rápida y aun así causar daños después. Un campo de base de datos inventado, un supuesto incorrecto sobre una API, una regla de permisos incompleta o un comportamiento inventado de un framework pueden permanecer ocultos hasta que el sistema llegue a producción.

Los errores más peligrosos suelen parecer totalmente razonables. Representan decisiones que nadie tomó de forma consciente.

Una fase de planificación hace visibles esas decisiones.

En vez de descubrir un supuesto dentro de una solicitud de cambios que contiene treinta archivos modificados, puedes detectarlo en un documento de requisitos o diseño cuando todavía es una sola frase.

Corregirlo resulta mucho más barato.

La velocidad sigue siendo valiosa

Voy a mantener los prompts rápidos como parte de mi flujo de trabajo. Es uno de mis puntos fuertes y sería absurdo fingir lo contrario.

La lección es que la velocidad gana valor cuando tiene una dirección.

Planificar no exige dedicar tres semanas a escribir un documento para un botón. El esfuerzo de planificación debe corresponder al riesgo y la complejidad de la tarea. Kiro incluso admite flujos de especificación más rápidos cuando un proceso completo de aprobación sería excesivo. Su documentación sobre especificaciones distingue entre especificaciones detalladas de funcionalidades, especificaciones rápidas y flujos de corrección de errores.

El objetivo es ejecutar de forma deliberada, sin burocracia innecesaria.

Para un pequeño ajuste visual, escribe el prompt y sigue adelante. Para la autenticación, los pagos, la arquitectura de bases de datos, los permisos, las migraciones o una funcionalidad que vaya a dar forma al resto del producto, reduce el ritmo.

Define los requisitos.

Revisa el diseño.

Divide el trabajo en tareas.

Después deja que la IA vaya rápido.