Aakash Gupta publicó ayer un hilo que cierra con una sola frase que vale como tesis de mercado:

Quien resuelva la revisión a escala gana todo este mercado.

El contexto: OpenAI ofreció $3.000 millones por Windsurf. Google pagó $2.400 millones por el CEO y los investigadores. Cognition agarró lo que quedó — el producto, el IDE, 350 clientes empresariales, $82 millones de ARR — por unos $250 millones. Aakash lo llama “la mejor compra en IA de código”. Tiene razón, pero no por los múltiplos.

Tiene razón por la conversión que esa compra acaba de posibilitar.

Dos apuestas opuestas sobre dónde vive el humano

Cognition ya tenía a Devin, el agente autónomo que corre en su propia máquina virtual con navegador, escritorio y uso completo de computadora. Devin pasó de $1 millón de ARR en septiembre de 2024 a $73 millones en junio de 2025. Adopción técnica fuerte. Problema de producto grande: un agente autónomo que vive fuera de tu editor es un agente al que se te olvida mirar. Nadie sale del IDE para abrir otra herramienta.

Windsurf le dio a Devin la puerta de entrada que le faltaba. Windsurf 2.0 convierte el IDE en un tablero Kanban de agentes. Planificas local, delegas tareas con un clic, cierras el laptop, y a la mañana siguiente despiertas con PRs abiertos.

Ese es el punto clave: es el primer producto de código que explícitamente te pide que dejes de mirar.

Cursor fue en la dirección contraria. Cursor 3.0 se lanzó este mes con una interfaz “agente primero” para manejar flotas paralelas de IA localmente. Cada agente necesita tu pantalla abierta. Cursor llegó a $2.000 millones de ARR en febrero, duplicándose en tres meses. El producto mejora cuanto más atención le das.

Cognition hizo lo opuesto: el producto mejora cuanto menos atención le das.

La brecha de ingresos todavía es enorme — $2.000 millones contra unos $155 millones combinados de Cognition más Windsurf. Pero las categorías ya se separaron. Cursor vende experiencia de programación más rápida. Cognition vende capacidad de ingeniería medida en horas de cloud.

Y las dos apuestas chocan con la misma pared.

La pared se llama 90%

Chamath Palihapitiya lo nombró ayer con la franqueza de siempre: el 90% del código dentro de una empresa es mantener y migrar cosas complicadas y desordenadas que ya existen. Vibe coding sirve para el 10% restante — lo greenfield, lo simple, lo que empieza en blanco.

Chamath habla con autoridad porque creó 8090, una empresa dedicada exactamente a ese 90%. Fortune 500 contratándolo para migrar sistemas complejos, reescribir código viejo, mantener decisiones que nadie documentó. No es teoría. Es su negocio.

Nikunj Kothari lo puso en imagen. Publicó el 14 de abril un diagrama del sistema de notificaciones de Slack: cuarenta y pico de nodos de decisión, canal muteado, usuario en DnD, menciones @channel, hilos suscritos, prefs globales, prefs por canal, tiempos de push móvil. El comentario de Nikunj es corto: “Cada vez que veo un tweet diciendo ‘puedo codear esto en un fin de semana’ pienso en el sistema de notificaciones de Slack”. No es un ejemplo retórico. Es un mapa. Nadie one-shotea ese mapa. Ni siquiera si el modelo es perfecto.

Un reply a Chamath lo hizo explícito: el 10% es vibe-codeable porque tú defines la interfaz. El 90% es duro porque la interfaz la definieron mil decisiones tomadas antes de que llegaras. Chesterton’s Fence aplica a cada sistema legacy. No puedes refactorizar lo que no entiendes.

Junta las dos observaciones y el resultado es obvio: el futuro donde Devin abre PRs de noche choca de frente con la realidad de que esos PRs tocan código que nadie del equipo entiende completamente. Y ahí te encuentras con el punto que Aakash dejó al final del hilo.

El cuello de botella se movió

Hace un mes escribí sobre revisión de código a nivel de PR individual. El problema de ese post era de calidad: el autor acepta la sugerencia de Copilot, el revisor ve código que nadie del equipo escribió, la cadena de explicación se rompe. Ese problema sigue vivo y sin resolverse.

Lo que acaba de aparecer es un problema distinto, una capa arriba.

Si cinco agentes Devin envían código de noche, despiertas con PRs en cinco repositorios tocando lógica que nunca habías leído. No es que el autor no pueda explicar. Es que no hay autor disponible cuando llega la pila. El cuello de botella pasa de escribir a revisar. Y revisar código agéntico generado en volumen es una habilidad que la mayoría de equipos nunca construyó, porque durante treinta años el supply de PRs estuvo acotado por cuánto podía escribir un humano.

Ese supply se acaba de desligar del humano. La demanda de revisión no.

Por eso la línea de Aakash es la tesis de mercado: quien construya la infraestructura que hace revisable la producción de una flota de agentes captura este ciclo. No quien construya el agente más rápido.

Tres deudas, el mismo pasivo

Llevo dos posts seguidos nombrando la misma mecánica con etiquetas distintas:

• Deuda de criterio, el 13 de abril. Sacar al humano del loop demasiado pronto te factura en marca, en decisiones sin examinar y en clientes que dejan de reconocer tu voz.
• Deuda de consumo, el 15 de abril, a propósito del presupuesto de IA quemado de Uber. Agentes corriendo en loops sin cortacircuitos aparecen directo en el P&L.
• Deuda de capacidad de revisión. Esto. Los agentes producen más PRs de los que tu equipo puede revisar con criterio, y el cobro llega en incidentes de producción, MTTR alto y clientes afectados.

Son caras distintas del mismo pasivo. Y se amortizan del mismo modo: instrumentando revisión humana adentro del flujo, no encima del flujo. Diagnóstico compartido: el modelo mental heredado — SaaS por asiento, reviews en horario de oficina, estimaciones anuales — se diseñó para un mundo donde la producción estaba acotada por humanos. Ese mundo se acabó.

Qué funciona para revisar a escala

Tres cosas que sí escalan, y una que no.

Muestreo ponderado por riesgo. Revisar cada PR de un agente con el mismo peso es matemáticamente imposible. Revisar por bandas sí funciona: cualquier cambio en dominio crítico — facturación, auth, datos de clientes — pasa por revisión humana completa; cambios en zona baja, como renames o updates de dependencias con tests sólidos detrás, corren con muestreo aleatorio. El muestreo no detecta todos los errores. Detecta los que valen detener el merge.

Invariantes duras que el agente no puede saltear. Tests de contrato, property tests, mutation testing. No dependen de que un humano revise a tiempo. Dependen de que el agente no pueda llegar a producción sin que una condición objetiva se cumpla. Esto es lo que Shopify está armando con procesos donde los agentes abren PRs pero el merge requiere que gates específicos pasen antes de que un humano ni siquiera mire.

Radio de impacto por ejecución. Límite explícito: un agente no puede tocar más de N archivos, más de M módulos, o cruzar fronteras de capas sin aprobación humana. El objetivo no es prevenir el trabajo. Es contener el blast radius cuando se equivoca. Cinco PRs que tocan cada uno su propio servicio son manejables. Un PR que refactoriza cinco servicios de un jalón no es revisable por nadie con tiempo finito.

Y la cosa que no funciona: contratar más revisores. Si tu supply de PRs es agéntico y exponencial, y tu supply de revisores es humano y lineal, estás perdiendo la carrera matemática desde el primer día.

Lo que hacemos en IQ Source

Cuando una empresa nos contrata para escalar agentes en producción, lo primero que preguntamos no es qué agente van a usar. Es quién va a revisar lo que produzca cuando corra de noche, cuando corra de madrugada, cuando corra los domingos.

Si la respuesta es “el mismo tech lead que hoy revisa PRs de humanos en horario de oficina”, el despliegue no funciona.

Lo que instalamos con Team OS es exactamente la capa que Aakash describió sin nombrarla: un modelo de revisión que escala con la producción agéntica, no con headcount. Muestreo por riesgo, invariantes duras, radio de impacto limitado, y gates humanos atados a costo y riesgo real, no a conteos de líneas.

Antes de autorizar el próximo agente en producción, dibuja en papel quién lo va a revisar cuando abra un PR a las 3 AM. Si el dibujo te sale en blanco, ya sabes la conversación que tenemos que tener.