Kodacode 1.3 reúne cuatro modos de trabajo del agente en un único cliente de escritorio

El agente ha escrito el código y modificado una decena de archivos, y entonces empieza el trabajo de siempre: abrir los cambios, revisar cada edición, ejecutar las pruebas y averiguar después por qué la automatización de CI terminó con un texto extraño en lugar de un estado normal. Kodacode 1.3 intenta reunir este proceso fragmentado en un solo lugar. Ahora el agente puede trabajar con aplicaciones a través de su interfaz, abrir páginas en un navegador integrado, mostrar sus propios cambios y ejecutarse en un pipeline con resultados legibles por máquinas.

El valor práctico no reside en añadir otra ventana de chat. Los desarrolladores obtienen un ciclo de trabajo más coherente: asignar una tarea, observar las acciones del agente, revisar el diff y pasar el resultado a la siguiente herramienta. Los equipos de producto pueden crear rápidamente un prototipo interactivo a partir de los componentes del proyecto. Los equipos de automatización obtienen flujos visuales con solicitudes HTTP, herramientas MCP, condiciones y aprobación humana obligatoria.

El agente sale de los límites del editor

El modo Computer Use permite que Kodacode vea la pantalla, encuentre la ventana necesaria, pulse elementos de la interfaz, desplace páginas e introduzca texto. Está disponible en la aplicación de escritorio y en los complementos para IDE cuando se utiliza el modo Agent.

Un ejemplo sencillo: es necesario transferir datos desde un panel interno a una hoja de cálculo, pero el panel no dispone de una API adecuada. El agente puede abrir la aplicación, encontrar el registro, copiar los valores y completar el formulario. Antes, una tarea así habría exigido crear una automatización específica para el navegador o hacerlo todo manualmente.

También se ha incorporado un navegador integrado. Los enlaces se abren dentro del cliente de escritorio, un fragmento seleccionado de una página puede enviarse directamente al agente y, para las comprobaciones, están disponibles la búsqueda, la selección de elementos y las capturas de pantalla. Esto reduce los cambios entre el chat, el navegador y el editor, aunque por sí solo no hace fiables las acciones del agente.

Precisamente aquí es donde la supervisión resulta esencial. Un agente visual puede pulsar el botón equivocado, interpretar mal el estado de la interfaz o seguir trabajando después de que aparezca una ventana inesperada. Por eso, las operaciones de publicación, pago, eliminación de datos o modificación de ajustes no deben delegarse sin confirmación humana.

Los cambios y prototipos aparecen junto a la conversación

El cliente de escritorio incorpora una vista de cambios en dos niveles: para toda la conversación y para un mensaje concreto. Esto ayuda a separar el resultado de una tarea específica de las modificaciones acumuladas. El diff funciona incluso en carpetas sin Git: la propia aplicación registra los cambios del agente.

El espacio de trabajo puede dividirse entre el chat y el visor de archivos. Allí están disponibles el árbol del proyecto, el resaltado de sintaxis y la posibilidad de adjuntar una sección concreta a la siguiente solicitud. En una sesión larga, esto es más útil que una pregunta general como “¿Qué has cambiado?”: el desarrollador puede señalar directamente la línea problemática y pedir que se corrija exactamente esa parte.

Los prototipos interactivos constituyen otro caso de uso. El agente puede montar varias pantallas con los componentes y estilos existentes del proyecto, y el equipo puede comparar las versiones móvil y de escritorio. Esto no sustituye una revisión de diseño, pero acelera la validación de una hipótesis antes de que los desarrolladores empiecen a pulir la implementación.

Flows y la CLI convierten al agente en parte del sistema

Flows es un constructor visual de automatizaciones similar a n8n o Zapier, pero con la posibilidad de que un agente ejecute pasos individuales. Un flujo puede iniciarse manualmente, según una programación, mediante un webhook o desde otro flujo. Incluye ramificaciones, bucles, trabajo con archivos, HTTP, MCP y pausas para aprobación.

Por ejemplo, un proceso matutino puede recopilar noticias, filtrarlas, preparar un borrador y esperar la aprobación de un editor. La palabra clave es “esperar”: la revisión manual forma parte del propio proceso, en lugar de depender de la promesa del equipo de no publicar automáticamente el resultado. Flows todavía está en fase beta, por lo que resulta sensato respaldar los procesos críticos con registros y comprobaciones en un sistema externo.

El modo headless se ha ampliado para CI. La CLI puede recibir un flujo de solicitudes a través de stdin, devolver eventos como JSON delimitado por saltos de línea, informar del consumo de tokens y terminar con un código inequívoco. El código 0 indica éxito; un código distinto de cero indica que la tarea no se completó. Un límite de pasos permite detener una ejecución atrapada en un bucle; al alcanzarlo, se devuelve el motivo de la detención y el código 2.

La conclusión práctica es comenzar probando la CLI con una comprobación segura, por ejemplo, un análisis de cambios sin permiso de escritura. Después, conviene conectar el JSON transmitido en tiempo real con los registros de CI, establecer un límite de pasos y comprobar el tratamiento de todos los códigos de salida. Computer Use y Flows deberían incorporarse más tarde, empezando por operaciones reversibles y exigiendo confirmación antes de cualquier acción externa.