El martes 21 de abril, Linas Beliūnas publicó en LinkedIn que Google armó un strike team liderado por Sergey Brin para cerrar la brecha con Anthropic en código. La cifra que disparó la reacción es la que está incomodando salas de juntas esta semana: en Google alrededor del 50% del código nuevo lo escribe IA. En Anthropic, casi el 100%. Brin entró en persona porque a esa brecha el comité ejecutivo no le encontró otra explicación.

La noticia se lee como victoria de Anthropic. Pero abre una pregunta más interesante. Si el modelo es el mismo Claude Opus 4.7 que cualquiera puede comprar por API, ¿por qué Anthropic puede correr al 100% y Google necesita un strike team para llegar al 50%?

La respuesta no es que Anthropic tenga un Claude secreto. Es que Anthropic tiene el codebase correcto para que Claude trabaje al 100%. La mayoría de los equipos de software no.

El testigo incómodo del lado del que enseña

Matt Pocock enseña un curso llamado “Claude Code for Real Engineers” (Claude Code para ingenieros de verdad). Vive vendiendo IA a desarrolladores. La semana pasada dio una charla en una conferencia donde dijo algo que en los keynotes de los vendors no se escucha. Probó el famoso flujo specs-to-code, el de moda en threads de X: escribir una especificación en markdown, dejar que la IA genere código, no mirar el código, solo cambiar la spec si algo falla. Su reporte: cada iteración produjo código peor que la anterior. Más bugs, menos coherencia, más deuda. El compilador de IA nunca convergió.

Su frase, en el original que dio en escena: “code is not cheap. In fact, bad code is the most expensive it’s ever been” (el código no es barato; de hecho, el mal código es más caro que nunca). El razonamiento, que cualquier CTO con cinco años de oficio debería tener pegado en la pared: cuando la IA puede entregar diez veces más código en el mismo tiempo, un codebase difícil de cambiar absorbe ese aumento de velocidad y lo convierte en basura. La velocidad sin arquitectura es deuda compuesta.

La salida que Pocock propuso no fue comprar un modelo más caro. Fue volver a tres libros que llevan veinte años en la repisa. A Philosophy of Software Design de John Ousterhout, que define complejidad como cualquier cosa en la estructura del sistema que hace difícil entenderlo o modificarlo. Domain-Driven Design de Eric Evans, que introduce la idea de un lenguaje ubicuo compartido entre desarrolladores, expertos de dominio y, ahora, agentes. The Pragmatic Programmer de Hunt y Thomas, con su capítulo sobre entropía del software: cada cambio que se hace pensando solo en ese cambio y no en el sistema entero degrada el codebase un poco más.

Lo que Pocock describe es lo que cualquier libro de ingeniería de software de los últimos veinte años llama buenas prácticas. La diferencia es que antes de la IA esas prácticas eran preferencia. En un equipo con 15 desarrolladores, un codebase mal estructurado costaba reuniones de planning, onboarding largo y commits que se rompen los viernes. El equipo igual lograba avanzar. Con un codebase mal estructurado y una IA escribiendo el 80% del código, el equipo deja de avanzar.

La factura del que mide

Pawel Huryn es PM con 130 mil suscriptores en su newsletter de producto. El sábado 25 de abril, publicó en X una pieza con 261 mil vistas. El título: “Claude Code’s Limits Are Generous. The Problem Is Your Harness” (los límites de Claude Code son generosos; el problema es tu harness, tu instrumentación).

El dato que abre la pieza es el que más interesa al CFO. Hace un mes Huryn pagaba $750 mensuales por Claude Code Max 20x más extra usage. Hoy paga $100. Mismo flujo de trabajo. Mismo modelo. Misma cantidad de prompts. La diferencia: limpió el harness.

Las cuatro palancas que lista Huryn son específicas y medibles.

Cache misses. Cada vez que cambias herramientas o modelo en medio de una sesión, el cache prefix de Anthropic se invalida y el siguiente turno se factura como token nuevo, no como cache read (que cuesta una décima parte). Hit rate saludable: 90% en cache de cinco minutos. Hay que fijar las herramientas y el modelo al inicio de la sesión.

Context bloat. Si dejas que la sesión crezca a 1M de contexto, cada turno paga por 1M de tokens. Compactar al 50%. Separar trabajos no relacionados con /clear. Usar subagentes para tareas mecánicas que no necesitan el razonamiento del padre.

Model routing. Opus por defecto cuesta 5x más que Sonnet y 25x más que Haiku. Enrutar cada subtarea al modelo más barato que la pueda hacer bien. Tareas mecánicas a Haiku, exploración a Sonnet, planificación con tradeoffs a Opus.

Input format. Pasar PDFs como pdftotext, no como imagen. Browsing con accessibility tree, no con screenshots (~90% menos tokens). Esos cambios bajan el conteo 80% en tareas que tocan documentos o web.

Ninguna de esas cuatro palancas requirió un modelo nuevo. Ninguna requirió pagar más. Lo que requirió fue tratar al harness como producto, con su propia disciplina de medición y mejora continua. Que es, otra vez, lo que un buen ingeniero llamaría buenas prácticas.

La validación que cierra el cuadro

El domingo 26 de abril, Guillermo Rauch, CEO de Vercel, escribió que los agentes de código van a ser la base de toda la superinteligencia. La razón: la habilidad de programar es indistinguible de la “proficiency with computers” (competencia con computadoras). El agente que domina bash, filesystems, configuración e instalación de programas también puede examinar su propio código, su estado, sus instrucciones, y proponer cambios a sí mismo. Lee Robinson, también de la órbita Vercel, agregó la observación que hace un año no era obvia: “it wasn’t obvious to me one year ago that an excellent coding agent would also be the path to a general agent for all knowledge work” (no era obvio para mí hace un año que un excelente agente de código también sería el camino hacia un agente general para todo el knowledge work). Si el agente de código es la base, entonces el codebase sobre el que ese agente corre es la base de la base. Esa capa no se va a convertir en commodity pronto, porque es la única que captura el contexto único de tu negocio.

El patrón que llevo viendo desde 1990

Llevo 36 años en esto. Empecé en 1990, a los 15, programando en una Commodore 64 y en una Texas Instruments. Desde entonces he visto al menos cinco veces el mismo patrón: una capa de infraestructura se vuelve barata, todos asumen que eso significa que ya no importa, y cinco años después descubren que la capa que está sobre la barata es lo que define quién gana.

Cinco ejemplos rápidos antes de seguir. En 1995, cuando Intel hizo los procesadores accesibles a la mayoría de las empresas, la gente que no estudió Big O ni diseño de algoritmos descubrió rápido que CPUs baratos no compensan código mal escrito. La fibra y el DSL llegaron a inicios del 2000 a precios que diez años antes parecían ciencia ficción, y los frontends que no optimizaban payloads siguieron sintiéndose lentos sin importar cuánto ancho de banda hubiera. AWS reescribió el costo del compute a partir de 2010, y muchos equipos descubrieron que cloud barato más arquitectura mal hecha igual a factura de seis cifras antes del primer trimestre, no a escalabilidad. El SaaS de la segunda mitad de la década comprimió el costo del software empresarial de licencias de seis cifras a suscripciones de tres, y los flujos de trabajo mal diseñados terminaron pagando suscripciones que no movieron la aguja del P&L.

Toca el quinto ciclo. Los tokens de IA están bajando hacia los $0.08 la hora de runtime que Anthropic acaba de poner como precio de referencia, y modelos de tier dos como GLM-5.1 ofrecen el mismo desempeño que Opus a una décima parte del costo. La tentación es repetir el mismo error de los cuatro ciclos anteriores. Confundir el abaratamiento de la capa con el fin de su importancia.

Lo barato del ciclo no es el problema. El problema es lo que está sobre lo barato. Y lo que está sobre lo barato esta vez es el codebase. Ese es el moat (ventaja competitiva) real de los próximos cinco años, y es exactamente la pieza que Anthropic ya tiene y la mayoría no.

El matiz que hace la diferencia

Hay una distinción importante entre el codebase que se rediseña cada año adentro de un producto SaaS y el codebase que es el producto. Para el primero, una arquitectura imperfecta es deuda técnica que se paga con el tiempo; el equipo igual cobra suscripciones. Para el segundo, el codebase es el balance sheet. Cada decisión de arquitectura es una línea en el activo o en el pasivo, según si recompensa o castiga al agente que va a vivir ahí los próximos cinco años.

Ese segundo grupo es la audiencia más expuesta a este cambio. Empresas de software cuyo producto vive en el codebase desde el día uno. Automatización industrial. EdTech con AR. Plataformas verticales de fintech LatAm. Software médico. ERPs especializados. Cada una tiene un dominio que su equipo entiende mejor que nadie, y eso no vale la pena reaprender. Pero la mayoría no tiene a nadie en el equipo que haya pasado los últimos seis meses pensando en cómo se diseña un codebase para que un agente lo pueda mantener sin que el costo por turno se dispare a Opus por defecto.

Es exactamente el lugar donde la conversación del fugazi de la semana pasada aterriza en operación. El one-shot es un demo. El codebase real, donde clientes que pagan hacen transacciones, sigue siendo trabajo.

Qué hacemos en IQ Source con esta distinción

Socio Tecnológico existe específicamente para empresas de software cuyo producto vive en el codebase desde el día uno. No es staff augmentation. No es una agencia que mete manos en cualquier cosa. Es un socio que entra al equipo del cliente con una tesis específica: que el codebase, no el modelo, es el moat de los próximos cinco años, y que diseñarlo para que recompense a los agentes en lugar de castigarlos requiere oficio que se compra por hora.

Lo que medimos en el primer mapa no es complicado, pero requiere disciplina. ¿Los módulos son profundos o superficiales? Un módulo profundo, como lo describió Ousterhout, tiene mucha funcionalidad detrás de una interfaz simple. Un módulo superficial tiene poca funcionalidad detrás de una interfaz complicada. Los codebases superficiales son los que vuelven loca a la IA, porque para entender algo simple tiene que recorrer veinte funciones distintas. ¿Existe un lenguaje compartido entre el equipo y los agentes, o cada función llama a la misma cosa con tres nombres distintos? ¿El test boundary está en la interfaz del módulo, o esparcido entre los detalles internos? ¿Alguien en el equipo es dueño del harness, mide cache hit rate, sabe cuándo invalidar prefix, y puede mostrar la curva de costo por feature entregado?

Ninguna de esas preguntas requiere un modelo nuevo. Las cuatro requieren a alguien que haya vivido en codebases reales con agentes reales el suficiente tiempo para haberse equivocado y haber corregido el patrón. Eso es lo que un Socio Tecnológico vende: tiempo ya invertido, errores ya cometidos, patrón ya estabilizado.

AI Maestro, la otra línea, aplica cuando la pregunta no es “cómo diseño mi codebase para agentes” sino “dónde tiene sentido la IA en mi operación y dónde no”. Las dos líneas se complementan, pero responden a preguntas distintas y se contratan en momentos distintos del ciclo de la empresa.

Cinco preguntas antes de firmar el siguiente cheque de productividad de IA

Si el comité ejecutivo va a aprobar el siguiente cheque de productividad de IA, hay un test corto que vale la pena correr antes de firmar.

Empieza por la pregunta más concreta: ¿el codebase recompensa a los agentes o los castiga? Una semana de medición lo revela. Si la IA produce código que empeora cada iteración (como reportó Pocock en su charla), el codebase está castigando. Si el código generado se integra limpio, está recompensando.

Sigue con el lenguaje. ¿Está capturado en algún lado el vocabulario compartido entre el equipo y los agentes? Y aquí no cuenta el wiki desactualizado. Cuenta un documento vivo con los términos de dominio, los nombres canónicos de las entidades y los invariantes que no se rompen. Si no existe, la IA inventa tres versiones distintas del mismo concepto en tres archivos distintos y nadie se entera hasta que el bug llega a producción.

La tercera revisa los tests. Idealmente viven en la interfaz del módulo, no esparcidos entre los detalles internos. Cuando los tests están en la interfaz, el agente puede reescribir todo lo que está adentro sin romper el contrato. Cuando están dispersos, cualquier refactor del agente rompe veinte tests por la razón equivocada.

Cuarta y quinta van juntas. ¿Alguien mide el cache hit rate? ¿Alguien es dueño del harness con nombre y apellido? Si la respuesta a la primera es no, estás pagando 10x lo que deberías pagar por cada turno de modelo. Si la respuesta a la segunda es “todo el equipo” o “el lead de IA”, la respuesta operativa es nadie, y el harness se va a degradar al ritmo del próximo Opus.

Si tu equipo no contesta las cinco con claridad, la siguiente conversación útil dura dos horas. Mapeamos uno de tus repos, respondemos las que sí se pueden contestar hoy, y dejamos por escrito qué requiere intervención. Sin cotización atada. El correo es el de siempre: info@iqsource.ai.

Brin entró en persona. Pocock dejó de hablarle al modelo y volvió a leer Ousterhout. Huryn limpió el harness y bajó la factura siete veces. Las tres historias suenan distintas, pero terminan en el mismo lugar. El código no es barato. El que diseña el codebase para los próximos cinco años, gana los próximos cinco años. El que asume que el modelo solo va a hacer el trabajo, paga la factura del que sí lo diseñó.