Yeda AI Tips · #206

Apunta tu agente de programación a un modelo abierto

El harness en el que ya confías — el que lee tu repo, edita archivos, corre tus pruebas — fue ajustado para el modelo de un proveedor, pero nunca estuvo casado con él. Bajo la marca, un agente de programación es un bucle: reunir contexto, tomar una acción mediante una llamada a herramienta, verificar el resultado, repetir hasta terminar la tarea. Ese bucle es agnóstico al modelo. Solo necesita un modelo que haga dos cosas bien: seguir instrucciones sin desviarse y llamar herramientas en el formato correcto. Todo lo demás va montado encima. Así que puedes cambiar el motor sin reconstruir el auto.

Por qué el cambio funciona

El agente habla con un endpoint de modelo, y lee ese endpoint desde variables de entorno. No fija el proveedor en el código. Así que apuntas esas variables a un proveedor distinto — uno que sirva un modelo abierto —, pones las credenciales, nombras el modelo y lanzas como siempre. El harness envía las mismas definiciones de herramientas, el mismo system prompt, el mismo contexto creciente, y recibe la respuesta en la misma forma. El harness nunca nota la diferencia.

Ese es todo el truco, y por eso "abierto vs. cerrado" no es una decisión de todo o nada. La interfaz es un contrato, no un matrimonio. Cualquier modelo que hable el contrato puede sustituirlo.

La configuración real

Define tres variables de entorno — una URL base, una API key y un nombre de modelo — y luego arranca el agente como siempre:

export AGENT_BASE_URL="https://<proveedor>/v1"
export AGENT_API_KEY="<tu-key>"
export AGENT_MODEL="<id-del-modelo-abierto>"
# lanza tu agente como de costumbre

Los nombres exactos de las variables dependen de tu harness — revisa su documentación para saber cuáles lee —, pero la forma es siempre la misma: a dónde enviar las solicitudes, cómo autenticarse, qué modelo pedir.

Si usas un router que ya lista modelos abiertos listos para usar, es aún más corto — un solo cambio de URL base más tu key del router. OpenRouter, por ejemplo, expone un endpoint compatible con OpenAI en https://openrouter.ai/api/v1; apunta la URL base de tu cliente allí, mete tu key del router y elige un modelo de su catálogo (quickstart de OpenRouter). Un cambio de config y estás corriendo.

Pruébalo con trabajo real, no un prompt de juguete

Esta es la parte que la gente se salta, y es la que importa. No juzgues el cambio con un prompt de juguete como "escríbeme una función". Una respuesta de un solo tiro no te dice casi nada sobre cómo se comporta el modelo dentro de un agente.

Apúntalo a un bug real en un repo real y míralo correr un bucle completo: leer el código, hacer un plan, editar varios archivos, correr las pruebas, leer las fallas, arreglar lo que se rompió, intentar de nuevo. Lo que en realidad estás comprobando es si el modelo sostiene el hilo a lo largo de unas diez llamadas a herramientas sin perder el plan. Eso solo aparece en trabajo real de horizonte largo — el tipo que corre por muchos minutos en lugar de responder de un tiro. Los modelos construidos específicamente para trabajo de agente de horizonte largo son los que sobreviven a esto; los modelos de chat de propósito general son donde verás el plan desmoronarse en silencio alrededor del paso diez.

Los límites honestos

Cambiar de modelo no está libre de compromisos, y fingir lo contrario te prepara para sorpresas:

El comportamiento de seguridad y rechazo difiere. Un modelo de otro laboratorio fue ajustado con valores por defecto distintos. Solicitudes que un proveedor permite, otro puede rechazar — y viceversa. Espera que los bordes se sientan diferentes.
La experiencia co-diseñada es más pulida. Cuando un harness y un modelo los construye el mismo equipo, los pequeños detalles encajan de formas que un modelo sustituido no reproduce a la perfección. Es parecido, no idéntico.
La frontera aún gana los problemas más difíciles. En el trabajo de arquitectura más complejo y novedoso, un modelo frontera se gana su precio. El 90% cotidiano — refactors, pruebas, código de pegamento — es donde un modelo abierto se acerca más a un truco.

En resumen

La postura correcta no es "cambiar todo" ni "no cambiar nada". Usa un modelo abierto para volumen, mantén un modelo frontera a un flag de config de distancia para el 10% más difícil, y trata la URL base como un dial que giras por tarea, no como una religión. El harness es tuyo en cualquier caso. El modelo de abajo es solo una variable de entorno.

Recursos

¿Estás construyendo una función con IA? Yeda AI diseña, audita y lanza sistemas LLM en producción.

Hablemos · Lee el blog