Por qué cambié mis asistentes de terminal por DeepSeek Harness

Hook

En agosto de 2026, mi flujo diario de desarrollo llegó al límite.

Tenía cuatro pestañas de terminal abiertas en paralelo corriendo instancias de asistentes locales en repositorios distintos, viendo la memoria RAM desaparecer gigabyte por gigabyte hasta que la máquina se congelaba por completo a mitad de una refactorización. La lentitud no daba tregua. Cambiar de contexto entre workspaces se volvió un ejercicio de paciencia y monitoreo de procesos en el sistema operativo.

Decidí crear este post para explicar exactamente por qué cambié para empezar a usar DeepSeek Harness, detallando las razones técnicas que me llevaron a adoptar esta herramienta en detrimento de cualquier otra herramienta del mercado. Es una decisión práctica sobre usabilidad, arquitectura modular y control real de recursos.

Tiempo estimado de lectura: 6 min

El contexto

En mi día a día de desarrollo, la rutina giraba alrededor de tres piezas centrales: Claude Code, Pi Coding Agent y OpenRouter para enrutar llamadas a distintos modelos. En teoría, parecía una combinación funcional para cubrir desde decisiones de arquitectura hasta cambios rápidos en el código.

En la práctica, el flujo empezó a pasar factura en cuanto la demanda me exigió paralelismo real entre diferentes frentes de trabajo. Quedarse atado a interfaces de terminal parece limpio a primera vista, pero manejar varios workspaces simultáneos en decenas de pestañas de consola se vuelve una molestia constante. El consumo de memoria simplemente no escala.

Cada sesión activa de Claude Code acumulaba cientos de megabytes de RAM en el sistema operativo; mantener cuatro o cinco instancias abiertas para avanzar en branches paralelas ahogaba la máquina completa en poco tiempo. Demasiado pesado.

Estaba también la rigidez interna de estas plataformas. Aun usando OpenRouter para meter modelos alternativos vía proxies, la estructura de estas herramientas seguía inaccesible, lo que impedía intervenir directo en el ciclo de razonamiento, en los adaptadores de modelo o en las políticas de contención de archivos. Yo necesitaba control operativo directo sobre la infraestructura de ejecución.

Lo que pasó

En agosto de 2026, cuando decidí probar DeepSeek Harness por primera vez, esperaba encontrarme con otro simple envoltorio de terminal con prompts retocados. La realidad técnica fue otra. En la práctica, esta herramienta funciona como un chasis modular: la base es firme y liviana, diseñada para cambiar cualquier pieza sin comprometer la estructura.

Esa flexibilidad viene directo del microkernel Cordis. En los asistentes convencionales, el ciclo de razonamiento del agente y el registro de herramientas forman un monolito cerrado. En Harness no hay núcleo privilegiado. El adaptador del modelo de lenguaje, la política de sandbox, las llamadas al sistema de archivos y el propio bucle de ejecución operan como plugins independientes. Si tengo que alternar entre rutas de Azure, endpoints directos de DeepSeek o el catálogo de OpenRouter, cambio un par de declaraciones en el archivo de configuración y el sistema absorbe los nuevos servicios en caliente, sin recompilar código ni reiniciar el servidor.

El impacto directo se notó en el uso de recursos de la máquina. En mis flujos anteriores, abrir varias instancias paralelas en terminales aisladas acumulaba procesos pesados que se comían la memoria RAM. Con la arquitectura desacoplada de DSH corriendo una interfaz web liviana desde un único proceso en segundo plano, pasé a sostener decenas de tareas activas en paralelo sin registrar caídas en la fluidez. La herramienta me dio la estabilidad operativa que le faltaba a mi entorno de desarrollo.

El punto de quiebre

El quiebre definitivo llegó cuando me topé con un cuello de botella típico de mi día a día: alternar entre branches y varios directorios con una conversación ya en marcha con el agente. En los asistentes de terminal cerrados, cambiar de branch en medio del razonamiento de la IA obligaba a cortar la sesión, tirar comandos manuales de git y cruzar los dedos para no perder el hilo. Si necesitas tres branches abiertas para probar arreglos en paralelo, el flujo se rompe por completo. Hacía falta una forma limpia de levantar git worktrees sin fricción.

Cuando decidí encarar el problema dentro de DeepSeek Harness, la diferencia de arquitectura saltó a la vista. La facilidad para armar una extensión a medida me llamó la atención desde el primer día. Gracias al modelo de eventos y servicios de Cordis, no tuve que recurrir a forks ni a scripts externos improvisados. Intercepté de forma directa el flujo de la pantalla de nueva conversación para meter un disparador nativo. El comportamiento es simple: al elegir una carpeta, el plugin genera la worktree correspondiente de Git y arranca la sesión del agente justo dentro de ese directorio aislado.

Esa experiencia fue la que me hizo tomar la decisión final. Ninguna otra opción ofrecía esta flexibilidad sin pasar factura en consumo de memoria o en costos de mantenimiento. Decidí empaquetar la implementación en el proyecto open source dsh-worktree-jump, consolidando mi cambio a Harness en detrimento de cualquier otra herramienta.

Para quien use la interfaz gráfica y quiera sumar este mismo acceso de worktrees al perfil web, solo tiene que correr:

dsh plugin --profile web add github:frederico-kluser/dsh-worktree-jump

Con el paquete registrado en el manifiesto del perfil, el cargador aplica la extensión en el siguiente inicio, sin pedir compilación manual ni retoques invasivos en el sistema.

Lecciones que aprendí

1. La interfaz no puede dictar los límites del flujo de trabajo. Los asistentes monolíticos de terminal parecen ágiles en la primera terminal abierta, pero se vuelven un ancla cuando necesitas operar diez workspaces paralelos y ves al proceso devorar gigabytes de memoria sin justificación creíble. Me equivoqué al insistir. Mirando hacia atrás, debí abandonar esas CLIs rígidas mucho antes en detrimento de una base liviana y modular. La ganancia real de productividad aparece cuando la herramienta se adapta a tu topología de carpetas, nunca al revés.

2. La extensibilidad real supera la conveniencia de cajas negras listas para usar. Un asistente comercial empaquetado resuelve lo básico el primer día. Pero en cuanto necesitas interceptar un evento de ciclo de vida o conectar un comportamiento puntual como disparar git worktrees bajo demanda, el sistema cerrado frena el avance. Debí priorizar soluciones con microkernel, como Cordis en DeepSeek Harness, desde los primeros experimentos. Contar con plugins de ciclo de vida reversible ahorra semanas de parches manuales.

3. El aislamiento de ejecución y la gestión de permisos exigen una separación quirúrgica. Mezclar la capa de visualización con las reglas de permisos del sistema operativo es un error grave de diseño. Ya no acepto herramientas que aten la ejecución de comandos a interfaces rígidas. Definir políticas de sandbox y aprobación desacopladas del motor central garantiza un control técnico estricto sobre cada llamada, cuidando la estabilidad de la máquina incluso con múltiples procesos simultáneos.

Qué le diría a mi yo del pasado

Deja de aceptar cajas negras.

Muchas veces uno se apega a asistentes con interfaces pulidas solo porque la instalación parecía rápida. El problema es que esas soluciones empaquetadas suelen esconder decisiones de ingeniería bastante ineficientes, desde consumo desmedido de memoria hasta bloqueos artificiales al elegir modelos o herramientas.

La productividad real con agentes depende de poder inspeccionar y moldear tu infraestructura de trabajo en el momento exacto en que la necesitas, sin quedar a merced de la buena voluntad de ningún proveedor.

Le diría que hiciera la migración a DeepSeek Harness mucho antes, adoptando una base modular en detrimento de cualquier CLI cerrada. Mantener el control mediante configuraciones declarativas en settings locales, definiendo rutas claras de API y encajando plugins propios para resolver los cuellos de botella del flujo, compensa cada minuto invertido en el setup. Cuando tienes autonomía sobre el entorno, el flujo de desarrollo simplemente no se rompe.

Reflexión final

DeepSeek Harness se ganó su lugar en mi flujo de trabajo diario porque le devuelve el control práctico de la arquitectura a quien desarrolla. Así de simple. Adoptar esta base modular en detrimento de herramientas cerradas de terminal resolvió de una vez la sobrecarga de memoria RAM y eliminó la fricción de cambiar entre diferentes contextos de trabajo. Cuando la base es liviana y cada componente se puede extender según la exigencia técnica del proyecto, el agente deja de ser un cuello de botella en el sistema y se adapta a cómo organizamos nuestro código.

Quiero saber cómo manejan ustedes múltiples repositorios en paralelo y cómo controlan el consumo de estas herramientas en el día a día. Compartan lo que piensan y sus flujos en el Slack de la comunidad o en los grupos de WhatsApp. Hagan la prueba.