Cuando contamos que llevamos un sistema real a producción en menos de tres semanas dirigiendo agentes de IA, la primera pregunta suele ser cuál modelo usamos. Es la pregunta equivocada.
La pregunta correcta es cómo estaba organizado el equipo.
Un chatbot no es un equipo
La forma más común de usar inteligencia artificial para desarrollar software es también la más frágil: una sola conversación donde el mismo asistente diseña la arquitectura, escribe el código, se revisa a sí mismo y declara que todo funciona. El resultado tiende a parecer bueno por la misma razón por la que un alumno que se autocalifica tiende a sacar diez.
Ningún equipo humano serio opera así. No dejamos que el desarrollador apruebe su propio pase a producción, no porque sea mala persona, sino porque revisar el trabajo propio tiene un punto ciego estructural. Con los agentes de IA ocurre exactamente lo mismo, amplificado: un modelo que generó una solución tiende a defenderla.
La alternativa que usamos fue tratar a cada agente como un integrante con puesto, responsabilidades y límites. Un organigrama.
Los roles que usamos
En nuestro proyecto, la estructura quedó así: una persona (el director del proyecto) como Product Owner, arquitecto de solución y comité de cambios; un agente dedicado a arquitectura, especificación técnica y QA; otro como ingeniero senior implementando directamente sobre el repositorio y la infraestructura; otro como ejecutor de tareas acotadas; uno más como contraste externo sin autoridad sobre la arquitectura; y uno dedicado a diseño de interfaz.
Los nombres de los productos importan menos que el principio: cada rol tiene un dominio donde decide y dominios donde solo opina. El agente de contraste puede señalar que una decisión de arquitectura le parece débil; no puede cambiarla. El implementador puede proponer un ajuste al esquema de datos; la decisión pertenece al rol de arquitectura y, en última instancia, al humano.
Cómo se evita que se contradigan
Dos agentes sin roles definidos se contradicen constantemente, y el proyecto avanza en zigzag: uno propone una estructura, el otro la "mejora" deshaciéndola. La solución no fue técnica sino organizacional, y descansa en tres reglas.
La primera: autoridad única por dominio. Para cada tipo de decisión (arquitectura, datos, implementación, diseño visual) hay exactamente un rol con la última palabra, y ese rol nunca es el que ejecuta el cambio. Las opiniones cruzadas son bienvenidas como insumo; como órdenes, no existen.
La segunda: el repositorio es la fuente de verdad, no la conversación. Lo que quedó decidido vive en especificaciones escritas, en el esquema de la base de datos y en el historial de cambios, no en la memoria de un chat. Cuando un agente arranca una sesión nueva, lee el estado real del proyecto en lugar de reconstruirlo de oídas. Esto elimina la fuente número uno de contradicciones: dos agentes trabajando sobre versiones distintas de la realidad.
La tercera: los límites se escriben, no se suponen. Cada agente opera con instrucciones permanentes que definen qué puede tocar y qué no: reglas de estilo, convenciones de commits, prohibiciones explícitas (no tocar producción, no inventar datos, preguntar antes de borrar). Un límite que solo existe en tu cabeza es un límite que el agente no tiene.
Los handoffs: donde los proyectos se caen
En equipos humanos, los proyectos rara vez fallan dentro de un rol; fallan en los traspasos entre roles: los handoffs, como se les conoce en el mundo de los agentes — el momento en que un rol entrega trabajo y contexto a otro para que continúe. Con agentes es igual, y el término no es decorativo: en nuestra operación diaria, diseñar bien los handoffs resultó tan importante como diseñar bien los roles. Un handoff de arquitectura a implementación que consiste en "haz un módulo de facturación" produce basura con cualquier modelo del mercado. El mismo traspaso con criterios de aceptación, esquema de datos definido y contrato de interfaz produce trabajo revisable.
Nuestra regla operativa: ningún handoff sin artefacto. De arquitectura a implementación se traspasa una especificación. De implementación a revisión se traspasa un cambio concreto en el repositorio con su justificación. De revisión a autorización se traspasa evidencia: qué se probó y qué resultó. Si el handoff no puede escribirse, la tarea no estaba lista para entregarse.
Lo que no funciona
Honestidad obligada: probamos variantes que descartamos. Dejar que dos agentes "debatan" hasta converger suena elegante y produce conversaciones larguísimas que terminan donde el modelo más insistente quería. Duplicar el mismo rol para "comparar" genera trabajo doble y decisiones de nadie. Y el error más caro: asumir que un agente recuerda los acuerdos de hace tres sesiones. No los recuerda; por eso la fuente de verdad tiene que estar escrita fuera de la conversación.
El organigrama tampoco sustituye el criterio del director. Amplifica el que exista. Si la persona al frente no puede distinguir una buena decisión de arquitectura de una mala, el organigrama solo organiza el desorden.
Conclusión práctica
Antes de preguntar qué modelo de IA usar para desarrollar, dibuja el organigrama: qué roles necesitas, quién decide qué, qué límites tiene cada uno por escrito y qué artefacto exige cada handoff. Es el mismo ejercicio que harías con un equipo humano, y por una buena razón: en cuanto los agentes trabajan en algo más grande que un script, dejan de ser herramientas y empiezan a ser un equipo. Los equipos sin organización producen lo mismo desde hace décadas, sean humanos o no: retrabajos.