Herramientas de IA para codear: cómo uso OpenRouter, Kimi Code y Continue.dev
Tabla de contenidos
Uso múltiples herramientas de IA para codear. Eso suena a exceso hasta que te das cuenta de que ninguna lo hace todo bien.
Esto no es un benchmark. No tengo puntuaciones ni tasas de finalización. Es una opinión sobre dónde encaja cada herramienta en mi flujo, basada en lo que realmente uso y lo que realmente dejé de usar.
Kimi Code para razonamiento de infraestructura (y sus límites)
Kimi Code es la herramienta que uso cuando necesito entender algo a través de muchos archivos. Charts de Helm, módulos de Terraform, manifiestos de Kubernetes, repos multi-servicio. La ventana de contexto y la integración con terminal lo hacen útil para infraestructura de una forma en la que los plugins de IDE no lo son.
Lo uso para:
- Depurar a través de varios archivos.
- Revisar Terraform o Helm en busca de errores.
- Escribir scripts que tocan varios servicios.
- Cualquier cosa donde de otra forma estaría haciendo grep y cambiando de contexto.
El modo agente también es genuinamente útil para tareas mecánicas: renombrar esta variable entre archivos, agregar manejo de errores a estas funciones, correr tests y reportar fallos. No le permito cambios sin revisión en configs de producción. Aprendí eso de la manera difícil cuando sugirió borrar un namespace que realmente necesitaba. Lo detecté porque estaba observando. Si lo hubiera ejecutado con auto-aceptar, habría tenido una mala tarde.
Donde Kimi Code falla es en velocidad. No es rápido. Un autocompletado simple toma segundos porque está ejecutando una llamada completa al modelo. Para asistencia de escritura rápida, es la herramienta equivocada. También dejé de usarlo para código Go porque seguía sugiriendo patrones de Python. El entrenamiento del modelo se nota.
OpenRouter para flexibilidad (y el caos de proveedores)
OpenRouter es el que tiene menos fricción en términos de acceso a proveedores. Puedo cambiar entre modelos sin cambiar mi configuración. Una clave API, muchos modelos. Para trabajo diario de Python, Go o TypeScript, me ahorra tiempo.
Donde falla es en consistencia. Diferentes modelos tienen diferentes fortalezas. Si necesito entender por qué falla un despliegue, podría necesitar probar varios modelos antes de encontrar uno que lo entienda. Una vez pasé diez minutos aceptando sugerencias para manejo de errores antes de darme cuenta de que el problema real estaba en un archivo completamente diferente que el modelo nunca había visto.
Lo uso para:
- Autocompletado a través de Continue.dev.
- Funciones pequeñas y boilerplate.
- Sugerencias inline mientras escribo.
- Experimentar con nuevos modelos a medida que salen.
Lo que dejé de usar para: cualquier cosa que requiera entender el sistema. Es un asistente de escritura, no un arquitecto.
Las molestias: a veces sugiere código que se ve bien pero usa APIs obsoletas. Acepté una sugerencia para kubectl exec con una sintaxis que funcionaba en v1.20 pero no en v1.28. Pasó mi revisión mental porque se veía familiar. Eso me costó veinte minutos de depuración.
Continue.dev para control local (y el costo de configuración)
Continue.dev es la herramienta que uso cuando quiero control. Es open source, soporta modelos locales a través de Ollama, y puedo configurar exactamente qué modelo maneja qué tarea. Eso lo hace la mejor opción cuando no quiero que mi código salga de mi entorno.
También es el más configurable. Puedo agregar proveedores de contexto personalizados y comandos slash. Esa flexibilidad es genial, pero significa que Continue.dev requiere más configuración que las otras. Pasé una tarde configurándolo para usar mi instancia local de Ollama con un prompt de sistema personalizado. Funcionó, pero la inversión de tiempo fue real.
Lo uso para:
- Modelos locales o autohospedados.
- Experimentar con nuevos proveedores a través de OpenRouter.
- Situaciones donde la privacidad del código importa.
Lo que dejé de usar para: tareas rápidas. La configuración es demasiado pesada para “ayúdame a escribir esta función”. También descubrí que los modelos locales no son lo suficientemente buenos para razonamiento complejo todavía. Mi instancia de Ollama con Llama 3.1 8B está bien para autocompletado pero lucha con revisiones de Terraform multi-archivo. Eso no es culpa de Continue.dev. Es el modelo.
Cómo realmente elijo (actualizado para la realidad)
| Tarea | Herramienta | Por qué |
|---|---|---|
| Depurar infraestructura multi-archivo | Kimi Code | La ventana de contexto importa |
| Escribir o refactorizar en el IDE | OpenRouter vía Continue.dev | Velocidad y sin fricción |
| Modelo local/autohospedado | Continue.dev | Privacidad y control |
| Investigación por terminal | Kimi Code | Puede ejecutar comandos |
| Autocompletado rápido | OpenRouter vía Continue.dev | Ya está ahí |
| Código sensible a privacidad | Continue.dev + modelo local | El código no sale de mi máquina |
| Razonamiento complejo con modelo local | Ninguno todavía | Los modelos locales no están listos |
| Cambios de configuración de producción | Ninguno | No dejo que la IA toque producción sin supervisión |
La respuesta correcta suele ser “usar más de una”. Estas herramientas se complementan más de lo que compiten. Pero la respuesta incorrecta es “dejar que cualquiera de ellas trabaje sin supervisión”.
Lo que realmente pago
| Herramienta | Costo | ¿Vale la pena? |
|---|---|---|
| Kimi Code | ~$20/mes | Sí, para trabajo de infraestructura |
| OpenRouter | Variable (~$15/mes) | Sí, para coding diario y experimentos |
| Continue.dev | Gratis (open source) | Sí, pero con costo de configuración |
| Mi tiempo depurando malas sugerencias | ~2 horas/mes | No, pero inevitable |
El costo oculto es el tiempo que paso verificando sugerencias. Ya no acepto código de IA a ciegas. El incidente del namespace me enseñó eso. Ahora leo cada sugerencia, especialmente para código de infraestructura. Eso me ralentiza, pero es más rápido que reconstruir un cluster.
Lo que dejé de hacer
Dejé de usar IA para:
- Aplicaciones de Terraform de producción. Reviso el plan manualmente.
- Cambios de configuración de Kubernetes sin una segunda revisión humana.
- Código relacionado con seguridad. Las sugerencias de IA para lógica de auth a menudo están sutilmente mal.
- Cualquier cosa donde el costo de estar equivocado sea alto.
Todavía uso IA para:
- Boilerplate y scaffolding.
- Depuración y análisis de logs.
- Aprender nuevas APIs.
- Escribir tests.
La línea es “¿puedo verificar esto rápida y baratamente?” Si sí, la IA ayuda. Si no, lo hago yo mismo.
Conclusión
Kimi Code, OpenRouter y Continue.dev no son intercambiables. Kimi Code es para razonar a través de archivos. OpenRouter es para velocidad y variedad de modelos dentro del IDE. Continue.dev es para control y privacidad.
Elige la herramienta que se ajuste a la tarea. No fuerces a una herramienta a hacerlo todo. Y nunca dejes que ninguna de ellas trabaje sin supervisión en infraestructura que importa.
La mejor configuración de IA para codear es aquella donde sabes exactamente en qué es buena cada herramienta, en qué es mala, y cuándo dejar de usarla.