- En el desarrollo de software, el cuello de botella no está en escribir código, sino en diversos procesos centrados en las personas como la revisión de código, la transferencia de conocimiento, las pruebas, la depuración y la colaboración/comunicación
- Gracias a los LLM, generar código en sí se volvió muy fácil, pero el costo y la carga de entenderlo, validarlo y confiar en él han aumentado aún más
- La generación rápida de código impone más carga a quienes revisan, integran y mantienen el software, y la velocidad real de todo el equipo no necesariamente mejora
- Entender el código es la parte más difícil, y aunque un LLM lo genere, la calidad no está garantizada sin la confianza y el contexto compartido del equipo
- Los LLM son potentes para el prototipado y la automatización, pero no pueden reemplazar los fundamentos del desarrollo de software, como el diseño cuidadoso, la revisión y el contexto compartido
El verdadero cuello de botella al escribir código
- Durante años, la tarea de escribir código en sí no ha sido el cuello de botella en la ingeniería de software
- Los verdaderos cuellos de botella aparecen en la revisión de código, la mentoría y la transferencia de conocimiento mediante pair programming, las pruebas, la depuración y el costo de la colaboración y la comunicación
- La gestión de tickets, las reuniones de planificación y los rituales ágiles también ralentizan más el trabajo
- En la práctica, estos procesos necesarios para asegurar la calidad exigen mucho más tiempo y reflexión que escribir código como tal
- Sin embargo, gracias a los LLM, el costo de generar código funcional está acercándose a cero
- Pero el costo de entender el código, probarlo y lograr confianza en él más bien aumenta
- La velocidad de implementación inicial mejoró, pero hay más código que revisar, integrar y mantener, lo que incrementa la carga
Los LLM cambian la naturaleza del trabajo, pero no lo eliminan
- Las herramientas LLM como Claude aceleran la implementación inicial, pero al final entra más código al sistema en menos tiempo, lo que aumenta la carga de quienes se encargan de la revisión y el mantenimiento
- Esta carga se agrava especialmente en las siguientes situaciones
- No está claro si la persona autora realmente entiende bien el código que envió
- El código generado usa patrones poco familiares o rompe las convenciones existentes
- Las condiciones límite y los efectos secundarios no intencionales no quedan claros
- Como resultado, aunque producir código se vuelve más fácil, la dificultad de validarlo aumenta y al final no se logra acelerar al equipo completo
- Antes ya existía entre desarrolladores la broma de la “ingeniería de copiar y pegar”, pero con los LLM este fenómeno se amplifica mucho más
Entender el código es la verdadera dificultad
> “El mayor costo del código no es escribirlo, sino entenderlo”
- Gracias a los LLM, producir código se acelera, pero razonar sobre su funcionamiento, encontrar bugs sutiles o garantizar su mantenibilidad a largo plazo no se vuelve más fácil en absoluto
- Esto se complica aún más cuando quien revisa no puede distinguir entre código generado y código escrito directamente, o cuando resulta difícil entender por qué se eligió una solución determinada
Los equipos siguen dependiendo de la confianza y del contexto compartido
- El desarrollo de software parte fundamentalmente de la colaboración y depende por completo de la comprensión compartida, el alineamiento y la mentoría
- Cuando el código se genera más rápido de lo que puede discutirse y revisarse, el equipo puede creer erróneamente que la calidad ya fue validada, cuando en realidad no la ha confirmado
- Esto aumenta la carga psicológica de quienes revisan y de quienes actúan como mentores, y puede terminar ralentizando al equipo completo de una nueva manera
Los LLM son potentes, pero no resuelven lo esencial
- Los LLM aportan mucho valor para el prototipado rápido, el scaffold y la automatización, pero no eliminan la necesidad de pensamiento claro, revisión cuidadosa y diseño profundo
- El costo de escribir código en sí bajó, pero el costo de que el equipo entienda el código en conjunto y le dé significado no ha cambiado
- El verdadero cuello de botella sigue estando en la "comprensión y la colaboración"
7 comentarios
Yo soy exactamente el tipo de desarrollador al que le falta la habilidad técnica que presenta este artículo y que depende muchísimo de los LLM.
Como me faltan conocimientos técnicos, me resulta difícil trabajar según el WBS sin IA...
Aun así, ¿qué podría hacer yo para reducir aunque sea un poco el tiempo de revisión de los desarrolladores senior...?
De paso, también estaría bueno que así pudiera ir acumulando conocimientos...
Para reducir el tiempo de revisión, uno mismo debe decidir y poder explicar en qué contexto surgió el código que escribió y por qué eligió esa opción entre varios métodos de implementación. Para lograrlo, debes trabajar de forma constante en el punto 3, ya sea los fines de semana o en tu tiempo libre, y también te conviene revisar al azar bibliotecas conocidas o código que otras personas han subido a GitHub para analizar cosas como la estructura del código y el estilo de implementación.
¡¡Muchas gracias por sus palabras!!
Aun así, ver que están reduciendo personal es desalentador... ¿Cómo se supone que 4 personas saquen adelante 12 proyectos... y encima una de ellas también tenga que encargarse de la gestión...
:'( Debe estar pasándola muy mal.
Opinión de Hacker News
Como mentor con experiencia, he visto a interns ambiciosos pero todavía inmaduros producir en un día lo que antes era una o dos semanas de código. Pero mi trabajo, en realidad, se volvió más difícil que antes. Al revisar código, a los interns les falta reflexión profunda sobre lo que escribieron, así que mi feedback no termina de llegarles. Los bugs simples o problemas menores casi han desaparecido, pero los problemas que quedan son más sutiles y complejos, y mucho más difíciles de explicar. Además, están apareciendo tipos de bugs nuevos que antes no veía. Hay código que por fuera se ve bien pero en realidad no funciona en absoluto, y muchas veces parece pulido aunque esté roto desde lo más básico. Los juniors que colaboran con LLM tienden, en vez de entregar código simple y que valga la pena discutir, a producir de una sola vez código complejo que parece terminado, pero que genera problemas de colaboración y mantenimiento en varios frentes. Como resultado, da la sensación de que el método tradicional de “mejora gradual” para pulir un PR hasta llevarlo a calidad final ya no funciona bien. Cuando les das feedback, en lugar de corregir el PR original a veces proponen un enfoque completamente nuevo, que a menudo introduce otros problemas nuevos. Al final, los seniors terminan invirtiendo mucho más tiempo en ese PR que los juniors. Puede que del lado junior sientan que están siendo muy productivos, pero también se nota que el feedback de los reviewers seniors cada vez suena menos cálido o alentador que antes. En última instancia, lo único que más o menos funcionó fue exigir muchísimos test cases, aunque incluso esos tests también chocan con limitaciones por problemas parecidos
Al ver este tipo de código que “parece terminado pero no funciona para nada”, me acordé de un proyecto internacional de desarrollo de software de 250 mil dólares que viví hace años. Sobre el papel, según la especificación, todo parecía correcto, pero en la práctica era un sistema completamente inconsistente. Estaban tan obsesionados con interpretar la especificación al pie de la letra que se les escaparon cosas de sentido común, y al final tiramos todo el proyecto completo a la basura. Me impresiona que ahora este tipo de cosas se estén automatizando y abaratando gracias a los LLM
Me identifico totalmente con este problema. En mi experiencia personal, con LLM sí puedes generar miles de líneas de código muy rápido, pero lo realmente difícil es revisar el código, corregir bugs, revisar vulnerabilidades de seguridad, refactorizar, eliminar código innecesario, etc. Al final, muchas veces programar directamente resultaba más productivo. La forma más realista de usar LLM es como autocompletado o para producir fragmentos simples. Si además tengo que pasar por un junior que usa LLM como intermediario y luego yo volver a traducir todo eso, la eficiencia cae todavía más. Es posible que quienes hoy sienten que son más productivos con LLM en realidad lo sientan porque se están saltando por completo estas tareas importantes o simplemente no les prestan atención. Al final, solo la minoría que sí se preocupa por la calidad del producto termina cargando con el peso de manejar volúmenes enormes de código. A veces los malinterpretan como personas innecesariamente difíciles, pero en realidad son quienes de verdad buscan entregar el mejor producto posible al usuario. No veo una solución clara; más bien parece que la situación va a empeorar. Seguirán entrando al sector desarrolladores formados usando solo LLM, y las empresas que fabrican estas herramientas seguirán haciendo marketing exagerado. Al final, la carga de mantener la calidad solo va en aumento
Yo también estoy viviendo este fenómeno de inversión del esfuerzo, donde los seniors terminan poniendo más trabajo en un PR que los juniors. En mi caso, quienes redactan notas de prensa o posts de blog usan AI, y cuando yo, que soy el experto en el tema, recibo el resultado, termino gastando 3 o 4 veces más tiempo corrigiendo alucinaciones y errores de AI. Su trabajo originalmente era apoyarme a mí, pero ahora resulta que yo tengo que ayudarlos a ellos. Encima, las alucinaciones de AI cambian cada vez, así que siempre hay que sufrirlas desde cero. Ya se lo comuniqué a los ejecutivos, y si esto sigue así, no me sorprendería que la mitad del personal de PR desaparezca el próximo año. Si el rol es copiar un email, pegarlo en ChatGPT y luego reenviármelo, entonces eso lo puedo hacer yo mismo
Me gustaría saber si podrías explicar con más detalle esa parte de “durante la revisión sentí que mi feedback no había sido realmente comprendido”. Estoy pasando por algo parecido, así que agradecería cualquier solución o insight que puedas compartir
Sumando mi propia perspectiva: la generación anterior desarrolló de forma natural una comprensión profunda de la estructura y el diseño del software a través del refactoring y de los unit tests. Pero si en adelante los LLM también generan los unit tests, tal vez los desarrolladores ya no tengan oportunidad de hacerse preguntas como “¿qué necesito realmente?” o “¿cómo podría simplificar esto?”. Para mí, ahí está justamente la diferencia entre “desarrollador”, “ingeniero” y “arquitecto”. Los LLM o el “vibe coding” nunca van a formar ese tipo de mentalidad. En lenguajes con menos carga sintáctica, como Go, estos errores de diseño se hacen más visibles durante la revisión. La estructura de unit tests en Go sirve bastante para diagnosticar complejidad en el código. Al final, necesitamos mejores métodos de testing y review. Ni el fuzz testing, ni las pruebas unitarias, ni las pruebas de integración son suficientes. Creo que hace falta un framework automatizado de pruebas que pueda verificar lógicamente si realmente se están invocando las ramas del código y si se cumplen las condiciones esperadas
Gracias a los LLM, el costo de introducir software nuevo se está acercando casi a cero, pero el costo de entenderlo a fondo, probarlo y confiar en él se siente más alto que nunca. Dicho eso, por mi experiencia, no creo que el código generado por LLM sea tan muchísimo peor que mucho código heredado que dejó gente que ya se fue y sobre el que ni siquiera puedes hacer preguntas, o que el código que anda circulando por internet. De hecho, a diferencia de las personas, el LLM no se fastidia al escribir tests ni se cansa y deja pasar cosas por flojera. Mi filosofía parte de la idea de que “todo código es deuda potencial”. Por eso no me preocupa tanto la confiabilidad del código. De hecho, he llegado a construir codebases enormes con AI y hacer que funcionen razonablemente bien, pero solo cuando el dominio es verificable y hay muchas pruebas e iteración. En resumen, los LLM aceleraron la producción de código, pero siento que la parte intelectualmente estimulante de programar se redujo, y con eso mi cerebro también se ha ido volviendo más perezoso. Más bien estamos entrando en una etapa donde el trabajo mental previo, como definir requisitos y diseñar, se vuelve mucho más importante
Incluso sin LLM, la industria ya estaba limitada no por “falta de código”, sino por la demanda del mercado y por los límites del capital. Las herramientas mejoraron tanto que programar en sí mismo dejó de ser el centro. El entorno actual es completamente distinto al de los primeros años. Me acuerdo de una anécdota de cuando Bill Gates era adolescente, en una época en la que la simple capacidad de “saber programar” era un recurso escaso. Una empresa tenía tanta urgencia que contrató a Gates y a Paul Allen con 16 años, y les parecía increíble solo porque podían escribir código rápido. Hoy la pregunta más importante es “¿qué vamos a construir y existe realmente un negocio detrás de eso?”
Video relacionado
Coincido con la idea de que el coding no era el cuello de botella por un tema de demanda del mercado. Antes del boom de AI, Marc Andreessen también decía que “hay capital de sobra, pero faltan buenas ideas en las que invertir”. No creo que eso refleje del todo la realidad, pero al menos los datos hacen que su comentario parezca creíble
Como en la vieja anécdota de Bill Gates, la capacidad de escribir código de alta calidad y entenderlo profundamente sigue siendo un recurso raro. La diferencia es que ahora la industria no parece valorar tanto esa capacidad
Desde la perspectiva de analizar el impacto de la AI, tendemos a sobreestimar demasiado la eficiencia. Pero la economía real tiene cuellos de botella mucho más complejos. Aunque la producción de código aumente 100 veces, no está claro cuánto de eso será realmente útil
Últimamente, cuando leo experiencias de otras personas, todo suena demasiado deprimente. Si un junior entrega un bloque enorme de código que no funciona, que ni siquiera probó o validó por su cuenta, que tampoco refinó para hacerlo conciso, y además lo manda sin documentación, comentarios ni explicación, eso en sí mismo ya puede describirse como una “versión de LLM instalada en un humano”. Al final, lo importante es el pensamiento crítico y el sentido de responsabilidad sobre el resultado. De hecho, creo que un LLM probablemente responda mejor al feedback que un junior de software tradicional
Yo también solía pensar que escribir código era el cuello de botella, pero después de 10 años entendí que lo realmente difícil es alinear la tecnología con el negocio. Incluso en entornos como B2B o SaaS, donde hay montones de código complejo que cambian según cada cliente, si la tecnología está bien alineada con el negocio, todo fluye. A estas alturas la tecnología ya avanzó lo suficiente; ahora lo que de verdad importa es el ego del desarrollador y su capacidad de enfocarse en el valor para el cliente. Hay que pensar qué quiere realmente el cliente, si estaría dispuesto a pagar por eso, o incluso si hace falta una interfaz web en primer lugar. Las “funciones juguete para gato” que los desarrolladores construyen para su propia satisfacción son la verdadera causa de que suban los costos de cloud. Lo más triste es que ni incentivos agresivos, ni stock options, ni salarios altos resuelven este problema de fondo. Tiene que existir al menos una persona con verdadero sentido de misión por construir buen software, alguien dispuesto a hablar directamente con el cliente y hacer las cosas bien
En organizaciones, el momento en que los LLM sí me han ayudado de verdad ha sido en mis proyectos personales o side projects. Cuando estás desarrollando una app para resolver un problema pequeño, y el tiempo no te alcanza, escribir código sí se vuelve un gran cuello de botella. En ese tipo de proyectos, mi uso de LLM es del 100%
Yo también coincido al cien por ciento. Si inviertes 1 o 2 horas al día en Claude code, para cuando se está acabando el fin de semana ya tienes algo utilizable en la práctica. Con una inversión corta de tiempo, validar ideas o experimentar se vuelve mucho más fácil. Creo que este tipo de herramientas LLM también aportan muchísimo valor en organizaciones profesionales. Se puede prototipar muy rápido todo tipo de herramientas internas o sistemas de automatización que normalmente nunca se construirían por falta de tiempo. Si un colega necesita una query de DB o una automatización simple, basta con preguntarle a Claude, revisar lo que devuelve y pegarlo directamente. De hecho, apoyar a personas que no son ingenieras para que puedan resolver por sí mismas tareas repetitivas dentro de su área es justamente el objetivo de mi proyecto mcp-front[0]
GitHub de mcp-front
Si soy sincero, en mi situación profesional actual ya no puedo darme el lujo de dedicarle una semana entera a algo, y por experiencia acumulada siempre estoy considerando requisitos no funcionales y el largo plazo. Aunque me saltara cosas como los tests, igual seguiría teniendo demasiadas cosas en qué pensar
Me vino a la mente la famosa frase de Robert C. Martin: “pasamos por lo menos 10 veces más tiempo leyendo código que escribiéndolo”
Cita relacionada
Lamentablemente, su estilo de clean code a veces fragmenta tanto el contexto que termina haciendo aún más difícil entender la intención real
Peor todavía: puede que el tiempo de escritura sí baje, mientras que el de lectura solo aumente, así que la carga total de trabajo ni siquiera se reduce
Nadie ha mencionado este texto de Joel Spolsky del 2 de octubre de 2000
Joel on Software: Painless Functional Specifications (2000)
El verdadero cuello de botella no es el código, sino la especificación funcional. Definir claramente cómo debe comportarse el software, en inglés, diagramas, user stories, etc., es más importante. Si la especificación está bien armada, un LLM puede generar de una vez soluciones, tests e integration tests bastante buenos. Si el alcance es demasiado grande, la especificación no debería manejarse en un solo archivo Markdown, sino dividirse por funcionalidad como en una wiki, con links y referencias. La verdadera ventaja competitiva no está en la dificultad de implementación, sino en cuánto esfuerzo se invirtió en la especificación
Quien escribe no está de acuerdo con la postura del autor. Puede que desde la perspectiva de una gran empresa el código no sea el cuello de botella, pero para una startup, con recursos limitados, la planificación eficiente siempre fue más importante. Es decir, también hubo muchos casos en que producir código que realmente funcionara sí era el mayor cuello de botella. En discusiones como esta, al final no se puede generalizar cuánto ayudan AI/LLM. Para algunos equipos el código era el cuello de botella, y para otros no
Como todos sabemos, muchas veces el código que generan los LLM es un desastre y ni siquiera se puede revisar. Cuando un junior entrega código hecho con LLM y le preguntas por qué está así, ni él mismo lo sabe y solo responde que lo hizo el LLM. Al final, esta tendencia solo agrega “ruido” y “overhead” al mantenimiento del código. Si ya no se puede evitar adoptar LLM, entonces reviews y mantenimiento también terminarán cayendo en manos de LLM. Claro, el resultado será todavía más spaghetti. Pero siendo realistas, en la mayoría de los negocios la calidad ni siquiera importa tanto, y si el código del LLM funciona más o menos, con eso basta. O bien basta con seguir apilando más LLM encima hasta que, de alguna manera, termine resolviéndose