El mundo del programación con
Inteligencia Artificial ha entrado en una nueva fase desde finales del año pasado cuando comenzamos a ver que programar con
IA dejaba de ser algo como
Vibe Coding, para convertirse en una herramienta capaz de hacer
tools y proyectos de gran tamaño y con gran calidad. Ahora le estamos dando el proyecto completo y lo hace con una alta calidad, y podemos ver resultados como el que os publiqué hace poco para, en un par de minutos,
migrar un código en C++ de un juego a TypeScript y tenerlo funcionando en Workers de Cloudflare.
Figura 1:La gestión de la "Deuda Cognitiva" en servicios
programados con Inteligencia Artificial
Impresionante. Y estamos entrando en una fase donde las empresas solo tienen que crear sus MCPs internos, darle las herramientas a sus empleados y dejarles que se creen las tools y los agentes que quieran para automatizar sus tareas del día a día más de forma mucho más avanzada que antes. Es común encontrarse con amigos y preguntarse... ¿qué estás haciendo tú con IA? Existe hasta cierta ansiedad por no ser el que menos partido le esté sacando a este nuevo mundo.
Me encanta. Puedes hacer en minutos tus proyectos, tus tools, y automatizar muchas cosas. Es un mundo increíble en el que se pueden hacer muchas cosas de forma muy rápida, y avanzar el ritmo de innovación a marchas forzadas. Pero la pregunta que queda en las conversaciones es... Te aburres, hazte un juego en un minuto.
Como ya os conté, nosotros fuimos creyentes de este mundo desde el día uno e incluso hicimos, pensando en mi
AMSTRAD CPC 6128, un
BASIC 1.0 Copilot para AMSTRAD CPC 6128, que publicamos en la RootedCON de hace dos años.
Sabíamos que la IA lo iba a cambiar todo, y por supuesto, también la programación, así que desde el principio nos pusimos mucho las pilas con esto. Pero... ¿y hoy en día?
¿Ya no será necesario saber programar?
Os prometo que yo me he hecho esta pregunta internamente muchas veces desde que escuché a CTOs decir que sus ingenieros ya no tiran líneas de código, y tengo mi propia reflexión, que tiene que ver con el título de este artículo y con un concepto muy relevante, que es el de "Deuda Cognitiva". Este concepto hace referencia a cuánto dejas de saber de cómo está hecha una pieza clave en tu negocio. Y lo que sería el nivel aceptable o no aceptable lo decides tú. Es así de sencillo.
Por ejemplo, hemos incurrido en mucha Deuda Cognitiva en cómo funcionan los sistemas operativos que utilizamos en las empresas. No conocemos todos los detalles de su funcionamiento, ni tan siquiera el control que de ellos pueden tener las empresas que los crean. Simplemente confiamos en ellos. En el Windows, en el Mac, en el iPhone y el Samsung Galaxy con Android. Pero también lo hacemos en el MS Office o el mismo Salesforce. Tenemos Deuda Cognitiva en cómo está construida la herramienta.
Pero si vamos a más allá, tenemos Deuda Cogntiva en casi todo. Cuando programamos y hacemos nuestro propio código fuente en Rust, JavaScript, Python o NodeJS, el código en ASM, o el binario son del pasado. No nos importa, porque confiamos que va a funcionar en otro sitio, y si no, al menos podemos reconstruirlo, porque sabemos cómo se hace, y podemos migrarlo.
Ahora bien, cuando hacemos un software con
Prompting, nuestro código fuente pasa a ser el
Prompt, y ese
Prompt, cuando se interpreta da un código, pero... no es determinista. Ya os conté mi aventura con el
Insane Vibe Coding with Harsh Prompting. Puede que lo haga de una forma u otra. No, no te asustes, esto también te puede pasar con un código en
C++ según el compilador que utilice se generará un código
ASM o binario diferente.
Eso sí, puedes garantizar que, con un 95% de probabilidades, el compilador no afectará a la lógica del programa resultante. Con el Prompt, no tenemos aún esa certeza si cambiamos el modelo que tenemos por debajo - corregidme si me equivoco - pero el nivel de creatividad y no determinismo es alto aún modelo contra modelo. Lo que podríamos hacer es darle el código generado por el modelo anterior a un nuevo modelo y decirle que lo migre o lo cambie. Pero volvemos a depender de que el modelo de IA lo haga bien. No tenemos control directo.
No pasa nada. Si la herramienta que estamos construyendo no es del core de nuestro negocio, puede que no sea importante, y en el caso de que tengamos un problema con ella, construimos otra de cero igual, o similar. Por ejemplo, una herramienta para hacer tareas personales, controlar nuestra gestión de acciones diarias o para trabajar con los documentos ofimáticos como nos gusta. Perfecto.
La duda es cuando llegamos al software core de nuestro negocio. Supongamos una compañía, que vive de tener un software de alta calidad en el backend y en las apps, ¿Puede entrar en Deuda Cognitiva? Podrían entrar en Deuda Cognitiva en módulos accesorios, o pruebas, pero en el Core de su servicio. Tengo mis dudas.
Cuando entramos en Deuda Cognitiva significa que no sabemos bien cómo está hecho, y cuando hay que actualizarlo, modificarlo o cambiarlo, no somos capaces de hacerlo fácilmente. De hecho, he visto a mucha gente haciendo una tool súper-chula y luego no ser capaces de meterle mano ni con IA para actualizarlo, cambiar algo, o mejorarlo. Cada cosa que tocaban, rompía algo diferente.
Yo me pasé horas con un proyecto, intentando que me hiciera un cambio sin romper la funcionalidad anterior y no fui capaz. Y me ha pasado hasta con gráficos hechos con Nano Banana, que una vez construidos, cuando he querido hacer una modificación sobre ellos a golpe de Prompting ha sido un horror.
Unas ideas finales
Creo que programar con IA es fundamental hoy en día, y creo que el tooling personal, los agentes, las apps internas pueden beneficiarse horrores de tener estas nuevas capacidades. Y creo también que delegar a desarrollo con IA proyectos completos que no son críticos para el negocio puede dar a las empresas y a las personas una ventaja competitiva brutal.
Pero....
Y aquí viene el pero (por poner algún soft-limit). Creo que no hay que incurrir sin control en Deuda Cognitiva en las piezas de software core de la compañía. Además, antes de poner en producción en un entorno abierto, estos proyectos de software hechos puramente por IA deben pasar mínimas evaluaciones de seguridad, búsqueda de vulnerabilidades, fortificación, y auditoría.
No hay que confiar más en que un modelo de
IA hace más seguro el
software que lo que lo haría un programador senior con experiencia, o que no vaya a cometer errores de seguridad tan sencillos de explotar como los que escribiría un desarrollador junior. Si no, léete el libro de "
Hacking IA" y te cambiará la visión.
Por supuesto, el CTO de la compañía tiene que tener el control de dónde hay Deuda Cognitiva, dónde no lo hay, y cuál es el riesgo en que estamos incurriendo aceptando la Deuda Cognitiva que estamos incorporando en la compañía. Vamos, que es otro indicador de riesgo que hay que tener presente.
¡Saludos Malignos!
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
