Todavía me encuentro gente que trabaja así: pestaña del navegador con el chat de turno abierto, pregunta, copia el código, lo pega en el editor y a otra cosa. Sin agentes, sin contexto del proyecto, sin nada. Muchos además usan la IA como quien busca en Google: se quedan con el primer resultado y dan por hecho que no se equivoca. Y se equivoca. Se inventa funciones, se equivoca en supuestos básicos y te lo cuenta todo con una seguridad pasmosa.
Cada vez que veo esto pienso lo mismo: aquí hay una escalera, y hay gente que ni siquiera está en el primer peldaño. Así que hoy toca ordenarla. Los niveles que veo de trabajar con agentes de IA haciendo código, qué cuesta cada uno y en cuál me he quedado yo después de haberlos probado casi todos.
Lo de siempre antes de empezar: esto es mi opinión y mi experiencia haciendo código full stack con Drupal. La IA para redactar o traducir es otra película y da para otro artículo.
El nivel -1: la IA como buscador
A esa forma de trabajar del principio la llamo el nivel menos uno. Ni siquiera le doy el cero, porque no entra en la clasificación. No se le puede llamar trabajar con agentes; es chatear con una web.
Hace unos años era lo que había y no te quedaba otra. Hoy es estar fuera de juego. Si te reconoces aquí, el primer paso no tiene misterio: instálate Claude Code u OpenCode y deja que la herramienta trabaje sobre el código directamente, con el contexto del proyecto delante, en vez de ir pasando trozos por el portapapeles. Solo con ese cambio ya juegas en otra liga.
Nivel 1: el vibe coding de toda la vida
El primer nivel de verdad es el de quien ya usa agentes, pero todo por defecto. Sin agentes especializados, sin skills, sin tocar nada. Opus o Fable para todo, hasta para renombrar una variable. Y sin saber leer el código que sale, así que la revisión ni existe: si parece que funciona, para adelante.
De la trampa que es esto ya escribí en su día, así que no me extiendo aquí. Lo que me interesa aquí es la parte económica, que se comenta menos: es la forma más cara de trabajar que existe. Pagas el modelo más caro del catálogo para tareas que un Haiku resuelve igual de bien, quemas tokens sin control porque no hay nada optimizado, y encima el resultado no lo valida nadie. Estás tirando el dinero por los dos lados.
Nivel 2: tú piensas, la IA pica, tú revisas
Aquí ya hablamos de un programador que usa bien la IA. Tiene su sistema de agentes montado y cada agente lleva asignado el modelo que le toca: Haiku para lo mecánico, Sonnet para lo habitual, Opus para lo que de verdad requiere criterio. Si tiras de OpenCode con pesos abiertos, la misma idea con DeepSeek, Qwen o el que mejor te encaje.
El reparto del trabajo cambia. Tú haces la planificación de la tarea y documentas los requisitos. La IA hace el trabajo pesado. Y luego tú revisas lo que ha generado antes de que llegue a producción. Dedicas más tiempo que antes a planificar y revisar, sí, pero mucho menos tiempo total por tarea, porque la parte pesada ya no la haces tú.
Si quieres ver esta base montada de verdad, la mía es pública. En ddev-ai-workspace tengo el entorno completo con el que trabajo, DDEV con Claude Code y OpenCode en contenedores separados dentro del mismo proyecto, y en drupal-ai-agents están los agentes especializados en Drupal con sus skills y el modelo asignado a cada uno. De cómo lo uso en el día a día ya he escrito en el blog, así que si trabajas con Drupal y DDEV tienes por dónde empezar sin montarlo todo de cero.
El pero de este nivel es evidente: el cuello de botella eres tú. Todo pasa por tus ojos, antes y después. Por muchos agentes que tengas corriendo, tu capacidad de revisar marca el ritmo.
Nivel 3: el meta-arnés
Antes de subir otro escalón, una definición rápida. Llamo arnés a lo que ejecuta los modelos y les deja hacer tareas de forma autónoma: Claude Code, OpenCode, Codex. Un meta-arnés es la capa de arriba, una herramienta para controlar los arneses entre ellos: que se comuniquen, que cuando uno termine otro haga la validación, que las tareas se disparen solas. En resumen, orquestar todo el conjunto cuando ya no tienes un agente trabajando, sino varios.
Tiene todo el sentido cuando llevas varios proyectos y cada uno corre su propio arnés. Yo me he montado el mío: me lleva el control de horas, el de costes de tokens y el de tareas, y desde las tareas me dispara automáticamente worktrees de git en los distintos proyectos. Así, dentro de un mismo proyecto puedo estar en varias tareas a la vez, cada una corriendo en su worktree separado, sin pisarse entre ellas. Si programas, sabes de lo que hablo.
En este nivel la revisión sigue siendo tuya, igual que en el 2. Lo que cambia es la escala: pasas de llevar una tarea a llevar varias en paralelo sin perder el control, y encima con las horas y los costes controlados por tarea.
Nivel 4: la IA revisa antes que tú
El cuarto nivel es donde el meta-arnés empieza a trabajar de verdad: cuando un arnés termina, lanza la validación con un arnés distinto. Un modelo hace los cambios en Claude Code, otro los revisa desde OpenCode o desde Codex y, si encuentra algo mal, se lo devuelve al primero para que lo corrija. Y así en bucle hasta que el código sale limpio de esa criba.
Hay quien dice que con esto ya no hace falta ni revisar ni entender el código, que basta con alguien que te monte bien el sistema y a partir de ahí magia y a producción. Yo lo he intentado y no me lo creo, ahora llego a eso. Pero una cosa sí es cierta: la calidad de lo que te llega mejora un montón.
El matiz importante: el código lo acabas leyendo entero igual, no revisas menos. Lo que cambia es cuántas veces pasa por ti. En los niveles 2 y 3, cada cosa que detectabas se la devolvías a la IA, esperabas la corrección y vuelta a revisar, y todas esas iteraciones tenían como cuello de botella al humano. Aquí esas idas y venidas se las comen los agentes entre ellos, y a ti solo te llega la versión casi definitiva. Revisas las mismas líneas, pero muchas menos veces, y el tiempo que dedicas a revisión cae en picado.
El problema es la factura. Te dejas mucho dinero en tokens para validaciones que muchas veces un humano habría despachado en cinco minutos. Trabajas más rápido porque el cuello de botella humano se estrecha, pero lo pagas.
Nivel 5: aquí ya no revisa nadie
Y el último escalón: como el 4, pero sin humano al final. Te fías de que la revisión de la IA es lo bastante buena y aquello sube a producción tal cual.
Lo he probado con Drupal y mi conclusión es que no. La revisión da por buenas cosas que están mal, hace supuestos incorrectos y ni lo detecta. Para una web pequeña y barata, de esas donde si algo falla lo arreglas cuando puedas, puede llegar a tener sentido. Para un proyecto grande donde el rendimiento y la seguridad importan de verdad, ni hablar. A día de hoy no te puedes fiar al cien por cien de una revisión hecha por otra IA, y menos según qué trabajo. La revisión humana sigue haciendo falta sí o sí, así que el nivel 5, directamente, lo descarto.
Visto con ojos de empresa, la escalera queda así: los del nivel 1 son malos trabajadores, porque ni revisan ni entienden qué hace la IA. Los del 2 y el 3 son los normales, los que hacen bien su trabajo con las herramientas de ahora, el 3 con más músculo de organización. Y los del 4 y el 5 son los más avanzados, pero con un sobrecoste que alguien tiene que justificar.
Yo he vuelto al 3
Probé el 4. Coqueteé con el 5. Y he vuelto al 3, básicamente por costes.
El meta-arnés, como te contaba antes, ya lo tengo montado y es mi día a día. Desde ahí doy un paso hacia el 4 solo en ciertas tareas: las pongo a autorrevisarse antes de que me lleguen, para no tener que pasar yo tantas veces por el mismo código. Me cuesta más dinero, pero me ahorra tiempo. Y en ese equilibrio ando, porque hacerlo con todas las tareas no le veo sentido: es quemar tokens sin más.
Aunque no lo doy por cerrado. Tengo en mente cómo dar ese paso al 4 sin que se dispare la factura, pero eso te lo cuento un poco más abajo.
¿Y por qué no lo haces todo en local?
Aquí entra la pregunta que me hacen cada dos por tres. Tengo un servidor en casa con una RTX PRO 6000 de 96 GB de VRAM sirviendo modelos con vLLM. Barata no fue, aunque la pillé en oferta y dentro de lo que cabe me salió bien. Y aun con ese equipo, sigo recurriendo a modelos externos para el trabajo serio. ¿Por qué?
Porque la calidad de los modelos locales todavía no llega. Estas semanas he estado probando el Qwen3.8 que salió hace unos días, y va bastante mejor que la versión anterior, al menos con mi montaje. Pero Opus sigue estando por encima, y Fable todavía más. Más caros y en manos de terceros, pero mejores.
Tampoco es que los de pago sean para tirar cohetes. Generan código que parece que funciona, pero con cosas mal optimizadas, decisiones que no encajan con el proyecto o soluciones cerradas que no dejan margen para lo que vas a necesitar dentro de seis meses. En Drupal lo veo constantemente: lo quieren arreglar todo con código custom, cuando la mitad de las veces era configuración o un módulo contribuido que lleva años en drupal.org haciendo justo eso. También me he encontrado parches custom propuestos para un problema que no era del módulo, sino de una configuración mal puesta. Alucinan, en el sentido más literal. Y esas cosas no las pilla otra IA por muchos bucles de revisión que montes. Las pilla alguien que conoce el ecosistema.
Toca ser transparente: ahora mismo no le estoy pagando a Anthropic. Me han dado unos meses de suscripción de Claude Code gratis por contribuir a proyectos open source, el equivalente al plan de 200 euros sin pagar un céntimo. Pero gratis no significa infinito. Funciona igual que la suscripción normal, con su ventana de uso, y esa ventana se agota. Cuando trabajaba en nivel 4 o en nivel 5, los bucles de revisión entre agentes me la consumían muchísimo más rápido, y me quedaba sin cuota para las tareas que de verdad me importaban.
Ahí me di cuenta de algo. Prefiero estar encima de la IA y dirigir la tarea hacia donde quiero desde el principio, que no dejarla a su aire y entrar en el ciclo de siempre: hace la tarea, la reviso, está mal, le digo que lo rehaga, lo vuelvo a revisar, ha mejorado pero sigue habiendo cosas mal, rehace la mitad otra vez... y así vas quemando tokens sin necesidad. El nivel 4 me consumía la suscripción, que por suerte no pago. Y cuando usaba modelos open source desde APIs de terceros, que esos sí los pagaba, la factura subía bastante más de lo que me esperaba. Por eso tengo el 4 y el 5 medio descartados.
Esas APIs externas de modelos open source, de hecho, las he dejado del todo: por calidad son peores que Fable u Opus, y con el Qwen3.8 en mi propia máquina llego a resultados muy parecidos sin depender de nadie ni pagar por token. Así que mi ecosistema hoy es Qwen3.8 corriendo en mi servidor, que me toca amortizar, más la suscripción gratuita de Claude Code. Es un chollo, sí, pero con fecha de caducidad, y por eso las cuentas de este artículo las hago como si pagara cada token.
Lo siguiente que quiero probar es un reparto distinto: que toda la edición inicial de código la haga el Qwen en local, y dejar la suscripción de Anthropic solo para el nivel 4, para los bucles de revisión. Si la ventana de uso no se me agota tan rápido, puedo jugar con los dos y sacar más trabajo adelante al mismo coste o menos. O como mínimo sacarlo más rápido, siendo yo menos cuello de botella de lo que soy ahora. Cuando tenga datos de verdad, lo cuento.
Si quieres optimizar costes, yo empezaría por aquí
Dicho todo esto, si en tu empresa queréis bajar la factura de IA, este es el orden que seguiría yo.
El primer paso es gratis y es el que más se salta la gente: montar bien el sistema de agentes y asignar modelos, que no te haga un Fable lo que despacha un Haiku. Solo con eso el gasto en tokens baja muchísimo. Cómo lo tengo yo lo conté en el artículo de optimizar tokens en Claude Code.
El segundo paso ya es montarte el servidor de inferencia local, que es donde le veo el recorrido de verdad: ahorras llamadas a APIs externas y dejas de depender de terceros, algo de lo que ya escribí largo y tendido. En hardware hay dos familias. Servidores con GPU, o de memoria unificada, que serían los Spark que se han puesto de moda o un Mac Studio. La memoria unificada te da más memoria por menos dinero, así que sale más rentable para cargar modelos grandes. A cambio, ejecuta bastante más lento.
Yo tiré por GPU por la velocidad, y no me arrepiento. Cargo modelos de 30, 40 o 50 GB y el resto de la VRAM lo dedico a ventanas de contexto y peticiones concurrentes: más de 200.000 tokens de contexto, por encima de los 100 tokens por segundo y entre 6 y 7 peticiones a la vez según el modelo. Y esa velocidad me deja activar el thinking en local: el modelo se queda un rato dándole vueltas antes de contestar, quema bastantes más tokens, pero como son míos no los pago, y el código sale claramente mejor.
El dimensionamiento tiene su ciencia. Llegué a probar configuraciones de hasta 20 peticiones concurrentes, que con varios agentes en paralelo se agradecen, pero exigían un modelo mucho más cuantizado, es decir, más comprimido y por tanto más tonto. Y un modelo tonto no me sirve por muchas peticiones a la vez que me permita. Al final lo que busco es el equilibrio entre tres variables: cuantizado, ventana de contexto y concurrencia. Un modelo lo bastante listo, lo bastante rápido y con margen para llevar varios proyectos al mismo tiempo. Ese punto dulce depende de cada modelo, y como cada pocas semanas sale uno nuevo, me toca reajustar el montaje cada poco. Por eso hasta hace poco lo compaginaba con APIs externas de modelos mucho más grandes, de los que no caben en mi tarjeta. Esto está en constante evolución.
En dinero: el mínimo por trabajador para algo decente anda entre los 3.000 y 4.000 euros. Un equipo como el mío hoy se va a partir de los 15.000, más o menos el doble de lo que me costó a mí con la oferta. La memoria unificada se queda en la franja de los 3.000 a 5.000, con más memoria que la mía pero mucho más lenta.
¿Cuál elegir? Depende de dónde tengas el cuello de botella. Si tus trabajadores van sobrados y lo que frena es la IA, GPU: más tareas en paralelo y más rápidas. Pero si la IA ya termina las tareas antes de que nadie pueda revisarlas, la velocidad extra no te sirve de nada, y una unificada más lenta pero con más memoria puede cuadrarte mejor: mientras una tarea se ejecuta, el trabajador va revisando la anterior.
Sea cual sea, es coste único. En menos de un año lo amortizas contra lo que se va en tokens y suscripciones de terceros. Y de paso dejas de estar pendiente de si mañana te suben los precios o te recortan los límites, que lo harán.
Un último apunte para quien se quede en APIs externas, algo que ya comenté cuando expliqué mi entorno con OpenCode: monta un proxy de IA a nivel de empresa, por ejemplo con LiteLLM. La idea es sencilla. En el proxy configuras qué modelos están disponibles y defines unos alias, del estilo modelo listo, modelo estándar, modelo barato, y a tus trabajadores les das acceso a los alias, no a los modelos directamente. Si mañana sale un modelo nuevo igual de capaz pero más barato, cambias la configuración del alias y toda la empresa pasa al modelo nuevo de golpe, sin depender de que cada trabajador lo implemente bien en su máquina ni de que use los modelos que le tocan.
Con el proxy ganas además el control que a casi todas las empresas les falta: sabes cuánto se gasta, qué trabajadores usan más o menos la IA y qué modelos utiliza cada uno. Y puedes ponerle límites por trabajador, de forma que quien llegue al suyo quede bloqueado en los modelos caros y tenga que seguir con los baratos. Para decidir qué modelos da la empresa a su gente y cuánto cuesta eso, a día de hoy no conozco forma mejor.
En qué peldaño quedarse
Si me tengo que mojar: trabaja en el nivel 2 y, en cuanto lleves más de un proyecto o más de una tarea a la vez, móntate el meta-arnés y súbete al 3, que ese escalón no quema tokens de más y se amortiza solo con el orden que te da. El 4 es tentador, y si el dinero no es problema en tu empresa, adelante, se trabaja más rápido y se pierde mucho menos tiempo en revisiones. Pero por lo que cuesta, para lo que aporta, a mí hoy no me salen las cuentas. Y el 5, directamente, descártalo.