Un amigo que trabaja como ingeniero en Estados Unidos me mandó esta semana una nota que no hubiera podido publicar en la intranet de ninguna gran empresa europea. No por ser políticamente incorrecta, sino por algo más prosaico: en muchas organizaciones del viejo continente, la sola idea de usar dos modelos de inteligencia artificial en producción —sin aprobación de tres comités— es impensable. Lo que él hace a diario aquí se debatiría durante meses. Os lo comparto porque es uno de los experimentos más honestos y útiles que he leído sobre el uso real de IA en el desarrollo de software.
El problema que nadie nombra: los tokens de exploración
Cuando usas un asistente de código con capacidad de acción —un modelo que puede leer tu proyecto, buscar archivos, editar y ejecutar pruebas— la tentación es hablarle como a un compañero de equipo muy listo: "arregla esto", "tú decide", "mira cómo está hecho". Y funciona. Pero tiene un coste que no aparece en la primera factura: cada búsqueda, cada archivo abierto, cada recorrido del árbol de directorios es una instrucción que se paga en tokens.
Mi amigo lo describe con una analogía que me parece perfecta: es como programar en ensamblador. El modelo recorre cajón por cajón hasta encontrar el tornillo. Técnicamente correcto. Caro. Si en lugar de eso le das un texto más parecido a un programa —qué archivos son relevantes, qué no puede tocar, cómo sabe que ha terminado— el modelo ejecuta directamente. Ya no busca el programa. Lo tiene.
Ese es el salto. El mismo salto de siempre en la historia de la informática: dejar de decirle al procesador cada movimiento y nombrarle lo que quieres. Solo que aquí el procesador es Claude Code, y quien tiene el proyecto entero montado eres tú.
El tándem: Grok como compilador, Claude como runtime
La arquitectura que describe es elegante en su sencillez. Tres capas:
- Arriba, el humano: qué quiere, qué va primero, qué es urgente hoy.
- En medio, Grok: traduce esa intención a un encargo estructurado. Qué archivos existen para este trabajo, qué puede cambiar Claude y qué no, cómo se medirá el éxito (una prueba, una métrica, una pantalla).
- Abajo, Claude Code: ejecuta. Manos en el disco, en las pruebas, en el servidor.
Nadie diseñó este lenguaje en una pizarra. Emergió. El punto de partida era más sencillo: dos modelos en tándem, uno que implementa y otro que revisa sin tocar el código. El problema fue que, si los dos recorrían el mismo árbol de directorios para entender el contexto, el tándem no ahorraba nada. Duplicaba el ensamblador. Hacía falta un texto compartido que los dos pudieran obedecer sin redescubrir el mundo. Ese texto acabó siendo el encargo. Y quien lo escribe, turno a turno con el humano, es Grok.
El resultado medible: los tokens que bajan en la sesión de Claude son, sobre todo, los de exploración. El trabajo de escribir la función no desaparece. Se acota, se nombra, y a veces se delega a otra máquina. El compilador no borra el programa; evita que el CPU recorra todo el disco para saber por dónde empezar.
Lo que esta analogía no cubre
Mi amigo es honesto aquí, y eso le da credibilidad. Un lenguaje de alto nivel no impide un bucle infinito. Un encargo mal redactado —"mira esto y decide"— es ensamblador disfrazado. Un veto demasiado estrecho puede tapar exactamente el arreglo que hace falta. La capa intermedia ahorra exploración, no criterio.
Tampoco es un producto. No hay nada que instalar. Es un efecto: el efecto de querer a Claude y a Grok trabajando juntos sin dejar que cada uno recompile el mundo por su cuenta. Si alguien junta los dos modelos y no escribe el encargo, no obtiene el ahorro. Obtiene dos exploraciones en paralelo.
¿Por qué esto es impensable en muchas empresas europeas?
La pregunta que me dejó su nota. No es una cuestión técnica. Es cultural y regulatoria. En muchas grandes organizaciones europeas, el proceso de aprobación de herramientas de IA es tan largo que para cuando un equipo puede usar legalmente un modelo en producción, han salido tres versiones nuevas. El ingeniero en EE.UU. que me mandó esto lo prueba, lo mide, lo ajusta y lo descarta o lo adopta en semanas. Esa velocidad no es un detalle. Es la diferencia entre experimentar con IA y hablar de experimentar con IA.
No digo que los controles europeos sean inútiles. Digo que hay un coste real en la lentitud, y que ese coste también se paga en tokens: los de oportunidad.
Artículo adaptado de una nota técnica compartida por un ingeniero de software en Estados Unidos. Por Grok + un humano al teclado — cuando se deshaga de él, ya nos avisará.
