Un veterano ingeniero desmonta el mito de que la programación está resuelta

Coding Is Not Solved – Alex Ewerlöf Notes

Un veterano ingeniero desmonta el mito de que la programación está resuelta

Alex Ewerlöf, con dos títulos de ingeniería y años construyendo sistemas con IA, sostiene que la programación no está resuelta: la IA no puede rendir cuentas y los requisitos no funcionales —mantenimiento, seguridad, escalabilidad— siguen siendo el grueso del coste. Solo en software personal, pruebas de concepto o usos maliciosos no hace falta leer el código. Critica que se degrade el servicio que pagamos por forzar la IA donde no pertenece.

La IA no puede rendir cuentas. No puede sufrir consecuencias. Lo peor que puedes hacerle a la IA es desenchufarla.
  1. efficax

    Leer el código no significa entender el código. Una lección que la experiencia en software me dio: nunca entendí el código. Crees que funciona de cierta manera, hasta que descubres que no.

    Lo que los LLMs hacen posible es que yo diga: descubre todas las formas en que esto funciona. Analiza las distintas maneras en que podemos ejecutar este software, construye un fuzzer, construye property tests y ejecuta este software en todos los escenarios posibles. Registra trazas completas. Registra todas las salidas. Ahora, analiza cada escenario en busca de bugs. No puedes hacer eso a mano.

    Si nos comprometemos con ello, si destinamos los recursos y dedicamos el tiempo (¡y podríamos hacerlo simplemente diciendo: tomará la mitad de lo que solía tomar!), el software construido por LLMs en sanidad, finanzas, automoción, defensa, plantas eléctricas, aviación, manufactura puede volverse MÁS fiable y mejor con LLMs... sin leer jamás una sola línea de código. Los LLMs son muy buenos en lógica, por cierto.

    En fin, todo esto suena a alguien que en realidad no usa LLMs para construir software o que no los ha probado en un tiempo. Yo sentía lo mismo en 2025. He escrito cientos de miles de líneas de código difícil. Tú, la persona que lee esto, probablemente has interactuado con software que yo he escrito. Durante un tiempo habrías interactuado con él cada vez que hacías una transacción con tarjeta de débito en Estados Unidos, por ejemplo. Entiendo el código y me importa la calidad, y por eso estoy totalmente a favor de los LLMs para el código.

  2. askonomm

    Lo que he encontrado es que la IA permite que los desarrolladores vagos e incompetentes sean más vagos y más incompetentes. Esto tiene como efecto que la calidad del producto se resienta más, y más rápido. Como resultado de la enorme cantidad de código que se está publicando ahora, las revisiones de código, algo que antes evitaba en cierta medida que los desarrolladores vagos e incompetentes publicaran código horrible, está efectivamente muerto y enterrado, ya que ningún humano puede revisar de forma realista tales cantidades de código. Algunas empresas han adoptado IA para revisar código, lo cual, bueno... tienes IA que hace código, IA que revisa código... espero que puedas ver la estupidez aquí si esperas ver algún resultado determinista.

    Supongo que el tiempo dirá si el consumidor se adaptará a la menor calidad de los productos, permitiendo a las empresas justificar la existencia de desarrolladores vagos e incompetentes, o si el consumidor se rebelará, forzando a las empresas a aumentar la calidad de sus desarrolladores.

    Nota: uso IA todos los días y es totalmente posible crear software de alta calidad con ella, siempre que no seas vago e incompetente.

  3. temp00345

    Leo artículos así más o menos cada día.

    Este artículo sería 100% correcto si hubiera salido hace 1 año, 75% correcto hace 9 meses, 50% correcto hace 3 meses y probablemente sea 25% correcto ahora, si no menos.

    Entiendo totalmente de dónde viene esto. Yo también estoy luchando por aceptar que mis más de 30 años de experiencia en programación se están volviendo obsoletos rápidamente. Estoy perdiendo el sueño por esto, es duro.

    Pero simplemente dale otra oportunidad a los últimos modelos (Opus 5.5 / Astra 6 a día de hoy).

    Mira de lo que son capaces y lee el código que producen.

    Cualquier área problemática, C++ de bajo nivel o TypeScript de alto nivel o Clojure o una combinación extraña de estos...

    No seas tímido, dales una tarea grande, deja que construyan una app entera, UI y todo...

    Ahora compara la salida con Opus 4 o gpt-5 de hace 1 año, cuando no podían armar una sola función sin que fuera rara y llena de bugs.

    Este es exactamente mi problema, no que los modelos ya sean muy buenos, sino lo rápido que se volvieron tan buenos.

    Así que si la programación no está resuelta todavía, llegará allí muy pronto.

  4. thesumofall

    Creo que el autor subestima lo aburrido y simple que es el 90% del software empresarial. La parte que no alimenta aviones y plantas eléctricas. Gran parte de él proviene de trabajos de una noche, subcontratistas mal gestionados y requisitos que ya de por sí son de baja calidad (porque los escriben personas con trabajos diarios muy distintos). ¿Y sabes qué? La mayor parte de eso funciona 24/7 sin un fallo. Los LLMs simplemente nos dan más de eso. Y quizá incluso sea mejor.

  5. brainless

    He estado programando durante unos 30 años (incluyendo los años de escuela). Profesionalmente durante 18 años.

    ¿Alguien puede decirme por qué tenemos 40 o más lenguajes de programación, con unos 10 populares? Luego unos 20 frameworks en cada uno de ellos. ¿Y añadir otras 200 bibliotecas populares para cada lenguaje? Esta matriz no tiene sentido hasta que te das cuenta: son preferencias hasta el fondo.

    La mayoría de nosotros, los ingenieros, hemos construido nuestro propio modelo mental de la programación. Todos tenemos razón. Pero a los usuarios no les importa. Los LLMs están aquí para producir código cada vez más cerca del metal según se necesite. Pueden sentarse y crear un grafo a partir de cada especificación, usar un AST que ellos desarrollen y ejecutarlo en la CPU si hace falta. Lo harán. Ninguna cantidad de discusión por nuestra parte detendrá eso.

    La programación va a ser reinventada. No creo que las formas actuales de escribir software siquiera importen.

  6. hibikir

    > Tampoco puedes ser responsable de lo que no puedes controlar. Esa comprensión es clave para razonar sobre el comportamiento del sistema y arreglarlo cuando la IA inevitablemente falle.

    Esta no es una buena premisa. En todo el derecho, encontrarás personas hechas responsables de lo que no controlan y que de algún modo poseen. Suelta un perro que daña a un niño, o simplemente tenlo en un entorno del que pueda escapar, y mira qué pasa.

    Existen situaciones impredecibles en las que uno podría no ser considerado responsable, ya que un problema podría ocurrir mucho más allá de las directrices razonables.

    Así que, por supuesto, se te puede hacer responsable de lo que hace una IA que supuestamente no puedes controlar del todo, o del código escrito por IA que entregas. Trátalo como soltar una manada de lobos, o vender un juguete inseguro que puede mutilar a niños. Hay precedentes por todas partes.

  7. thefilmore

    De los autores de "la programación está resuelta": hoy, un colega que intentaba ejecutar Claude Code se topó con un problema en el que muestra el menú de ayuda de Bun en su lugar [1]. Antes, Claude Code se desinstaló a sí mismo varias veces cuando yo lo usaba. [2]

    [1] https://github.com/anthropics/claude-code/issues/88715

    [2] https://github.com/anthropics/claude-code/issues/7547

  8. hakunin

    Aquellos que afirman que el software generado por LLM es suficientemente bueno:

    No han escrito código en siglos

    ¡No pueden detectar si su código, literalmente, tuviera 6 dedos!

    Tienen un listón bajo de lo que es bueno

    No les importa la calidad ni los RNF

    Tienen dificultades para entender una curva S

    Hay excepciones como antirez, pero creo que esto se aplica a muchos optimistas ruidosos por ahí.

  9. lordnacho

    Mis pensamientos sobre esto:

    - La programación a pequeña escala está resuelta. Tengo un estado actual, quiero cambiarlo y sé cómo quiero cambiarlo. Por ejemplo, tengo un manejador TCP bloqueante por alguna razón y quiero hacerlo asíncrono. Puedo trastear con él o simplemente dejar que el LLM haga los cambios por mí.

    - La programación en el sentido más amplio nunca está resuelta. Necesitas criterio para decidir qué quieres que se haga. Sin importar lo que estés construyendo, habrá decisiones que tomar (¿Para quién/qué es?) y esas decisiones cambian con el tiempo. Los LLMs pueden tomar algunas decisiones por defecto por ti, y si estás de acuerdo con ellas, obtienes lo predeterminado (genial para POCs). Sin embargo, puede que ni siquiera te des cuenta de lo que decidió hacer por ti. A cierta escala, pasarás mucho tiempo revisando esas decisiones. Pero lo que tenemos ahora es que la fricción para cambiar las decisiones es bastante menor. Ahora puedes probar muchas cosas que antes consumían mucho tiempo.

    - El punto de que los LLMs son probabilísticos no es tan importante como se hace ver. Si le pido a un desarrollador junior que programe algo, tampoco sé qué hará. Demonios, puedes estar seguro de que eres capaz de resolver algo, y aun así tú mismo no sabes cómo será la solución. Quizá resulta que la biblioteca que ibas a usar no es apropiada después de todo. No sabes qué usarás al final, pero sí sabes que algo arreglará el problema. Puede haber más de una solución a un problema, y no siempre importa cuál encuentres.

    - SIGO t [...]

  10. josephmtummon

    Leyendo el artículo, definitivamente estuve de acuerdo con el autor, pero también me encontré de acuerdo con los contraargumentos en los comentarios.

    Lo que encuentro conflictivo personalmente sobre las prácticas de programación con IA es que estoy completamente de acuerdo en que la IA es increíblemente impresionante para completar incluso tareas complicadas, y al menos puedo decir que es muchísimo mejor que yo escribiendo código.

    Mi problema con ello es que te da una opción "vaga" cada vez que no requiere el mismo nivel de pensamiento. Entiendo que esto es completamente culpa mía como desarrollador, y la solución simple es que debo asegurarme de tomarme mi tiempo para aprender y entender exactamente qué está produciendo el LLM. Intento esto y he configurado habilidades separadas para asegurarme de construir mi comprensión sobre la marcha.

    De todos modos, si me siento hoy e implemento algo sin usar LLM, me toma mucho más tiempo, pero una vez que entro en ello, encuentro un estado de flujo que nunca puedo obtener del ir y venir leyendo la salida del LLM. Luego, cuando termino, aunque mi solución no sea perfecta, he aprendido mucho más y mi propio contexto del problema es mucho mejor, y por lo general entonces puedo revisar con un LLM. Esto normalmente me deja con una mejor implementación y, más importante, una que puedo defender.

    Creo que para un desarrollador más nuevo como yo (~2 años de experiencia), como no he acumulado años y años de experiencia resolviendo problemas, si no me hago tiempo en el día para dejar de lado las herramientas de IA y mejorar mi resolución de problemas, me [...]

Más de este día

2026-09-28