OpenClaw y la ingeniería agéntica: menos supervisión humana, más pruebas automáticas

Greg Kamradt presentó una visión concreta de la ingeniería agéntica centrada en un problema menos discutido que el costo de tokens o la potencia de cómputo: la atención humana. Su propuesta con OpenClaw apunta a reducir la necesidad de supervisión constante mediante transcripciones de trabajo, revisiones automáticas y entornos remotos para probar cambios en sistemas limpios.
***

• Greg Kamradt afirmó que su principal limitación ya no son los tokens ni la CPU, sino la atención que exige supervisar agentes de programación.
• OpenClaw incorporó tres piezas clave a su flujo: transcripciones adjuntas a PRs, autorrevisión automática antes de enviar cambios y “cajas” remotas para pruebas.
• Aunque los agentes requieren menos babysitting, Kamradt sostuvo que todavía fallan al entender cómo encaja una tarea dentro del panorama completo del sistema.

La conversación sobre agentes de inteligencia artificial para programación suele girar en torno a costos, contexto y velocidad. Sin embargo, Greg Kamradt planteó otra restricción que, según su experiencia reciente, pesa más en el trabajo diario: la atención humana.

Durante su presentación, explicó que primero estuvo limitado por tokens y luego por CPU. Ahora, tras resolver parcialmente ambos frentes, dijo que el cuello de botella real es cuántas veces una persona debe entrar al ciclo de trabajo para corregir, revisar o validar a un agente.

Esa idea fue el eje de OpenClaw Creator & Agentic Engineering, presentado por Greg Kamradt. Su tesis fue directa: el valor de un agente aumenta cuando puede avanzar desde el prompt hasta la verificación con menos intervención humana.

El planteamiento resulta relevante más allá de OpenClaw. A medida que más equipos experimentan con agentes de código, el debate se mueve desde “¿pueden programar?” hacia “¿cuánto trabajo extra generan para quienes deben supervisarlos?”.

Kamradt respondió a esa pregunta con tres cambios concretos que, según dijo, transformaron su flujo en los últimos meses. Se trata de transcripciones adjuntas a los pull requests, revisión automática dentro de la sesión original y una infraestructura de cajas remotas para descargar pruebas y validaciones.

La transcripción como señal de calidad en los pull requests

El primer problema que describió fue el volumen de pull requests que recibe OpenClaw. Según relató, algunos colaboradores generan PRs con un esfuerzo mínimo, a veces limitándose a pedirle al agente que “arregle” algo y publique cambios de hasta 4.000 líneas.

Ese escenario complica la evaluación humana. No siempre queda claro si quien abrió el PR entendió el problema, invirtió tiempo en iterar o simplemente delegó todo al agente sin mayor criterio técnico.

Para resolverlo, Kamradt diseñó una habilidad pequeña que invita a subir una versión sanitizada de la transcripción de trabajo una vez creado el PR. También se comunica al usuario que incluir ese material aumenta la probabilidad de que alguien revise su contribución.

La lógica detrás de esa práctica no es meramente documental. Kamradt explicó que la longitud y el contenido de la transcripción le ofrecen una señal adicional sobre el nivel de cuidado invertido en el arreglo.

En sus palabras, una sesión más extensa puede elevar su confianza en que la persona realmente intentó comprender lo que estaba corrigiendo. Añadió que esa información no solo le resulta útil a él, sino también a su propio agente, que gana más contexto para interpretar la intención detrás del cambio.

El desarrollador señaló que tardó demasiado en implementarlo porque pensó el problema de forma innecesariamente compleja. Al final, dijo, no hacía falta construir ganchos sofisticados, ya que bastaba con una skill que explicara al agente cómo localizar y cargar el JSON de la sesión.

Kamradt afirmó que la habilidad fue diseñada para funcionar con cualquier agente de programación, ya que en el fondo el insumo es JSON. El sistema intenta sanitizar el contenido, aunque reconoció que la limpieza no será perfecta porque se sigue confiando en el mismo agente que produjo la sesión.

Por eso también dejó una advertencia práctica. Recomendó no escribir secretos extremadamente sensibles dentro de una sesión de programación, aun si en condiciones normales el proceso debería funcionar sin mayores problemas.

La decisión final fue convertir esa skill en una función predeterminada del repositorio. De ese modo, cualquiera que descargue el proyecto obtiene automáticamente la instrucción de cargarla al crear un PR o un issue.

Según Kamradt, la calidad de los pull requests y de los reportes mejoró de forma marcada entre quienes adoptaron esa práctica. Para su flujo, fue un cambio fácil de agregar y con una ganancia alta en señal y trazabilidad.

La autorrevisión automática antes de exponer el código a terceros

La segunda pieza que mostró fue la revisión automática. Kamradt la describió como su skill favorita, aunque admitió que también volvió todo más lento y disparó el consumo de tokens.

El problema original era familiar para muchos equipos que trabajan con IA. Un agente genera código, luego alguien abre un PR y después otro agente o una persona revisa ese cambio desde fuera, en un proceso que puede ser tardado y poco práctico.

Su solución consistió en hacer que el agente cargue una skill por defecto cuando realiza un commit o abre un PR. Esa skill invoca una CLI capaz de usar las herramientas disponibles en el sistema para revisar el cambio y devolver observaciones.

La parte que Kamradt considera más valiosa no es la revisión en sí, sino el destino del feedback. En lugar de enviarse a una sesión separada, vuelve a la sesión original de programación, que conserva mucho más contexto sobre el problema y las restricciones del cambio.

Ese detalle busca evitar una falla recurrente en revisiones ingenuas. Kamradt dijo que a veces un revisor detecta tres cosas, las corrige sin comprender por completo el diseño y termina rompiendo algo que en realidad obedecía a una decisión deliberada.

Con el feedback de vuelta en la sesión inicial, el propio agente que ejecutó el trabajo puede decidir si la crítica es válida o si choca con una restricción importante. Ese filtro, según explicó, mejora la calidad del ajuste posterior.

Además, añadió instrucciones para que el agente modifique la descripción del PR con las decisiones tomadas durante esa fase. Así, la siguiente persona que examine el cambio tiene más contexto y menos riesgo de reabrir debates ya resueltos.

Kamradt bromeó con que ese sistema probablemente enriqueció a proveedores de modelos por su consumo intensivo de tokens. Aun así, defendió el costo implícito porque la autorrevisión reduce fricción posterior y puede ahorrar tiempo humano más escaso.

No obstante, también advirtió sobre un límite. Dijo que la revisión automática puede excederse, por lo que conviene definir invariantes claros en los agentes, como archivos que no deben alterarse después de cierto punto o supuestos que el sistema puede dar por válidos.

Ese matiz apunta a un problema más amplio en la programación asistida por IA. Los agentes tienden a escribir para el peor caso posible, incluso cuando el sistema real opera bajo reglas más estrechas que un humano ya conoce.

“Crapbox”: cajas remotas para descargar la CPU y probar en sistemas limpios

La tercera herramienta fue la que Kamradt dijo amar más. La presentó como “crapbox”, un mecanismo pensado para resolver el deterioro del rendimiento cuando un desarrollador mantiene muchas sesiones largas de agentes trabajando en paralelo.

Su descripción fue muy concreta. Con múltiples sesiones simultáneas, las CPUs se disparan, la laptop parece querer despegar y todo se vuelve más lento, lo que termina afectando directamente la productividad.

Antes de este cambio, explicó que llegó a operar con varias máquinas a la vez, incluyendo su equipo principal, una Mac en la nube y una Mac Studio. Aunque funcional, esa solución le parecía incómoda y difícil de sostener como respuesta ideal.

La idea de las cajas remotas parte de dar al agente un pequeño entorno aislado donde pueda sincronizar los cambios del repositorio y ejecutar tareas costosas sin cargar la máquina local. Kamradt dijo que el sistema puede comenzar desde el mismo estado definido en GitHub Actions.

Eso implica que, si el proyecto ya cuenta con integración continua, la caja debería funcionar por defecto sin demasiado trabajo adicional. A partir de allí, el agente sincroniza cambios y corre pruebas dentro de ese entorno externo.

El beneficio inmediato es de capacidad computacional. Todo lo caro ocurre fuera del equipo principal, lo que elimina buena parte del problema de CPU que antes lo obligaba a repartir tareas entre varias computadoras.

Con el tiempo, sin embargo, la herramienta tomó un papel más amplio. Kamradt afirmó que ya soporta alrededor de 30 proveedores, incluso opciones menos comunes o apropiadas para compañías con altos requisitos de seguridad.

La expansión también incluyó soporte para Linux y Windows, además de macOS. Eso abrió una capacidad importante para los agentes: instalar y probar software en máquinas frescas, en vez de depender de un sistema local ya modificado por configuraciones previas.

Kamradt subrayó que esa limpieza importa mucho cuando se validan errores difíciles de reproducir. Si la prueba ocurre en el computador habitual del desarrollador, podrían existir ajustes antiguos que oculten el fallo o hagan pasar algo que en realidad no funciona para otros usuarios.

Por esa razón, defendió la idea de empezar desde una máquina nueva para elevar la confianza en que lo solicitado por prompt realmente funciona. En su demostración, mostró que el agente puede instalar OpenClaw en Linux, macOS y Windows dentro de estas cajas.

Verificación visual, enlaces compartibles y menos babysitting

Kamradt añadió que a esos entornos remotos les dio “ojos”, es decir, capacidad de capturar pantallas e interactuar visualmente con la interfaz. Aclaró que no tienen “oídos”, pero sí pueden hacer clic y navegar para configurar sistemas paso a paso.

Ese detalle acerca la experiencia a formas de “computer use”, pero con una diferencia importante. Como el agente opera dentro de una caja fresca a la que se accede vía VNC, el usuario no pelea con su propio cursor, con cambios de foco ni con interrupciones del sistema local.

En la práctica, Kamradt dijo que el agente puede abrir un navegador, preconfigurar opciones y dejar listo un entorno de prueba. Aunque el proceso puede tardar, el resultado es verificable porque el humano ve el estado de la pantalla.

También destacó que esos enlaces son compartibles. Si crea un entorno para probar una nueva función, puede enviarlo a otra persona para que la explore al instante, usando GitHub u otra capa de autenticación como base.

Esa capacidad cambia la forma de validar ideas dentro de un equipo. Kamradt imaginó incluso un canal de feedback donde un bot implemente una propuesta y responda con un enlace a una sesión VNC para que alguien sin conocimientos de programación pruebe la función.

Según su visión, ese tipo de flujo ayuda a extender el bucle de verificación. Una sugerencia puede ser sometida a una prueba más concreta antes de que él tenga que dedicar tiempo a leerla o priorizarla.

El beneficio no es solo técnico, sino organizacional. Si parte del feedback ya llega acompañado de una verificación práctica, el desarrollador puede concentrarse en una fracción menor de ideas realmente interesantes.

Kamradt presentó ese modelo como una forma de reducir babysitting. En lugar de observar durante 20 minutos a un agente codificar en vivo, prefiere revisar el resultado cuando ya pasó por varias capas de validación automática o semiautomática.

En ese punto citó un ejemplo visual sencillo. Con la infraestructura adecuada, dijo, es fácil crear prompts que generen videos o GIFs con estados “antes y después”, lo que permite inspeccionar un bug y su arreglo de forma rápida antes de presionar “merge”.

Su conclusión fue que hoy necesita mucha menos supervisión directa que hace un año. Aun así, dejó claro que el ahorro no elimina la necesidad de criterio humano, especialmente cuando la pregunta deja de ser “¿funciona?” y pasa a ser “¿deberíamos construir esto?”.

El límite actual: más herramientas para agentes, pero poca visión de conjunto

Hacia el final, Kamradt reconoció que no ha resuelto por completo el problema de la atención. Dijo, medio en broma, que no puede “matarlos a todos”, sugiriendo que aún existen demasiados frentes abiertos para una sola persona.

Su balance fue moderadamente optimista. Los agentes requieren menos supervisión porque ahora tienen más herramientas para trabajar durante más tiempo por su cuenta, pero todavía siguen necesitando dirección y sincronización inicial.

De hecho, uno de los puntos que más le molestan de su flujo actual es precisamente esa necesidad de “syncing”. Según explicó, hoy producen mucho más código y construyen sistemas más complejos, lo que paradójicamente eleva la demanda de pensamiento de alto nivel.

En su diagnóstico, los agentes todavía no son buenos para entender cómo encaja una tarea dentro del panorama amplio del sistema. Pueden enfocarse con fuerza en un problema puntual, pero no captan bien si el resultado se siente correcto en el conjunto.

Kamradt comparó esa conducta con la de caballos a los que se intenta obligar a mirar alrededor. La imagen resume una crítica frecuente en la ingeniería agéntica actual: la capacidad local mejora, pero la comprensión sistémica sigue siendo limitada.

Ese límite es importante para cualquier organización que planee automatizar más desarrollo. Las herramientas pueden reducir carga operativa, acelerar pruebas y mejorar la trazabilidad, pero no sustituyen todavía la labor de decidir prioridades ni la coherencia arquitectónica.

También apareció otra preocupación más mundana, aunque reveladora. Ante la posibilidad de transcripciones sanitizadas, Kamradt admitió que no le sorprendería que algunos usuarios maquillaran resultados, recordando casos previos en los que personas editaron manualmente calificaciones de PR para aparentar una nota mejor.

La anécdota sugiere que la automatización no elimina incentivos humanos dudosos. Incluso en flujos dominados por agentes, siguen existiendo problemas de confianza, reputación y gobernanza del proceso.

Con todo, la presentación dejó una idea nítida. El siguiente salto en herramientas de IA para desarrollo no pasa solo por generar más código, sino por diseñar mecanismos que amplíen el rango de acción de los agentes antes de requerir atención humana.

En ese sentido, OpenClaw funciona como un experimento práctico sobre una pregunta central para la industria. Si los agentes pueden documentar mejor, revisarse entre sí y validar cambios en entornos limpios, el recurso más escaso ya no será la inferencia, sino el criterio de quien decide qué merece ser fusionado.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín