Diseñar software para equipos de IA: cuando las especificaciones se convierten en el producto

Recuerdo estar sentado en una sala de reuniones hace años, viendo a un grupo de ingenieros sénior debatir con fervor casi religioso si usar tabulaciones o espacios para la indentación. La discusión derivó hacia las convenciones de salto de línea para los argumentos de una función, la ubicación de las llaves, e incluso el orden preferido de las declaraciones de importación. Era una escena familiar: desarrolladores experimentados enfrascados en una batalla sobre minucias estilísticas que, en el fondo, apenas afectaban la funcionalidad del software. Y sin embargo, esos debates cargaban un peso que iba mucho más allá de la estética. Eran proxies de algo más profundo: la necesidad compartida de establecer un lenguaje común, un ritmo colectivo, un contrato social codificado en texto.

Aquellas discusiones no eran solo excentricidades de programadores. Eran los rituales mediante los cuales los equipos negociaban convenciones compartidas, mantenían la intención de diseño y preservaban un sentido de pertenencia. El código fuente era el lugar de encuentro donde los humanos alineaban sus modelos mentales, imponían la mantenibilidad y codificaban decisiones de arquitectura. Servía a dos audiencias muy distintas a la vez: la máquina que ejecutaba las instrucciones, y el próximo humano que tendría que leerlas, entenderlas y modificarlas. El código era, al mismo tiempo, un artefacto técnico y un contrato social.

¿Qué ocurre cuando los humanos ya no necesitan encontrarse dentro del código?

Durante la mayor parte de mi carrera, esa habría sido una pregunta extraña. La implementación y la coordinación estaban tan estrechamente ligadas que separarlas era, en gran medida, teórico. La IA hace que esa separación sea práctica. El código sigue teniendo que existir. Lo que cambia es quién necesita entenderlo, y dónde debe residir la comprensión que lo gobierna.

01 El código conserva su función, pierde a su audiencia

El código no desaparece en este modelo. Sigue siendo el artefacto de tiempo de ejecución — el sustrato que las máquinas ejecutan y que los sistemas de verificación inspeccionan. Pero cambia su audiencia principal. Durante décadas, la legibilidad, los nombres, el formato, los comentarios, las abstracciones y la revisión de código cumplieron una función tanto social como técnica. Optimizábamos el código no solo porque la máquina tenía que ejecutarlo, sino porque otra persona eventualmente necesitaría entender por qué existía.

Esa segunda audiencia moldeó una cantidad extraordinaria de la práctica de ingeniería. Las guías de estilo redujeron desacuerdos innecesarios. Las convenciones de nomenclatura comprimieron el conocimiento del dominio en vocabulario. Las revisiones de código hacían más que atrapar errores: distribuían contexto entre el equipo. Incluso las discusiones habituales sobre si un método era demasiado largo eran, en realidad, discusiones sobre el costo futuro de la comprensión humana.

Si la implementación es producida, inspeccionada y reparada predominantemente por agentes, algunas de esas convenciones seguirán siendo útiles. Otras pueden perder la justificación económica y social que las hacía importantes. La pregunta no es si el código generado debería ser ilegible — los humanos seguirán necesitando investigar fallas y auditar comportamientos consecuentes. Pero se vuelve más difícil defender el código fuente como el lugar principal donde una organización negocia significado.

Las especificaciones asumen ese papel en su lugar. Dejan de ser documentos de requisitos que preceden a la implementación, y empiezan a cargar los límites arquitectónicos, los criterios de aceptación, las restricciones no funcionales, los trade-offs, las políticas y la memoria institucional que antes se filtraba a través de comentarios de código, pull requests, tickets y conversaciones.

Cuando los humanos dejan de escribir la implementación, las especificaciones dejan de describir el trabajo. Se convierten en el trabajo.

Eso no convierte la escritura de especificaciones en un reemplazo administrativo de programar — todo lo contrario. Hace que la ambigüedad sea más costosa. Un requisito vago solía disparar una conversación con un desarrollador capaz de cuestionar o inferir la intención mientras lo implementaba. Un sistema autónomo, en cambio, puede convertir esa ambigüedad en un subsistema perfectamente coherente construido sobre el supuesto equivocado. El artefacto humano tiene que volverse más preciso, sin pretender que toda decisión pueda predeterminarse.

02 Agentes correctos, organización incorrecta

La sala de revisión estaba en silencio, pero tensa. Un incidente de producción reciente había disparado las alarmas: dos agentes de IA habían desplegado cambios conflictivos sobre el mismo servicio en cuestión de minutos, provocando fallas en cascada. Ningún humano había escrito la implementación, y sin embargo varios agentes habían tocado el código de formas que se superponían. El equipo revisó registros e historiales de diffs, tratando de desenredar los traspasos invisibles entre agentes: quién disparó qué, qué supuestos cargaba cada agente, y por qué decisiones individualmente razonables se habían combinado en un resultado globalmente irrazonable.

El patrón resultaba familiar. Los sistemas distribuidos nos han enseñado durante décadas que componentes individualmente correctos pueden producir sistemas incorrectos. La concurrencia, el estado obsoleto, los reintentos, el conocimiento parcial y los traspasos mal coordinados generan fallas que ningún componente individual “posee”. Los equipos de agentes heredan el mismo problema.

Agentes correctos no producen necesariamente una organización correcta.

Eso cambia lo que los humanos necesitan observar. No necesitan vigilar cada token generado ni inspeccionar cada diff solo porque existe. Necesitan procedencia de las decisiones: qué especificación estaba activa, qué contexto recibió el agente, qué regla arquitectónica restringió la elección, qué evidencia hizo que un agente aceptara la salida de otro, dónde comenzaron a divergir dos ramas de trabajo. La observabilidad del comportamiento de los agentes no es una comodidad: es gobernanza.

Los equipos humanos tenían versiones informales de esto que rara vez llamábamos por ese nombre: diagramas de arquitectura, revisiones de diseño, conversaciones en pull requests, daily stand-ups, charlas de pasillo. Hacían visible la coordinación lo suficiente como para que alguien notara que dos personas resolvían el mismo problema de forma distinta antes de que la diferencia se convirtiera en comportamiento de producción. Una organización de desarrollo con IA necesita superficies equivalentes, aunque no necesariamente interfaces equivalentes. El objetivo no es un tablero lleno de actividad de agentes; es hacer legibles las decisiones, los supuestos y los conflictos lo suficiente como para que los humanos puedan gobernar el sistema sin convertirse en otro cuello de botella.

03 Verificación distinta, no menos verificación

La revisión de código ocupaba un lugar central en la gobernanza de software tradicional porque la implementación era costosa y de origen humano. Leer el cambio de otro ingeniero era un lugar práctico para preguntar si coincidía con el diseño, violaba convenciones o malinterpretaba el problema. Ese mecanismo se tensiona cuando la implementación se vuelve abundante. Si un equipo de agentes puede producir docenas de cambios sustanciales en el tiempo que antes tomaba preparar un solo pull request, poner la revisión humana al final de cada diff generado simplemente traslada el cuello de botella.

Las especificaciones, las reglas arquitectónicas, los sistemas de diseño, los criterios de aceptación, las políticas de seguridad y privacidad, la verificación automatizada y la recolección de evidencia empiezan a formar un sistema de control en capas alrededor de los agentes. El juicio humano permanece presente, pero se desplaza hacia los límites donde la interpretación, el riesgo o el significado de negocio no pueden reducirse de forma segura a una regla automatizada.

Supongamos que un equipo de IA genera cinco interfaces distintas con el mismo error conceptual — una acción importante del flujo de trabajo queda consistentemente oculta, o una regla de dominio se representa mal cada vez. Un equipo humano podría reparar las cinco instancias y resolver el problema inmediato. Eso pasaría por alto la pregunta interesante: ¿qué hizo que ese error fuera válido cinco veces? Tal vez la especificación era ambigua. Tal vez el sistema de diseño codificaba la convención equivocada. Tal vez un gate de verificación revisaba la sintaxis y la accesibilidad, pero pasaba por alto el comportamiento de negocio que realmente importaba.

El líder técnico ya no arregla el resultado. El líder técnico arregla el sistema que produjo el resultado.

En un equipo de IA, los defectos recurrentes rara vez son solo problemas de implementación. Son defectos de gobernanza. Hay un peligro aquí, y no es menor: la gobernanza puede convertirse en una burocracia elaborada escrita en formato legible por máquina, y los equipos pueden terminar confiando en los gates porque son automatizados, no porque sean significativos. La buena gobernanza no reduce la innovación; reduce la improvisación — pero esa tensión no desaparece solo porque el proceso nuevo sea más rápido.

04 El backlog se convierte en un corpus vivo de intención

Los backlogs nos dicen algo sobre la economía del modelo anterior. Cuando la demanda supera la capacidad de implementación, el trabajo tiene que esperar en algún lugar, así que convertimos esa espera en una cola y llamamos backlog al artefacto resultante. Si la IA aumenta radicalmente la capacidad de implementación, el backlog no se vuelve inútil: las organizaciones seguirán teniendo más ideas de las que deberían perseguir, y la atención, el capital y la tolerancia al riesgo siguen siendo finitos. Pero el significado de la cola cambia. El objeto escaso deja de ser tanto “tiempo de desarrollador necesario para escribir esta funcionalidad” y pasa a ser “confianza organizacional en que esto es lo correcto para construir bajo estas restricciones”.

Un backlog en ese entorno empieza a parecerse a un corpus vivo de intención: resultados deseados, restricciones de dominio, preguntas sin resolver, trade-offs y alternativas rechazadas. La ejecución empieza a parecerse menos al procesamiento de tickets y más a un bucle de control — la intención humana se convierte en especificación, los agentes ejecutan contra ella, los sistemas automatizados verifican el resultado y reúnen evidencia, los humanos examinan la evidencia donde se requiere juicio, y el ciclo vuelve a empezar.

Un bucle sin especificaciones simplemente automatiza la improvisación.

Esto no es simplemente una versión más rápida de Agile. La velocidad cambia el modo de falla tanto como la tasa de entrega. Un bucle mal gobernado puede alejarse de la intención más rápido de lo que jamás pudo hacerlo un equipo humano, generando implementaciones, pruebas, documentación y migraciones internamente consistentes alrededor de un supuesto que nunca debió sobrevivir a la primera conversación de diseño. El bucle importante no es el que genera más software. Es el que puede regresar repetidamente a la intención.

05 El software como participante organizacional

Un líder de producto abre el sistema un lunes por la mañana. Durante el fin de semana, el sistema analizó un gran volumen de conversaciones de soporte, detectó una regresión recurrente, correlacionó las quejas con un lanzamiento reciente y comparó el comportamiento con la especificación vigente. Varios agentes exploraron posibles cambios. Se ejecutaron las pruebas relevantes. El sistema reunió la evidencia y destacó los trade-offs.

No cambió el producto en silencio. En cambio, presenta algo más parecido a: esto es lo que observé, esto es lo que propongo, estas son las consecuencias.

La automatización tradicional ejecuta un proceso que ya entendemos. Este tipo de sistema participa en el bucle de retroalimentación mediante el cual la organización decide en qué debería convertirse el proceso. Esa distinción importa porque participar requiere contexto. Un sistema que actúa dentro de finanzas debe entender más que números; el cumplimiento normativo no puede reducirse a verificar si existe un campo. Sin conocimiento de dominio, una organización autónoma puede volverse extraordinariamente eficiente produciendo sinsentidos.

Un sinsentido eficiente sigue siendo un sinsentido.

La responsabilidad no puede delegarse al agente. Una recomendación puede ser generada por máquina, pero la organización que eligió la especificación, las restricciones, los umbrales de evidencia y los límites de decisión sigue siendo dueña de la consecuencia. Esa es una razón por la que la metáfora del “compañero de equipo” solo es útil hasta cierto punto: el software puede participar en el trabajo organizacional sin volverse moralmente responsable de él.

06 ¿Qué es, entonces, un ingeniero de software?

Tomemos en serio la premisa por un momento: ningún humano del equipo de desarrollo necesita tocar el código de producción. ¿Qué es entonces un ingeniero de software? ¿Qué es un arquitecto cuando la implementación deja de ser el medio principal a través del cual la arquitectura se vuelve real? ¿Qué es un líder técnico cuando no hay pull requests humanos que aprobar?

Los roles no desaparecen, pero su centro de gravedad se desplaza. El trabajo de ingeniería se mueve hacia las especificaciones, los límites arquitectónicos, la estrategia de verificación, la evaluación de evidencia, los trade-offs de dominio y la memoria institucional. QA pasa a preocuparse por si la evidencia realmente demuestra el comportamiento prometido, no solo por si una suite de pruebas está en verde. La arquitectura deja de tratarse tanto de dibujar la estructura que los humanos van a codificar, y pasa a definir las restricciones dentro de las cuales la implementación autónoma puede variar de forma segura.

Eso resulta atractivo hasta que nos preguntamos de dónde viene el juicio de ingeniería. La mayoría de los arquitectos experimentados que conozco no aprendieron arquitectura leyendo documentos de arquitectura. Aprendieron viviendo con las consecuencias — depurando condiciones de carrera que deberían haber sido imposibles, viendo migraciones fallar a mitad de camino, heredando abstracciones que se veían elegantes en un diagrama y se volvían insoportables ante un cambio real. Implementar era doloroso, pero el dolor nos enseñaba algo. Puede que descubramos, con el tiempo, que la implementación no era solo trabajo. También era la forma en que los ingenieros aprendían.

Quizás parte de ese aprendizaje pueda trasladarse a otro lugar: los ingenieros podrán investigar fallas a fondo aunque no hayan escrito la implementación, las revisiones de evidencia podrán volverse más ricas de lo que jamás fueron las revisiones de código, algunas personas seguirán descendiendo a la implementación generada cuando las consecuencias lo justifiquen. Pero todavía no lo sabemos. Una profesión puede automatizar parte de su trabajo más rápido de lo que entiende qué le estaba enseñando ese trabajo — y eso puede convertirse en uno de los límites más importantes de los equipos de desarrollo totalmente basados en IA.

Sospecho que los ingenieros seguirán discutiendo sobre software. Siempre lo hemos hecho. Pero tal vez las discusiones se trasladen a otro lugar — no las tabulaciones o los espacios, no dónde va la llave, no si una llamada a función debería caber en una línea. Las discusiones que queden serán más difíciles: qué quisimos decir realmente, qué restricciones importan, qué no estamos dispuestos a sacrificar, qué evidencia es suficiente, y cómo sabemos que un sistema construido por máquinas todavía representa las intenciones de las personas responsables de él.

El código nunca fue el producto. La comprensión compartida sí lo era.

Si esa comprensión se traslada del código fuente hacia las especificaciones, la gobernanza, la evidencia y la memoria institucional, no hemos eliminado la parte humana de la ingeniería de software — la hemos concentrado. Esa concentración trae sus propios riesgos. Los equipos pueden perder instintos de implementación que no sabían que necesitaban. La gobernanza puede volverse opaca precisamente porque está automatizada. Las especificaciones pueden desviarse mientras cada agente sigue comportándose correctamente contra una interpretación obsoleta.

Por eso me interesa menos si la IA puede construir una aplicación sin que un humano toque el código. Esa pregunta se está volviendo ordinaria rápidamente. La pregunta más interesante es si podemos diseñar un sistema de ingeniería que preserve la intención humana mientras permite que la implementación se convierta en trabajo casi enteramente de máquinas. Quizás el problema más difícil de la ingeniería de software nunca fue enseñar a las máquinas a construir lo que describimos. Fue aprender a describir, con la precisión suficiente, lo que realmente queremos decir.