Por Kwame Boateng
La programación asistida por IA suele describirse como una versión más rápida de la programación en pareja. Esa comparación se ha quedado pequeña. Cuando un agente puede inspeccionar un repositorio, modificar varios archivos, ejecutar herramientas, generar una vista previa y abrir una solicitud de incorporación de cambios, el problema central de colaboración ya no es simplemente «¿Puede escribir código?». Es «¿Pueden las personas ver, revisar, aprobar y reconstruir posteriormente lo ocurrido?»
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 directo, flujos de trabajo de comentarios y aprobación, archivado automático y registros de auditoría. La aplicación de Copilot de GitHub también ha añadido un panel «Mi trabajo» para organizar incidencias y solicitudes de incorporación de cambios 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 de 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 hace que esos detalles puedan inspeccionarse. Debería vincular 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 sistema de seguimiento de incidencias, una solicitud de incorporación de cambios, un canal de colaboración o una consola de agentes—, pero la información debería conservarse después de que termine la sesión.
Esto importa por razones ordinarias de ingeniería, no solo por cumplimiento normativo. Si aparece un error dos semanas después, un equipo necesita algo más que la diferencia final. Puede necesitar conocer el requisito original, el plan generado, las pruebas realizadas, los comentarios del revisor y si una persona aceptó explícitamente una compensación arriesgada. 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, esto 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.
- Evidencias: resultados de pruebas, salida del análisis de estilo, comprobaciones de seguridad, capturas de pantalla y una vista previa en directo o desplegable cuando corresponda.
- Registro de decisiones: comentarios del revisor, cambios solicitados, aprobación, rechazo, reversión o trabajo de seguimiento.
La cuestión 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 cuestión es que el nivel de escrutinio sea proporcional al impacto potencial.
Las aprobaciones deben estar vinculadas a acciones
«Humano en el circuito» es demasiado impreciso 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 darse cuenta de que el agente también modificó un archivo de despliegue. Los flujos de trabajo mejores especifican qué permite la 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 desplegar. 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 aquellas que solo pueden recomendar refleja este patrón más amplio: la autonomía debe asignarse por tarea, no asumirse globalmente.
Las aprobaciones también necesitan alcance y caducidad. Una aprobación para «actualizar el texto de la página de destino» no debería autorizar silenciosamente un nuevo paquete de analítica. Un plan aprobado ayer no debería cubrir automáticamente una diferencia modificada sustancialmente hoy. 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 directo puede revelar espaciados incorrectos, estados ausentes, controles inaccesibles o un cambio no intencionado 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 de discusión: un revisor puede señalar una pantalla, un estado o una interacción específicos y dejar comentarios asociados al cambio propuesto.
Esto es especialmente valioso cuando personas no especializadas forman parte de la revisión. Es posible que un responsable 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 tratamiento de datos. El espacio de trabajo asistido por agentes puede dirigir cada pregunta a la persona mejor preparada para responderla.
Las diferencias necesitan contexto, no solo color
La conocida diferencia 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 los commits o grupos de cambios acotados, expliquen por qué cambió cada archivo sustancial y 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é supuestos hizo el agente sobre el comportamiento existente?
- ¿Qué pruebas se añadieron, modificaron o no se ejecutaron?
- ¿Podría este cambio afectar a los permisos, la retención de datos, la facturación o las API externas?
Estas preguntas convierten la revisión de una petición vaga de «échale un vistazo» en un examen repetible. También ayudan a sacar a la luz 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.
Archivar el razonamiento importante
Preservar cada token de cada conversación con un modelo no es automáticamente útil. Los historiales largos pueden ser costosos de almacenar y difíciles de buscar, mientras que la investigación sobre la compactación del contexto advierte que los resúmenes pueden perder información importante. Por lo tanto, un registro de auditoría práctico debería conservar artefactos relevantes para las decisiones en lugar de guardar indiscriminadamente todo.
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 del 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 a las fuentes y el momento en que estas informaron el cambio. En trabajos de alto riesgo, puede estar justificado conservar la interacción completa y el registro de ejecución.
Haz que los registros sean evidentes ante manipulaciones cuando la importancia del asunto lo requiera, y define las reglas de retención antes de que se produzca 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.
Qué cambia esto para las carreras de software
La habilidad emergente no consiste únicamente en escribir mejores prompts. Consiste en diseñar un trabajo que otra persona pueda inspeccionar y considerar fiable. Los desarrolladores deberán sentirse cómodos especificando criterios de aceptación, descomponiendo tareas, revisando diffs a escala, creando pruebas significativas y decidiendo cuándo 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 clarificación de la intención. Los ingenieros de QA pueden ayudar a definir los puntos de aprobación y los casos de fallo. Los responsables de ingeniería deberán medir el rendimiento sin recompensar la asunción de riesgos invisibles. Los redactores técnicos y los especialistas en 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. Después, pregunta dónde un futuro compañero de equipo se vería obligado a adivinar. Cada suposición es candidata a un espacio de trabajo mejor, un permiso más claro o un registro más duradero.
Una regla operativa sencilla
Deja que los agentes avancen rápidamente dentro de un ámbito visible y reversible. Proporciónales un espacio de trabajo definido, restringe las acciones sensibles, exige aprobación en los límites importantes, adjunta evidencias 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 puede entenderse, cuestionarse, aprobarse, deshacerse y servir de aprendizaje.
