El sábado vi pasar dos posts más en el feed que dicen lo mismo desde micrófonos distintos. Andrew Chen (@andrewchen) tuiteó el 3 de mayo con cinco palabras: “bullish on the PM role quietly becoming the most important role in tech again” (alcista en el rol de PM volviendo calladamente a ser el más importante en tecnología). 140K vistas, 1,400 likes, 203 respuestas, 166 retweets. Aakash Gupta lo expandió en LinkedIn el mismo día con 1,210+ reacciones y 71 comentarios, citando los números reales del equipo de Claude Code en Anthropic.

Lo que ambos están diciendo, desde micrófonos distintos: cuando construir se volvió barato, la persona que decide qué construir se volvió el último recurso escaso.

Los números de Boris Cherny que no tienen versión PowerPoint

Aakash citó al equipo de Claude Code en Anthropic. Las cifras del jefe del equipo, Boris Cherny:

• 5 instancias de Claude corriendo en paralelo
• 20 a 30 pull requests despachados al día
• Cowork construido como producto completo para usuarios no ingenieros en aproximadamente 10 días
• +70% de productividad por ingeniero, medida con Anthropic triplicando headcount al mismo tiempo
• Los PMs revisan software funcionando a las 9 a.m. cada día. Para el mediodía, han matado el 80%. Lo que sobrevive sale ese viernes.

Los PMs en Anthropic ya no escriben PRDs tradicionales. Revisan prototipos vivos en pantalla y deciden cuáles tres de los quince valen el segundo turno. La decisión vive a velocidad de jornada laboral, no de sprint.

El número que la prensa no citó

Aparece dos párrafos antes del cierre del post de Aakash, sin negrita: “AI PM offers at OpenAI, Anthropic, and Google DeepMind now run past $1M total comp” (las ofertas de PM con IA en OpenAI, Anthropic y Google DeepMind ya pasan el millón de dólares de compensación total). Más de un millón. Un PM con criterio calibrado para matar el 80% en una mañana cobra lo que un VP de Ingeniería cobraba hace cinco años.

El mercado le puso precio a la nueva escasez antes de que el coro terminara de discutirla. Cuando un PM se llevaba seis semanas para llegar a un release, esa decisión se podía contratar a salario de PM. Cuando un PM toma esa misma decisión cada mañana, contra software funcionando, esa decisión vale lo que valía construir el software hace cinco años.

El coro alrededor del post de Aakash

Setenta y un comentarios, varios con peso. Vale leer al coro entero, no solo a los que están de acuerdo:

• Kath Champion: “The bottleneck didn’t move to PM. It moved to decision quality under speed” (el cuello no se movió al PM, se movió a la calidad de la decisión bajo velocidad). Cuando construir toma 45 minutos, las malas decisiones escalan al instante y los prototipos se vuelven distracción. La habilidad no es construir rápido; es mirar varias versiones funcionando y saber cuál sirve.
• Palash Somani lo dijo más corto: “Speed didn’t make decisions easier, it just made bad decisions cheaper to recover from” (la velocidad no hizo las decisiones más fáciles, solo hizo las malas decisiones más baratas de recuperar). Antes el costo de equivocarse se medía en sprints. Ahora se mide en horas.
• Saeed K metió la objeción útil: enmarcar personas y funciones como “cuellos de botella” es incorrecto a menos que sean una disfunción real. Tiene razón parcial. El cuello no es el PM. Es el criterio. Y el criterio puede vivir en distintos lugares de la org. Lo que importa es que sea explícito y nombrable, no que tenga un cargo.
• Rakesh Kothari subrayó el riesgo del lado opuesto: “Beware of shadow PMs, i.e. senior engineers who think they have product taste but unfortunately don’t” (cuidado con los PMs sombra, ingenieros senior que creen tener gusto de producto y no lo tienen). Cuando construir se vuelve barato, todo el que puede construir cree que tiene derecho a decidir.
• Yasir Ahmed Sheikh: “In enterprise AI, judgment isn’t just valuable, it’s load-bearing” (en IA empresarial, el criterio no solo es valioso, es estructural). Una mala decisión en una app de consumo se arregla en el siguiente sprint. Una mala decisión incrustada en un workflow de ERP la heredan todos los procesos downstream.
• Rohit Gajaraj dejó la frase más afilada del hilo: “Taste without exposure is just opinion” (gusto sin exposición es solo opinión). El criterio no se entrena leyendo a Jobs ni a Karpathy; se entrena viendo a 50 clientes usar el producto y matando los 47 que estaban mal.

Cinco ciclos desde 1990. Lo barato cambia. Lo escaso sube un piso.

Llevo 36 años en computación. Empecé en 1990, a los 15, con una Commodore 64 y una Texas Instruments. He visto este movimiento cinco veces. Una capa se vuelve barata; la de arriba, escasa. La industria pasa tres a cinco años quejándose del nuevo cuello, hasta que alguien le pone precio.

Inicio de los 90 — ensamblador a alto nivel. Escribir código se volvió barato. Diseñar el sistema correcto, no. La industria pasó la década quejándose de “no encontramos arquitectos” antes de aceptar que el escaso ya no era el codeador.

Mediados de los 2000 — on-prem a cloud. Aprovisionar un servidor pasó de seis semanas a seis minutos. Decidir la arquitectura distribuida correcta no se aceleró. Cinco años de “no encontramos ingenieros de cloud” cuando lo escaso era criterio de arquitectura, no familiaridad con el SDK.

Finales de los 2000 — QA manual a tests automatizados. La automatización abarató las pruebas, pero el criterio de qué probar no se automatizó. Los equipos terminaron con 8,000 tests verdes que no atrapaban regresiones porque nadie había decidido cuáles 200 valían correr.

Década de 2010 — custom a SaaS. Construir herramientas se volvió barato. Decidir qué integrar, para qué proceso y con qué dueño, no. Las empresas terminaron con 47 SaaS pagados, 12 usados de verdad y 35 contratos autorrenovándose porque nadie tenía la decisión asignada.

2026 — modelo a harness. Generar 15 prototipos en una mañana se volvió barato. Decidir cuáles 3 escalar, no. Anthropic le puso precio. El resto de la industria todavía no.

Cinco ciclos, mismo movimiento. La diferencia es la velocidad: el ciclo anterior tomaba cinco años en revelar dónde quedó el cuello. Este lo reveló en seis meses.

La pieza hermana del 14 de abril

Hace tres semanas escribí sobre deuda de criterio (taste debt). Esa pieza es el lado downstream del problema: lo que se acumula cuando sacas humanos del loop de ejecución demasiado pronto: la calidad del entregable se degrada porque nadie revisa con criterio. Esta pieza es el lado upstream: cuando construir se volvió barato, decidir qué construir es la nueva escasez.

Son piezas hermanas. La primera mide la calidad del trabajo terminado. La segunda mide la calidad de la elección de qué trabajo hacer. Las dos cargan peso. Las dos requieren criterio explícito y nombrable. Y las dos fallan en la misma forma: cuando nadie en la sala se siente cómodo diciendo “esto no” sobre algo que ya está construido y se ve bonito.

Lo que IQ Source hace con esta distinción

AI Maestro nombra cuáles 3 de los 15 prototipos vale la pena escalar. La auditoría no produce más prototipos: produce la lista corta y el criterio detrás de cada elección, en formato que sobrevive al cambio de gerente o de ingeniero senior. Es la versión institucional de lo que Boris Cherny hace a las 9 a.m. en Anthropic, traducida a una empresa que no tiene 5 instancias de Claude corriendo en paralelo todavía pero pronto las va a tener.

Socio Tecnológico entra cuando tu producto no es solo cliente del problema sino productor. Empresas de software cuyo roadmap es el moat (la ventaja competitiva) tienen una pregunta de gobierno distinta: cómo se documenta y se versiona el criterio de qué se construye, de modo que la siguiente persona en la silla pueda defender la decisión seis meses después. La respuesta no vive en slides. Vive en la lista de cosas que matamos y por qué.

El 27 de abril escribí que el código no es barato: el costo real está en las decisiones de qué código tener. El runtime se commoditizó hace tres semanas. El harness se reveló como ingeniería el 1 de mayo. Y hoy: el rol que decide qué corre encima del harness se reveló como la nueva escasez.

Cinco preguntas para tu próximo standup de producto

Si tu equipo viene de una semana donde nadie cree que se decidió bien, vale la pena meter estas cinco preguntas antes de la siguiente:

1. Volumen. ¿Cuántos prototipos hizo tu equipo la semana pasada, y quién decidió cuáles 1 o 2 mantener? Si la respuesta es “no medimos eso”, el cuello de botella ya no es construir; pero nadie en el equipo lo sabe.
2. Tasa de matanza. ¿Cuál es tu kill rate de prototipos? Si es menor al 50%, no estás construyendo lo suficiente. Si es 95%, quizás sí estás construyendo, pero no estás eligiendo bien al inicio.
3. Hora del día. ¿Quién en tu equipo revisa software funcionando a las 9 a.m., no slides a las 2 p.m.? Si la respuesta es “los slides son para alinear”, la alineación se está pagando con el costo de oportunidad de los 14 prototipos no revisados.
4. Defendibilidad. ¿Hay un dueño nombrado de “lo que enviamos” que pueda defender la decisión seis meses después? No “lo aprobamos en comité”. Defender, con la lista de qué se mató y por qué.
5. Pago. ¿Estás pagando por confianza (CV, cargos previos) o por calibración demostrada (track record de qué mató, no solo qué envió)? Anthropic acaba de reescribir el techo del segundo grupo. Vale revisar antes de la próxima oferta.

Si tu siguiente release tiene 30 prototipos en backlog y nadie ha decidido cuáles 3 van, tienes el problema correcto. Si nadie está construyendo 30, también tienes un problema, pero distinto. Una conversación de noventa minutos te da una vista cruda de tu kill rate real, dónde vive el cuello de botella en tu org y qué decisiones llevan tres meses sentadas en backlog esperando a que alguien las tome con criterio. info@iqsource.ai.