Lo que los agentes de código ya tienen
Un agente de código suele empezar en un sitio que ya parece trabajo: un repositorio (el proyecto de código), un historial de cambios, pruebas automáticas que pueden fallar, una revisión humana antes de fusionar el código, una forma de revertir. Si se usa el mismo tipo de modelo en un trato de ventas, esa imagen se rompe. Los registros viven en Salesforce, los documentos en Notion, el correo en Gmail, el chat en Slack, el historial de soporte en Zendesk, cada uno con su propio inicio de sesión. Antes de actuar, el agente tiene que juntar esos hilos.
Ese hueco es el argumento de Karan Vaidya, cofundador y CTO de Composio, en una charla de conferencia que el canal AI Engineer publicó el 3 de septiembre de 2026. Agrupa el apoyo que falta en seis partes, desde un lugar compartido para trabajar hasta deshacer, y habla desde la infraestructura que construye su propia empresa.
La capa alrededor del modelo
El primer movimiento de Vaidya es separar el progreso del modelo del entorno que lo hace usable. Hace tres años, dice, la ayuda de código era autocompletar; ahora se deja correr a un agente de código. Cree que la velocidad vino menos del modelo solo que de lo que hay alrededor: el repositorio, el historial de cambios, las pruebas automáticas, la revisión, los linters —herramientas que revisan el estilo y errores simples del código— y la opción de revertir. Esos archivos, comprobaciones y permisos viven fuera de las instrucciones que se le dan al modelo.
No aísla la calidad del modelo de las herramientas en una comparación controlada; la historia causal es su tesis. Una nota de Anthropic de diciembre de 2024 sobre construir agentes eficaces, aún útil por su arquitectura aunque ahora avisa de que el paisaje de herramientas cambió, hace un punto cercano: los agentes de código pueden iterar porque el entorno de trabajo existente empuja de vuelta, sobre todo con tests, y la revisión humana sigue teniendo que ver si un cambio encaja en requisitos más amplios. La complejidad extra debería esperar a la medición. Eso da motivo para tomar en serio el argumento de la capa alrededor. Su frase más fuerte —que la ingeniería de software es plenamente autónoma— no queda establecida aquí.
Un solo sitio para trabajar
Las tareas de código, dice, suelen empezar cerca de un proyecto que el agente puede ver. El trato de ventas es el contraste: cinco sistemas, cinco inicios de sesión, ningún centro por defecto. El acceso no es el contexto. Darle al modelo muchas herramientas puede dejarlo uniendo por su cuenta las piezas de un trato. Tampoco todo repositorio es tan limpio —tickets, notas de diseño y configuración de producción pueden quedar fuera—, pero el código al menos tiene un sitio por defecto donde empezar.
Un registro que se puede inspeccionar
Git es el análogo en código. Un agente puede mirar atrás cómo se hizo un cambio; una persona puede inspeccionar el trabajo en vez de fiarse de un mensaje que dice que el trabajo terminó. Vaidya quiere un registro entre aplicaciones de lo que el agente tocó, saltó, acertó y falló. La historia aquí es evidencia para inspeccionar, no comprensión garantizada.
El lado de las apps de negocio de esa afirmación es demasiado amplio. La documentación de auditoría de Dataverse de Microsoft, consultada el 9 de septiembre de 2026, describe un registro oficial y configurable de cambios en registros de cliente: quién creó o actualizó, qué campos cambiaron, valores anteriores y recuperación por Web API o SDK. Eso es historial usable en un sistema de negocio. No es la narración unificada de un trato a través de cinco productos. Un historial fragmentado es la versión más defendible de su punto.
El mapa y los criterios de calidad locales
El contexto, para Vaidya, son dos cosas que a menudo se mezclan. Una es el mapa: arquitectura, flujo de datos, cómo se mueve el trabajo de verdad. La otra son los criterios de calidad locales: incluso para el mismo tipo de documento, qué contenido y tono cuentan como un buen resultado cambia de una organización a otra. Escribir un documento para un cliente, en su ejemplo, necesita datos de uso, analítica de producto y contexto del trato antes de la primera frase. Si se registran suficientes acciones, dice, los patrones pueden volverse procedimientos reutilizables en tres niveles: cómo funciona una herramienta, cómo trabaja una empresa y cómo prefiere trabajar una persona.
Eso describe lo que la gente experimentada lleva en la cabeza. Recoger documentos no es lo mismo que tener el mapa, y un manual destilado de registros de acciones no es, con esta evidencia, una habilidad demostrada.
Válido no es lo mismo que correcto
En código, las pruebas unitarias, las de integración, los tipos y el compilador pueden rechazar una salida definida. El contraste en trabajo de conocimiento es su anécdota de correo de contratación. Dice que encargó a su propio agente el correo a candidatos; siguió las instrucciones; los mensajes eran válidos y llegaron a personas reales; y aun así se arrepintió del resultado. Todas las comprobaciones del manual de código, dice, habrían pasado. Nadie preguntó si el envío debía haber salido.
Es su relato en primera persona. El punto que sobrevive sin más detalle del incidente es más estrecho: el éxito de formato y entrega no responde si la acción era apropiada. Sus arreglos propuestos son una comprobación de estilo contra borradores previos, y un sandbox —un entorno de prueba que aísla el efecto— que reciba el golpe antes que la herramienta real. Ese entorno puede coger algunos errores antes de que tengan efecto. No demuestra todo el comportamiento en el mundo real.
Límites que se aplican fuera del prompt
La gobernanza, en la charla, es el conjunto de restricciones que ya usan los equipos de software: un agente puede trabajar en su propia rama, una persona revisa antes de fusionar el código, hay responsables de archivos críticos, la vista previa no es producción. Esos límites varían con el radio de daño. Vaidya dice que las apps de trabajo de conocimiento tienen trozos de la misma idea —alcances de correo, niveles de permiso en el CRM— pero están fragmentados, así que la gente vuelve a escribir las reglas en las instrucciones al modelo. Cuando el sistema resume o recorta contexto anterior para que quepa en la conversación limitada que el modelo aún puede ver, algunas instrucciones pueden desaparecer. No ocurre en cada turno; por eso una regla con la que el agente no puede discutir tiene que vivir fuera de esas instrucciones.
Lo que una herramienta puede alcanzar no es lo mismo que lo que puede hacer ahí. Describe una segunda capa: políticas en lenguaje natural sobre ese acceso, también impuestas fuera de las instrucciones al modelo. Esas reglas hay que configurarlas. Los agentes de código no carecen por naturaleza de derechos de fusionar código o de desplegarlo. Si esos derechos están abiertos, el límite no está solo porque el trabajo sea código.
Deshacer no es prevenir
Los cambios locales de código suelen poder echarse atrás. La documentación oficial de Git describe revert como registrar commits nuevos que invierten el efecto de otros anteriores. Eso no es recuperar un correo enviado ni deshacer un pago. Vaidya es explícito en que esta última pieza está inacabada para el trabajo de conocimiento. Quitar una etiqueta puede ser reversible; un borrado duro o un mensaje enviado puede no serlo. Para acciones sin inversa fiable quiere el sandbox y una revisión antes de que nada llegue a producción. Pillar un error antes de que ocurra no es lo mismo que invertirlo.
Una ilustración local
Para hacer concreto que válido no es lo mismo que correcto, ejecutamos un ejemplo pequeño y construido. Usa registros de tarea inventados y la biblioteca estándar de Python: no hay llamada a un modelo, ni red, ni correo. Una actualización bien formada a una tarea del proyecto permitido se aceptó y dejó un marcador local de aviso. El mismo JSON dirigido a una tarea de otro proyecto se rechazó antes de cambiar nada. Una versión antigua se rechazó. Un cuerpo recortado no llegó a la comprobación de política. Restaurar la edición local aceptada desde el estado previo registrado devolvió la tarea. El marcador de aviso se quedó: representa un efecto secundario —como un mensaje ya enviado— que restaurar la tarea no puede recuperar. En este ejemplo el aviso es una marca dentro del proceso, no un correo real, y el código de restauración no lo borra. Nada salió del proceso.
El flujo, la tabla y el comando de abajo son ese ejemplo. No miden agentes ni recrean la plataforma de la charla.
- Propuesta Una edición JSON sustituye una petición con forma de modelo contra una tarea sintética.
- Comprobación de formato El esquema debe pasar antes de que corra lo demás. Un cuerpo truncado no llega a la política.
- Política de proyecto y revisión La tarea debe estar en el proyecto permitido y citar la revisión actual.
- Actualización local Si la tarea está en el proyecto permitido, se actualiza y se registra un marcador local. No hay llamada de red.
- Deshacer acotado Restaurar desde el estado previo registrado devuelve la tarea. El marcador que queda representa un efecto secundario, como un mensaje ya enviado, que restaurar la tarea no puede recuperar.
| Caso | Esquema | Política | Cambio local |
|---|---|---|---|
| Actualización en el proyecto permitido | válido | válido | tarea más marcador local |
| Otro proyecto, JSON válido | válido | rechazo | no |
| Revisión caducada | válido | rechazo | no |
| Cuerpo malformado | falla | omitido | no |
| Restaurar edición local | n. a. | restaurado; aviso local intacto | tarea restaurada |
python3 demo.pyassertions_passed: TruePara qué sirven las seis partes
Vaidya cierra diciendo que el cuello de botella se ha movido del modelo a la infraestructura, y que su empresa está construyendo la capa que falta. La estructura de seis partes sigue sirviendo para mirar un flujo de agente. Las afirmaciones más fuertes —ingeniería de software plenamente autónoma, escala de la empresa— no quedan establecidas de forma independiente aquí. No comparamos modelos contra herramientas alrededor, y no usamos el producto de Composio.
Para quien ya usa un agente de código, las seis partes se sostienen juntas como una sola comprobación. Si el trabajo no tiene un centro por defecto, el agente está uniendo el contexto a trozos. Si no hay historial que inspeccionar, te fías de un mensaje que dice que el trabajo terminó. Si lo “bueno” no está en el entorno, el modelo adivina qué trata la organización como un buen trabajo. Si las únicas comprobaciones son formato y entrega, una acción válida puede seguir siendo la equivocada. Si el límite vive solo en las instrucciones al modelo, puede desaparecer cuando el contexto anterior se resume o se recorta. Si no hay inversa, la prevención tiene que llegar antes del efecto. La charla original merece verse por las diapositivas y la entrega.
Archivos de reproducción
Fuente
También de
Fuentes y criterio editorial
Original: subida de AI Engineer xxfMT-bPEmU, 3 de septiembre de 2026, 20:41. Un fotograma data la sesión el 30 de junio de 2026; septiembre es la publicación. Usamos metadatos y capítulos del publicador y fotogramas seleccionados. No hubo subtítulos del original (HTTP 429). La evidencia de habla es la pista completa de subtítulos automáticos en inglés de la subida de Tech Bridge del 8 de septiembre (16z2oh_m5cI). Los automáticos pueden fallar en nombres. Los enlaces de capítulo usan el original. Los documentos oficiales citados se consultaron el 9 de septiembre de 2026. El ejemplo local prueba nuestro código.