Por qué Spec-First cambió mi forma de programar con IA (y por qué debería cambiar la tuya)
Tiempo estimado de lectura: 4 min
- Spec-First reduce suposiciones del modelo al definir contratos antes de pedir implementación.
- Escribir tipos y casos de error toma minutos; arreglar código generado con suposiciones incorrectas puede costar días.
- Combinar Spec-First con TDD convierte especificaciones en tests ejecutables y acelera desarrollo mantenible.
- Aplica Spec-First en sistemas críticos, APIs públicas y módulos que deben escalar; evita para prototipos one-off.
Por qué Spec-First cambió mi forma de programar con IA (y por qué debería cambiar la tuya). Poca gente habla de esto después del entusiasmo inicial. Descubrí algo curioso: no era la IA la que fallaba, era el orden de mis decisiones.
La primera vez que pides código a un asistente te sientes en una peli de ciencia ficción. La décima vez estás peleando con alucinaciones, nombres mal elegidos y lógica que solo funciona en el mundo ideal del modelo. Spec-First rompió esa dinámica.
Resumen rápido (lectores con prisa)
Spec-First: escribe el contrato (tipos, entradas/salidas, casos límite) antes de pedir implementación. Reduce suposiciones del modelo y convierte especificaciones en tests ejecutables. Útil para código mantenible y APIs, menos para prototipos one-off.
El coste real del Prompt-Driven Development
El flujo habitual es: pides, pegas, arreglas. Repetir. Para prototipos funciona. Para software que vive y crece, no.
- El modelo no conoce tu arquitectura.
- No sabe tus convenciones ni decisiones pasadas.
- No respeta tus límites de efectos secundarios ni tus políticas de error.
Resultado: módulos que compilan pero no encajan. Bugs lógicos distribuidos. Revisiones interminables.
Spec-First no te da respuesta mágica. Te devuelve tiempo y predictibilidad.
Qué debe contener una spec si vas a usar IA
No necesitas un documento de 30 páginas. Necesitas lo mínimo imprescindible para quitarle decisiones al modelo:
Tipos e interfaces
define entradas y salidas antes de pedir lógica.
interface CreateUser { email: string; name?: string }type Result<T> = { ok: true; value: T } | { ok: false; error: string }
Casos límite
nulos, dominios bloqueados, fallos de red, retries, timeouts.
Comportamiento determinista
funciones puras, sin efectos laterales, o explícitamente con side effects autorizados.
Restricciones de integración
versiones de librería, patrones prohibidos, dónde puede tocar la base de datos.
Escribir esto toma minutos. Arreglar un desastre generado por IA puede costarte días.
Spec-First + TDD = velocidad real
Si ya definiste tipos y casos de error, pedirle al modelo que genere tests primero es natural. Los tests pasan a ser la especificación ejecutable.
Flujo práctico:
- 1) Escribe tipos y contratos.
- 2) Genera tests unitarios con la IA.
- 3) Pide la implementación hasta que los tests pasen.
La diferencia: pasas menos tiempo adivinando por qué algo falla y más en ajustar diseño.
Ejemplo rápido (mental, no código largo)
En vez de: “Crea función que valide emails”, di:
“Función pura que recibe string, valida email corporativo (rechaza gmail.com, hotmail.com), retorna Result<Email, ValidationError>, cero excepciones, sin llamadas externas.”
Esa frase evita que el modelo haga lo que le da la gana y te devuelve algo integrable.
Cuándo aplicar Spec-First (y cuándo no)
No es una religión. Úsalo cuando importe la mantenibilidad y la integración:
- Sistemas críticos, core domain, APIs públicas.
- Equipos distribuidos con contratos firmes.
- Proyectos que deben escalar o durar.
No lo emplees para scripts one-off o prototipos exploratorios donde la velocidad de concepto importa más que la calidad.
Cambia tu rol profesional: de mecanógrafo a director de orquesta
La IA está comoditizando la escritura de código. El valor real se desplaza hacia quien define qué construir y por qué. Spec-First es el instrumento para ejercer ese criterio sin perder velocidad.
Tú no vas a competir con la IA en velocidad de tecleo. Vas a competir en claridad de intención, disciplina arquitectónica y capacidad de traducir requisitos imprecisos en contratos firmes.
Cómo empezar hoy (3 pasos prácticos)
- Antes de pedir código, escribe los tipos. Solo eso.
- Genera tests unitarios desde esa spec.
- Pide la implementación, haz que los tests pasen.
Hazlo en el siguiente ticket que abras. No hace falta cambiar todo tu flujo; prueba en un módulo nuevo y compara el resultado.
Haz esto ahora: la próxima vez que pidas una función al asistente, detente 30 segundos y define solo los tipos. Luego vuelve y genera los tests. Verás la diferencia.
Esto no acaba aquí: si quieres, puedo convertir tu próxima descripción vaga en una spec lista para usar con cualquier LLM.
Este artículo trata sobre IA aplicada y flujos de trabajo con modelos, por lo que puede interesarte explorar recursos prácticos y experimentos en Dominicode Labs. Es un complemento natural para probar especificaciones y pipelines de tests en prototipos controlados.
FAQ
- ¿Qué es Spec-First?
- ¿Cuándo debo usar Spec-First?
- ¿Spec-First reemplaza al TDD?
- ¿Cuánto tiempo toma crear una spec básica?
- ¿Es útil para prototipos rápidos?
- ¿Qué incluye una spec mínima?
¿Qué es Spec-First?
Es una práctica que prioriza escribir contratos (tipos, entradas/salidas, casos límite) antes de solicitar la implementación a un asistente IA o a un desarrollador.
¿Cuándo debo usar Spec-First?
Cuando la mantenibilidad, integraciones o el dominio crítico importen: APIs públicas, core domain y equipos distribuidos. No es necesario para scripts one-off o experimentos rápidos.
¿Spec-First reemplaza al TDD?
No lo reemplaza; se complementan. Spec-First define contratos y TDD convierte esos contratos en tests ejecutables que guían la implementación.
¿Cuánto tiempo toma crear una spec básica?
En muchos casos, minutos. Definir tipos y casos límite mínimos suele ser suficiente para reducir suposiciones del modelo y evitar reescrituras costosas.
¿Es útil para prototipos rápidos?
No siempre. Para prototipos donde la velocidad de concepto importa más que la calidad, puedes omitirlo. Para piezas que deban mantenerse o integrarse, sí.
¿Qué incluye una spec mínima?
Los tipos e interfaces de entradas/salidas, casos límite (nulos, dominios bloqueados, fallos de red), comportamiento determinista (funciones puras o efectos explícitos) y restricciones de integración (versiones, patrones prohibidos).
Leave a Reply