OpenCode: el rival open source de Claude Code que nadie esperaba

Claude Code es muy bueno.

Tan bueno que muchos developers han empezado a construir su flujo de trabajo alrededor de él: analizar repos grandes, generar tests, refactorizar módulos, revisar deuda técnica, documentar decisiones y entender código legacy sin perder media mañana.

Pero ahí está precisamente el problema.

Cuando una herramienta pasa de ser "algo que uso" a ser "la forma en la que trabajo", la pregunta cambia.

Ya no es solo:

¿funciona bien?

Ahora la pregunta es:

¿cuánto control tengo sobre ella?

Y ahí es donde OpenCode se ha metido en la conversación con una fuerza que pocos esperaban.

No como otro chatbot para programar.

No como otra demo de "crea una app con un prompt".

No como otro wrapper bonito encima de un modelo.

OpenCode importa porque representa otra idea:

> usar agentes de IA para programar sin quedar atrapado en un único proveedor.

Qué es OpenCode#

OpenCode es un agente de IA open source para trabajar con código. Su propio repositorio lo define como "the open source AI coding agent" y actualmente incluye app de escritorio, instalación por terminal y agentes incorporados como build y plan.

Dicho fácil:

OpenCode es una capa de trabajo encima de tus modelos.

No es "el modelo".

No es "la IA".

No es "el proveedor".

Es la herramienta que conecta tu proyecto, tus ficheros, tus comandos, tus agentes y los modelos que quieras usar.

La diferencia es importante.

Con una herramienta cerrada, normalmente dependes de:

• su modelo
• sus límites
• su pricing
• su roadmap
• sus decisiones de producto
• su forma concreta de trabajar

Con OpenCode, el enfoque es otro:

• puedes usar distintos proveedores
• puedes traer tus propias API keys
• puedes trabajar con modelos locales
• puedes configurar agentes
• puedes integrarlo en flujos más abiertos
• puedes cambiar de modelo sin rehacer por completo tu workflow

Y esto para un developer PHP/Laravel/Symfony no es postureo.

Es práctico.

Muy práctico.

Por qué OpenCode está explotando ahora#

El momento no es casualidad.

OpenCode aparece justo cuando los coding agents empiezan a dejar de ser juguetes y se convierten en herramientas reales de trabajo.

Y cuando una herramienta se vuelve real, aparecen las preguntas incómodas:

• ¿qué pasa si sube de precio?
• ¿qué pasa si me cambian los límites?
• ¿qué pasa si deprecan un modelo?
• ¿qué pasa si bloquean una forma de acceso?
• ¿qué pasa si mi equipo entero depende de una única CLI?
• ¿qué pasa si mañana necesito usar otro proveedor?

Según comparativas recientes, OpenCode ya aparece por encima de Claude Code en estrellas de GitHub, con cifras alrededor de 161K frente a 124K en mayo de 2026.

Las estrellas no demuestran que una herramienta sea mejor.

Pero sí demuestran algo:

hay hambre de alternativa.

Hay muchos developers mirando hacia herramientas que no les obliguen a casarse con una única empresa.

Y ese es el punto fuerte de OpenCode.

El bloqueo de Anthropic fue el mejor marketing posible#

Uno de los momentos que más alimentó esta conversación fue el conflicto con Anthropic.

A principios de 2026 hubo reportes y discusiones públicas sobre bloqueos a formas de autenticación usadas por herramientas de terceros para conectarse a Claude fuera de los clientes oficiales. En GitHub hay issues abiertas del proyecto OpenCode relacionadas con estos bloqueos, y varios análisis externos explicaron cómo afectó a herramientas que dependían de OAuth de Claude.

Y aquí viene lo interesante.

Lo normal habría sido que eso frenara a OpenCode.

Pero pasó casi lo contrario.

Porque el mensaje que muchos developers leyeron fue este:

> si una empresa puede romper tu workflow de un día para otro, quizá necesitas una herramienta que no dependa de una única empresa.

Ese bloqueo convirtió el argumento de OpenCode en algo mucho más fácil de entender.

No era solo una cuestión técnica.

Era una cuestión de independencia.

El problema real no es Claude Code#

Quiero dejar esto claro.

El problema no es que Claude Code sea malo.

Claude Code es muy bueno.

Para muchas tareas sigue siendo de lo mejor que puedes usar hoy: análisis de repositorios, generación de tests, refactors grandes, explicación de código legacy, revisión de arquitectura y trabajo intensivo dentro de un proyecto.

El problema es otro.

El problema es depender demasiado de cualquier herramienta cerrada.

Porque si todo tu flujo de desarrollo vive dentro de una sola herramienta, esa herramienta ya no es un complemento.

Es infraestructura.

Y cuando algo se convierte en infraestructura, necesitas pensar como ingeniero:

• ¿puedo migrar?
• ¿puedo auditar?
• ¿puedo controlar costes?
• ¿puedo cambiar de proveedor?
• ¿puedo automatizarlo?
• ¿puedo usarlo en local?
• ¿puedo integrarlo con mi stack?
• ¿puedo adaptarlo a mi equipo?

OpenCode no viene a decirte:

"Claude Code no sirve".

Viene a decirte:

"no pongas todo tu sistema de trabajo en manos de un único proveedor".

Provider freedom: la parte importante#

La idea clave de OpenCode es la libertad de proveedor.

O dicho más simple:

> que puedas cambiar de modelo sin cambiar toda tu forma de trabajar.

Hoy puedes usar Claude.

Mañana GPT.

Pasado Gemini.

Otro día un modelo local con Ollama.

Y si aparece un modelo que funciona especialmente bien con PHP, Laravel o Symfony, puedes probarlo sin tirar tu workflow a la basura.

Eso es mucho más importante de lo que parece.

Porque el futuro de los agentes de código no va a ser usar siempre "el mejor modelo".

Va a ser usar el modelo adecuado para cada tarea.

Para explicar una clase sencilla, quizá no necesitas el modelo más caro.

Para generar nombres de tests, tampoco.

Para revisar una migración delicada de base de datos, sí quieres un modelo fuerte.

Para analizar código privado, quizá prefieres un modelo local.

Para documentación interna, puede valerte uno barato.

Para un refactor grande, quieres precisión.

El valor está en poder elegir.

BYOK: trae tu propia clave#

Otro punto fuerte de OpenCode es BYOK: Bring Your Own Key.

Es decir:

tú usas tus propias API keys.

Esto cambia bastante el control del gasto y del acceso.

No dependes únicamente de una suscripción cerrada.

Puedes conectar tus claves, separar proyectos, probar proveedores y controlar mejor qué modelo usas en cada caso.

Para un freelance, una agencia o un equipo pequeño, esto tiene mucho sentido.

Ejemplo realista:

• Cliente A: usa Claude para tareas complejas.
• Cliente B: usa GPT para documentación y generación de tests.
• Proyecto personal: usa Ollama en local.
• Proyecto legacy: usa un modelo potente solo para análisis puntual.
• CI/CD: usa un modelo barato para checks básicos.

Misma herramienta.

Distintos proveedores.

Distintos costes.

Distintos niveles de privacidad.

Eso es exactamente lo que deberíamos querer como developers.

Ollama y modelos locales: privacidad real#

Una de las partes más interesantes es que OpenCode puede trabajar con modelos locales vía Ollama. La documentación de Ollama incluye integración específica con OpenCode y explica cómo usarlo como proveedor local.

Esto no significa que un modelo local vaya a sustituir siempre a Claude, GPT o Gemini.

No vendamos humo.

Pero sí significa algo muy potente:

puedes tener tareas donde tu código no sale de tu máquina.

Y eso para ciertos proyectos importa mucho.

Casos donde usaría modelo local:

• explicar una clase
• generar documentación
• revisar naming
• detectar smells sencillos
• crear esqueletos de tests
• preparar resúmenes de módulos
• trabajar offline
• experimentar sin coste por token
• analizar código sensible sin enviarlo a terceros

No siempre será la mejor opción.

Pero tener la opción cambia la conversación.

Desktop v2 y agentes en background#

OpenCode también está empujando fuerte en experiencia de uso.

La app de escritorio ya aparece documentada en el repositorio oficial como aplicación beta disponible para macOS, Windows y Linux. Además, análisis recientes sobre Desktop v2 destacan mejoras de interfaz y agentes en background con actualizaciones push sin polling.

Esto es importante porque durante mucho tiempo las herramientas open source potentes tenían un problema:

eran potentes, sí.

Pero también incómodas.

Muy de terminal.

Muy de "esto lo usa alguien que se lee el README entero antes de desayunar".

Desktop v2 intenta reducir esa fricción.

Y los agentes en background son especialmente interesantes.

Porque no es lo mismo pedirle a una IA:

Explícame esta clase.

Que pedirle:

Analiza el módulo de facturación, detecta deuda técnica, revisa posibles bugs,
propón un plan de refactor y avísame cuando tengas el informe.

La segunda tarea ya no parece un chat.

Parece un proceso de trabajo.

Y ese es el futuro real de los coding agents.

No una caja donde preguntas cosas.

Sino agentes trabajando alrededor de tu repositorio.

Por qué esto importa para PHP y Laravel#

Muchos debates sobre agentes de código se quedan en benchmarks.

Que si SWE-bench.

Que si el modelo X supera al modelo Y.

Que si resuelve más issues.

Que si genera una app en 40 segundos.

Eso está bien para medir.

Pero el día a día de un developer PHP/Laravel es otra película.

Lo importante no es si el agente sabe resolver un ejercicio aislado.

Lo importante es si entiende un proyecto real.

Un proyecto con:

• controllers demasiado gordos
• services mezclando responsabilidades
• jobs en cola
• eventos y listeners
• policies
• observers
• FormRequests
• resources
• migraciones antiguas
• factories incompletas
• tests a medias
• módulos legacy
• queries que nadie quiere tocar
• reglas de negocio que solo existen en la cabeza de alguien

Ahí es donde un agente empieza a ser útil.

Pero solo si tiene contexto.

Y solo si puedes dirigirlo bien.

OpenCode no te hace mejor developer por magia.

Pero sí puede convertirse en una capa muy interesante para trabajar mejor con tu código.

Cómo lo usaría en un proyecto Laravel real#

Yo no empezaría usando OpenCode para crear una app entera.

Ese es el error típico con la IA.

Le das demasiada libertad, demasiado pronto, con demasiado poco contexto.

Luego genera mucho código, tú te emocionas cinco minutos y después te toca limpiar el incendio.

Yo empezaría con tareas concretas.

Pequeñas.

Medibles.

Revisables.

1. Auditoría de un módulo#

Analiza el módulo de invoices.

Quiero:
- responsabilidades mezcladas
- queries pesadas
- validaciones duplicadas
- lógica de negocio en controllers
- problemas de concurrencia
- oportunidades de tests
- propuesta de refactor por fases

No modifiques archivos todavía.
Devuélveme primero un diagnóstico técnico.

Esto es perfecto para un agente.

No le estás pidiendo que toque nada.

Le estás pidiendo que mire, entienda y ordene.

2. Plan de refactor#

Con el diagnóstico anterior, propón un plan de refactor en pasos pequeños.

Condiciones:
- no romper endpoints existentes
- mantener compatibilidad con tests actuales
- separar validación, lógica de negocio y respuesta API
- indicar riesgo de cada paso
- explicar qué archivos tocarías

No escribas código todavía.

Esto evita el clásico problema de:

"me ha cambiado medio proyecto y no sé por qué".

Primero plan.

Luego ejecución.

3. Generación de tests útiles#

Crea tests para InvoiceService.

Prioridad:
1. casos de error
2. reglas de negocio
3. estados límite
4. regresiones probables

Usa factories existentes.
No hagas mocks innecesarios.
Si falta una factory, propónla antes de crearla.

Aquí el agente puede ahorrar muchísimo tiempo.

Pero la clave está en dirigirlo.

No le pidas "haz tests".

Dile qué tipo de tests quieres.

4. Revisión de migraciones#

Revisa las migraciones y modelos relacionados con orders.

Busca:
- índices faltantes
- relaciones inconsistentes
- columnas mal nombradas
- posibles problemas con soft deletes
- queries que podrían romper en producción

No cambies nada.
Primero dame una lista priorizada de riesgos.

Este tipo de tarea es oro.

Porque no siempre necesitas que la IA escriba código.

Muchas veces necesitas que te ayude a ver lo que se te escapa.

5. Documentación técnica#

Genera documentación técnica del flujo de facturación.

Incluye:
- entidades principales
- endpoints
- jobs
- eventos
- reglas de negocio
- dependencias externas
- riesgos conocidos
- cómo probarlo en local

Esto para onboarding de equipo puede ser brutal.

Y para tu yo de dentro de seis meses, más todavía.

OpenCode con AGENTS.md#

Aquí OpenCode encaja muy bien con una práctica que cada vez tiene más sentido: documentar instrucciones persistentes para agentes.

Un AGENTS.md puede decirle al agente cómo trabajar en tu proyecto.

Ejemplo:

# AGENTS.md

## Stack

- PHP 8.3
- Laravel 11
- PostgreSQL
- Redis
- Pest
- Docker

## Reglas de arquitectura

- Los controllers deben ser finos.
- La lógica de negocio va en Services o Actions.
- Las validaciones van en FormRequest.
- No crear helpers globales salvo justificación.
- No tocar migraciones antiguas sin crear una nueva.
- No modificar contratos públicos de la API sin avisar.

## Tests

- Usar Pest.
- Priorizar tests de feature para endpoints.
- Usar factories existentes.
- No mockear Eloquent salvo necesidad clara.

## Flujo de trabajo

Antes de modificar código:
1. analizar el problema
2. proponer plan
3. esperar confirmación
4. ejecutar cambios pequeños
5. explicar cada cambio

Esto es context engineering aplicado al desarrollo.

No dependes de escribir cada vez el prompt perfecto.

Creas contexto persistente para que el agente trabaje mejor.

Ejemplo práctico: agente para revisar deuda técnica#

Imagina que tienes este comando mental para tu proyecto:

Revisa este módulo como si fueras un tech lead preparando una refactorización segura.

Quiero:
- problemas reales
- prioridad
- riesgo
- archivos afectados
- propuesta por fases
- qué tests faltan
- qué no tocarías todavía

La salida buena no debería ser:

El código puede mejorarse separando responsabilidades.

Eso no sirve.

La salida buena debería parecerse a esto:

{
  "modulo": "Invoices",
  "riesgo_general": "medium",
  "problemas": [
    {
      "tipo": "controller_gordo",
      "archivo": "app/Http/Controllers/InvoiceController.php",
      "riesgo": "high",
      "motivo": "mezcla validación, cálculo de totales y persistencia",
      "accion": "extraer cálculo a InvoiceCalculator y validación a FormRequest"
    },
    {
      "tipo": "query_sin_indice",
      "archivo": "database/migrations/2024_03_10_create_invoices_table.php",
      "riesgo": "medium",
      "motivo": "se filtra por status y due_date pero no existe índice compuesto",
      "accion": "crear nueva migración con índice compuesto"
    }
  ],
  "primer_paso_recomendado": "crear tests de regresión antes del refactor"
}

Esto sí es útil.

Porque ya no es una opinión genérica.

Es una herramienta de trabajo.

OpenCode no sustituye a Cursor, Copilot o Claude Code#

Este punto es importante.

No veo OpenCode como "borra todo lo demás".

Lo veo como otra pieza del stack.

Un stack realista podría ser:

• Copilot para autocompletado rápido.
• Cursor para edición asistida dentro del IDE.
• Claude Code para tareas complejas donde Claude brilla.
• OpenCode para flujos abiertos, BYOK, modelos locales y libertad de proveedor.
• Codex para revisión, automatización o tareas específicas de repo.

La pregunta no es:

¿cuál es la única herramienta buena?

La pregunta buena es:

¿qué herramienta uso para cada tipo de tarea?

Y sobre todo:

¿qué parte de mi workflow quiero controlar yo?

El riesgo de los agentes#

También hay que decir la parte incómoda.

Los agentes pueden liarla.

Mucho.

Un agente con permisos amplios, poco contexto y una instrucción vaga puede hacer auténticas barbaridades.

Por eso no usaría OpenCode ni ningún otro agente así:

Mejora este proyecto.

Eso es una bomba.

Lo usaría así:

Analiza este módulo y no modifiques nada.

Luego:

Propón un plan de refactor en pasos pequeños.

Luego:

Ejecuta solo el paso 1.

Luego:

Enséñame el diff y explícame riesgos.

La clave no es que el agente haga más cosas.

La clave es que haga cosas controladas.

Reglas que pondría desde el primer día#

Para usar OpenCode en un proyecto serio, pondría estas reglas:

• nunca tocar producción
• nunca modificar migraciones antiguas sin avisar
• nunca cambiar contratos API sin confirmación
• nunca borrar tests para hacer pasar la suite
• nunca modificar .env
• nunca hacer cambios masivos sin plan previo
• siempre explicar el diff
• siempre separar análisis de ejecución
• siempre pedir confirmación antes de cambios destructivos

Esto no es paranoia.

Es ingeniería.

Un agente es útil cuando trabaja dentro de límites claros.

Lo que más me gusta de OpenCode#

Lo que más me gusta no es que sea open source.

Aunque eso ayuda.

Lo que más me gusta es que cambia la conversación.

Porque durante los últimos años hemos pasado de:

"la IA me ayuda a escribir código"

a:

"la IA empieza a formar parte de mi flujo de desarrollo"

Y si forma parte de tu flujo, necesitas control.

OpenCode pone encima de la mesa varias ideas muy sanas:

• no depender de un único proveedor
• poder usar modelos locales
• separar herramienta y modelo
• traer tus propias claves
• configurar agentes
• trabajar con contexto persistente
• integrar la IA en procesos reales

Esto es mucho más interesante que otra comparativa de benchmarks.

Lo que todavía me genera dudas#

OpenCode no es magia.

Y no todo son ventajas.

Primera duda: más libertad también significa más configuración.

Claude Code puede ser más directo para mucha gente.

Instalas, abres, trabajas.

OpenCode puede requerir más criterio: proveedor, modelo, claves, permisos, agentes, configuración.

Segunda duda: la calidad depende mucho del modelo.

OpenCode puede darte libertad, pero si conectas un modelo flojo, tendrás resultados flojos.

Tercera duda: los agentes en background necesitan control.

Si los usas bien, pueden ser una maravilla.

Si los dejas demasiado sueltos, pueden generar ruido, cambios innecesarios o PRs que nadie quiere revisar.

Cuarta duda: en equipos hace falta proceso.

No basta con instalarlo.

Hay que definir:

• cuándo se usa
• quién revisa los cambios
• qué permisos tiene
• qué ramas toca
• qué tareas puede ejecutar
• qué comandos están prohibidos
• cómo se mide si aporta valor

Sin eso, puedes acabar con mucho movimiento y poco avance.

Cómo empezaría yo mañana#

Mi forma de empezar sería muy sencilla.

Nada de montar un sistema gigante.

Nada de automatizar medio equipo.

Nada de vender humo.

Solo tres usos.

1. Entender código legacy#

Explícame este módulo como si fueras a hacer onboarding a un developer nuevo.

Incluye:
- responsabilidades principales
- flujo de datos
- clases importantes
- riesgos
- partes que no tocarías sin tests

2. Detectar deuda técnica#

Analiza este módulo y dame deuda técnica priorizada.

Formato:
- problema
- archivo
- impacto
- riesgo
- recomendación

3. Crear tests antes de refactorizar#

Antes de refactorizar, propón tests de regresión para cubrir el comportamiento actual.

No cambies código de producción.
Primero genera solo los tests.

Con eso ya puedes sacar valor real.

Sin humo.

Sin prometer que la IA te va a hacer el SaaS entero mientras tomas café.

La conclusión importante#

OpenCode no es importante solo porque sea una alternativa a Claude Code.

Es importante porque representa una dirección.

Una dirección donde los developers no aceptan que el futuro de programar con IA sea una caja negra controlada por tres empresas.

Una dirección donde puedes usar Claude, GPT, Gemini, Ollama o lo que venga después sin rehacer todo tu workflow.

Una dirección donde el agente no es una cárcel.

Es una interfaz.

Y para mí esa es la clave.

Claude Code puede seguir siendo excelente.

Pero OpenCode está diciendo algo que muchos developers querían escuchar:

> puedes usar IA para programar sin entregar todo tu workflow a un único proveedor.

El futuro del desarrollo no será solo quién tenga el mejor modelo.

Será quién controle la capa donde trabajan los developers.

Y ahí OpenCode acaba de entrar muy fuerte.

Checklist para probar OpenCode en un proyecto PHP/Laravel#

• [ ] Crear un AGENTS.md con reglas del proyecto
• [ ] Empezar en modo análisis antes de permitir cambios
• [ ] Probarlo primero en un módulo pequeño
• [ ] Usarlo para detectar deuda técnica
• [ ] Pedir planes antes de refactors
• [ ] Generar tests antes de tocar producción
• [ ] Configurar proveedor y costes conscientemente
• [ ] Probar Ollama para tareas locales sencillas
• [ ] Revisar siempre el diff
• [ ] No delegar decisiones de arquitectura sin criterio humano

Fuentes#

• OpenCode GitHub: repositorio oficial, instalación, Desktop App y agentes incorporados. https://github.com/anomalyco/opencode
• Morph: comparativa OpenCode vs Claude Code, cifras de estrellas y evolución del ecosistema. https://www.morphllm.com/comparisons/opencode-vs-claude-code
• AI Builder Club: análisis de Desktop v2 y agentes en background. https://www.aibuilderclub.com/blog/opencode-vs-claude-code-2026
• GitHub issue de OpenCode sobre bloqueos relacionados con Anthropic. https://github.com/anomalyco/opencode/issues/10956
• Paddo.dev: análisis del bloqueo de OAuth y el debate sobre herramientas de terceros. https://paddo.dev/blog/anthropic-walled-garden-crackdown/