Por Kwame Boateng
A menudo se describe la programación asistida por IA como una versión más rápida de la programación en pareja. Esa comparación ya se queda corta. Cuando un agente puede inspeccionar un repositorio, modificar varios archivos, ejecutar herramientas, generar una vista previa y abrir una solicitud de extracción, el problema central de colaboración ya no es simplemente «¿Puede escribir código?». Es «¿Pueden las personas ver, revisar, aprobar y reconstruir después lo que ocurrió?»
Por eso, el cambio de diseño más importante en los equipos de software asistidos por agentes podría ser el paso de los prompts privados a los espacios de trabajo visibles. Slack Code, por ejemplo, se describe como una combinación de canales de proyecto con agentes de programación, auditoría de diferencias de código, vistas previas HTML en vivo, flujos de trabajo de comentarios y aprobación, archivado automático y registros de auditoría. La aplicación Copilot de GitHub también añadió un panel «Mi trabajo» para organizar incidencias y solicitudes de extracción en distintos proyectos. Estas funciones apuntan hacia un principio práctico: el trabajo de un agente debería parecerse menos a una respuesta opaca y más a un conjunto de cambios que avanza por un proceso de producción controlado.
El chat no es el registro del trabajo
Una conversación con un agente puede ser útil para explorar una idea, pero es un sistema de registro débil. Los detalles importantes pueden quedar enterrados en un hilo largo: qué archivos cambiaron, qué comandos se ejecutaron, qué supuestos hizo el agente, qué rechazó un revisor y si el resultado final difiere de la primera propuesta.
Un espacio de trabajo duradero permite inspeccionar esos detalles. Debería conectar la solicitud con un repositorio o proyecto específico, conservar el plan del agente, mostrar las acciones de las herramientas y los cambios en los archivos, enlazar con las pruebas y las vistas previas, y registrar quién aprobó el resultado. La interfaz exacta puede variar —un gestor de incidencias, una solicitud de extracción, un canal de colaboración o una consola de agentes—, pero la información debería permanecer después de que termine la sesión.
Esto importa por razones ordinarias de ingeniería, no solo por cumplimiento. Si aparece un error dos semanas después, un equipo necesita más que la diferencia final. Puede necesitar conocer el requisito original, el plan generado, la evidencia de las pruebas, los comentarios del revisor y si una persona aceptó explícitamente una compensación riesgosa. Un registro duradero acorta esa investigación.
Cinco capas de trabajo visible
Los equipos que adoptan agentes de programación pueden tratar cada cambio como un pequeño expediente inspeccionable. Cinco capas son especialmente útiles:
- Intención: la incidencia, los criterios de aceptación, las restricciones y el alcance solicitado.
- Plan: el enfoque propuesto por el agente antes de editar archivos. Para una tarea no trivial, este es un punto de control de aprobación, no un adorno.
- Diferencia: las adiciones, eliminaciones, cambios de dependencias, modificaciones de configuración y recursos generados exactos.
- Evidencia: resultados de pruebas, salida del análisis de estilo, comprobaciones de seguridad, capturas de pantalla y una vista previa en vivo o implementable cuando corresponda.
- Registro de decisiones: comentarios del revisor, cambios solicitados, aprobación, rechazo, reversión o trabajo de seguimiento.
La idea no es obligar a que cada cambio pase por un comité pesado. Un error tipográfico y un cambio en el flujo de pagos no deberían tener controles idénticos. La idea es que el nivel de escrutinio sea proporcional al impacto potencial.
Las aprobaciones deben estar vinculadas a acciones
«Humano en el circuito» es demasiado vago para ser un control útil. Una persona podría aprobar un plan sin ver la diferencia resultante, o aprobar un cambio de código sin notar que el agente también modificó un archivo de implementación. Los mejores flujos de trabajo especifican qué permite cada aprobación.
Por ejemplo, un equipo podría permitir que un agente lea un repositorio y ejecute pruebas locales automáticamente, exigir aprobación antes de escribir fuera de una rama designada y exigir una aprobación independiente antes de fusionar o implementar. Un agente podría proponer una migración de base de datos, pero tener prohibido ejecutarla en producción. El enfoque propuesto por los EAU para clasificar qué tareas pueden completar los agentes frente a cuáles solo pueden recomendar refleja este patrón más amplio: la autonomía debe asignarse por tarea, no asumirse de forma global.
Las aprobaciones también necesitan alcance y vencimiento. Una aprobación para «actualizar el texto de la página de inicio» no debería autorizar silenciosamente un nuevo paquete de analítica. Un plan aprobado ayer no debería cubrir automáticamente una diferencia que hoy cambió de manera sustancial. La interfaz debería hacer visibles esos límites.
Las vistas previas convierten la revisión en inspección
La revisión de código suele ser más fácil cuando las personas pueden inspeccionar el resultado en lugar de inferirlo a partir de los archivos fuente. Una vista previa HTML en vivo puede revelar espaciado incorrecto, estados faltantes, controles inaccesibles o un cambio no previsto en la navegación que un revisor podría pasar por alto en una diferencia textual.
Las vistas previas no demuestran que algo sea correcto. Deben estar junto a las pruebas y la revisión del código fuente, no reemplazarlas. Pero crean un objeto común para el debate: un revisor puede señalar una pantalla, un estado o una interacción específicos y dejar comentarios adjuntos al cambio propuesto.
Esto es especialmente valioso cuando personas no especializadas forman parte de la revisión. Es posible que un gerente de producto no pueda evaluar un cambio de framework, pero puede ser la persona adecuada para confirmar que el flujo coincide con el requisito. Un diseñador puede validar una regresión visual. Un especialista en seguridad puede centrarse en los permisos y el manejo de datos. El espacio de trabajo asistido por agentes puede dirigir cada pregunta a la persona mejor capacitada para responderla.
Las diferencias necesitan contexto, no solo color
Una diferencia conocida en rojo y verde sigue siendo esencial, pero los cambios generados por agentes pueden ser lo bastante amplios como para abrumar a un revisor. Los equipos deberían pedir a los agentes que mantengan reducidos los commits o grupos de cambios, expliquen por qué cambió cada archivo importante e identifiquen por separado los archivos generados o de proveedores.
Entre las indicaciones útiles para la revisión se incluyen:
- ¿Qué comportamiento visible para el usuario cambió?
- ¿Qué archivos se modificaron únicamente para respaldar la implementación?
- ¿Qué suposiciones hizo el agente sobre el comportamiento existente?
- ¿Qué pruebas se agregaron, modificaron o no se ejecutaron?
- ¿Este cambio podría afectar los permisos, la retención de datos, la facturación o las API externas?
Estas preguntas convierten la revisión de una solicitud vaga de «revisar esto» en un examen repetible. También ayudan a poner de manifiesto un modo de fallo común: una función plausible acompañada de una actualización incompleta de las pruebas o de un cambio accidental en la configuración.
Archiva el razonamiento importante
Preservar cada token de cada conversación con un modelo no es automáticamente útil. Los historiales extensos pueden ser costosos de almacenar y difíciles de buscar, mientras que las investigaciones sobre la compactación del contexto advierten que los resúmenes pueden perder información importante. Por lo tanto, un registro de auditoría práctico debería conservar los elementos relevantes para las decisiones, en lugar de guardar todo indiscriminadamente.
Como mínimo, conserva la solicitud, el plan aprobado, el diff final, los resultados de las herramientas y las pruebas, la referencia de la vista previa o el despliegue, las decisiones de los revisores y cualquier excepción concedida. Si un agente utilizó fuentes externas o recuperó documentos internos, registra las referencias pertinentes y el momento en que influyeron en el cambio. Para trabajos de alto riesgo, puede estar justificado conservar la interacción y el registro de ejecución completos.
Haz que los registros permitan detectar alteraciones cuando la importancia del asunto lo requiera y define las reglas de retención antes de que ocurra una crisis. Un registro de auditoría que desaparece cuando se archiva un canal —o que no puede distinguir un resultado modificado del original— no servirá para respaldar una investigación seria.
Lo que esto cambia para las carreras de software
La habilidad emergente no consiste simplemente en escribir mejores prompts. Consiste en diseñar un trabajo que otra persona pueda inspeccionar y en el que pueda confiar. Los desarrolladores deberán sentirse cómodos especificando criterios de aceptación, descomponiendo tareas, revisando diffs a gran escala, creando pruebas significativas y decidiendo en qué momento un agente debe detenerse y preguntar.
Los profesionales de producto y diseño tendrán un papel más importante en la revisión de vistas previas y la aclaración de la intención. Los ingenieros de QA pueden ayudar a definir los puntos de aprobación y los casos de fallo. Los gerentes de ingeniería deberán medir el rendimiento sin recompensar la toma de riesgos invisibles. Los redactores técnicos y los especialistas de operaciones pueden contribuir haciendo que las decisiones, las excepciones y los runbooks sean duraderos.
Un ejercicio útil consiste en tomar una función rutinaria y trazar su cadena de evidencias: solicitud, plan, rama, diff, pruebas, vista previa, aprobación, lanzamiento y reversión. Luego, pregunta en qué punto un futuro compañero de equipo se vería obligado a adivinar. Cada suposición es una candidata para un espacio de trabajo mejor, un permiso más claro o un registro más duradero.
Una regla operativa sencilla
Permite que los agentes avancen rápidamente dentro de un espacio visible y reversible. Asígnales un espacio de trabajo definido, restringe las acciones sensibles, exige aprobación en los límites importantes, adjunta evidencia al cambio y conserva la decisión final. El objetivo no es ralentizar la automatización hasta que se parezca a la programación manual. Es hacer que la velocidad sea compatible con la rendición de cuentas.
En el desarrollo asistido por agentes, el mejor colaborador no es el sistema que produce más código de forma aislada. Es el sistema cuyo trabajo se puede entender, cuestionar, aprobar, deshacer y aprovechar para aprender.
