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 el sitio donde se queda el conocimiento, y esa colocación es todo el argumento. Hay una pieza aparte que la pone al lado de Waterfall, Agile y DevOps, que respondieron a lo mismo de otra forma, y calcula qué cuesta la diferencia para un equipo.
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.
Qué cuesta adoptarlo, y para quién es
El framework no exige un tamaño de equipo concreto. Un fundador en solitario que corre el ciclo solo y un equipo de diez personas que lo corre junto están haciendo las mismas cinco cosas: definir, preparar contexto, ejecutar, verificar, aprender. La diferencia es quién escribe cada artefacto y cuánta gente tiene que estar de acuerdo antes de que avance. Una fábrica de una sola persona sostiene lo mismo desde el otro lado: el ciclo no pesa menos porque nadie más lo esté mirando, pesa menos porque no hay con quién negociar el contrato.
El coste real es un impuesto por tarea, no un programa de formación ni una plantilla que se añade. Escribir el contrato y registrar la decisión llevan minutos la primera vez. Lo que compran a cambio es la hora que un agente se ahorra al no tener que reconstruir la intención a partir de un diff y un mensaje de commit, y ese cambio se repite cada vez que el trabajo se retoma tras una pausa. Controlar el coste de la IA cubre el mismo cambio en el lado de los tokens: un agente atascado dando vueltas sobre una tarea mal acotada quema mucho más de lo que habría costado escribir el criterio que lo habría frenado a tiempo.
Dónde vive ese rastro es una pregunta aparte de quién lo paga. El framework no impone una capa de almacenamiento, solo que las decisiones, los motivos y los caminos abandonados viajen fuera del chat. La memoria de producto desarrolla qué se olvida exactamente cuando nada sostiene esa capa, y la gestión de la ventana de contexto explica por qué ninguna ventana, por grande que sea, hace esto opcional: la compactación se come el propio registro de la sesión sobre lo que pasó, con independencia de lo grande que empezara la ventana.
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.
¿Cuánto overhead añade el framework por tarea?
El tiempo de escribir un contrato pequeño, registrar un párrafo de decisión y adjuntar la evidencia al cerrar la tarea, no un proceso aparte encima del trabajo. El impuesto se paga por adelantado y en piezas pequeñas; la alternativa es pagar una factura mayor y sin avisar más tarde, en la sesión donde alguien tiene que reconstruir por qué el código hace lo que hace.
¿Esto funciona para un desarrollador solo, o solo para equipos?
Escala hacia abajo hasta una sola persona. Los cuatro artefactos se mantienen igual, solo cambia cuánta gente los escribe y los lee. Una fábrica de una sola persona sostiene que el ciclo importa más para un fundador en solitario, no menos, porque no hay nadie más cerca para recordar los motivos si no quedan escritos.