Open Code Desktop App: La herramienta de programación con IA a la que me cambié
Tengo un problema. No dejo de instalar herramientas de programación con IA. Claude Code, Cursor, Codeex, Gemini CLI — en un momento tenía cinco asistentes de IA diferentes peleando por espacio en mi flujo de trabajo, cada uno atado a su propio proveedor de modelos, cada uno exigiéndome que me comprometiera con su ecosistema antes de mostrarme lo que realmente podía hacer.
Así que cuando Open Code lanzó una aplicación de escritorio la semana pasada — construida en Rust, de código abierto, conectada a más de setenta y cinco modelos de cualquier proveedor — casi no la probé. Otra herramienta. Otra configuración. Otros treinta minutos que nunca recuperaría.
La instalé de todos modos. Y ahora estoy escribiendo este artículo porque pasó algo que no había pasado con ninguna de las otras herramientas: dejé de buscar las alternativas.
No porque Open Code sea la mejor en algo específico. No lo es. Sino porque resolvió una frustración que no me había dado cuenta del todo que tenía hasta que desapareció. La frustración de estar atado a un modelo, un proveedor, una forma de trabajar — y tener que cambiar de aplicación completa cuando ese modelo no era el adecuado para la tarea que tenía enfrente.
Déjame guiarte por lo que la aplicación de escritorio realmente hace, dónde genuinamente brilla, dónde todavía tiene asperezas, y por qué creo que el enfoque agnóstico de modelos importa más de lo que la mayoría de los desarrolladores se dan cuenta ahora mismo.
Qué es realmente Open Code (para quienes no han oído de él)
Open Code empezó como una herramienta CLI — un agente de programación con IA basado en terminal que te permite escribir, refactorizar y depurar código con asistencia de IA directamente desde tu línea de comandos. Piensa en él como el primo de código abierto de Claude Code. Mismo concepto general: describes lo que quieres, la IA lee tu código fuente, escribe o modifica archivos, y tú revisas los cambios.
El diferenciador clave desde el primer día fue la flexibilidad de proveedores. Mientras que Claude Code requiere la API de Anthropic y Gemini CLI requiere la de Google, Open Code se conecta a lo que tú quieras. Claude, GPT-4o, Gemini, Mistral, DeepSeek, Llama — si hay un endpoint de API o una instancia de Ollama corriendo localmente, Open Code puede comunicarse con él.
La nueva aplicación de escritorio envuelve esa base CLI en una interfaz gráfica completa. Construida con Rust y el framework Tauri, lo que significa que es rápida y ligera — nada de la pesadez de Electron que hace que algunas aplicaciones de escritorio se sientan como si estuvieran corriendo dentro de tres capas de navegador.
Pero llamarla un "envoltorio GUI" subestima lo que construyeron. La aplicación de escritorio añade capacidades que la CLI nunca tuvo: múltiples sesiones corriendo en paralelo, gestión de espacios de trabajo para manejar varios proyectos, un visor de diferencias limpio con comentarios en línea, pestañas de terminal integradas, y transferencia con un clic a editores externos como VS Code o Cursor.
La decisión arquitectónica de usar Rust y Tauri vale la pena mencionarla si te importa el rendimiento. Cada interacción se siente ágil. Escaneo de archivos, cambio de modelo, renderizado de diferencias — no hay retraso perceptible en nada. Viniendo de herramientas basadas en Electron donde escribir a veces se siente como avanzar a través de miel, la capacidad de respuesta se nota de inmediato.
Así es como se ve la aplicación en la práctica. Abres un proyecto, seleccionas tu modelo (más sobre esto en un momento), e inicias una conversación. Puedes planificar primero — describiendo lo que quieres construir y dejando que la IA haga preguntas de clarificación — luego cambias al modo de construcción donde realmente escribe archivos. Cada cambio aparece en una vista de diferencias donde puedes comentar en línea, aceptar o rechazar cambios individuales, y ejecutar el resultado en una terminal integrada sin salir nunca de la aplicación.
Ese flujo de trabajo suena sencillo en el papel. La prueba real es si se mantiene cuando estás construyendo algo real. Lo probé en dos proyectos durante la última semana, y los resultados me dijeron más que cualquier lista de características.
Prueba uno: Construyendo una aplicación de análisis de datos desde cero
Mi primera prueba fue deliberada. Quería ver cómo Open Code manejaba un proyecto desde cero — sin código existente, sin contexto, solo un directorio vacío y una descripción.
La tarea: construir una aplicación web que permita a los usuarios subir archivos CSV, procese los datos, extraiga insights y genere visualizaciones interactivas. No trivial, pero tampoco de nivel empresarial. El tipo de cosa que un desarrollador podría prototipar en una tarde.
Empecé en modo planificación con Claude Sonnet 4.6 conectado a través de mi clave API de Anthropic. La IA hizo preguntas de clarificación inteligentes de inmediato — stack tecnológico preferido, preferencia de librería de gráficos, cómo quería que se manejara el parsing de CSV (del lado del cliente o del servidor). Ese comportamiento de hacer preguntas varía según el modelo, tema al que volveré, pero con Sonnet se sintió como programar en pareja con un colega reflexivo.
El modo planificación produjo un documento de alcance claro: estructura de archivos, decisiones tecnológicas (HTML/JS vanilla para velocidad, Chart.js para visualizaciones, Papa Parse para manejo de CSV), y un orden de implementación paso a paso. Suficientemente bueno. Hora de construir.
Aquí es donde encontré mi primer punto de fricción de la era beta. La aplicación no hizo la transición automáticamente del modo planificación al modo construcción. Tuve que cambiar manualmente. Un inconveniente menor, pero rompe el flujo cuando esperas que la IA diga "ok, déjame empezar a programar" y en cambio sigue planificando. Esta es una limitación conocida — el equipo está trabajando en ello — pero vale la pena mencionarla porque herramientas competidoras como Claude Code manejan esta transición sin problemas.
Una vez en modo construcción, la IA generó archivos rápidamente. Esqueleto HTML, módulos JavaScript para parsing de CSV y renderizado de gráficos, CSS para un diseño limpio. Cada archivo apareció en el visor de archivos de la aplicación con resaltado de sintaxis completo, y la vista de diferencias mostraba exactamente lo que se estaba creando.
El resultado: una aplicación web funcional que manejaba subidas de CSV, mostraba resúmenes de datos (conteo de filas, tipos de columnas, estadísticas básicas) y generaba cuatro tipos de gráficos — barras, líneas, circular y histograma. Todo desde una conversación que tomó unos doce minutos.
¿Era lista para producción? No. El manejo de errores era mínimo, la interfaz era funcional pero no pulida, y no había validación de entrada que valiera la pena mencionar. ¿Pero como prototipo funcional sobre el que podía iterar? Sólido. He visto a desarrolladores junior tardar más en producir menos.
Sí encontré un bug de interfaz — la lista de tareas que la IA generó para rastrear sus propias tareas se renderizó dos veces, superponiéndose en la barra lateral. Software beta siendo software beta. La funcionalidad no se vio afectada, solo la visualización. Lo menciono porque si estás evaluando la herramienta ahora mismo, espera este tipo de asperezas. Se está corrigiendo activamente, pero existe hoy.
La observación más interesante: podría haber cambiado de modelo a mitad del proyecto. Empezar la planificación con Claude, cambiar a GPT-4o para la implementación, luego usar un modelo local Llama para preguntas rápidas de refactorización que no justificaban costos de API. Ninguna otra herramienta de programación de escritorio que haya usado me deja hacer eso en una sola sesión. Esa flexibilidad resultó importar más en mi segunda prueba.
Prueba dos: Añadiendo funcionalidades a un proyecto existente de Next.js
La prueba real de cualquier herramienta de programación con IA no es el trabajo desde cero — es navegar un código existente con patrones establecidos, dependencias y restricciones.
Abrí uno de mis proyectos activos: un rastreador de finanzas personales construido con Next.js, Tailwind CSS, Drizzle ORM y SQLite. El código tiene unos cuarenta archivos distribuidos en doce directorios, con patrones establecidos para ruteo, acceso a datos y estructura de componentes.
La tarea: construir una página de metas con funcionalidad CRUD completa — crear, leer, actualizar y eliminar metas financieras, con un rastreador de progreso que muestre los ahorros hacia cada meta.
Para esta prueba, elegí deliberadamente un modelo diferente. Me conecté a Kimi K2.5, en parte porque quería probar una opción gratuita y en parte porque quería ver qué tan bien funciona en la práctica el cambio de modelos de Open Code.
Cambiar de modelo tomó unos diez segundos. Abrir la configuración, seleccionar el proveedor, elegir el modelo, listo. Sin reconfiguración, sin reinicio, sin perder el contexto de mi proyecto. La sesión continuó con el nuevo modelo como si nada hubiera cambiado. Esa fluidez es algo que no aprecié hasta que la experimenté — antes, cambiar de modelo significaba cambiar de herramienta completamente.
Kimi K2.5 manejó la tarea de forma diferente a como lo habría hecho Claude. Pasó más tiempo escaneando archivos existentes antes de proponer cambios — leyendo la estructura de rutas, el esquema de base de datos existente, los patrones de componentes que yo había establecido. Luego generó una lista de tareas con los pasos de implementación y empezó a trabajar en ellos.
La IA creó una nueva tabla de metas en el esquema de base de datos, añadió rutas de API siguiendo el patrón existente, construyó un componente React para la página de metas con un formulario para crear/editar metas y una visualización de progreso, y conectó todo con la navegación existente.
Vi esto suceder a través de la vista de diferencias de Open Code, que mostraba cada modificación de archivo con resaltado estilo Git. Líneas verdes para adiciones, rojas para eliminaciones, y — esta es la funcionalidad que me convenció — burbujas de comentarios en línea donde podía hacer preguntas o solicitar cambios en secciones específicas sin interrumpir el flujo general.
"¿Por qué usaste useState aquí en lugar del patrón useReducer que uso en la página de transacciones?" escribí en un comentario en línea en el componente de metas. La IA leyó el comentario, revisó el código de la página de transacciones, y refactorizó para coincidir con mi patrón existente. Esa interacción — dirigida, contextual, no disruptiva — se sintió más natural que cualquier revisión de código basada en chat que haya hecho con otras herramientas.
Mientras Kimi K2.5 trabajaba en la aplicación de finanzas, cambié a mi otra sesión — el proyecto de análisis de datos — y seguí iterando. Dos proyectos, dos modelos de IA diferentes, corriendo en sesiones paralelas dentro de la misma aplicación. Cada sesión mantenía su propio contexto, su propio historial de conversación, su propio estado de archivos.
Aquí es donde la función de sesiones múltiples deja de ser un punto en una lista y se convierte en una ventaja real de flujo de trabajo. Yo programo en tres o cuatro proyectos en cualquier semana dada. Tener todos accesibles en una sola aplicación, cada uno con su propio contexto de IA y potencialmente su propia elección de modelo, elimina el cambio constante de herramientas que fragmenta mi atención.
La página de metas funcionó en la primera prueba. No perfectamente — faltaba el diálogo de confirmación de eliminación, y la barra de progreso tenía un problema de desbordamiento CSS — pero funcionalmente completa. Dos comentarios en línea y unos noventa segundos de refinamiento por IA después, ambos problemas estaban resueltos.
Tiempo total desde abrir el proyecto hasta una página de metas funcional y probada: unos veintidós minutos. Con un modelo gratuito. En un código que la IA nunca había visto antes.
Eso no es un milagro. Un buen desarrollador que conoce el código podría hacerlo más rápido. Pero un buen desarrollador que conoce el código soy yo, y prefiero pasar esos veintidós minutos en decisiones de arquitectura mientras la IA se encarga del scaffolding de implementación.
La ventaja de ser agnóstico de modelos (y por qué importa más de lo que crees)
Déjame argumentar por qué la flexibilidad de proveedores de Open Code no es solo una característica agradable — es una ventaja arquitectónica fundamental que importará más en los próximos doce meses, no menos.
Ahora mismo, el panorama de modelos de IA cambia cada pocas semanas. Un nuevo modelo aparece, los benchmarks cambian, los precios se modifican, los límites de uso se ajustan, las capacidades evolucionan. Si tu herramienta de programación está atada a un proveedor, estás atado al ritmo de mejora y las decisiones de precios de ese proveedor.
He experimentado esto directamente. Claude es mi modelo preferido para razonamiento arquitectónico complejo y revisión de código con matices. Pero para generación directa de código repetitivo — endpoints CRUD, scaffolding de componentes, creación de archivos de prueba — GPT-4o es más rápido y más barato. Para preguntas rápidas mientras depuro, un modelo local Llama corriendo a través de Ollama no cuesta literalmente nada y responde en milisegundos sin latencia de red.
Antes de Open Code, usar el modelo correcto para la tarea correcta significaba cambiar entre tres aplicaciones diferentes. Ahora significa hacer clic en un menú desplegable.
Las cuentas salen más rápido de lo que esperarías. Mi gasto en API bajó aproximadamente un 40% en la primera semana usando Open Code, no porque programara menos sino porque enrutaba tareas simples a modelos más baratos (o gratuitos) en lugar de gastar tokens premium de Claude en trabajo que no necesitaba ese nivel de razonamiento.
Aquí va un desglose aproximado de cómo ahora distribuyo el uso de modelos:
Arquitectura compleja y refactorización — Claude Sonnet u Opus. La profundidad de razonamiento justifica el costo. Tal vez un 25% de mis interacciones de programación con IA.
Tareas de implementación estándar — GPT-4o o Gemini. Rápidos, capaces, más baratos por token. Aproximadamente el 45% de las interacciones.
Preguntas rápidas, consultas de sintaxis, refactorizaciones simples — Llama 3 local vía Ollama. Gratis, instantáneo, privado. Aproximadamente el 30% de las interacciones.
Esa distribución solo es posible con una herramienta agnóstica de modelos. Y a medida que el panorama de modelos sigue fragmentándose — nuevos proveedores, nuevos niveles de precios, modelos especializados para diferentes tareas — el valor de la flexibilidad solo aumentará.
También hay un ángulo de privacidad aquí. Ejecutar un modelo local a través de Ollama significa que tu código nunca sale de tu máquina. Para proyectos de clientes con requisitos estrictos de confidencialidad, o para códigos propietarios donde enviar código a una API en la nube resulta incómodo, el soporte de modelos locales no es una característica — es un requisito. Open Code lo maneja de forma nativa. La mayoría de los competidores ni siquiera reconocen el caso de uso.
Lo que todavía falta (y no es poco)
He sido genuinamente positivo hasta ahora, así que déjame ser igualmente genuino sobre las carencias. La aplicación de escritorio de Open Code está en beta, y se nota de formas específicas y prácticas.
Sin integración de Git incorporada. Esta es la pieza más grande que falta. No puedes hacer commit, push, pull, ni gestionar ramas desde dentro de la aplicación. Cada operación de Git requiere cambiar a la terminal integrada o a una herramienta externa. Claude Code maneja operaciones de Git de forma nativa — dices "haz commit de estos cambios" y lo hace. Open Code te hace escribir git add . && git commit -m "message" tú mismo.
Para una herramienta diseñada en torno a la productividad del desarrollador, la ausencia de integración con Git se siente como una pared faltante en una casa por lo demás bien construida. Puedes solucionarlo. Pero no deberías tener que hacerlo.
Sin cambio automático de modo. Mencioné esto antes, pero vale la pena repetirlo. La aplicación tiene un modo de planificación y un modo de construcción, y la IA no puede hacer la transición entre ellos de forma autónoma. Tienes que cambiar manualmente. En la práctica, esto significa que ocasionalmente te encontrarás en una conversación donde la IA ha terminado de planificar y claramente está lista para programar, pero sigue generando texto relacionado con la planificación porque no puede hacer el cambio por sí misma.
Es una fricción pequeña, pero ocurre en el momento exacto donde el impulso más importa — la transición de "sé qué construir" a "déjame construirlo." Romper ese impulso con un cambio manual de modo se siente como reducir la marcha en la autopista.
Sin pipelines de automatización. Codeex, uno de los competidores de Open Code, soporta flujos de trabajo automatizados — ejecutar pruebas después de generar código, hacer lint automáticamente, disparar builds. Open Code no tiene nada de eso. Cada paso posterior a la generación es manual.
Bugs de interfaz de calidad beta. Elementos duplicados, fallos de renderizado ocasionales en la vista de diferencias, y una instancia donde el árbol de archivos de una sesión no se actualizó después de que la IA creara nuevos archivos (se arregló cambiando de sesión y volviendo). Nada que destruya datos. Pero suficiente para recordarte que esto es software pre-lanzamiento.
Lagunas en la documentación. La aplicación avanza más rápido que la documentación. Algunas opciones de configuración aún no están documentadas, y el proceso de configuración para ciertos proveedores de modelos implica adivinanzas o búsquedas en foros de la comunidad. Esto mejorará, pero ahora mismo, espera algo de resolución de problemas por tu cuenta.
Enumero estas cosas no para desanimarte sino porque cada otra reseña que he visto o ignora las limitaciones o las entierra en una nota al pie. Si vas a probar esta herramienta — y creo que deberías — mereces saber en qué te estás metiendo.
Cómo se compara con lo que uso a diario
Uso Claude Code todos los días. Está profundamente integrado en mi flujo de trabajo, maneja operaciones de Git, entiende refactorizaciones complejas de múltiples archivos y produce código consistentemente de alta calidad. Después de probar Open Code durante una semana, ¿me cambio? Déjame ser específico con la comparación.
Donde gana Claude Code: integración con Git, transiciones automáticas de modo, razonamiento más profundo en problemas arquitectónicos complejos, interfaz más pulida y estable, mejor recuperación de errores cuando algo sale mal a mitad de generación.
Donde gana Open Code: flexibilidad de modelos (por mucho), múltiples sesiones simultáneas, menor consumo de recursos, comentarios en línea en las diferencias, la capacidad de usar modelos gratuitos o locales para trabajo que no justifica costos de API, y transparencia de código abierto.
Donde están aproximadamente iguales: calidad de código para tareas de implementación estándar, comprensión del código fuente, velocidad de generación de archivos, y la sensación general de "programación en pareja" de la interacción.
Mi recomendación honesta: si trabajas exclusivamente con los modelos de Anthropic y valoras la estabilidad y la integración profunda, Claude Code sigue siendo la mejor opción diaria. Si trabajas con múltiples modelos, te importa la optimización de costos, manejas múltiples proyectos simultáneamente, o quieres la flexibilidad del código abierto, Open Code merece una evaluación seria.
Actualmente estoy usando ambos. Claude Code para mis proyectos más complejos y tareas que requieren cadenas de razonamiento profundas. Open Code para todo lo demás — que, resulta ser, es mucho de todo lo demás. Aproximadamente el 60% de mis interacciones de programación con IA durante la última semana ocurrieron en Open Code, principalmente porque la flexibilidad de modelos y las sesiones paralelas lo hacen más adecuado para la realidad variada y multi-proyecto de mis días de trabajo.
Lo que esto señala sobre las herramientas de programación con IA en general
Aléjate de las características específicas por un momento. La aplicación de escritorio de Open Code representa algo más amplio que está pasando en el espacio de herramientas de programación con IA al que creo que la mayoría de los desarrolladores no le están prestando suficiente atención.
La primera ola de herramientas de programación con IA fue propietaria. Cada herramienta atada a un proveedor, un modelo, un ecosistema. Eso tenía sentido cuando solo había dos o tres modelos que valía la pena usar. Ya no tiene sentido.
Estamos entrando en una fase donde el modelo que quieres usar depende de la tarea, el presupuesto, los requisitos de privacidad, y qué modelo resulta ser el más fuerte este mes. Una herramienta que te ata a un modelo es una herramienta que cada vez más se sentirá como una restricción en lugar de un habilitador.
Open Code no es el único proyecto moviéndose en esta dirección, pero es una de las implementaciones más pulidas de la filosofía agnóstica de modelos. Y el hecho de que sea de código abierto significa que el ritmo de desarrollo lo impulsa la comunidad de desarrolladores que realmente lo usan, no la hoja de ruta de producto de una empresa.
He contribuido con dos reportes de bugs en la última semana. Ambos recibieron respuestas dentro de veinticuatro horas. Uno ya está parcheado en la última build. Intenta obtener ese tiempo de respuesta del equipo de soporte de una herramienta propietaria.
La aplicación de escritorio es software beta. Tiene asperezas. Le faltan funcionalidades que los competidores tienen desde hace meses. Y a pesar de todo eso, la estoy usando más de lo que esperaba, para más tareas de las que predije, con mejores resultados de los que asumí.
Esa trayectoria — áspera pero valiosa desde el día uno, mejorando visiblemente cada semana — es exactamente lo que me convenció de adoptar Claude Code tempranamente, cuando era mucho menos pulido de lo que es ahora. Estoy viendo el mismo patrón con Open Code.
La herramienta no está terminada. Pero la base es correcta. Y en el espacio de herramientas de IA ahora mismo, acertar con la base importa más que acertar con el pulido. El pulido siempre llega. Las decisiones arquitectónicas son mucho más difíciles de cambiar.
Si has estado esperando una herramienta de programación con IA agnóstica de modelos que no requiera vivir en la terminal, la espera terminó. Tiene asperezas. Se colgará ocasionalmente. La integración con Git te molestará.
Y la seguirás abriendo de todos modos. Porque una vez que experimentas la libertad de elegir el modelo correcto para cada tarea en lugar del modelo correcto para cada herramienta — esa libertad es difícil de devolver.
¿Qué construirías si tu asistente de programación pudiera usar cualquier modelo de IA que exista? Esa ya no es una pregunta hipotética. Es una opción de configuración.
Let's Work Together
Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.
- Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise solutions): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (security services): xcybersecurity.io
