Claude Code no hace que tu producto sea mejor

• El efecto de productividad de los agentes de código no es uniforme, sino que se divide en forma de K, y la métrica clave no es cuántas líneas de código se producen por hora, sino si realmente aumentó la velocidad de mejora del producto por ingeniero
• Dax, Karri Saarinen y David Cramer no son críticos de la IA, pero no han llegado a convencerse de que los agentes de código eleven claramente la velocidad de mejora del producto, y Cramer considera que los LLM aumentan la complejidad y el bloat, frenando la velocidad a largo plazo
• Si Claude Code hubiera dado una ventaja exclusiva dentro de Anthropic durante 7 meses, la brecha frente a los competidores debería haberse ampliado de forma compuesta, pero Codex, Cursor, Cognition y Factory siguen compitiendo, lo que sugiere que el cuello de botella quizá no sea producir código
• Una buena cultura de ingeniería trata las líneas de código no como un activo, sino como un costo; a medida que aumentan las funciones e integraciones, también crecen la superficie de bugs, las dependencias y las funciones periféricas, por lo que la complejidad no aumenta de forma lineal sino compuesta
• En la frontera de la calidad del producto, son más importantes el criterio, la compresión, la eliminación y la capacidad de decir que no que escribir código rápido; Claude Code es útil para pasar de 0 a un nivel Camry, pero no hace que los artesanos de Ferrari construyan un Ferrari más rápido

---

Curva de productividad en forma de K

• La mejora de productividad de los agentes de código no es uniforme, sino que se divide en forma de K
  • Los ingenieros senior muestran un aumento medible en su producción desde el punto de inflexión de los LLM en 2023
  • La producción de los ingenieros junior está prácticamente estancada o incluso ha bajado
  • La métrica importante no es cuántas líneas de código se escriben por hora, sino si realmente sube la velocidad de mejora del producto por ingeniero
• La programación con agentes sí reduce el tiempo para crear Pull Requests en ciertas tareas
  • Se repiten afirmaciones como “resolvimos 6 años de backlog en un trimestre”, “con Cursor armé el backend en 3 días” o “Claude Code fue programado completamente con Claude”
  • Aun así, sigue siendo otra cuestión distinta si la velocidad de producción de código equivale a una mejora en métricas como la calidad del producto

Señales de advertencia de ingenieros que sí saben construir buen producto

• Dax, Karri Saarinen y David Cramer no son críticos de la IA, pero no están convencidos de que los agentes de código aumenten claramente la velocidad de mejora del producto
  • Dax está construyendo opencode.ai
  • Karri Saarinen es CEO de Linear
  • David Cramer creó Sentry desde cero y lo llevó hasta una escala de 10 millones de dólares al mes
• David Cramer cree que los LLM hoy no generan una mejora neta de productividad
  • Bajan la barrera de entrada, pero crean software complejo difícil de mantener
  • Según él, parecen ralentizar la velocidad a largo plazo
  • Señala como problemas la “falta de rendimiento en desarrollo incremental dentro de la complejidad”, la “falta de capacidad para simplificar de verdad y generar interfaces idiomáticas” y las “técnicas desprolijas de generación de tests” de los LLM
  • Al final, su juicio es que la mayor parte es bloat
• Dax dice que todavía no ha encontrado con claridad la mejor forma de aprovechar los agentes de código
  • Mientras tanto, afuera abundan afirmaciones como “todos los PR son generados por IA”, “velocidad sin precedentes” o “resolvimos 6 años de backlog”
  • Pero todos ellos tienen dificultades para aumentar de verdad la velocidad de mejora del producto

La ventaja exclusiva de Claude Code no se refleja en una brecha

• Si Claude Code fue programado completamente con Claude, entonces la velocidad de mejora del producto debería haberse acelerado
  • Incluso si usar Claude Code elevara la velocidad de mejora del producto apenas 1.5 veces, un equipo que lo usara desde el principio debería ir abriendo distancia frente a sus competidores con el paso del tiempo
  • La productividad de ingeniería es una función compuesta, así que la diferencia debería crecer trimestre tras trimestre
• La situación real del mercado no muestra esa brecha compuesta
  • Codex salió unos meses después de Claude Code, pero ya puede competir en funcionalidades
  • El impulso comercial de Cursor sigue siendo fuerte
  • Cognition y Factory también siguen ganando contratos empresariales importantes
  • La gente todavía debate cuál herramienta es mejor
• La refutación clave es que, si Anthropic tuvo Claude Code en exclusiva durante 7 meses, una verdadera ventaja en velocidad de producto debería haber ampliado la distancia con sus competidores hasta volverla imposible de alcanzar
  • Codex debería haberse vuelto irrelevante, pero no fue así
  • Si no se ve una ventaja compuesta, es muy probable que el cuello de botella de la calidad del producto no fuera el código
• Incluso las posibles objeciones refuerzan la misma conclusión
  • Aun si hubo ganancias, la deuda de complejidad pudo habérselas comido
  • El equipo de ingeniería de Anthropic pudo ser tan grande que la ganancia marginal por ingeniero se diluyó
  • Pero incluso en ese caso, el cuello de botella ya no sería la producción de código, sino algún otro factor más difícil

Las líneas de código no son un activo, sino un costo

• Una buena cultura de ingeniería trata las líneas de código no como producto generado, sino como gasto
  • Se escribe código para las funciones importantes, y no se escribe para las que no lo son
  • Una base de código no se parece a un activo en el balance, sino más bien a un pasivo
• La subsidiaria de software tinychat de comma.ai hacía sonar una alarma cuando la base de código superaba cierto tamaño y celebraba cuando se eliminaba código
  • Cada línea de código es una superficie para bugs
  • Cada función se vuelve una dependencia de la siguiente función
  • Cada feature genera features periféricas
• La superficie del producto se expande como un fractal
  • Si agregas una integración con Slack, luego necesitas integración con Teams y una ruta alternativa por email
  • Si agregas notificaciones, luego hay que rehacerlas para móvil, SMS y políticas MDM empresariales
  • Si agregas soporte para MFA, debe ser compatible con Duo, Okta y SAML
  • La complejidad no aumenta de forma lineal, sino compuesta
• Linear tiene 178 personas, 6 años y 100 millones de dólares de ARR
  • Jira es 56 veces más grande que Linear en esfuerzo de ingeniería acumulado, pero aparece 6 puntos por debajo en calidad percibida por usuarios
  • La clave es que calidad y masa de la base de código no son lo mismo
• A escala de Facebook, la capacidad de producir rápido código de UI no es el cuello de botella
  • Un ingeniero hábil puede hacer en un día un mockup del feed de Facebook
  • La restricción real es reducir la cantidad de líneas de código necesarias para entregar esa experiencia a miles de millones de personas manteniendo uptime bajo cualquier carga y latencia
  • La función de recompensa no es la producción, sino la compresión
  • En ese tipo de trabajo, los agentes de código no pueden evaluar trade-offs de largo plazo ni tienen una teoría del sistema

El verdadero cuello de botella es empujar la frontera de las buenas ideas de producto

• La mejora de la calidad del producto en la frontera no está limitada por qué tan rápido escribes código, sino por qué tan rápido se te ocurren ideas lo bastante buenas como para empujar esa frontera
• La diferencia entre Jira y Linear no está en si dibujaron cajas mejores
  • Linear tenía una visión creativa concreta sobre cómo debía sentirse el software de gestión de proyectos, y la ejecutó con disciplina durante años
  • Esa calidad no sale del throughput de tokens, sino del criterio y de decidir hacer menos
• La afirmación de “resolvimos 6 años de backlog” no es tan impresionante como suena
  • Un backlog lleno de features CRUD y herramientas internas encaja muy bien con el tipo de trabajo que los agentes de código aceleran
  • Al mismo tiempo, ese no es el trabajo que empuja la frontera del producto
  • Un producto no mejora porque lo lances más rápido, sino porque lo que lanzas hace que a los usuarios les importe más
• Los agentes de código con IA ayudan a que productos que van de 0 a 1 lleguen más rápido a la frontera de calidad
  • Reducen el tiempo necesario para llegar a una primera versión funcional
  • En trabajo de etapa temprana, el aumento de velocidad sí existe
• Pero también hay costos
  • La base de código crece más rápido que la calidad
  • La deuda técnica se acumula de forma compuesta
  • La velocidad que ganas hoy la estás comprando con un costo que tendrás que pagar después

Camry para todos, Ferrari para nadie

• El cuello de botella para los equipos en la frontera no son los agentes de código, sino las personas con criterio
  • La capacidad de volverse el mejor “quitando cosas con buen gusto”, como en Linear o Sentry, vive en ciertas personas concretas
  • Se mencionan como ejemplo Nan Yu de Linear y Kelly Johnson de Skunk Works
  • El equipo selecto de Kelly Johnson creó el SR-71, que 60 años después sigue siendo citado como la aeronave tripulada de admisión de aire más rápida
  • El Blackbird no fue rápido porque produjera más planos, sino porque Johnson tenía una teoría sobre qué no dejar dentro
  • El criterio para eliminar, comprimir y rechazar no aparece en ninguna hoja de ruta de modelos frontier, y se vuelve todavía más valioso a medida que sube el piso
• Si ya estás en la frontera, no está claro que duplicar el gasto de I+D vía gasto en tokens genere valor económico
  • Se dice que los ingenieros de Ramp, en el último año, efectivamente duplicaron su salario mediante gasto en tokens
  • Es difícil confirmar si el producto de Ramp realmente mejoró
  • Si ya eres el número 1, tu tasa de victoria está casi fijada y es difícil medir qué significa ser “número 1 por más diferencia”
  • Para cambiar el juicio, harían falta datos sobre la tasa de victoria o el profit and loss de Ramp
  • Como cliente de Ramp, el autor dice que no percibe una diferencia clara entre ahora y el año pasado
• Claude Code puede ayudar a cualquiera a construir un competidor tipo Camry, pero no ayuda a que los artesanos de Ferrari hagan un Ferrari más rápido
  • Es muy útil para pasar de 0 a un nivel Camry
  • Es muy probable que el costo de producción de software que no está en la cima baje mucho
  • A cambio, se acumularán bastante confusión y deuda en las vigas de la fábrica, y al final alguien tendrá que limpiarlas

[GN⁺]

Opiniones en Lobste.rs

• La complejidad aumenta exponencialmente, y quizá incluso más rápido. Por eso, incluso quienes temen una singularidad de AGI a menudo pasan por alto que, por más inteligente que sea una persona, un modelo o un agente, cuando las ideas, los sistemas, los proyectos, las bases de código o el conjunto de funcionalidades crecen, tarde o temprano chocan con un muro de complejidad que sube de golpe
  Todos los proyectos de software avanzan relativamente bien al principio, pero en algún momento el crecimiento exponencial de la complejidad termina aplastándolo todo. Una buena arquitectura, diseño y calidad solo retrasan ese momento, y aunque gente capaz, con buen diseño y cuidando la calidad, puede aguantar unas 10 veces más en tamaño, funciones, rendimiento y factor sorpresa, al final igual se llega al muro
  La asistencia con LLM permite crear mucho más rápido funcionalidades y código de cierto nivel, por lo general de calidad promedio. Es decir, también hace que llegues mucho más rápido a ese muro. Sirve para crecimiento, experimentación y tareas de baja complejidad que eran relativamente fáciles pero consumían mucho tiempo, pero no hace posible crear cosas sin precedentes ni proyectos grandes y complejos. Para eso se necesitan mejoras que contengan la complejidad, y los LLM actuales no están ofreciendo eso de verdad

  • Es un problema clásico. Cuando causa y efecto están pegados, el beneficio inmediato se ve fácilmente, pero cuando hay distancia temporal entre causa y efecto, los efectos negativos son mucho más difíciles de notar
    http://bastiat.org/en/twisatwins.html
    El costo de usar agentes de código no aparece de forma directa y, sobre todo, proviene de una pérdida de entendimiento colectivo sobre cómo funciona el sistema
  • Aun así, la organización jerárquica sí ofrece una forma de manejar la complejidad a gran escala. En la naturaleza también se ve cómo surgen estructuras enormemente complejas de esta manera. Se pueden construir sistemas donde unidades independientes se combinan para formar estructuras mayores
    Un sistema robusto debe poder resistir impactos y adaptarse por sí mismo, así que cada parte debe poder fallar de manera independiente y con daños localizados. Si organizas el sistema como subsistemas anidados, aparecen unidades tipo célula que se comunican entre sí para hacer el trabajo. Estas unidades funcionan como subensambles estables sin necesidad de conocer los procesos internos de otras células
    Como cada capa no queda frenada por lo que sucede en otros lugares, puede autoorganizarse dentro de su propio ámbito y mantener resiliencia. En la práctica, esto encapsula la complejidad incidental detrás de interfaces y crea abstracciones donde esas interfaces cargan el significado. Conviene ver las capas como tejido conectivo que une los componentes de un sistema grande
    Erlang OTP es un buen ejemplo de este enfoque en software: construye sistemas grandes a partir de procesos aislados que se envían mensajes entre sí. Aunque un proceso individual muera o falle, no derriba a todo el sistema
  • “Contener la complejidad” implica decisiones, posturas y, a veces, oposición o conflicto
    Si le pides a alguien que implemente algo, puede responder cosas como “es demasiado complejo”, “esto va a explotar en un año”, “no es compatible con lo que está haciendo el equipo Y” o “no hay suficiente gente para implementarlo”. Esa última respuesta puede ser literal, o una forma indirecta de decir “no se puede”
    Es muy poco probable que un LLM responda así. Sobre todo porque están ajustados para ser optimistas y corteses. Además, como esa tendencia parece necesaria para aumentar el uso, tampoco parece probable que se ajusten de otra manera
    Este problema se parece al de los LLM que ayudaron a usuarios a suicidarse. Eso es bastante evidente, y aun así los LLM lo han hecho muchas veces. Que un proyecto muera por complejidad no gestionada es mucho menos obvio, así que no hay muchas razones para esperar que los LLM lo hagan mejor en el corto plazo

• Un razonamiento del tipo “si usar Claude Code realmente da una ventaja de velocidad en desarrollo de producto, y Anthropic lo tuvo en exclusiva durante 7 meses, entonces la brecha entre Claude Code y todos sus competidores debería ser imposible de cerrar; Codex debería ser irrelevante. Pero la gente todavía debate activamente cuál de los dos es mejor” no me parece muy sólido
  Claude Code es buen software, pero no es alguna clase de magia extraña de AGI que vuelva imposible competir

  • Además, Codex también fue hecho con vibe coding, así que la comparación también da un poco de risa por ese lado. Haber empezado unos meses antes puede no significar mucho. Muchas de las funciones que se agregan salen de lo que los usuarios reales hacen con la herramienta
    No es que Claude Code tuviera desde el principio una hoja de ruta cerrada ni que la barrera principal fuera la velocidad para escribir código. La barrera principal son las ideas. Todo el mundo lo va construyendo sobre la marcha
    Solo hojeé el texto en general, así que no puedo hablar muy a fondo, pero incluso dejando de lado el problema de mayúsculas al inicio de las frases, la mayor parte parecía prosa escrita por un LLM, así que no me dieron ganas de leerlo

• Hasta ahora, los errores de los agentes tienden a acumularse de forma multiplicativa
  Si creas una API que técnicamente funciona pero requiere un poco de código extra al usarla, el resultado es más código, y también más lugares donde aparecen duplicación, ramificaciones y bugs. Entonces, como en un fractal, se termina escribiendo todavía más código no tan bueno
  Una vez un agente diseñó una estructura donde el campo id era opcional. Ese campo solo hacía falta por un constructor que el propio agente había escrito. Luego se puso a escribir sin cansarse dos versiones del código, una para cuando id existía y otra para cuando no, y hasta inventó rutas alternativas torpes para el caso sin id. Esas rutas alternativas eran, por supuesto, complejas y frágiles. Infectó casi todos los usos de la estructura y hasta lo que dependía de ellos, y al final el constructor sin id ni siquiera se usaba. Se podía borrar fácilmente la mitad del codebase
  De verdad no sé si esto se corrige metiendo suficientes instrucciones del tipo “si estás haciendo una tontería, deja de cavar” y solo quedan algunos hacks antes de que el coding quede “resuelto”, o si es un problema de largo plazo de un loro estocástico donde seguirán haciendo falta costos que crecen exponencialmente para obtener mejoras lineales. Mientras los errores se acumulen con interés compuesto, ese crecimiento compuesto tarde o temprano te va a frenar

  • He visto cosas muy parecidas también en desarrolladores humanos. Creo que una de las características que separa a los mejores desarrolladores es la tendencia a detenerse, subir un nivel y mirar desde afuera
    A veces eso incluso incluye el proceso de negocio. Un desarrollador que conoce bien el dominio, en vez de pasarse meses implementando una solución técnica, puede preguntar: “¿y si en lugar de seguir cavando simplemente cambiamos el proceso?”. Y a veces la respuesta es “claro, eso es fácil”
    Creo que los LLM eventualmente también mejorarán en esta parte. Ya ahora, si les preguntas directamente “este enfoque no se ve bien, ¿podemos pensar en una alternativa?”, bastante seguido logran encontrarla. El problema es que hoy el éxito y el fracaso son muy irregulares, y una vez que ya hicieron algo tonto, es poco probable que lo detecten por sí solos mientras están ocupados con otra tarea no relacionada
    Aquí también hay una compensación. La gente ya se queja de que los modelos sobrepiensan los problemas y queman tokens. Si tienes experiencia e intuición sobre “cómo debería sentirse” el código que resuelve cierto problema, como desarrollador sabes de manera natural cuándo conviene detenerse y reevaluar. Quizá los agentes también lleguen a adquirir esa intuición con mejor entrenamiento

• Me gustaría ver una versión actualizada con datos posteriores al punto de inflexión de noviembre de 2025