Cada vez que aparece un modelo de inteligencia artificial más potente, vuelve la misma pregunta: ¿se acaban los programadores? Con Claude Fable 5 la pregunta suena más fuerte porque ya no hablamos de un asistente que escribe funciones sueltas o corrige un error de sintaxis. Hablamos de modelos capaces de entender proyectos completos, razonar sobre arquitectura, depurar, proponer cambios, escribir documentación, revisar seguridad y ayudar a mantener conversaciones largas sobre código, producto y decisiones técnicas.
Yo no creo que esto sea el fin de los programadores. Sería demasiado simple. Lo que sí creo es que estamos entrando en una democratización enorme del desarrollo de software. Y esa democratización va a afectar a todos los niveles: al profesional senior, al desarrollador junior, al emprendedor, al administrador de sistemas, al creador independiente y a cualquiera que tenga una idea clara pero no siempre el tiempo, el equipo o la energía para convertirla en una aplicación real.
En mi caso lo he vivido de una forma muy personal. Yo empecé a programar en otra época, con Turbo Pascal, Turbo C, Delphi y aquellas herramientas que te obligaban a entender muy bien la máquina, el compilador, las librerías y tus propios límites. Después la vida profesional te lleva por otros caminos: empresas, infraestructura, cloud, gestión, ventas, marketing, proyectos, clientes, equipos. No dejas de tener criterio técnico, pero ya no estás todos los días escribiendo código como antes.
Y, de repente, la IA me ha devuelto parte de esa capacidad de programación con menos esfuerzo.
No porque el modelo haga magia. No porque uno le pida “hazme una app” y aparezca un producto serio. Sino porque reduce muchísimo el coste de volver a intentarlo. Te permite recuperar velocidad, preguntar, contrastar, probar enfoques, recordar patrones, revisar errores y avanzar. En mi caso, eso se ha traducido en aplicaciones para iOS y Mac como Mbox Viewer Pro, FlarePurge, DocProtect o FitBono; en herramientas para Windows como FlarePurge; y en proyectos open source como mboxshell, pensado para abrir ficheros MBOX de copias de correo.
También me ha permitido algo que me interesa casi tanto como crear cosas nuevas: rescatar cosas viejas.
La IA como palanca para recuperar software olvidado
Una de las partes más bonitas de esta etapa no está en crear otra aplicación de moda, sino en poder rescatar software, formatos y proyectos que parecían condenados al olvido.
Durante los últimos meses he podido refactorizar aplicaciones antiguas y obsoletas como bitadir.com, programacion.net o glosarium.com. Proyectos que tenían historia, utilidad o valor personal, pero que arrastraban código antiguo, dependencias viejas, estructuras heredadas y decisiones técnicas de otra época. Antes, enfrentarse a eso requería una cantidad de tiempo difícil de justificar. Hoy, con IA, se puede revisar, entender, reordenar y modernizar con una velocidad muy distinta.
No es automático. Hay que saber qué tocar y qué no tocar. Hay que probar. Hay que desconfiar. Hay que leer el código. Pero la barrera baja mucho.
El ejemplo más personal quizá sea UnQuantum, el proyecto open source que he lanzado en GitHub para rescatar el formato de compresión Q (Quantum), aquel compresor de MS-DOS que me encantaba. Un formato de los años 90, creado originalmente por David Stafford en Cinematronics, que usaba LZ77 con codificación aritmética y que tuvo relación histórica con tecnologías como Microsoft Cabinet. Lo he reimplementado en Rust para sistemas modernos, con soporte multiplataforma para Linux, macOS y Windows.
Hace años, un proyecto así habría sido una mezcla de nostalgia, documentación dispersa, ingeniería inversa y muchas horas de prueba. Ahora sigue haciendo falta todo eso, pero la IA ayuda a ordenar el proceso. Te permite entender mejor especificaciones antiguas, comparar implementaciones, escribir tests, estructurar el proyecto, revisar errores de portabilidad y documentar lo que estás haciendo.
Esto no es “vibe coding” entendido como soltar instrucciones y confiar ciegamente. Es otra cosa: usar la IA como una extensión de tu memoria técnica, de tu capacidad de análisis y de tu velocidad de ejecución.
La IA no destruye el desarrollo, cambia su precio
Hace unos días escribí en este blog sobre una idea que sigo viendo muy clara: la IA no está destruyendo empleo, está cambiando el precio del trabajo. Aplicado al desarrollo de software, ocurre algo parecido. La IA no elimina el software. Reduce el coste de producirlo, modificarlo, probarlo y mantenerlo. Y cuando algo baja mucho de precio, muchas veces no se usa menos. Se usa mucho más.
Si crear una utilidad interna costaba dos semanas y ahora cuesta dos tardes, se crearán más utilidades. Si refactorizar una web antigua costaba demasiado y ahora es asumible, se rescatarán más proyectos. Si construir una app de nicho no compensaba económicamente y ahora se puede lanzar con menos esfuerzo, aparecerán más aplicaciones pequeñas, concretas y personales.
Esto no significa que todo vaya a ser bueno. De hecho, puede pasar lo contrario: tendremos más software mediocre, más código generado sin entender, más dependencias innecesarias, más apps que funcionan en una demo pero no aguantan un uso real, más problemas de seguridad y más proyectos abandonados porque nadie sabe mantener lo que la IA generó.
Pero esa parte no invalida el cambio. Solo nos recuerda que el desarrollo nunca fue solo escribir código.
Programar es entender el problema. Es organizar. Es decidir. Es probar. Es pensar en el usuario. Es saber cuándo una solución es demasiado compleja. Es saber cuándo una librería no merece la pena. Es entender qué datos manejas, dónde los guardas, qué pasa si algo falla, cómo se actualiza, cómo se firma, cómo se distribuye y cómo se mantiene.
La IA acelera mucho la escritura de código. Pero no sustituye el criterio.
Quien sepa programar tendrá más ventaja, no menos
Aquí es donde discrepo de los titulares más alarmistas. No veo un futuro donde “nadie necesite programadores”. Veo un futuro donde mucha más gente podrá crear software básico o intermedio, y donde los buenos programadores serán todavía más valiosos.
Porque cuando cualquiera puede producir código, la diferencia estará en producir buen software.
Un desarrollador con criterio podrá hacer más. Mucho más. Podrá revisar propuestas de la IA, detectar errores sutiles, pedir mejores alternativas, dividir tareas, crear tests, diseñar arquitectura, automatizar despliegues, documentar decisiones y convertir un prototipo en algo mantenible.
Una persona sin base técnica también podrá crear cosas. Y eso es positivo. Pero dependerá mucho más del modelo. Si algo falla, quizá no sepa por qué. Si el proyecto crece, quizá no sepa cómo ordenarlo. Si aparece una vulnerabilidad, quizá no la vea. Si una dependencia queda abandonada, quizá no entienda el riesgo.
La diferencia entre “pedir código” y “construir software” va a ser cada vez más importante.
Y esto afecta también a las empresas. Una compañía que use IA solo para despedir desarrolladores probablemente acabará con deuda técnica más rápida y más barata. Una compañía que use IA para multiplicar a sus equipos técnicos, documentar mejor, reducir tareas repetitivas, probar más hipótesis y lanzar productos que antes no eran viables puede ganar muchísimo.
La pregunta buena no es: “¿cuánta gente puedo ahorrar con IA?”.
La pregunta buena es: “¿qué puedo construir ahora que antes no podía?”.
Claude Fable 5 y el problema de los modelos demasiado potentes
Claude Fable 5 representa muy bien esta nueva fase. Anthropic lo presenta como un modelo de clase Mythos para uso general, con capacidades avanzadas en desarrollo de software, trabajo técnico, investigación y tareas largas. Pero también llega con salvaguardas importantes. En determinadas áreas sensibles, como ciberseguridad, biología, química o desarrollo de modelos frontera, el sistema puede limitar respuestas o redirigir consultas a otro modelo más controlado, como Claude Opus 4.8.
Esta parte me parece muy relevante, porque muestra una contradicción que vamos a ver cada vez más.
Por un lado, queremos modelos mejores. Queremos que programen mejor, que entiendan mejor, que encuentren errores, que revisen seguridad, que ayuden a investigar, que automaticen tareas complejas. Por otro lado, cuando el modelo es demasiado bueno en ciertas áreas, aparece el miedo razonable a que también sirva para atacar sistemas, explotar vulnerabilidades, ayudar en usos peligrosos o transferir capacidades a competidores.
Ahí empieza una nueva etapa: modelos muy potentes, pero con puertas internas.
No pagas solo por inteligencia artificial. Pagas por una inteligencia artificial condicionada por políticas del proveedor. Algunas restricciones tendrán sentido por seguridad. Otras pueden mezclarse con intereses comerciales. Y otras serán simplemente incómodas para quien quiera usar el modelo como herramienta técnica de alto nivel.
Esto también obliga a pensar en dependencia. Si basas tus flujos de desarrollo en un único modelo cerrado, aceptas sus cambios de política, sus límites, sus precios y sus decisiones. Igual que aprendimos con el cloud que no conviene depender de un único proveedor sin plan de salida, tendremos que aprender lo mismo con la IA.
El riesgo de la programación sin comprensión
La democratización del desarrollo será positiva, pero no inocente. Vamos a ver a mucha gente crear software sin saber realmente cómo funciona. Y eso tiene riesgos.
El primero es la falsa sensación de control. Si la aplicación arranca, parece que todo va bien. Pero quizá no gestione bien errores, no valide entradas, no tenga tests, exponga datos, use mal permisos o dependa de una librería insegura.
El segundo es la deuda técnica generada a gran velocidad. Antes una mala arquitectura tardaba semanas en crecer. Ahora puedes crear una mala arquitectura en una tarde.
El tercero es la pérdida de aprendizaje. Si los perfiles nuevos solo piden soluciones y nunca entienden por qué funcionan, no desarrollan criterio. Esto me preocupa especialmente en los juniors. La IA puede ser un tutor extraordinario si se usa bien, pero también una muleta peligrosa si sustituye el esfuerzo de comprender.
El cuarto es la homogeneización. Si todo el mundo usa los mismos modelos para generar las mismas soluciones, veremos patrones repetidos, interfaces parecidas, arquitecturas copiadas y errores comunes a gran escala.
Por eso creo que la nueva alfabetización técnica no consistirá solo en aprender a programar. Consistirá en aprender a trabajar con IA sin abdicar del criterio.
Del programador que escribe código al creador que dirige sistemas
La imagen clásica del programador era alguien escribiendo líneas de código durante horas. Esa figura no desaparece, pero se transforma. Cada vez será más importante saber dirigir sistemas: modelos, agentes, repositorios, tests, despliegues, documentación, APIs, permisos, datos y usuarios.
El valor se desplazará desde “sé escribir esta función” hacia “sé convertir esta necesidad en un sistema que funcione”.
Eso favorece a perfiles híbridos. Personas que entienden negocio y tecnología. Administradores de sistemas que saben dónde duele una infraestructura. Emprendedores que conocen un problema de nicho. Periodistas capaces de automatizar análisis de documentos. Abogados que entienden procesos repetitivos. Médicos o investigadores que saben qué herramienta les falta. Y, por supuesto, programadores que saben pensar más allá del código.
Ahí veo una oportunidad enorme.
No todos crearán grandes empresas de software. Pero sí veremos muchas más herramientas pequeñas. Más proyectos personales. Más utilidades internas. Más rescates de software antiguo. Más automatización local. Más aplicaciones que antes no existían porque no compensaba pagar su desarrollo.
En ese mundo, el software se vuelve más personal. Más cercano. Más hecho a medida.
Mi conclusión personal
Claude Fable 5 no es el final de los programadores. Es una señal de que el desarrollo de software se está abriendo. Como lo hicieron en su día los ordenadores personales, los lenguajes visuales, la web, WordPress, GitHub o el cloud. Cada salto redujo una barrera. Cada salto creó ruido. Y cada salto hizo más valioso el criterio de quienes sabían usar bien la herramienta.
Yo, que venía de Turbo Pascal, Turbo C y Delphi, he podido volver a programar de una forma que hace años me habría parecido difícil de encajar en mi día a día. He podido crear aplicaciones nuevas, refactorizar proyectos antiguos, recuperar formatos olvidados y lanzar herramientas open source. Eso no me convierte en un ingeniero de software moderno a tiempo completo. Pero sí demuestra algo importante: la IA devuelve capacidad de creación a personas que ya tenían experiencia, ideas y criterio, aunque no estuvieran metidas cada día en el último framework.
Y eso va a cambiar muchas cosas.
No se nos viene encima un mundo sin programadores. Se nos viene encima un mundo con muchos más creadores de software. Algunos serán buenos. Otros harán desastres. Los mejores serán quienes combinen IA con fundamentos: arquitectura, seguridad, producto, datos, pruebas, experiencia de usuario y sentido común.
La programación no muere. Se desplaza.
Antes la pregunta era: “¿sabes escribir código?”.
Ahora empieza a ser: “¿sabes dirigir la construcción de algo útil?”.
Y ahí, quien sepa programar, organizar y pensar seguirá teniendo una ventaja enorme.
Preguntas frecuentes
¿Claude Fable 5 puede sustituir a los programadores?
No creo que sustituya a los buenos programadores. Sí puede automatizar muchas tareas de desarrollo y permitir que más personas creen software, pero el criterio técnico seguirá siendo decisivo.
¿Qué cambia para quienes aprendieron a programar hace años?
La IA reduce la barrera para volver. Permite recuperar velocidad, entender nuevas herramientas, refactorizar proyectos antiguos y crear aplicaciones modernas sin tener que empezar desde cero en cada tecnología.
¿Por qué saber programar seguirá siendo importante?
Porque generar código no es lo mismo que construir software fiable. Hay que revisar, probar, entender arquitectura, seguridad, datos, despliegues y mantenimiento.
¿Qué riesgo tiene crear software con IA?
El principal riesgo es aceptar código sin entenderlo. Eso puede generar deuda técnica, errores de seguridad, dependencia del proveedor de IA y aplicaciones difíciles de mantener.
PD: Igual el modelo Claude Fable 5 te lo encuentras cerrado a petición del Gobierno de los EEUU porque «es peligroso», como si no hubiese muchas más cosas peligrosas. Aunque claro peligroso para que y para quien…
La entrada Claude Fable 5 y la nueva programación: del Turbo Pascal a la IA aparece primero en Carrero.
