Human-Agent Collaboration
Una relación de trabajo durante el desarrollo
Human-Agent Collaboration es la relación de trabajo mediante la cual personas y sistemas AI distribuyen, coordinan y revisan contribuciones, decisiones y responsabilidades durante la ingeniería de software. Incluye formular problemas, compartir contexto, proponer alternativas, delegar ejecución, intercambiar feedback, verificar resultados y decidir su aceptación. Esta definición del Atlas describe una relación configurable, no un proceso obligatorio ni un conjunto universal de cargos.
La colaboración puede comenzar antes de escribir código y continuar después de revisar un diff. Una persona puede aportar una restricción comercial desconocida para el agente; este puede encontrar una incompatibilidad que obliga a reconsiderar el encargo. El valor del intercambio depende de cómo se conectan esas aportaciones con decisiones y evidencia. Mantener una conversación larga, aprobar muchos comandos o producir muchos cambios no demuestra por sí solo una colaboración efectiva.
Coding Assistants describe modalidades de asistencia donde la persona conduce buena parte del progreso. Coding Agent describe un sistema capaz de realizar trabajo de desarrollo mediante ejecución delegada. Human-Agent Collaboration pregunta cómo trabajan juntos los participantes en cualquiera de esas modalidades. Un assistant participa en colaboración; un coding agent también puede requerir intervención humana frecuente. No son dos modelos de colaboración completamente separados ni escalones de madurez determinados por la interfaz.
El equipo puede alternar ayuda dirigida, exploración compartida y ejecución delegada durante una misma tarea. Esa variación responde a incertidumbre, impacto y conocimientos disponibles. No corresponde deducir que usar un agente elimina a la persona del proceso o la convierte únicamente en aprobadora del resultado final.
Colaboración, HITL y actividades particulares
Human in the Loop, o HITL, sitúa intervención humana en puntos seleccionados de un proceso. Puede haber un pedido de autorización antes de publicar o una revisión cuando aparece una excepción. La colaboración es más amplia: también comprende construir una interpretación común del problema, recibir información nueva y ajustar el trabajo antes de llegar a esos puntos. Un proceso colaborativo puede utilizar HITL sin reducirse a sus checkpoints.
La aprobación autoriza una acción concreta. No explica por sí sola quién definió el objetivo, cómo se interpretó el requisito o quién evaluará el resultado. Agent Permissions and Approval Boundaries conserva esa distinción y sus mecanismos. No hace falta pedir permiso nuevamente para cada paso que ya está comprendido en una autorización válida.
La delegación asigna trabajo acotado; la colaboración incluye además exploración conjunta, preguntas, discusión de alternativas, feedback y aceptación. Subagents and Delegation desarrolla la ejecución delegada entre agentes, sin convertir toda colaboración humana en una topología multiagente. Delegar una investigación y discutir sus conclusiones son acciones relacionadas, con responsabilidades diferentes.
Un handoff transfiere control o responsabilidad operativa dentro de un alcance. La colaboración puede incluirlo, pero también puede continuar sin transferir quién conduce el trabajo. Agent Handoffs distingue ese cambio de una simple entrega de información. Finalmente, AI-Assisted Code Review es una actividad particular: colaborar también abarca requisitos, diseño, implementación, testing, release y aprendizaje posterior. Ninguna de estas actividades representa por sí sola la relación completa.
Capacidad, autonomía, autoridad y responsabilidad
Capacidad expresa qué puede realizar técnicamente un sistema. Autonomía describe qué decisiones o acciones puede seleccionar sin dirección paso a paso dentro de un encargo. Autoridad expresa qué está autorizado a decidir o ejecutar. Responsabilidad identifica obligaciones de actuación y rendición de cuentas dentro de la organización. Son dimensiones relacionadas que no se sustituyen entre sí.
Un agente puede disponer de una herramienta para desplegar y carecer de autorización para usarla en esta tarea. También puede ejecutar muchas acciones de lectura de manera autónoma sin poder cambiar una regla de negocio. Más autonomía no concede mayor autoridad organizacional. Que un runtime permita una operación tampoco demuestra que el usuario haya autorizado sus consecuencias.
La ejecución AI no transfiere automáticamente responsabilidad por requisitos, aceptación, riesgo, producción o consecuencias del negocio. Su distribución depende del equipo, del sistema y de los acuerdos organizacionales: puede involucrar autor, reviewer, responsable de producto u operación. No se prescribe un único cargo responsable de todo ni se afirma aquí una regla jurídica universal. Sí interesa que la automatización no deje esas decisiones sin dueño identificable.
Las dimensiones de autonomía y delegación acotada permanecen en coding-agent. La colaboración las aplica a alcance, duración, permisos, frecuencia de revisión y evidencia requerida. Una investigación extensa puede tener poca autoridad y una edición breve puede tocar una regla crítica. Conviene dimensionar el control por las consecuencias y las incertidumbres, no únicamente por la cantidad de pasos o el tiempo que el sistema trabaja solo.
Un encargo compartido y revisable
Repository Exploration and Task Framing ayuda a transformar un pedido incompleto en un problema situado. Para colaborar importa compartir objetivo, alcance, restricciones, condiciones de éxito, incógnitas y revisión del repositorio. No se necesita que ambos participantes conozcan cada archivo, sino que puedan reconocer qué decisiones están acordadas y qué información falta.
Task Prompts comunica el encargo; Persistent Instructions conserva guía reutilizable aplicable. Ninguno elimina la necesidad de comprobar que el estado observado sigue siendo pertinente. Un resumen desactualizado puede describir una autorización revocada o un test anterior al último cambio. Context Engineering for Software Development trata la selección y actualidad de información, sin confundir disponibilidad con autoridad.
Una propuesta del agente debe poder distinguirse de una decisión aceptada. Si descubre que la corrección requiere cambiar un contrato compartido, puede explicar la dependencia y sus alternativas antes de presentar la ampliación como un hecho consumado. En cambio, no necesita consultar al humano por cada búsqueda reversible cuyo alcance ya está definido. La colaboración mantiene claras las decisiones relevantes sin convertir la ejecución en una sucesión de confirmaciones triviales.
El acuerdo también puede revisarse. Un supuesto refutado justifica cambiar el plan o reducir el resultado prometido. Ocultar esa información para preservar una apariencia de progreso hace más difícil aceptar o continuar el trabajo. La continuidad se apoya en acuerdos vigentes y evidencia disponible, no en que ninguna expectativa inicial haya cambiado.
Feedback y escalación con propósito
El feedback puede viajar del humano al agente mediante una corrección, del agente al humano mediante una observación, de una herramienta a ambos mediante un fallo o del proceso de CI mediante resultados. Es información para ajustar el trabajo. No todo feedback constituye verificación: una preferencia expresada, una respuesta convincente o un comentario favorable no demuestra que la implementación satisfaga el requisito.
Escalar significa hacer visible una decisión o condición que la ejecución no puede resolver responsablemente dentro de su alcance. Puede haber ambigüedad de negocio, autoridad insuficiente, un servicio inaccesible, evidencia contradictoria o riesgo nuevo. Una escalación útil especifica qué se observó, qué decisión falta, qué alternativas son concretas y qué parte del trabajo puede continuar independientemente.
No toda incertidumbre exige intervención humana inmediata. El agente puede investigar una hipótesis con observaciones autorizadas y de bajo impacto, contrastar documentación o ejecutar una prueba pertinente. Preguntar repetidamente lo que el repositorio ya puede responder consume atención sin mejorar la decisión. A la inversa, inventar una política comercial para no interrumpir desplaza una elección que no le corresponde.
La frecuencia de comunicación puede adaptarse al trabajo. Un cambio pequeño quizá necesite una entrega final breve; una investigación prolongada puede necesitar actualizaciones al cambiar la hipótesis o aparecer un bloqueo. El propósito es conservar capacidad de decidir, no transmitir cada operación ni producir un registro continuo que oculte los hallazgos relevantes.
Revisión humana, verificación y aceptación
La revisión humana aporta interpretación, conocimientos del dominio y una oportunidad de cuestionar premisas. También puede omitir defectos, carecer de contexto, compartir el supuesto del generador o convertirse en una firma rutinaria. «Revisado por una persona» no garantiza corrección y «revisado por otro agente» tampoco garantiza independencia.
Generated Code Verification conserva la selección de evidencia para el cambio concreto. Una revisión puede contribuir a esa verificación, junto con pruebas, análisis y observaciones pertinentes. Quien acepta necesita saber qué afirmación respalda cada resultado y qué quedó sin comprobar. Leer solamente la explicación del autor puede reforzar una interpretación equivocada, aunque todos los participantes estén de acuerdo.
Aceptar decide si el resultado cumple las condiciones y límites acordados según el proceso vigente. Autorizar release decide si puede producirse ese efecto externo. Terminar una ejecución no equivale a ninguna de las dos cosas. Una aprobación previa de acciones tampoco certifica retrospectivamente sus resultados. Mantener las distinciones permite delegar con claridad sin añadir un nuevo gate humano obligatorio a todas las tareas.
Los Development Context and Execution Records pueden conservar revisión del repositorio, cambios, comprobaciones, incertidumbres y decisiones pendientes. Facilitan continuidad y revisión sin exigir una transcripción completa ni razonamiento privado del modelo. La confianza del destinatario debe poder apoyarse en evidencia recuperable, no únicamente en el tono seguro del resumen.
Ejemplo: corregir una importación parcial
Un equipo solicita corregir una importación que pierde actualizaciones válidas cuando otra fila contiene un error. La persona aporta la política comercial de aceptación parcial; el agente localiza el flujo y muestra que existe además una dependencia entre filas. La colaboración comienza al hacer visible esa diferencia, antes de decidir cómo programar la solución.
El agente puede proponer rechazar el grupo dependiente o preservar ciertas filas según una regla explícita. El responsable correspondiente decide la política; el agente implementa dentro del alcance acordado y ejecuta las comprobaciones relevantes. Si un servicio necesario está inaccesible, reporta el límite y puede verificar las partes independientes. No reemplaza la integración ausente con la afirmación de que «debería funcionar».
Durante la revisión, una persona contrasta el comportamiento con la intención y detecta un supuesto que las pruebas compartían. El feedback conduce a revisar expectativa e implementación. Ese intercambio no demuestra que la colaboración anterior fuera inútil: muestra por qué conviene poder cuestionar oráculos y decisiones, además de inspeccionar sintaxis.
La entrega distingue cambio preparado, evidencia reunida, aceptación y autorización de publicación. Si alguien retoma la tarea, necesita estado verificable y límites actuales. Transferir el resumen puede bastar para compartir contexto; transferir la conducción requiere además delimitar quién continúa y bajo qué autoridad. No hay una secuencia obligatoria de agentes o productos detrás de este ejemplo.
Formas de participación y fallos de colaboración
La ayuda dirigida por una persona, la ejecución compartida, el trabajo delegado y las tareas prolongadas son combinaciones posibles. Pueden variar entre actividades del mismo proyecto: diseño discutido conjuntamente, edición delegada y aceptación bajo un proceso del equipo. Ninguna exige pasar por niveles universales ni reducir progresivamente la participación humana. Algunas decisiones merecen más interacción aun con un agente técnicamente competente.
La aprobación rutinaria sin examen, o rubber-stamping, ocurre cuando se confirma sin examinar evidencia suficiente. La confianza ciega y el sesgo de automatización pueden llevar a favorecer una salida por su origen o presentación. El control excesivo de cada paso trivial produce el problema inverso: consume atención que podría dirigirse a decisiones de mayor impacto. Más intervenciones no significan mejor colaboración.
La autoridad ambigua deja al agente decidir lo que el equipo suponía reservado. La delegación sin límites hace difícil evaluar completion. La incertidumbre oculta y la asimetría de contexto permiten que una persona acepte sobre premisas que el agente ya sabe débiles, o que este ejecute con acuerdos que dejaron de aplicar. Conviene corregir esas condiciones concretas antes de agregar rituales o participantes.
Coding-Agent Failure Modes and Recovery desarrolla las desviaciones de ejecución; Agent Evaluation examina comportamiento entre tareas. Aquí interesa cómo la relación de trabajo permite prevenir, detectar y discutir esos problemas. deterministic-and-probabilistic-development-workflows aborda la composición de mecanismos que pueden aportar control y evidencia, sin reemplazar los acuerdos entre personas.
Fuentes y alcance editorial
Las distinciones, el ejemplo y las recomendaciones son síntesis del Atlas. Guidelines for Human-AI Interaction de Microsoft Research, asociadas al trabajo de CHI 2019 y consultadas el 2026-10-28, ofrecen una referencia primaria sobre interacción inicial, uso habitual, errores y evolución en el tiempo. Su alcance general de diseño de interacción no establece una metodología de desarrollo, una política universal de responsabilidad ni una garantía de corrección para coding agents.