Saltar al contenido principal

Tres voces, mismo aviso: el one-shot es un espejismo

Chamath, Yongfook y Berder coincidieron en 24 horas: el AI one-shot no construye empresa. Edge cases, retención, trust y distribución no caben en un prompt.

Tres voces, mismo aviso: el one-shot es un espejismo

Ricardo Argüello

Ricardo Argüello
Ricardo Argüello

CEO & Fundador

Estrategia Empresarial 13 min de lectura

Entre el jueves 23 y el viernes 24 de abril, tres voces de tres rincones distintos del ecosistema de IA dijeron casi lo mismo en menos de 24 horas. No es una coincidencia editorial. Es lo que pasa cuando las señales ya están a la vista y solo falta que alguien lo diga en voz alta.

Ronan Berder publicó el 23 de abril a las 7:48 a.m. que está convencido de que la mayoría de las cuentas de IA en su timeline son humo. Que nadie está realmente “corriendo 20 agentes de un día para otro” construyendo software que la gente use. La pieza llegó a 765 mil vistas en menos de 48 horas. Cierra con una posdata autocrítica: “puede que tenga un IQ de 82 y no logre entenderlo”. Ese cierre es lo que la blindó. Si vas a llamar humo a algo, es más fuerte hacerlo dejando abierta la puerta de “puede que el del problema sea yo”.

Jon Yongfook respondió esa misma tarde. Yongfook lleva diez años corriendo Bannerbear, Clipcat y Roborabbit como SaaS bootstrapped, y reporta abiertamente $79 mil de MRR. Su línea: “la idea de hacer one-shot a una app con IA es un fugazi (estafa). Si tuvieras que describirme mi app con todos los edge cases que he resuelto, sería un prompt del tamaño de un libro chico, y mi app ni siquiera es complicada”. 387 mil vistas.

Chamath Palihapitiya cerró el patrón al día siguiente. “El ciclo de hype va a desvanecerse pronto, va a entrar el trough of disillusionment (valle de la desilusión), y muchas de estas promesas mágicas se van a deshacer junto con las empresas que las hicieron. El AI one-shot es una buena forma de crecer rápido, pero no convierte mágicamente los gross margins negativos en un buen negocio. La salida estrecha para esta gente es crecer superrápido y vender a tiempo (Windsurf, Cursor)”. 184 mil vistas.

Tres incentivos distintos. Un VC con cartera pública, un bootstrapper rentable, un indie maker que admite no ser el más listo de la sala. Mismo aviso. Esa es la noticia.

Lo que las tres voces estaban diciendo a la vez

Cada uno de los tres miró el mismo problema desde un costado distinto.

Berder lo encuadró como problema de evidencia. Él usa IA todo el día, escribe su propio código con agentes, mantiene devpu.sh y basecoatui.com; no es un crítico ideológico. Su problema es que las afirmaciones que más vistas tienen en su feed no las puede reproducir, y los que las hacen no enseñan en vivo cómo se hace. En sus propias palabras al responder en su hilo: “agents rarely run more than a few minutes at a time” (los agentes raramente corren más de unos minutos seguidos). Lo que está pasando, según Berder, no es que la IA no sirva; es que el formato dominante en redes está mintiendo sobre cómo se usa.

Para Yongfook el problema es de materia prima, no de retórica. Una app de producción, incluso una “no muy complicada”, está construida encima de una pila de decisiones tomadas en respuesta a usuarios reales. El edge case del email que llega con encoding raro. El cliente del país donde la moneda tiene cinco decimales en vez de dos. La integración de pago que cambia su API sin avisar. La cláusula de borrar datos que tiene que cumplir con el GDPR pero también con la ley brasileña, que no son compatibles entre sí. Esa pila no se describe en un prompt porque ni siquiera está completa en la cabeza del fundador; vive como respuestas reactivas en el código, en el changelog, en los workarounds que solo el equipo recuerda.

Chamath se fue al lado financiero, que es el que le toca por oficio. Aunque la app sí se haga overnight, los costos unitarios no cambian solo porque el código se generó rápido. Cada inferencia cuesta. Cada token cuesta. Los gross margins de un producto de IA dependen del costo del modelo, que sube con el uso, no baja. El que pagó $20 al mes y consume $200 en cómputo está costándole dinero al vendor cada día que sigue activo. La única salida documentada para ese tipo de negocio, dice Chamath, es venderlo a alguien con suficiente bolsillo para absorber la pérdida operativa por unos años, como hicieron Windsurf y Cursor.

Junta los tres ángulos y aparece la misma estructura. Edge cases, retención, soporte, costo real de inferencia, trust del cliente, distribución. Seis capas. Ninguna cabe en un prompt. Una respuesta cualquiera de Yongfook lo dijo más limpio que el resto: “you can one-shot the demo. you still have to pay for edge cases, retention, support, inference, trust and distribution” (puedes one-shot el demo; igual te toca pagar por los edge cases, la retención, el soporte, la inferencia, el trust y la distribución). Esa frase es el resumen de la conversación.

Por qué este aviso llega justo ahora

Este es el tercer post de la semana sobre la misma curva, vista desde tres alturas distintas.

El primero fue el lunes, cuando GitHub, Anthropic y xAI movieron precios en la misma semana y la era flat-rate de la IA se cerró. Ese post explica el lado de la oferta: el subsidio de adopción terminó porque el costo real del cómputo agéntico ya no cabe en planes de $20 al mes. El segundo fue el sábado, respondiendo al ensayo de Jaya Gupta. Ahí distinguí memoria de pattern recognition y argumenté que la experiencia mal usada es impuesto, pero la experiencia bien usada es moat (ventaja competitiva). El de hoy cierra el ciclo: si el moat es pattern recognition entre ciclos, ese moat se manifiesta concretamente como las seis capas que Yongfook y los demás listaron. Edge cases, retención, soporte, inferencia, trust, distribución.

Por eso la convergencia de Berder, Yongfook y Chamath cae justo ahora. El vendor está cerrando la etapa del subsidio mientras el operador empieza a cobrar premium por juicio acumulado. La promesa del one-shot, que era el puente narrativo entre los dos lados, deja de tener apoyo cuando ambos se mueven a la vez.

El patrón que llevo viendo desde 1990

Llevo 36 años en esto. Empecé en 1990, a los 15 años, programando en una Commodore 64 y en una Texas Instruments. Desde entonces he visto al menos cinco veces el mismo guion: una herramienta nueva sale, comprime drásticamente el tiempo de “del cero al primer demo”, y en los seis meses siguientes aparece un círculo de cursos, threads y videos vendiendo “construye tu negocio de software en un fin de semana”.

El primero fue Visual Basic, a inicios de los noventa. La promesa era arrastrar y soltar componentes para armar una app de Windows en una tarde. El demo era real. La cantidad de gente que efectivamente construyó un negocio de Visual Basic fue una fracción minúscula del número de gente que pagó por libros, conferencias y suscripciones a revistas de Visual Basic. Lo que hizo el demo fue acelerar el momento en que un programador serio podía empezar; no eliminó las semanas siguientes de aprender estructura de datos, manejo de errores y deployment.

El segundo fue Rails, a mediados de los 2000. rails generate scaffold armaba un CRUD funcional en sesenta segundos. El video del fundador de 37signals construyendo Basecamp en quince minutos en una conferencia recorrió internet. Cinco años después, los negocios que sobrevivieron no eran los que se generaban con scaffold; eran los que sobrescribieron casi todo el scaffold inicial respondiendo a usuarios reales. Mismo guion, otra herramienta.

WordPress hizo el mismo movimiento un poco después. “Cualquiera puede tener un sitio web con WordPress.” Cierto. La parte que el meme se saltó es que mantener un sitio WordPress de producción seguro contra plugins maliciosos, optimizar la base de datos cuando crece, y manejar la actualización de PHP sin romper la mitad del tema, sigue requiriendo un humano que haya pasado años trabajando con sistemas. La curva de aprender WordPress se acortó. La curva de operar un negocio sobre WordPress no.

Bubble y los no-code de los 2010 fueron la cuarta repetición. La quinta es ahora con vibe coding y AI one-shot.

Cada ciclo se comprimió en duración. Visual Basic vivió como narrativa unos siete años. Rails vivió cinco. WordPress como “todos pueden”, tres. Bubble alcanzó dos. El AI one-shot está corriendo a nueve meses entre punta y punta. Pero la forma de la curva es idéntica cada vez. Demo real. Hype. Cursos. Algunos negocios reales hechos por gente que ya tenía pattern recognition antes de la herramienta. Una mayoría que pagó por la promesa. Y al final, cinco años después, herramientas que dejaron de ser tema porque ya son parte del oficio.

El matiz que hace la diferencia

Vale separar una cosa, porque si no se entiende el aviso, se rompe en el primer ejemplo contrario que aparezca en X. Hay una diferencia gigante entre agentes corriendo sin supervisión y orquestación con humano en el loop.

Claire Vo respondió al hilo de Berder con una observación útil. Ella reporta que mantiene “unos 10 openclaws en distintos cronogramas haciendo tareas para mi negocio” y que el único que corre overnight de forma regular es uno especializado en una tarea acotada. Es una práctica concreta, no una promesa. Los agentes funcionan cuando el operador tiene años de experiencia diseñando los puntos de control humano: cuándo revisar, cuándo aprobar, cuándo dejar correr, cuándo cortar. Eso es ingeniería de proceso, no magia.

El “fugazi” del que habla Yongfook no es la idea de usar agentes. Es la idea de usar agentes sin saber lo que estás haciendo y cobrar por enseñar a otros a hacerlo igual. Esos dos no son la misma cosa, y poner a Claire Vo del mismo lado que el grifter del thread sobre “construye tu unicornio en una noche” sería injusto y técnicamente incorrecto.

La pregunta operativa es: ¿de qué lado está el agente que estás considerando? Si está en un flujo de baja consecuencia, con datos no críticos, sin clientes pagando, sin auditoría externa, una salida defectuosa solo cuesta una vuelta más; el one-shot ahí es razonable. Si está en producción tocando datos de clientes, integraciones de pago, contratos firmados, reputación de marca, una salida defectuosa cuesta semanas de remediación y a veces meses de reconstrucción de confianza. Esa zona no tolera one-shot por definición.

Lo que esto significa para una empresa de software

Si tu empresa es de software y vende a otros, este aviso te toca dos veces.

La primera vez como comprador. Probablemente alguien en tu equipo está experimentando con generación one-shot para acelerar prototipos internos. Eso está bien, mientras el output se trate como prototipo y no como código de producción. El cleanup tax que escribimos hace meses sigue aplicando: el código generado rápido sin revisión es deuda técnica facturable, no ahorro. Cuanto antes el equipo aprenda a distinguir las dos zonas, menos costoso es el corte.

Y hay una deuda menos visible que la técnica que se acumula al mismo ritmo, en silencio: la deuda de criterio. Cada vez que el equipo deja que el agente decida algo que antes habría discutido (qué validación pedir, qué edge case manejar, qué sí merece test), ese músculo se atrofia un poco. La deuda técnica la paga el siguiente sprint. La deuda de criterio la paga el siguiente ciclo, cuando hay que decidir algo nuevo y nadie en la sala recuerda cómo se hacía esa conversación. Es exactamente el moat que el post anterior describió: pattern recognition acumulado por años de discutir decisiones reales. Si el agente toma todas las decisiones, ese pattern recognition no se está formando.

La segunda vez como vendedor. Si tu producto compite con una promesa de “esto se puede one-shot”, la respuesta no es bajar el precio para igualar la promesa, porque la promesa misma se va a desinflar en seis a nueve meses, y bajar precio en respuesta a un competidor que va a desaparecer es un movimiento defensivo que solo daña el propio margen. La respuesta es construir el caso del valor incremental, ser específico sobre las capas que tu producto resuelve y la promesa one-shot no, y dejar que el mercado se encargue de filtrar a los compradores que aprendieron por las malas. Algunos de esos van a regresar.

Chamath nombró la salida estrecha del lado del vendedor de IA. Pero hay otra salida que no nombró, más relevante para una empresa de software seria: no participar en la categoría de “construye tu app en un prompt”, sino construir productos que asuman que el comprador sí entiende la diferencia entre demo y operación, y cobrarle al que la entienda lo que vale resolverle las seis capas reales.

Qué hacemos en IQ Source con esta distinción

AI Maestro existe precisamente porque el comprador promedio de IA empresarial está expuesto justo a este tipo de promesa. Cuando entramos a una empresa, parte del primer mapa es identificar dónde la organización está usando IA en zona segura (prototipos, herramientas internas, validación rápida) y dónde está empezando a usarla en zona crítica (productos en producción, datos de cliente, decisiones financieras). Las dos zonas merecen IA. Cada una merece un tipo distinto de IA, y un proceso de gobernanza distinto. Esa separación, que el comité ejecutivo no puede hacer solo porque vive dentro del incentivo de demostrar adopción rápida, es lo que entregamos en el primer mapa.

Socio Tecnológico, la otra línea, aplica para empresas de software cuyo producto vive en zona crítica desde el primer día. Un equipo de producto puede ser excelente en pattern recognition de su mercado y al mismo tiempo no querer convertirse en especialista de runtimes de agentes, harnesses propios y pricing dinámico de modelos. Para esas empresas, la respuesta correcta no es contratar a tres ingenieros senior de IA para que entiendan algo que se va a recomprimir en doce meses. Es comprar el oficio por hora a un socio que vive ahí, que mantiene el harness propio, y que entrega código de producción que el equipo interno sí puede mantener cuando el oficio se estabilice.

En ambos casos el principio es el mismo. El one-shot tiene un lugar, pero ese lugar es chico y conocido. El resto del trabajo de software, especialmente cuando hay clientes pagando, sigue requiriendo lo que siempre requirió: alguien que ya pasó por los edge cases, sabe dónde se rompen las cosas, y no le va a vender al CEO la idea de que el negocio se hace en un fin de semana.

Si tu próxima conversación interna incluye la frase “deberíamos hacer esto con IA, dicen que se puede one-shot”, esa es la conversación. Dos horas con tu equipo, mapa escrito al final, distinción clara entre las dos zonas. Sin cotización atada. El correo es info@iqsource.ai.

Berder lo dijo poniéndose primero a sí mismo en duda. Yongfook habló desde la comodidad de un negocio que ya factura sin rondas de inversión. Y Chamath, que es el menos cómodo de los tres porque tiene plata adentro de la categoría, terminó nombrándole el ciclo a su propia cartera. Tres ángulos. Mismo aviso. Cuando tres incentivos distintos coinciden en 24 horas, lo que está pasando no es que tres personas tuvieron la misma opinión por casualidad. Es que las señales ya llevaban días a la vista, y la prensa estaba demorada.

Preguntas Frecuentes

vibe coding AI one-shot Chamath Palihapitiya Jon Yongfook trough of disillusionment AI Maestro Socio Tecnológico

Artículos Relacionados

Adopción no es transformación: el modelo post-McKinsey
Estrategia Empresarial
· 11 min de lectura

Adopción no es transformación: el modelo post-McKinsey

Raphaël Dabadie nombró el modelo. La consultoría tradicional hace muestreo. La transformación AI necesita agentes que mapeen toda la organización.

McKinsey Raphaël Dabadie AI Maestro
La era flat-rate de IA terminó esta semana
Estrategia Empresarial
· 9 min de lectura

La era flat-rate de IA terminó esta semana

GitHub pausó Copilot Pro, Anthropic sacó Claude Code del plan de $20, xAI cobra $300 por Grok 4.3. Tres vendors, una semana, la misma pared.

precios IA GitHub Copilot Anthropic Claude Code