Estás persiguiendo herramientas. La habilidad está debajo.

Casi todos los días escribo código con dos modelos distintos, y cambio de uno a otro sin mucha ceremonia. Uno es rápido, y lo uso cuando el trabajo es mecánico y quiero que el loop se sienta como una extensión de mis propias manos. El otro es más lento y llega más lejos, y lo traigo cuando el problema necesita razonamiento de verdad. Esta es la parte que tardé en admitir. El cambio no altera casi nada del trabajo. La especificación que escribo es la misma. La forma en que descompongo el problema es la misma. La revisión del final es la misma. Cambio el motor y conservo todo lo que construí a su alrededor.

La pregunta es una encuesta

La pregunta que me hacen, y la que veo por todas partes, es cuál es la mejor herramienta. Qué modelo, qué agente, qué editor. Suena técnica. En realidad es una encuesta. ¿Mejor para qué, para quién, con qué restricciones, en qué codebase? Quita todo eso y no queda respuesta, solo gusto, y el gusto no es conocimiento. Y la respuesta a la que llegaras quedaría obsoleta con la siguiente versión. Habrías gastado esfuerzo real en producir un dato que caduca en semanas.

Estás optimizando la parte del sistema que más cambia y menos importa. Hay tres capas en juego. El modelo, que es de lo que van las discusiones, y que puedes cambiar en un día. El harness que lo rodea, el producto que compras en realidad: cómo gestiona el contexto, si puede leer tu codebase, ejecutar tus tests y recuperarse cuando se rompe. Y el loop que haces pasar por él, las specs y la revisión, que es tuyo y va contigo a todas partes. Para el trabajo del día a día, los modelos de frontera están tan cerca que elegir entre ellos es tirar una moneda; lo que queda es rápido contra profundo, y esa es una elección que haces por tarea, no un ranking. La pregunta de la herramienta se obsesiona con la primera capa y apenas menciona las otras dos, y las otras dos deciden el resultado.

La misma herramienta, dos manos

Dale la misma herramienta a dos desarrolladores y obtienes dos resultados distintos. Uno especifica el problema, lee la salida, detecta dónde se torció y lo corrige. El otro acepta lo que salga. Deja fija la herramienta y los resultados divergen. Deja fija a la persona, yo lo hago cada vez que cambio de modelo, y casi nada se mueve. Esa asimetría te dice dónde poner la atención.

Saltar de herramienta en herramienta también tiene un coste, y se paga exactamente en esa atención. Cada cambio resetea algo. Reaprendes las manías y reescribes tus instrucciones, y la ganancia es pequeña y no dura. Mientras tanto, lo que rinde interés compuesto queda sin tocar, porque estabas ocupado mirando escaparates. El desarrollador que elige una herramienta suficientemente buena y profundiza en el loop adelanta al que siempre está migrando.

Donde la herramienta sí importa

Nada de esto significa que la herramienta no sea nada, y la versión perezosa de este argumento finge que sí. La categoría importa mucho. Un autocomplete que te termina la línea, un agente de terminal que edita por todo un repo y abre una pull request, y un runner al que apuntas a una tarea y dejas trabajando son instrumentos distintos, y tratarlos como sustitutos es la forma en que la gente acaba decepcionada.

En los problemas más difíciles, los que no caben limpiamente en un benchmark, la diferencia entre un setup fuerte y uno débil es si llegas a entregar o no, y la mayor parte de esa diferencia está en el harness y en el loop, no en el nombre del modelo. Si tu trabajo vive en una plataforma, la herramienta nativa de esa plataforma puede ganar solo por integración. Hasta la velocidad que mencioné es una diferencia real, no un gusto; parte de la habilidad es saber cuándo una tarea necesita el modelo rápido y cuándo el lento.

"Aprende los fundamentos y ya" es otra respuesta vacía cuando significa ignora las herramientas. Las herramientas amplifican los fundamentos. Por eso los fundamentos rinden, y eso no es permiso para ignorar con qué los estás amplificando.

Y luego está la factura

El sitio donde más importa la herramienta no tiene nada que ver con qué modelo es más listo. Es el precio. Durante mucho tiempo viví sobre una herramienta que cobraba una tarifa plana, y la exprimí a fondo, todo el día, todos los días, y la factura no se movía. Sabía exactamente lo que costaba un mes. Luego el precio cambió debajo de mí, de tarifa plana a pago por uso, y el mismo trabajo de siempre empezó a sumar más de mil euros en una sola semana. Nada de mi habilidad ni de mi loop había cambiado, solo el contador.

Un cambio de precio es una razón real para cambiar de herramienta, y es lo contrario de perseguir novedades. Me pasé a una herramienta con un tope predecible, con los mismos modelos que ya prefería, y mi factura volvió a ser un número con el que podía planificar. De vez en cuando choco con un límite. No echo de menos las semanas de mil euros. Las herramientas que dejé siguen cobrando un extra precisamente por los modelos que quiero, lo cual es un buen negocio para ellas y un mal trato para mí.

Cualquiera que haya operado cosas en el cloud ya ha visto las dos mitades de esto. La factura que pasa a pago por uso y luego te sorprende. La capacidad con la que no puedes contar del todo: la instancia que no levanta en tu región, el límite con el que chocas justo a la peor hora. El cloud pasó una década enseñando a los ingenieros a vigilar el contador, poner topes donde se pueda y no atarse tan fuerte a un proveedor que irse signifique una reescritura. Las herramientas de IA van por el principio de la misma historia, y la lección se traslada tal cual.

Así que cuando alguien te dice que la herramienta no importa, esta es la parte que se está dejando fuera. La inteligencia converge y el harness importa, pero las condiciones del trato pueden importar más que ambos. No solo el precio y la capacidad, también la licencia que cambia debajo de ti, y la política de privacidad que empieza a meter tu código en el entrenamiento del siguiente modelo. Son palancas que un proveedor puede accionar de la noche a la mañana sin tocar una línea tuya, y todas y cada una se le han accionado a alguien en los últimos años. Ese es el argumento real para mantener tu loop portátil. No para perseguir un leaderboard, sino para que el día que cambie el trato, puedas marcharte.

La versión buena de la pregunta

La versión buena de la pregunta de la herramienta tiene respuesta, porque nombra sus restricciones. La mejor para refactors grandes que tienen que caber en un solo contexto. La mejor con un presupuesto mensual fijo. La mejor para código que no puede salir de nuestras máquinas. La mejor en el lenguaje en el que trabajamos de verdad. Esas tienen respuesta. "¿Cuál es la mejor herramienta de IA para programar?" no la tiene, porque nunca dice mejor en qué. Así que descomponla, y cambia a propósito y no por impulso: cuando hayas nombrado una capacidad que te falta y hayas hecho una comparación justa. Guarda también un poco de tiempo para explorar, mirando qué adopta de verdad la gente en la que confías, porque el cambio que más importa a veces es hacia una categoría que no sabías que existía.

Elegí mi setup así y luego dejé casi de pensar en ello. Las instrucciones del proyecto, las specs y los hábitos de revisión se conservan; solo el modelo de debajo cambia con la tarea. Las herramientas que he construido apuntan en la misma dirección: un pipeline que convierte una frase en un plan y abre sus propias pull requests, un control plane que gobierna flotas de agentes. A ninguna le importa qué modelo tiene detrás. Son andamiaje alrededor del mismo loop.

Y esto va más allá de mis propias herramientas, porque la mayor parte de lo que parece un producto de IA nuevo está construido sobre modelos de frontera que cualquiera puede alquilar. He ayudado a construir productos que hacen trabajo serio en derecho, en salud, en investigación científica y en auditoría, y ninguno corre sobre un motor secreto. Dentro hay un pipeline: varios pasos con sus propias dependencias, a menudo modelos distintos en pasos distintos por razones distintas, uno rápido donde la restricción es la latencia, uno profundo donde lo es el razonamiento, la misma división que hago yo en mi escritorio. Pero todos los modelos de la cadena salen del mismo menú corto del que piden los competidores. Lo que hace que estos productos merezcan pagarse es todo lo que rodea a los modelos: el retrieval sobre fuentes que importan de verdad, el grounding que mantiene la respuesta anclada a esas fuentes, el flujo de trabajo moldeado a cómo funciona la profesión en realidad. Los modelos no son el foso de nadie. El valor se acumula alrededor de ellos, no dentro, y esa es la misma lección a otra altitud.

Lo que de verdad te quedas

Así que persigue una herramienta durante una semana si quieres, y luego hazte bueno. El modelo que usas será reemplazado por uno genuinamente mejor en un calendario que no controlas, y aun así no salvará al desarrollador que nunca aprendió a especificar ni a leer. La forma en que piensas un problema y el ojo que detecta la línea equivocada siguen siendo tuyos en cada cambio. Una de esas cosas merece que la construyas. La otra merece una semana de tu atención, y una salida que mantienes abierta.