Prompt-Engineering y Spec-Driven-Development. Cómo programar con IA como un ingeniero senior en Big Tech
Reduce los errores de alucinación del vibe-coding (Prompt Engineering) al adoptar Spec-Driven-Development. Aprende a programar con IA, escribir prompt y utilizar IDEs como Cursor y Amazon Kiro.
¡Hola! Hoy os traigo un artículo que escribí originalmente en inglés y a mucha gente le resultó útil. ¡Espero que a ti también!
Ya estás usando IA para escribir código más rápido, pero ¿te está convirtiendo en un mejor ingeniero? La diferencia entre un desarrollador de nivel medio y uno senior estará más en cómo usan la IA para construir software robusto y mantenible.
Confiar solo en el “vibe coding” básico (Prompt Engineering) es rápido para tareas pequeñas, pero se encuentra con un límite en proyectos complejos. Nuevos IDEs como Kiro de Amazon están adoptando lo que se llama Desarrollo Guiado por Especificaciones (Spec-Driven Development).
Los ingenieros más exitosos se están volviendo “bilingües”, usando ambos enfoques. Saber cuándo usar cada uno es el nuevo superpoder para crecer en tu carrera.
En este post aprenderás:
La diferencia entre Prompt Engineering y Desarrollo Guiado por Especificaciones
Cuándo usar cada enfoque
Cómo estructurar tus prompts para obtener mejores resultados
Herramientas que soportan cada flujo de trabajo y cómo elegirlas
Prompt Engineering
Algunas personas llaman a esto vibe coding. No estoy de acuerdo. Vibe coding es cuando confías ciegamente en la IA y haces git push --force sin revisar. Eso no es lo que hacemos aquí. Al menos no todo el tiempo 😛
Prompt Engineering es conversacional. No estás planeando una solución perfecta. Haces una solicitud acotada y iteras según el resultado. Usas comandos inline como “refactoriza esto” o “agrega verificación de valores nulos”, y la IA edita directamente en tu código.
He visto que este enfoque funciona mejor cuando mantienes un prompt bien definido. Algunas personas simplemente escriben “agrega tests” y esperan magia. He comprobado que invertir tiempo extra en crear el prompt correcto da frutos, especialmente para flujos repetitivos como revisiones o generación de tests unitarios.
Es como encontrar un bug en una revisión de código versus encontrarlo en producción. Cuanto más tarde tienes que cambiar el enfoque, más costoso es.
PDD es rápido, pero frágil. Para tareas acotadas, es excelente. Creo que veremos cada vez más cómo los pequeños comentarios en revisiones de código son atendidos por la IA antes de hacer push, sacando al humano del ciclo. Avanzas rápido, pero la lógica detrás de tus decisiones queda en la ventana de chat del IDE, en lugar de compartirse con tu equipo.
Desarrollo Guiado por Especificaciones (Spec-Driven Development)
Spec-driven development invierte el proceso. En lugar de pedir código, pides un plan.
Le pides a la IA que escriba una especificación: historias de usuario, criterios de aceptación, diseño de alto nivel y lista de tareas. Luego la revisas. Solo cuando estás satisfecho con el plan le pides generar la implementación real.
Básicamente, es lo que hacen los equipos de software: no escribes código antes de alinearte con tu equipo y las dependencias de la arquitectura de tu sistema y las interfaces expuestas.
Este modelo me convenció después de leer sobre usar Cursor en modo “Ask” para generar un plan y modo “Agent” para ejecutarlo. Él estaba simulando flujos de trabajo guiados por especificación dentro de un editor prompt-first. Ese truco funcionó. Ahora herramientas como Kiro de Amazon tienen soporte integrado para modo especificación con documentación y artefactos versionados. Ya no es solo una “buena práctica”, es una función del IDE.
El futuro de este enfoque trata las especificaciones como código, versionadas junto al código fuente para completa auditabilidad. También permite enlaces de trazabilidad entre tareas, commits y tests.
Dicho esto, el desarrollo guiado por especificaciones no es gratuito. Escribir una especificación para cambiar el color de un botón es un overhead. Solo lo uso cuando sé que el costo de que la IA genere mucho código incorrecto es alto. Para un nuevo servicio o algo que permanecerá años, SDD vale la inversión inicial.
¿Cómo elegir?
No necesitamos elegir un solo lado. Usaremos ambos según la situación.
Si estoy corrigiendo un bug o ajustando una función, uso prompt-first. Es rápido y suficiente. Si estoy diseñando una nueva funcionalidad o escribiendo algo de lo que otros dependerán, uso spec-first. Así evito retrabajo y confusión.
Actualmente, los LLMs empiezan a seleccionar el enfoque automáticamente. GPT-5 recién lanzado elige entre una sugerencia directa o iniciar su proceso de razonamiento. La capa de decisión se mueve del usuario a la herramienta, y espero que los IDEs implementen esto pronto.
Por ahora, debemos elegir, así lo pienso:
Usa Prompt Engineering cuando la tarea es pequeña, individual o incierta. Estás explorando, no comprometiéndote.
Usa Desarrollo Guiado por Especificaciones cuando la tarea es grande, colaborativa o crítica. Necesitas alineamiento, no velocidad.
Nada ha cambiado respecto a los viejos días de ingeniería sin IA. No escribirías un documento para cambiar el color de un botón, pero sí para alinear con tu equipo y las dependencias cómo y qué formato debería tener la información en un payload de evento o API.
IDEs para cada paradigma
El ecosistema se divide en dos: herramientas prompt-first para iteración rápida y spec-first para desarrollo estructurado. Cada una tiene su lugar. Yo uso ambas a diario.
Prompt Engineering IDEs
Cursor: En modo Agent, emito comandos como “refactoriza a async” o “agrega retry logic” y gestiona ediciones aisladas rápido.
Amazon Kiro (Vibe Mode): Te permite saltar la fase de planificación y prompt libre. Lo uso cuando quiero velocidad sin estructura.
GitHub Copilot Chat: Ideal para preguntas rápidas y stubs de código.
Replit Ghostwriter: Útil para prototipos rápidos en navegador.
Claude Code: Buena ventana de contexto.
Windsurf: Buena memoria.
Spec-driven IDEs
Amazon Kiro (Spec Mode): Es la opción completa. Escribe
requirements.md,design.mdytasks.json, y los commitea al repo. Cuando la estructura importa, voy aquí.Cursor (Ask + Agent): Puedes simular SDD generando un plan en Ask y ejecutando en Agent. Pero no obtienes artefactos versionados a menos que los guardes manualmente.
Otros: Con disciplina, puedes simular SDD con prompts manuales, pero es todo manual.
🎯 Conclusión
Tenemos un tradeoff: agilidad vs estructura.
Prompt Engineering es rápido, flexible y genial para tareas individuales o exploratorias.
Desarrollo guiado por especificaciones es estructurado, claro y excelente para escalar trabajo en equipos.
Los ingenieros que crecen más rápido son los que saben alternar entre ambos.
Prueba ambos en tu próxima funcionalidad. Escribe una mini-especificación. Luego prueba algunos bucles de prompts. Observa cuál se siente más rápido, limpio y mantenible. Tu próximo ascenso podría depender de tu adaptación a este cambio.
¡Hasta la próxima!
