Es martes a la mañana y abres un correo de la herramienta de IA para programar que tu equipo adoptó el año pasado. Tu plan cambia. El uso que tu equipo hace cada semana ahora cuesta mucho más, o choca con el límite el miércoles, o las nuevas condiciones de datos ya no cubren el código de tu cliente como asumía tu contrato.
Sacas la cuenta de lo que costaría cambiarte y el resultado duele. No porque la herramienta en sí sea difícil de reemplazar, sino por todo lo que construiste a su alrededor: los comandos personalizados, los archivos de reglas, el paso de revisión en CI, el doc de onboarding que les explica a quienes llegan cómo escribirle prompts. Todo eso habla el dialecto de un solo proveedor.
En ese momento muchos equipos se dan cuenta de que elegir una herramienta de IA para programar dejó de ser una decisión de productividad hace rato. Ahora es una decisión de riesgo.
Tu herramienta de IA ya es infraestructura
Hace uno o dos años, un asistente de IA era algo que alguien del equipo probaba en una rama aparte. Si desaparecía, perdías un poco de autocompletado.
Hoy hace trabajo de verdad. Escribe los primeros borradores de las migraciones, genera tests, revisa pull requests y responde preguntas sobre el codebase que antes le llegaban a la única persona que recuerda por qué existe ese módulo. Tu equipo armó sus hábitos a su alrededor.
Algo de lo que tu equipo depende tanto merece las preguntas que le harías a una base de datos o a un proveedor de nube. ¿Qué pasa si el precio se duplica? ¿Qué pasa si cambian las condiciones? ¿Cuánto tardarías en reemplazarlo?
Para la mayoría de las herramientas cerradas, la respuesta a esa última es “más de lo que nos gustaría”.
Lo que realmente te ata
Cambiar de herramienta es lo fácil: instalar otra te lleva una tarde. Lo difícil es todo lo que queda atado a ella, y eso está en tres lugares:
- El modelo. Muchas herramientas cerradas están atadas a los modelos de un solo proveedor, o pasan por su propio backend. Cuando ese proveedor cambia precios, límites o calidad, el cambio te llega, lo quieras o no.
- Las condiciones. Las políticas de retención de datos y de entrenamiento pueden cambiar con un plan nuevo o un dueño nuevo. Si trabajas con código que no es tuyo, como el de un cliente, eso no es una nota al pie.
- Tus artefactos de trabajo. Las bibliotecas de prompts, las reglas del proyecto, los agentes personalizados y las integraciones suelen vivir en un formato que solo esa herramienta lee. Ahí se esconde la mayor parte del costo de cambiarte.
Ojo, el proveedor no es el villano de esta historia. Los precios cambian porque correr modelos es caro y los modelos de negocio todavía no terminan de asentarse. Pero eso no quita que la forma de trabajar de tu equipo dependa de decisiones en las que no tienes voto.
Lo que cambia un agente abierto e independiente del modelo
Ahí entran herramientas como OpenCode. OpenCode es un agente de programación de código abierto que corre en tu terminal y funciona con muchos proveedores de modelos, incluidos los que alojas tú mismo.
No promete ser más pulido que las herramientas cerradas. Promete que el stack lo controlas tú. En la práctica, eso te da algunas opciones concretas que antes no tenías:
- Cambia el modelo sin cambiar la herramienta. Si un proveedor sube los precios o sale un modelo mejor en otro lado, cambias una línea de configuración. Tus comandos y tus hábitos quedan donde estaban.
- Mantén el código sensible en casa. Para un repo que no puede salir de tu red, puedes apuntar el agente a un modelo propio y seguir con el mismo flujo de trabajo.
- Lee el código. Cuando el agente tiene acceso a la shell de tu máquina, poder ver exactamente qué hace es una ventaja de seguridad real.
- Haz un fork si el proyecto toma un rumbo que no te gusta. Los proyectos de código abierto también cambian de rumbo. La diferencia es que la última versión buena sigue a tu alcance.
Tu costo de salida baja mucho, y eso limita cuánto daño te puede hacer el próximo correo de un proveedor.
Lo que te cuesta esa libertad
Si lo estás evaluando para tu equipo, conviene que sepas en qué te metes.
Más configuración. Tú eliges el modelo, administras las API keys, armas la configuración y decides cómo encaja con tus políticas de seguridad. Una herramienta cerrada toma la mayoría de esas decisiones por ti.
Menos pulido. Un onboarding cuidado, una experiencia fluida en el IDE y una interfaz consistente son justo donde las herramientas comerciales ponen su dinero. Prepárate para más momentos de “qué raro” y más visitas al issue tracker.
Sin línea de soporte. Cuando algo se rompe, tienes la documentación, una comunidad y el código fuente. Para algunos equipos, alcanza. Para otros, significa que la persona que lo puso en marcha se convierte en la línea de soporte.
Los modelos los sigues pagando. Que sea independiente del modelo no significa que sea gratis. Cambias una factura por otra, y ahora comparar proveedores es tarea tuya.
También vas a notar que el mismo agente se siente muy distinto según el modelo, y eso es información útil, pero también más trabajo.
Es fricción de verdad, y no se va en una semana.
Cuándo vale la pena pagarlo
El trade-off tiene más sentido cuando alguna de estas cosas es cierta en tu caso:
- Ya te quemaste con un cambio sorpresa de precios o de políticas, y recuerdas cuánto duró el apuro.
- Trabajas con código bajo reglas de datos estrictas: repos de clientes, industrias reguladas, cualquier cosa que no deba salir de tu red.
- Tu equipo usa la IA tan a fondo que cambiar de herramienta implicaría reescribir flujos de trabajo reales, no solo reinstalar una extensión.
- Tienes al menos a una persona en el equipo a la que le gusta hacerse cargo de las herramientas y que tiene tiempo para hacerlo.
Tiene menos sentido si tu equipo es pequeño, está contento con su herramienta actual, el código no es sensible y cambiarte te lleva una tarde. En ese caso, probablemente el pulido valga más para ti que la opción de salida.
Una forma barata de reducir tu riesgo este mes
No necesitas migrar a tu equipo para saber en qué punto estás. Tres pasos pequeños te dicen casi todo lo que necesitas:
- Anota tu costo de salida. Haz una lista de lo que tendrías que reconstruir si tu herramienta actual duplicara su precio mañana. Si la lista es corta, estás bien. Si es larga, ese es tu riesgo, por escrito.
- Mantén tus instrucciones portables. Pon las reglas y convenciones del proyecto en archivos Markdown simples dentro del repo, en lugar de un formato que solo lee una herramienta. La mayoría de los agentes, abiertos o cerrados, pueden leerlos.
- Pasa una tarea real por un agente de código abierto. Elige algo de tu backlog, apunta el agente al modelo que ya usas y compara el resultado. Así sabes cuánta fricción te espera de verdad, antes de que sea urgente.
Si todavía estás comparando las herramientas cerradas entre sí, escribimos sobre cómo elegir entre Claude Code y Cursor según la tarea. Elijas la que elijas, vale la pena saber cuánto te costaría reemplazarla antes de que llegue el próximo correo con precios nuevos.
