Qué cambia cuando tu equipo de desarrollo es una IA

Casi todo lo que se escribe sobre desarrollo con IA trata de la primera hora: la demo, el andamiaje, la función que apareció en diez minutos. Muy poco trata del noveno mes, cuando la base de código es grande, hay varios cambios en vuelo a la vez y los fallos interesantes ya no son errores de sintaxis.

Esta es una nota del noveno mes.

Las decisiones escritas se convirtieron en la verdadera restricción

Un equipo humano de ingeniería carga con una enorme cantidad de contexto compartido que nunca se escribe en ninguna parte. Todo el mundo conoce la regla de multi-tenencia, el motivo por el que se abandonó el enfoque antiguo, qué módulo es un campo de minas.

Un equipo de IA no tiene nada de eso entre sesiones. Así que toda decisión que importe tiene que existir como documento duradero y localizable, o directamente no existe.

En la práctica eso significa una estratificación estricta. Cada funcionalidad tiene una especificación funcional (qué hace para la persona usuaria), un diseño técnico (esquema, endpoints, arquitectura) y un archivo de épica (historias y su estado). Las decisiones arquitectónicas que atraviesan varias funcionalidades tienen su propio registro numerado: por qué la plataforma se adapta al sector en lugar de usar plantillas, por qué los modos de operación de la IA tienen la forma que tienen, por qué el sitio de marketing es una exportación estática. Un archivo de arranque en la raíz del repositorio enruta los tipos de trabajo a su lectura obligatoria, de modo que una tarea que toca la autenticación arrastra automáticamente el modelo de amenazas.

Lo que me sorprendió: esto no es un sobrecoste que se paga en beneficio de la IA. Es la disciplina de documentación que todo equipo de ingeniería dice querer y pocos sostienen, vuelta obligatoria porque la alternativa es inmediatamente visible. Cuando la documentación se desvía, la siguiente sesión construye lo que no era ese mismo día, no dentro de seis meses cuando entre alguien nuevo.

El estado registrado no es una prueba

El modo de fallo que no anticipé, y el que más tiempo ha costado, es fiarse de un estado que resultó ser una descripción de intenciones.

Una incidencia cerrada significa que alguien decidió que estaba hecha. Una compilación en verde significa que los trabajos que se ejecutaron pasaron. Ninguna de las dos demuestra que la cosa funcione. A lo largo de un día particularmente instructivo aparecieron cinco defectos en funcionalidades cuyas incidencias estaban cerradas y cuyas tuberías estaban en verde. En todos los casos el registro era exacto sobre lo ocurrido y mudo sobre lo que no.

Las trampas concretas se repiten y valen mucho más allá del desarrollo con IA:

• Una batería de pruebas que no encuentra ninguna prueba informa de éxito. También lo hace un filtro con una errata en la ruta. El verde sobre un conjunto vacío es idéntico al verde sobre un conjunto que pasa, salvo que compruebes el recuento.
• Una tubería con filtros de ruta se salta las baterías que tu cambio no tocó. Una ejecución que informa de «éxito» en dieciséis trabajos puede no probar nada sobre el cambio que tienes delante.
• Una compilación puede pasar en una máquina con dependencias obsoletas y fallar después para todos los demás.

La corrección es una regla, no más vigilancia: verifica contra el artefacto, no contra el registro. Lee el código, cuenta las aserciones que se ejecutaron, carga la página. Hoy es el primer instinto y no el último recurso, y es la práctica que trasplantaría a cualquier equipo, con IA o sin ella.

El paralelismo necesita aislamiento, no buenos modales

Varias sesiones de IA trabajan a la vez sobre este repositorio. Comparten un único directorio de git, lo que significa que las referencias de rama, los guardados temporales y el estado remoto son comunes a todas: los árboles de trabajo aíslan archivos, nunca referencias.

Sin aislamiento duro pasan tres cosas, y las tres pasaron: dos sesiones construyen lo mismo de forma independiente, una sesión empuja código sobre la rama de otra y una sesión recoge trabajo en curso que era de otra persona.

Las reglas que lo arreglaron no tienen ningún glamour. Cada sesión trabaja en su propio árbol de trabajo creado desde la rama principal compartida. Una rama tiene exactamente un dueño; nunca se empuja a una rama que no creaste. Nunca se toca estado compartido que no creaste: el guardado temporal de otra persona no es tuyo para limpiarlo. Y la limpieza se hace al principio de una sesión y no al final, porque una sesión no puede eliminar el árbol de trabajo dentro del que se está ejecutando; la instrucción de recoger después fue silenciosamente imposible durante un año, que es por lo que nadie la había cumplido nunca.

Si eso suena a la descripción de un sistema distribuido más que de un equipo, ese es justamente el punto. La coordinación entre agentes es un problema de ingeniería con soluciones de ingeniería, no un problema de comunicación con soluciones culturales.

Las pruebas cambiaron de oficio

Con desarrolladores humanos, las pruebas capturan regresiones. Con desarrolladores de IA, las pruebas son cómo se transmite la intención. Una especificación dice qué debería pasar; una prueba lo afirma de una forma que no se puede malinterpretar, no se desvía y falla ruidosamente cuando un cambio posterior la contradice.

Eso cambia qué merece la pena probar. Las pruebas de mayor valor aquí no son las que cubren más líneas, sino las que codifican una regla que nunca debe violarse y cuyo incumplimiento sería silencioso: que ninguna consulta pueda escapar del ámbito de su cliente, que un permiso no pueda ampliarse por una ruta de código, que exista un registro de auditoría por cada mutación. Esas sostienen el edificio. Una prueba que comprueba que un ayudante formatea una fecha, no.

La conexión con el producto

Aquí es donde deja de ser una historia sobre procesos.

Todo lo anterior describe lo que un sistema necesita para que una IA pueda trabajar sobre él con seguridad: un modelo de datos sin ambigüedades, decisiones registradas en un formato legible por máquina, estado que se puede verificar en vez de suponer, permisos que se sostienen sin depender del buen comportamiento, una traza de auditoría que dice quién hizo qué y una forma de deshacer un error.

Es también, exactamente, la lista de lo que una plataforma de negocio necesita para que una IA pueda operarla con seguridad en nombre de un cliente.

Lo que significa que construir Cyril de este modo no ha sido una excentricidad ni un ahorro. Ha sido la prueba más exigente posible de la promesa central del producto. Cada vez que el proceso de desarrollo necesitó una garantía nueva para seguir siendo seguro, esa misma garantía resultaba faltar en la plataforma. Un registro de auditoría en lugar de varios. Un modelo de permisos que el actor automatizado hereda en lugar de esquivar. Una vía de reversión que existe porque el esquema la soporta, no porque alguien se acordó de añadir un botón de deshacer.

No planeé esa simetría. Hoy defendería que no es casualidad: el software operable por agentes y el software construible por agentes son la misma categoría de cosa, y si estás construyendo lo primero, construirlo de la segunda manera es la prueba honesta más barata que vas a encontrar.

Qué le diría a quien empiece

• Escribe la decisión en el momento en que la tomas, en el sitio donde mirará la siguiente sesión. Una decisión no documentada se volverá a litigar, y probablemente se revertirá.
• No te fíes nunca de un campo de estado. Confirma contra el artefacto. Da por hecho que cada luz verde responde a una pregunta más estrecha que la que hiciste.
• Aísla el trabajo paralelo a nivel de herramienta. Las reglas que dependen de la cortesía entre agentes fallan en la primera colisión.
• Gasta tu presupuesto de pruebas en los invariantes que fallan en silencio, no en el porcentaje de cobertura.
• Revisa el diff, no el resumen. El resumen lo escribe el mismo sistema que escribió el código, y describe lo que pretendía.

Cyril está en fase previa al lanzamiento. Su modo Agéntico —en el que le entregas un objetivo por completo— está por llegar, no publicado; lo que existe hoy es la plataforma y un asistente de IA que planifica, enseña su plan y actúa donde puedes mirar. Esa distinción me importa más de lo que le importaría a un departamento de marketing, porque todo el argumento anterior sostiene que la distancia entre lo que un sistema afirma y lo que puede demostrar es donde viven los problemas.

Preguntas frecuentes

¿De verdad escribe una IA todo el código?

La implementación, las pruebas y la documentación las escribe la IA. La dirección de producto, la priorización, la aprobación y la revisión son humanas. La división que funciona es que la IA es dueña del cómo y una persona es dueña del qué y del si.

¿Es más rápido que un equipo humano?

Sustancialmente, en el momento de escribir código, y eso resulta ser la variable menos interesante. El límite está en la capacidad de revisión y verificación, que es humana, así que las prácticas que hacen rápida la verificación importan más que el volumen bruto de salida.

¿Qué se rompe más a menudo?

Fiarse del estado registrado. No código malo: confianza equivocada sobre si el código existente funciona, a partir de un campo de estado que era exacto sobre la intención y mudo sobre el resultado.

¿Se lo recomendarías a otro equipo?

Las prácticas, sin reservas, uses IA o no: decisiones escritas y duraderas, verificación contra artefactos, aislamiento duro del trabajo paralelo y pruebas como codificación de la intención. El modelo de plantilla es otra cuestión y depende de cuánta capacidad de revisión tengas, porque esa es la restricción real.

---

Si quieres estar entre los primeros en usar Cyril, apúntate a la lista de espera.