La semana pasada explorábamos cómo sería el futuro del sector tecnológico si programar dejara de ser el cuello de botella. Pero ¿y si nunca lo fue en primer lugar?

Pedro Tavares, ingeniero sénior de software en PagerDuty, sostiene precisamente este punto de vista: escribir código nunca fue el verdadero cuello de botella. En su artículo "Writing Code Was Never The Bottleneck", Tavares desmonta las narrativas dominantes sobre los LLMs y expone la realidad del desarrollo de software en equipo.

Su análisis va al corazón de lo que realmente ralentiza a los equipos de ingeniería. Y no es lo que muchos créemos. Le pedí permiso para traducirlo, y aceptó amablemente, así que aquí os lo dejo y espero que lo disfrutéis tanto como yo.

Durante años, he tenido la convicción de que escribir líneas de código nunca fue el cuello de botella en ingeniería de software.

Los verdaderos cuellos de botella fueron, y siguen siendo, las revisiones de código, la transferencia de conocimiento mediante mentoría y programación en pares, las pruebas, la depuración, y la sobrecarga humana que conlleva la coordinación y comunicación. Todo esto envuelto dentro del laberinto de tickets, reuniones de planificación y rituales ágiles.

Estos procesos, destinados a impulsar la calidad, a menudo nos ralentizan más que el acto de escribir código en sí, porque requieren reflexión, comprensión compartida y buen juicio.

Ahora, con los LLMs facilitando la generación de código funcional más rápido que nunca, ha cobrado fuerza la idea de que escribir código era el cuello de botella, y que finalmente lo hemos resuelto.

Pero eso no es del todo correcto.

El coste marginal de agregar nuevo software se está acercando a cero, especialmente con los LLMs. Pero ¿cuál es el precio de entender, probar y confiar en ese código? Más alto que nunca.

Los LLMs desplazan la carga de trabajo, no la eliminan

Herramientas como Claude pueden acelerar una implementación inicial. Sin embargo, el resultado es a menudo más código fluyendo a través de los sistemas y más presión sobre las personas responsables de revisarlo, integrarlo y mantenerlo.

Esto se vuelve especialmente claro cuando:

• No queda claro que el autor entienda claramente lo que ha entregado

• El código generado introduce patrones poco familiares o rompe convenciones establecidas

• Los casos límite y consecuencias inesperadas no son obvios.

Todo esto nos lleva a una situación en la que el código es más fácil de generar pero más difícil de validar, lo cual no necesariamente hace que los equipos avancen más rápido en general.

No es un desafío nuevo. Los desarrolladores han bromeado durante mucho tiempo sobre la “ingeniería del copiar y pegar”, pero la velocidad y escala que los LLMs habilitan han amplificado esos hábitos de copiar y pegar.

Entender el código sigue siendo la parte difícil

El mayor coste del código es entenderlo, no escribirlo.

Los LLMs reducen el tiempo que lleva generar código, pero no han cambiado la cantidad de esfuerzo requerido para razonar sobre el comportamiento, identificar errores sutiles, o asegurar el mantenimiento a largo plazo. Ese trabajo puede ser incluso más desafiante cuando quien revisa lucha por distinguir entre código generado y escrito a mano o entender por qué se eligió una solución particular.

Los equipos siguen dependiendo de la confianza y un contexto compartido

La ingeniería de software siempre ha sido colaborativa. Depende del conocimiento compartido, el alineamiento y la mentoría. Sin embargo, cuando el código se genera más rápido de lo que puede ser discutido o revisado, los equipos corren el riesgo de adoptar una dinámica en la que la calidad se asume en lugar de asegurarse. Eso crea estrés en los revisores y mentores, potencialmente ralentizando las cosas de maneras más sutiles.

Los LLMs son potentes, pero no resuelven lo fundamental

Hay un valor real en la creación más rápida de prototipos, andamiaje y automatización. Pero los LLMs no eliminan la necesidad de pensamiento claro, revisión cuidadosa y diseño consciente. Si acaso, estos se vuelven aún más importantes a medida que se genera más código.

Sí, el coste de escribir código ciertamente ha disminuido. Pero el costo de comprenderlo y gestionarlo colectivamente no lo ha hecho.

Ese sigue siendo el cuello de botella. No pretendamos que no lo es.