Qué significa desarrollo AI-First
Usar un asistente para escribir código no cambia por sí solo el proceso de desarrollo. El equipo sigue necesitando decidir qué comportamiento quiere, expresar las restricciones, revisar la implementación y comprobar el resultado.
El desarrollo AI-First adapta ese ciclo a una realidad concreta: una parte creciente de la implementación la producen agentes que no conservan una memoria estable del producto. Por eso el contexto, la intención y la evidencia deben existir fuera de cada sesión y viajar con el trabajo.
La unidad de trabajo deja de ser solo un diff. Incluye el motivo del cambio, el contrato que debe cumplir, el código resultante y la prueba obtenida al verificarlo.
Esta guía es un capítulo de un problema operativo más amplio. Cuando los agentes producen la mayor parte de la implementación, la habilidad escasa pasa a ser dirigir el ciclo que los rodea, y la guía para construir software con agentes de IA cubre ese cuadro completo. Lo que sigue es la parte AI-first: qué artefactos necesita el ciclo y cómo se mantienen conectados.
Los artefactos del framework
Un flujo AI-First necesita pocas piezas, pero deben estar conectadas:
- Evidencia de producto: observaciones, datos o conversaciones que justifican una necesidad.
- Decisión: la opción elegida, las alternativas descartadas y sus motivos.
- Especificación: comportamiento esperado, restricciones y criterios de aceptación.
- Contexto de código: componentes afectados, dependencias, interfaces e invariantes.
- Ejecución: tareas y cambios producidos por personas o agentes.
- Verificación: tests, logs, capturas u otras pruebas ligadas a la versión del contrato.
El valor no está en acumular documentos. Está en poder recorrer los enlaces: desde una línea de código hasta la decisión que la autorizó, y desde un criterio hasta la evidencia que demuestra si se cumple.
Estos artefactos son la forma práctica de los principios del desarrollo asistido por IA mantenible. Los principios dicen qué debe sobrevivir a cada sesión. Los artefactos son el sitio donde sobrevive.
El ciclo operativo
Definir
El equipo convierte una necesidad en un contrato comprobable. Antes de ejecutar, separa hechos de hipótesis, registra las decisiones abiertas y escribe criterios que permitan distinguir un resultado correcto de uno plausible.
El desarrollo guiado por especificaciones cubre esta parte con más detalle.
Preparar contexto
La tarea recibe solo el contexto relevante: reglas del repositorio, arquitectura afectada, interfaces, decisiones vigentes y ejemplos necesarios. Un contexto más largo no siempre es mejor; debe ser trazable y estar actualizado.
Ejecutar
El agente implementa contra el contrato. Si descubre una restricción nueva o necesita cambiar una interfaz compartida, esa información vuelve al contrato en lugar de quedar encerrada en la conversación del agente.
Verificar
La salida se comprueba con evidencia reproducible. Un mensaje que dice «los tests pasan» es estado; la ejecución, los logs y la versión de los criterios forman la prueba. La guía para verificar código generado con IA desarrolla esta distinción.
Aprender
El resultado actualiza el conocimiento del producto. Una hipótesis puede confirmarse o descartarse; una decisión puede cambiar; una especificación puede quedar obsoleta. El sistema debe mostrar esas revisiones sin borrar la procedencia.
Por qué la velocidad sola no se acumula
Los equipos que adoptan agentes suelen ver primero un salto de producción y después un frenazo en el mantenimiento. El arco es tan común que se puede predecir. Los proyectos se vuelven insostenibles, no porque el código generado esté mal, sino porque nadie puede reconstruir por qué es como es. Medida en meses en lugar de sesiones, parte de la ganancia de productividad resulta ser una ilusión: las horas ahorradas escribiendo código vuelven como horas dedicadas a reconstruir la intención antes de cada cambio.
El framework existe para que el tiempo ahorrado se quede ahorrado. Cada etapa del ciclo deja un artefacto detrás, de modo que el siguiente cambio arranca de un contrato y un rastro en lugar de arrancar de arqueología. Ese es el trato completo: un pequeño impuesto por tarea a cambio de no pagar nunca la factura de la reconstrucción.
Adoptarlo en un repositorio existente
Nada de esto exige un proyecto desde cero. El framework crece feature a feature.
- Elige el próximo cambio que ibas a hacer de todas formas.
- Escribe el contrato más pequeño que lo haga comprobable, con el comportamiento, las restricciones y los criterios que demostrarían que está hecho. Si el repositorio no tiene ninguna spec, empieza por las costuras que tocas, no por un sprint de documentación.
- Registra la decisión cuando elijas un enfoque. Un párrafo, con las alternativas que descartaste.
- Cierra con la evidencia adjunta, sea una ejecución de tests, un log o una captura.
Tras unos cuantos ciclos el equipo tiene un rastro pequeño y conectado, y una medida real del coste. Ese es el punto en el que escalar la práctica pasa a ser una decisión informada en lugar de un acto de fe.
Arquitectura y patrones
El framework no obliga a usar una arquitectura concreta. Un producto pequeño puede mantener contexto dentro de un monolito. Un sistema con varias fuentes y modelos puede separar la ingesta, el almacenamiento y la recuperación. Un dominio de alto riesgo puede requerir revisión humana antes de ejecutar o publicar.
La decisión depende del volumen, la sensibilidad de los datos, la latencia, el coste de una salida incorrecta y la capacidad operativa del equipo. La comparación de patrones de arquitectura para sistemas con IA explica esos costes.
Inyección de contexto
La inyección de contexto entrega al agente las reglas y artefactos necesarios en el momento de ejecutar. No consiste en pegar toda la documentación en un prompt. Consiste en seleccionar contexto por tarea y conservar la procedencia de cada elemento.
Una implementación útil responde a estas preguntas:
- ¿Qué regla o decisión necesita esta tarea?
- ¿De dónde procede y cuándo se actualizó?
- ¿Qué ocurre si dos fuentes se contradicen?
- ¿Cómo se registra una restricción descubierta durante la ejecución?
Uso responsable
El mismo rastro que ayuda a mantener el software sirve para gobernar el uso de IA. Conviene registrar las fuentes de datos y versiones de modelo, limitar el acceso a información sensible, evaluar sesgos relevantes para el dominio y definir quién aprueba decisiones de alto impacto. La revisión de seguridad forma parte del mismo ciclo, no de una fase posterior, y asegurar el código generado con IA cubre el lado de las herramientas de esa comprobación.
Antes de automatizar una decisión, el equipo debe poder indicar a quién afecta, qué datos utiliza, cómo se revisa una salida y qué mecanismo permite detener o corregir el sistema. Estas preguntas forman parte del contrato, no de una revisión posterior.
Lo que el framework no resuelve
El método no convierte una hipótesis en evidencia, no garantiza que una especificación sea correcta y no elimina la necesidad de juicio humano. Tampoco compensa un repositorio sin límites claros o una suite de tests que no observa el comportamiento importante.
Su función es más concreta: mantener conectados el motivo, la decisión, la ejecución y la verificación para que el equipo pueda revisar y cambiar el producto sin reconstruir su historia en cada iteración.
Preguntas frecuentes
¿Qué es el desarrollo AI-First?
Es un enfoque donde contexto, intención y evidencia son artefactos de primer nivel junto al código. El objetivo no es generar más, sino conservar un contrato que personas y agentes puedan ejecutar y verificar.
¿En qué se diferencia de usar una herramienta de IA para programar?
Una herramienta acelera una sesión de implementación. Un framework organiza el ciclo completo: cómo se decide, qué contexto recibe el agente, cómo se valida la salida y cómo vuelve el aprendizaje al producto.
¿El desarrollo AI-first es lo mismo que el desarrollo guiado por especificaciones?
No. El desarrollo guiado por especificaciones es la etapa de definir de este ciclo, la disciplina de convertir la intención en un contrato comprobable antes de ejecutar. El desarrollo AI-first cubre el ciclo completo alrededor: cómo llega el contexto al agente, cómo se verifica la salida y cómo lo aprendido vuelve al conocimiento del producto.
¿Qué necesita un equipo para empezar?
Un contrato pequeño y comprobable, reglas del repositorio, una forma de entregar contexto por tarea y evidencia reproducible al terminar. La complejidad adicional solo se justifica cuando esas piezas básicas ya funcionan.