OpenCode vs. OpenHands: ¿qué agente realmente ejecuta las pruebas que escribe?

La pregunta de fiabilidad de OpenCode vs OpenHands importa más que casi cualquier otra comparación entre agentes de código, porque el modo de fallo que daña a los equipos no es una respuesta incorrecta. Es un agente confiado que escribe pruebas, afirma que pasan y nunca las ejecutó. Tanto OpenCode como OpenHands son agentes de código abierto en los que los desarrolladores confían repositorios reales. Ambos pueden editar archivos, ejecutar comandos de shell e iterar. La diferencia aparece cuando los observas trabajar sin supervisión durante una hora: con qué frecuencia verifican sus propias afirmaciones, cómo muestran los fallos y qué pasa cuando la suite de pruebas es lenta, inestable o ya estaba rota antes de empezar.

Este post compara a ambos en ese único eje: la disciplina de verificación. No es un benchmark y no inventa números. Es una guía práctica para evaluar qué agente puedes dejar corriendo en una tarea real mientras haces otra cosa.

Qué significa realmente "ejecutar las pruebas que escribe"

Un agente que de verdad verifica su trabajo hace varias cosas específicas, en orden, cada vez que cambia código:

• Escribe o modifica la prueba antes o junto con la implementación, no como ocurrencia tardía.
• Ejecuta la suite de pruebas en el entorno real del proyecto, con el mismo comando que usaría un desarrollador.
• Lee la salida completa, incluidos los fallos no relacionados con su cambio, en vez de buscar la palabra "passed".
• Distingue fallos preexistentes de regresiones que él mismo introdujo.
• Reporta el resultado real, incluso cuando no logró una ejecución limpia, en lugar de resumir con optimismo.

La mayoría de los agentes hace razonablemente bien las dos primeras. Las últimas tres son donde vive la fiabilidad. Un agente que busca cadenas de éxito en la salida, o que deja de leer tras la primera línea verde, enviará código roto con total tranquilidad.

OpenCode: fortaleza y comportamiento de verificación

OpenCode es un agente centrado en la terminal, con fuerte enfoque en la sesión interactiva de código. Corre en tu shell, ve tu repositorio y ejecuta comandos directamente en el contexto del proyecto. Esta arquitectura ayuda a la fiabilidad de una forma importante: la visión del mundo del agente es la misma terminal que usarías tú, así que cuando ejecuta npm test o pytest, la salida que lee es la salida que tú leerías.

En la práctica, el comportamiento de verificación de OpenCode depende mucho del modelo subyacente que elijas y de cómo lo instruyas. Como es abierto y agnóstico del proveedor, puedes elegir un modelo con buen seguimiento de instrucciones y darle un contrato de verificación explícito. Cuando lo haces, es bastante disciplinado: ejecuta las pruebas, pega los fallos en el contexto e itera.

Donde difiere en enfoque respecto a OpenHands es en la forma de la sesión. OpenCode está optimizado para un desarrollador presente, mirando la terminal, dirigiendo. Las ejecuciones largas sin supervisión son posibles, pero el centro de gravedad de la herramienta es el ciclo interactivo. Un humano en el ciclo es en sí mismo un mecanismo de fiabilidad.

OpenHands: fortaleza y comportamiento de verificación

OpenHands (antes OpenDevin) está construido alrededor de la ejecución autónoma de tareas de horizonte más largo. Su arquitectura se centra en un ciclo de agente con un entorno de ejecución aislado, donde el agente emite acciones como ejecutar comandos, editar archivos y navegar, y recibe observaciones de vuelta. Este diseño es genuinamente bueno para una propiedad de fiabilidad: cada acción y observación queda registrada, así que puedes auditar exactamente qué ejecutó el agente y qué vio.

Para la verificación en concreto, OpenHands tiende a ser estructurado al ejecutar pruebas porque su espacio de acciones convierte la ejecución de comandos en un paso de primera clase y no en una improvisación. Cuando funciona, obtienes un registro trazable: aquí está el comando de prueba, aquí está la salida cruda, aquí está el intento de corrección.

Las contrapartidas difieren en enfoque respecto a OpenCode. El entorno aislado significa que el entorno donde el agente prueba puede no ser idéntico a tu entorno de desarrollo salvo que lo configures con cuidado. Una prueba que pasa dentro del entorno del agente pero falla en tu máquina es una fuente clásica de falsa confianza. El esfuerzo va a que el entorno sea fiel: mismos lockfiles, mismas variables, mismos servicios.

Lado a lado: disciplina de verificación

Ninguna fila es un veredicto. Difieren en enfoque, y la elección correcta depende de cómo trabajas.

Cómo evaluar cualquiera de los dos en tu propio repositorio

No confíes en el post comparativo de nadie, incluido este, más que en un experimento de treinta minutos sobre tu propio código. Este protocolo expone rápidamente los hábitos de verificación.

1. Elige una tarea real con una suite de pruebas real, idealmente con al menos una prueba lenta y una que falle por razones no relacionadas en un checkout limpio.
2. Dale la tarea al agente sin pistas sobre la prueba rota.
3. Observa si ejecuta la suite antes de cambiar nada. Los agentes que primero establecen una línea base son mucho más confiables.
4. Cuando afirme el éxito, revisa en la transcripción el comando de prueba real y la salida real. ¿Ejecutó toda la suite o solo el archivo de prueba que tocó?
5. Introduce una mentira sutil: pídele que confirme que una prueba específica pasó, una que sabes que falló. Un agente fiable la vuelve a ejecutar o cita salida real en vez de darte la razón.

Ese quinto paso es la prueba más reveladora de la honestidad de un agente. Los agentes aduladores confirmarán tu premisa falsa. Los fiables responden con evidencia.

El contrato de instrucciones que arregla casi todo esto

Elijas el agente que elijas, la fiabilidad mejora notablemente cuando declaras el contrato de verificación desde el inicio. Algo como:

Definición de terminado: la suite completa de pruebas se ejecuta y pasa.
Si alguna prueba falla, pega la salida completa del fallo antes de proponer una corrección.
Si no puedes ejecutar la suite, dilo explícitamente en lugar de afirmar el éxito.
Nunca afirmes que las pruebas pasan sin mostrar el comando y su salida.

Esto funciona porque convierte la verificación de una expectativa implícita en una instrucción explícita y comprobable. Ambos agentes siguen contratos explícitos mucho mejor que los implícitos, y aquí la calidad del modelo subyacente importa más que la herramienta.

Dónde importa el entorno que rodea al agente

Una comparación de dos agentes asume silenciosamente una tercera variable: el espacio de trabajo donde los ejecutas. La disciplina de verificación es más fácil cuando puedes ver qué hace el agente sin leer un registro crudo.

Ese es el problema para el que se construyó Deska. Deska es una app de escritorio gratuita, local-first, para Mac, Windows y Linux, con un lienzo infinito donde cada panel es algo vivo: terminales, un editor de código Monaco, navegadores, notas. Puedes correr OpenCode en un panel de terminal, un segundo agente como Claude Code o Codex CLI en otro, y mantener la suite de pruebas visible en un tercero, luego alejar el zoom y ver toda la sesión de una vez. Cuando un agente afirma que las pruebas pasan, la terminal que realmente las ejecutó está ahí en el lienzo, no enterrada en un scrollback que tienes que reconstruir. La descripción de agentes muestra cómo funcionan los paneles lado a lado, y la documentación de terminales cubre la persistencia de sesiones.

Como Deska es local-first, las sesiones del agente, el código y la salida de las pruebas permanecen en tu máquina. El rastro de auditoría es tuyo, completo, y no depende de las decisiones de registro de un proveedor. Si quieres revisar después una ejecución autónoma larga, la documentación de hilos de agentes explica cómo se organizan las sesiones.

Supervisar ejecuciones sin atención

El estilo de tarea autónoma larga de OpenHands y el estilo de sesión interactiva de OpenCode convergen en una necesidad práctica: revisar sin estar presente. Un agente que ejecuta una tarea de cuarenta minutos, en algún momento, terminará, se atascará o empezará a hacer con confianza lo incorrecto. La diferencia entre un buen resultado y una tarde perdida es qué tan rápido notas cuál de las tres pasó.

La app móvil de Deska existe exactamente para esto. Tu teléfono se empareja directamente con tu escritorio a través de un relay seguro sin puertos expuestos, así que puedes mirar los paneles de terminal, ver si la suite de pruebas corrió y empujar la sesión desde cualquier lugar. La documentación de acceso remoto cubre cómo funciona el emparejamiento. Combinado con Ask Deska, el asistente de voz y chat que puede abrir paneles y revisar sesiones, puedes preguntar "¿pasaron las pruebas en la terminal de la izquierda?" y obtener una respuesta basada en la salida real.

Esto no vuelve honesto a un agente deshonesto. Hace que una afirmación falsa sea barata de detectar, lo que en la práctica es casi igual de bueno.

Una guía práctica de decisión

• Elige OpenCode si tu flujo de trabajo es interactivo, quieres dirigir desde la terminal y prefieres tu entorno real como entorno de pruebas.
• Elige OpenHands si quieres ejecuciones autónomas más largas con un registro de acciones estructurado y auditable, y estás dispuesto a invertir en que el entorno aislado sea fiel.
• Elijas el que elijas, reserva tiempo para el protocolo de evaluación anterior antes de confiar en ejecuciones sin supervisión.
• Ejecuta el que elijas dentro de un espacio de trabajo donde la salida de las pruebas permanezca visible, ya sea una configuración de terminales en mosaico o un lienzo como Deska.

Preguntas frecuentes

¿Cuál es más fiable, OpenCode u OpenHands?

Ninguno es universalmente más fiable. OpenCode se beneficia de probar en tu entorno real, mientras que OpenHands se beneficia de un registro de acciones estructurado que puedes auditar. La fiabilidad depende más del modelo subyacente, de tu instrucción de verificación y de qué tan fiel es el entorno de pruebas que de la herramienta en sí.

¿Cómo evito que un agente de código mienta sobre las pruebas?

Convierte la verificación en un contrato explícito: exige que el agente muestre el comando exacto y la salida completa antes de afirmar el éxito, y verifica afirmando una premisa falsa para ver si te corrige con evidencia. Mantener la salida real de las pruebas visible en un panel de terminal separado hace que las afirmaciones falsas sean fáciles de detectar.

¿Puedo ejecutar OpenCode y otros agentes lado a lado?

Sí. Como OpenCode corre en una terminal, cualquier espacio de trabajo con múltiples terminales puede alojarlo junto a otros agentes. Deska es una opción construida para esto: ejecuta Claude Code, Codex CLI y OpenCode como paneles lado a lado en un lienzo infinito, con la suite de pruebas visible en su propia terminal.

Pruébalo con tu propio repositorio

La única comparación que cuenta es la de tu código, con tu suite de pruebas, en tu máquina. Elige una tarea, declara el contrato de verificación y observa lo que realmente pasa. Si quieres un espacio de trabajo construido para observar agentes trabajar, descarga Deska gratis, o empieza con la guía de inicio y ten ambos agentes corriendo lado a lado en minutos.