Dan Luu: por qué la IA hace viable software ambicioso

Por qué Dan Luu cree que la IA permite construir software más ambicioso

Dan Luu tardó unas 5 horas en construir una IA superhumana para un juego de mesa sin tener ningún conocimiento previo de ese dominio. Con 20 horas de trabajo llegó a lo que en su momento fue la IA más fuerte del momento en ese juego. Ese es el punto de partida de su último ensayo: si el costo de intentar cayó tanto, la pregunta para un founder ya no es si puede construir algo, sino qué vale la pena construir.

Michael Malis lleva meses mostrándole a Luu lo que hace con pgrust, una reescritura de Postgres en Rust, y la conclusión incomoda al sector: casi todos los proyectos de reescritura que se ven hoy son "vibeslop", pero eso no es motivo para no intentarlo. Luu sostiene que las capacidades de los modelos avanzaron lo suficiente como para que proyectos antes inviables hoy sean alcanzables para una sola persona.

El ejemplo más concreto es suyo. Luu construyó un motor de regex que puede ajustarse para superar a otras librerías de propósito general en cualquier carga que le importe, un fork de ripgrep que usa el compilador nativo de ese motor, y una variante de Rust que acelera los builds de sus proyectos. Todo eso le tomó "un número de horas de un solo dígito". Sin saber nada de regexes, algoritmos de string matching ni compiladores, ese mismo conjunto de proyectos le habría llevado "un año o más" en alcanzar calidad "funciona para mí".

La frase que da título al ensayo es de Malis, no de Luu: "deberíamos ser más ambiciosos con el software que construimos". Luu matiza que él escribiría "podemos" en lugar de "deberíamos", y ahí está el punto interesante: no es una exhortación moral, es un cambio en el costo de intentar.

¿Qué es pgrust y qué encontró en Postgres?

pgrust es una reescritura de Postgres en Rust y su propuesta principal es el rendimiento. La razón por la que Luu lo defiende no es que funcione, sino lo que ya produjo en el camino: al testearlo de forma exhaustiva, Malis encontró bugs reales en Postgres —un bug numérico que puede hacer fallar operaciones válidas de SP-GiST, un bug de caché de formato que puede devolver resultados incorrectos de JSONPath, un bug de pgcrypto que hace fallar operaciones posteriores, varios bugs de seguridad de memoria en el cargador de diccionarios y un bug de overflow en el tipo money.

Ese detalle es el que suele perderse en la discusión pública. Aunque pgrust nunca llegue a producción, el intento ya mejoró Postgres de forma durable. Y si falla, algunas de las optimizaciones que demostró podrían terminar en Postgres o en ClickHouse, aunque por una vía menos directa que reportar bugs que después se corrigen.

Luu es honesto sobre el sesgo: si no conociera a Malis, asumiría que pgrust es otro proyecto generado por IA que nunca va a funcionar. "¿Quién tiene tiempo para investigar todos estos proyectos?", escribe. La conclusión práctica es que el ruido ambiental no debería definir lo que tú intentas construir.

¿Por qué la verificación es el nuevo cuello de botella?

Acá el ensayo se cruza con datos duros del sector. Un estudio de investigadores de Harvard que analizó datos agregados de Jellyfish sobre 300 millones de eventos de trabajo y más de 700.000 empleados en más de 700 empresas encontró que la introducción de agentes de código aumenta 30% las líneas de código generadas, 20% los commits y 23% los pull requests, pero no cambia de forma estadísticamente significativa la tasa de resolución de issues y epics, según reportó Ars Technica. La ganancia en la fase de escritura se absorbe aguas abajo: las revisiones se alargan y los pull requests requieren más correcciones.

El mercado ya está respondiendo a eso. Qodo, una startup de agentes para revisión, testing y gobernanza de código, levantó una Serie B de US$70 millones liderada por Qumra Capital, que elevó su financiamiento total a US$120 millones, según TechCrunch. Su tesis: generar y verificar sistemas requieren enfoques distintos. La misma nota cita una encuesta según la cual 95% de los desarrolladores no confía del todo en el código generado por IA, pero solo 48% lo revisa de forma consistente antes de hacer commit.

Una encuesta de LocalStack sobre 309 desarrolladores y managers en empresas de más de 1.000 empleados, publicada por Virtualization Review, aporta otro ángulo: 65% genera al menos el doble de código que antes de adoptar IA, pero solo 61% de ese código generado llega a producción. Y 54% reporta más bugs en el código asistido por IA. Más código no es más software.

¿Deberían todos ser más ambiciosos con la IA?

El ensayo incluye una réplica de Yossi Kreinin, citada con permiso, que apunta al otro lado: "para la mayoría de la gente, deberían ser menos ambiciosos con el software que construyen con IA o van a experimentar un fracaso absoluto". Su argumento es que muchos problemas no se prestan a bucles agénticos porque no tienen criterios claros de pasa/no pasa, y que razonar sobre cajas negras gigantes es difícil incluso para gente con experiencia.

Luu acepta parte del punto. Reconoce que si usas IA para acelerar un flujo sin entender cómo se descompone el sistema, terminas con código sobreajustado al caso que testeaste, que no generaliza ni se mantiene. Y agrega una observación contraintuitiva: a medida que los modelos mejoran, él se aleja de "todo funciona" porque empieza a trabajar en cosas más difíciles. La brecha entre lo que un modelo puede implementar y lo que puede verificar sin supervisión se agranda.

También marca un límite de sentido común: no vale la pena invertir mucho en herramientas internas que un laboratorio de IA va a volver obsoletas en tres meses. Su ejemplo es un tool que reinicia Codex cuando detecta una fuga de memoria, útil hoy y probablemente inútil cuando OpenAI lo arregle.

Qué significa esto para tu startup

La lección no es "usa más IA". Es que el cuello de botella se movió de escribir código a verificar que el código hace lo que dice hacer. Cuatro movimientos concretos:

• Define el criterio de verificación antes de escribir la primera línea. Si no puedes expresar qué significa "funciona" en términos de tests, propiedades o benchmarks reproducibles, el proyecto no está listo para delegarse a un agente. Luu menciona que el testing basado en propiedades y el fuzzing le resultaron más eficientes que escribir tests unitarios tradicionales, incluso en dominios donde le decían que no aplicarían.
• Mide resultados, no volumen. Las métricas que importan son pull requests mergeados, issues cerrados y el porcentaje de código generado que efectivamente llega a producción. Si ese porcentaje es bajo, el problema no es la velocidad de generación.
• Elige proyectos que antes descartabas por costo, no los que ya hacías. El argumento de Luu es que la ganancia aparece cuando atacas cosas que eran demasiado caras de intentar. Aplicar IA al mismo backlog de siempre rinde poco por la ley de Amdahl.
• Presupuesta tokens como presupuestas horas de ingeniería. Luu gastó "uno o dos meses" de una suscripción de US$200 al mes para resolver un problema de reglas ambiguas que le habría costado mucho más tiempo en trabajo manual. Ese es el tipo de cálculo que conviene hacer explícito.

El contexto de infraestructura refuerza la dirección. Cerebras cerró un acuerdo multianual con OpenAI por entre US$10.000 y US$20.000 millones y 750 megavatios de capacidad, según Crypto Briefing, y recaudó US$5.550 millones en su debut en Nasdaq, según 247wallst.com. Luu menciona que OpenAI destinó más de US$10.000 millones a acceder a Cerebras mientras bloqueaba el acceso de Anthropic. La velocidad de inferencia es hoy una variable competitiva, y eso empuja a que las herramientas de desarrollo se aceleren desde arriba.

La conclusión de Luu es la de alguien que lleva años midiendo: que otros produzcan cantidades industriales de software apenas funcional no obliga a nadie a hacer lo mismo. La ambición razonable no es construir más rápido lo mismo, sino construir lo que antes no tenía sentido intentar.

Fuentes

• https://danluu.com/ambitious (fuente original)
• AI coding agents generate more code, but not more software
• Qodo raises $70M for code verification as AI coding scales
• AI Agents Get Cloud Access Despite Near-Universal Concerns, LocalStack Survey Finds
• General Compute buys large fleet of Cerebras chips to enhance AI inference output
• Billionaire Tech CEO: Our $25 Billion Backlog Shows the Demand Is Booked