Inteligencia artificial, creación y el proceso interior

Comienza a ser un debate recurrente, en algunos casos puede que hasta cansino, la relación del humano con la inteligencia artificial, si nos sustituirá o no, si sólo debe actuar como un copiloto o si afecta a nuestras capacidades cognitivas o no.

En este post quiero hacer una breve reflexión sobre el caso concreto del proceso creativo. Una reflexión que no es teórica, y que no busca realmente un posicionamiento, sino que es una visión muy individual mía, muy experiencial, aunque presumo que sensaciones parecidas las deben experimentar muchas otras personas, y por eso me parece valioso compartirlo.

El salto de la inteligencia artificial generativa

Quizá unos de los ámbitos en que más ha mejorado la inteligencia artificial en los últimos tres años, sea en todo lo que tiene que ver con la 'creación' o, si se prefiere, la generación de contenidos. Unos contenidos que inicialmente, fueron esencialmente textuales, pero en seguida saltaron a la imagen, al vídeo y a la música.

Un proceso, ese de la generación que, sobre todo en el campo del texto, va más allá de una creación mecánica de ese texto, sino que aporta 'conocimiento', datos y estructura. Y que, además, puede incluso hacer uso de resortes emocionales, quizá especialmente destacados en el caso de la generación musical.

Sobre el discutido concepto de creatividad

Se discute mucho sobre lo que es creatividad y lo que no y, sobre todo, si lo que hace la inteligencia artificial generativa es verdadera creatividad o no y, yendo más lejos, si se puede llegar a considerar arte algo creado con inteligencia artificial generativa.

No creo que sea un tema claro, realmente. Me parece, aunque me confieso un poco lego en la materia, que el propio concepto de lo que es el arte es, como diría 'el otro', algo discutido y discutible.

Pero sin llegar a la de idea de arte, y quedándonos sólo en creatividad, se alega a veces que la inteligencia artificial no es creativa porque, en el fondo, reutiliza unos patrones de base estadística que se le han enseñado y los utiliza para sus nuevas creaciones o, si se prefiere, generaciones. No sé si eso es suficiente para decir que la inteligencia artificial no es creativa, y menos teniendo en cuenta que parece que, en el fondo, la creatividad humana funciona, al menos parcialmente, de la misma forma: aplicando a ámbitos nuevos o de formas nuevas patrones que ya ha visto en el pasado.

En cualquier caso, el debate sobre la presunta o no creatividad de la inteligencia artificial, aunque atractivo, no es lo que me ocupa ahora. Para lo que sigue, el que llamemos creatividad o no a producción de contenidos de la inteligencia artificial generativa, me es irrelevante.

Lo cierto es que puede crear textos, imágenes, videos, sonidos y música nuevos y de una alta calidad factual y estética.

¿Dónde quedamos los humanos y nuestra creatividad y nuestro arte, ante todo esto?

Tomándomelo de modo personal

Todo lo que antecede es una exposición de contexto, pero a partir de aquí comienzo con mi experiencia personal. Y para esa experiencia hablaré de mi particular producción de contenidos.

Mi producción de contenidos se centra especialmente en lo textual, en la escritura. Creo textos, por ejemplo, para este mismo blog. He creado, y espero seguir creando, texto para los libros que he publicado o en los que he colaborado. He creado texto como material docente. He creado, incluso, aunque al menos de momento muy poco publicado, texto de naturaleza más artística, del ámbito literario (ensayo, narrativa e incluso alguna especie de poesía).

Para mi labor como 'speaker' y como docente, utilizo también mucho las hoy en día un poco denostadas presentaciones PowerPoint.

En bastante menor medida también creo en otros medios. Creo imágenes como complemento de artículos o presentaciones. Creo algunos vídeos como promoción, como realce de alguna charla o clase... o por el placer de hacerlo. Creo con mi voz participando en podcasts. Y he creado algo de música fundamentalmente como fondo de vídeos. 

Para esta creación multimedia, imágenes, video y música hoy en día me apoyo mucho, cada vez más, en el uso de la inteligencia artificial.

Sin embargo, para la voz y, sobre todo, para la creación textual y las presentaciones, pese a que sabría perfectamente cómo hacerlo con inteligencia artificial (es más, de vez en cuando enseño cómo hacerlo) mi mecánica sigue siendo clásica, es decir, genero el texto o las presentaciones por mí mismo, más o menos manualmente, aunque, evidentemente, usando un ordenador, y esporádicamente alguna ayuda de la inteligencia artificial.

¿Por qué ese diferente planteamiento según el contenido que genero?

Pues tiene mucho que ver con lo principal que quiero transmitir en este post: con el proceso interior de creación. Pero antes, un apunte sobre la calidad del resultado generado con inteligencia artificial.

La calidad del resultado

La inteligencia artificial generativa ha avanzado una barbaridad en poco tiempo y los resultados que ofrece son cada vez mejores. Los textos están bien redactados, bien estructurados, con mucho conocimiento por detrás y, en general, 'suenan bien' o incluso muy bien.

La calidad física de imágenes, vídeos y música es muy alta. Por calidad física me refiero a calidad del sonido en música o a la resolución y calidad de imagen en imágenes estáticas y vídeo. La composición suele ser buena, pero aquí, y reconociendo antes mi escasa preparación en materia de diseño o arte visual, tengo algunas 'pegas'. Las imágenes, si uno no se pelea mucho con ellas, y usando prompts cada vez más especializados, suelen ser abigarradas y un poco repetitivas. En el vídeo, se observan todavía con cierta frecuencia las famosas alucinaciones. En general, además, y aunque me imagino que esto se podría superar con práctica, insistencia y un promting avanzado y especializado, las herramientas tienden a generar imágenes, vídeo y música, de buena apariencia, pero un poco 'según le parece' y cuesta guiarla a que realicen tu idea (cuando la tienes). Con frecuencia, si no se pelea mucho, los resultados tienden además a ser repetitivos.

En general, mi sensación es que la calidad de la producción textual, es ahora mismo bastante más alta que la de la producción multimedia, pese a que ésta última nos impresiona muchísimo más.

Y, sin embargo, pese a que la inteligencia artificial genera, en mi opinión, mejores resultados en texto que en multimedia, mi uso es justo al revés, la utilizo mucho en multimedia y poco en texto.

¿No es esto contradictorio?

Pues la respuesta tiene mucho que ver con el proceso interior.

El proceso interior y la experiencia personal

Por el proceso interior, me refiero a mi forma de trabajar en la creación de contenidos, lo que experimento cuando lo hago, y lo que eso aporta al resultado y, sobre todo, a mí mismo. Y un proceso que, aunque describo como propio, me imagino que cualquier otra persona experimenta algo parecido.

En ese proceso interior de creación aportas y recibes. 

Veámoslo de forma separada

Lo que aportas cuando creas

Cuando estoy creando un texto de tipo profesional, para publicar o para docencia, aporto por un lado mi conocimiento, todo lo que he aprendido estudiando, leyendo, trabajando o escuchando a otros. Y aporto la experiencia profesional, lo que he vivido en las empresas que he trabajado, los clientes o proveedores con los que he tratado, lo que he visto en jefes y colaboradores. Y, no sólo eso, aporto mi comprensión, síntesis y en ocasiones opinión sobre el tema tratado. La inteligencia artificial puede aportar mucho en cuanto a conocimiento, datos  y estructura en este ámbito pero siento, y no quiero ser presuntuoso, que con frecuencia no está a mi altura. Lo que hace es muy correcto y lo cuenta muy bien... pero le falta 'un algo', un algo de discurso, de claridad, de exposición, de perspicacia, a veces incluso de 'alma' o personalidad. Salvo en casos y temas concretos, me gusta mucho más el contenido textual que yo genero que el que me aporta la inteligencia artificial. No es un prejuicio, es lo que veo.

Es importante resaltar, y de nuevo no quisiera ser presuntuoso pero sí claro, que esto es así en parte, por mi propias capacidades, circunstancias y motivaciones. Creo que puedo generar mejores textos que la inteligencia artificial porque atesoro mucho conocimiento, experiencia, lecturas y estudio en mis ámbitos de especialidad, porque además me gusta escribir y tengo mucha práctica en ello y, finalmente, porque soy perfeccionista y me gusta 'hacer las cosas bien' y dar los mensajes correctamente, en el orden correcto, de manera comprensible y, si es posible, incluyendo motivación.

Aún así, reconozco que, en cuanto a aportación, la inteligencia artificial es un gran competidor.

Y es por mi aportación, por lo que, en parte, no utilizo la inteligencia artificial en la generación de textos pero sí en multimedia. Porque si en texto yo creo aportar mucho, en multimedia no es así. 

Multimedia para mí es muy diferente. No tengo formación artística ni musical, salvo la muy básica obtenida en la enseñanza obligatoria. No tengo habilidad manual ninguna para dibujar. No le dedico demasiado tiempo a contemplar arte o a escuchar música. Y, quizá, uniendo la escasa formación y la falta de dedicación a contemplar las obras de terceros, no tengo imaginación suficiente para concebir una buena escena de vídeo y muchísimo menos una buena canción. Por todo ello, tengo muy poco que aportar a la hora de creación de imagen, vídeo o música. Y, sin embargo, la inteligencia artificial me permite crear con muy poco esfuerzo, aunque con las carencias ya reseñadas, imágenes, vídeos y canciones de alta calidad física, y razonable, aunque no perfecta, composición. Eso es mucho más de lo que yo soy capaz de hacer. Y por eso no duda en utilizar la inteligencia artificial.

Lo que recibes cuando creas

Pero luego está lo que yo recibo. Y probablemente eso sea muchísimo más importante y más decisivo a la hora de no utilizar la inteligencia artificial que la visión de lo que aporto.

He expresado más de una vez que 'pienso cuando escribo'. Cuando redacto un texto, del tipo que sea, reflexiono sobre lo que estoy escribiendo, maduro y cuestiono ideas, estructuro el mensaje. Incluso temas que domino, pasan por ese tamiz de la reflexión, el cuestionamiento y la reestructuración. Y todo ese proceso, aparte de ayudar a generar un mejor resultado, es enormemente enriquecedor para mí mismo, y diría que es también una forma de aprendizaje.

La reflexión, cuestionamiento y reestructuración del contenido es en sí mismo, como decía, un proceso de aprendizaje. Te ayuda a entender mejor, a estructurar mejor y a recordar. Es muy agradable, muy satisfactorio desde el punto de vista intelectual y muy enriquecedor. Te hace mejorar y a la vez te hace disfrutar. Al menos a mí.

Lo anterior aplica sobre todo a la escritura profesional.

En el caso de la escritura literaria, también aplica en buena medida lo anterior, sobre todo la reflexión, pero hay algo más y diferencial, que es la emoción. En el caso de algunos textos de carácter literario (alguno publicado y alguno no), la propia escritura me ha despertado emociones, porque al fin y al cabo escribes sobre cosas que, de alguna manera, te importan. Puede parecer absurdo, pero alguna vez hasta he soltado alguna lagrimita al releer algo que acaba de escribir. Me creo que la inteligencia artificial escriba un texto que te pueda llegar a conmover...pero estoy seguro de que no es lo mismo, en absoluto, que cuando es un texto tuyo, escrito por ti y sobre lo que te importa.

Como he dejado patente, no realizo verdadera creación artística en materia de imagen, vídeo o música. Pero presumo que, algo paralelo a lo que yo experimento al escribir, lo puede vivir un pintor o diseñador gráfico al crear una imagen, un cineasta al crear un corto o un compositor al crear una nueva pieza musical. 

E, incluso, si supusiésemos, y puede llegar a ser cierto, que la inteligencia artificial llegue a generar textos, imágenes, vídeos  y música de calidad, no solo física sino también artística, superior o similar a la humana, sólo por el hecho de experimentar en uno mismo el proceso interior de la creación, valdría la pena no utilizar la inteligencia artificial, o al menos no de vez en cuando, al menos no para aquello que realmente te importa.

Y el proceso exterior

Sólo un apunte final, que ya no hace mención al proceso interior, sino al proceso exterior.

Para el caso de creación de tipo profesional, para documentos, logotipos, presentaciones, vídeos promocionales, tiendo a pensar que al público receptor de la creación, le importe poco si lo ha hecho la inteligencia artificial, una persona o a medias. Tiendo a pensar que lo que vale es el resultado.

Pero ¿y en el caso de la creación puramente artística? ¿Y en el caso en que al autor trasmita experiencia y emociones propias? 

¿Le importaría al lector de una poesía o una novela introspectiva que haya una persona detrás que vivido, sufrido y disfrutado, o quiere sólo el texto? 

Y lo mismo diría de cualquier otra creación puramente artística  ¿Nos importa sólo el producto o también la persona y experiencia que hay detrás?

De la contestación a esas preguntas no estoy seguro. Creo que, probablemente, a muchas personas les dará igual quién sea el autor o autora de la obra, y si es una persona o la inteligencia artificial. Pero también quiero suponer, y supongo realmente, que habrá personas que esperan que haya una persona al otro lado, un escritor para una novela, un poeta para una poesía, un compositor para una melodía.

Conclusiones

La inteligencia artificial es capaz de generar contenidos de una altísima calidad formal y una buena calidad en cuanto a composición. Y pudiera, en esa labor de creación, llegar a sustituir a los humanos.

Sin embargo, en ciertas ocasiones, los humanos bien preparados, creo que pueden generar mejores resultados. 

Y, sobre todo, lo más importante y más allá del resultado, el propio proceso interior asociado a la creación, es tan agradable, tan satisfactorio y tan enriquecedor que aunque sólo sea por experimentarlo, vale la pena no delegar en la inteligencia artificial según qué cosas.

¿Qué inteligencia artificial queremos enseñar?

Ante el auge imparable de la inteligencia artificial, ante la riqueza de opciones de adopción y casos de uso disponibles, se produce una enorme demanda de formación en inteligencia artificial. una demanda de la que, por supuesto, no puedo dejar de alegrarme.

Es una reacción lógica de empresas e incluso individuos: si estamos ante una tecnología tan transformadora y tan disponible, debemos, como personas y como empresas, ponernos manos a la obra cuanto antes para conocerle y utilizarla

Existe, incluso, una demanda por parte de regulaciones como la AI Act que habla, aunque de forma algo borrosa, de alfabetización en IA.

Sin embargo, creo que con frecuencia, precisamente porque es una tecnología que todavía se está conociendo, no existe claridad en la demanda de formación, ni por parte de individuos ni de organizaciones, puede que muchas veces ni siquiera por parte de las propias entidades dedicadas a formación: escuelas de negocio, academias, universidades, etc.  

Y lo cierto es que es muy diferente no sólo el currículum a desarrollar, sino incluso el estilo y profundidad de una docencia en inteligencia artificial según el colectivo a que nos dirijamos, su punto de partida y sus expectativas.

Aunque muchas son las posibilidades, veo tres grandes currícula muy comunes, a saber:

• Inteligencia artificial para usuarios
• Inteligencia artificial para directivos
• Inteligencia artificial para desarrolladores 

Pero en realidad, las opciones son muchas y, aunque quizá, se trate de caso algo más particulares, voy a comentar otros dos:

• Inteligencia artificial para científicos de datos
• Inteligencia artificial para juristas

No voy a entrar en currícula detallados, pero sí brevemente voy a comentar qué se espera, o debería esperar, de una formación en cada una de estas visiones.

Inteligencia artificial para usuarios

Probablemente sea lo más demandado ahora mismo. Ante el auge de la inteligencia artificial generativa, ante lo sencillo que es utilizarla y ante las inmensas posibilidades que ofrece, una gran demanda cae en este campo: ¿Cómo utilizar la IA generativa en mi día a día?

Fundamentalmente se trata de formación muy práctica, con escasa teoría, en ingeniería de instrucciones ('prompt engineering') adornada con presentar diversas herramientas como, por supuesto, los chatbots generativos (ChatGPT, Gemini, Claude, etc) pero también otras herramientas algo más especializadas para crear presentaciones, videos, música, etc. Y todo ello aderezado con la identificación de muchos casos de uso, unos casos de uso normalmente centrados en el trabajo individual. 

Es una formación en cierto sentido superficial, pero muy útil en el día a día, muy demandada y muy bien recibida en general porque es, a la vez, útil y divertida.

Inteligencia artificial para directivos

Un currículm algo más heterogéneo y más difícil de centrar es la formación en inteligencia artificial para directivos. De nuevo, y como en el caso del colectivo anterior, los directivos, creo que de forma algo equivocada, huyen de la teoría, por lo que, aunque creo que se debe aportar algún fundamento, los contenidos suelen estar orientados a dónde y cómo aplicar la inteligencia artificial en la empresas.

Un peligro actualmente es centrarse sólo en las soluciones generativas cuando, en el ámbito de la empresa, siguen teniendo mucho peso e interés los modelos de machine learning más tradicionales usados en analítica inteligente y modelos predictivos y prescriptivos.

De nuevo, tienen mucho interés los casos de uso pero en este caso, se deben ver con una perspectiva algo más amplia e incluir, no sólo el empleo individual de herramientas generativas sino la aplicación corporativa de la inteligencia artifivial en materia de analítica y automatización.

Aunque no siempre los directivos (salvo que pertenezcan a un área de IT) están interesado en ello, creo que es bueno que conozcan, además, algo de los servicios ofrecidos en la nube, especialmente por hiper-escaladores y, en general el mercado de soluciones existentes.

A eso, añadir elementos importantes de gestión del dato, de gobernanza, de ética, de legislación y 'compliance'.

Inteligencia artificial para desarrolladores

Un perfil completamente diferente es el de los desarrolladores: personas técnicas que van a construir, 'con sus manos', soluciones de inteligencia artificial.

En este caso creo que precisan de algo más de teoría en cuanto a algoritmia y arquitectura. Por supuesto, es inexcusable el conocimiento de python (aunque puede ser interesante alguno otro lenguaje como R) y de las librerías que se utilizan en el ámbito del machine learning tradicional y para el uso de modelos generativos. 

Deberían conocer también las plataformas en la nube y alguna comunidad, muy especialmente Hugging Face.

Probablemente también sea conveniente formación en gobierno del datos y en las pruebas y evaluación de modelos.

Y, quizá, se debería comenzar a comentar elementos de 'vibe coding' o desarrollo software asistidopor inteligencia artificial.

*****

Creo que, aunque de una forma simplificada, estos son los tres grandes perfiles, pero, por supuesto, la formación se puede y debe adaptar a diferentes colectivos, diferentes expectativas y diferentes puntos de partida. Y, un poco en esa línea, voy a comentar otros dos perfiles posibles.

*****

Inteligencia artificial para científicos de datos

Se trata de un perfil parecido al de desarrollador, pero, en aquellas empresas que distinguen entre los ingenieros de datos (más próximos a la pelea con los datos y al desarrollo) y los científicos de datos, más próximos a los modelos propiamente dichos y al negocio, la formación de este colectivo, puede diferir ligeramente.

Por ejemplo, puede poner más énfasis el conocimiento de los diferentes modelos y algoritmos de machine learning y cuándo aplicarlos así como todo lo relativo a la evaluación de los modelos. Deben ponerse énfasis también en aquella parte de las plataformas orientadas a la selección de modelos con especial interés en que conozcan los posibilidades de Auto ML.

Quizá, en este colectivo, pueda ser interesante también poner algo más de foco en los aspectos de responsabilidad y ética, y alguna pincelada de 'compliance'.

Adicionalmente, y aunque adaptado a cada caso, dado que los científicos de datos se orientan a las necesidades del negocio, puede ser bueno una formación específica en vocabulario, aspectos sectoriales y particularidades del sector o área funcional a que se dirigen sus modelos. Por ejemplo, podría ser relevante la formación en marketing digital.

Inteligencia artificial para juristas

Un colectivo muy interesado en la inteligencia artificial es el de los juristas. En este caso, podrían recibir una formación similar a la de directivos cuando lo que buscan es la aplicación en su bufette o empresa, pero cuando los distingo como colectivo es pensando en una formación orientada a aplicar las regulaciones sobre IA o a orientar a sus clientes en los mecanismos de protección y 'compliance'.

En este aspecto, por supuesto, deberían recibir formación, si no la tienen ya, en las regulaciones existentes, notoriamente en Europa en RGPD y AI Act.

Pero sería muy conveniente una formación algo más teórica sobre fundamentos de inteligencia artificial, sobre cómo funcionan y manejan los datos los algoritmos tanto de machine learning tradicional como lo s generativos.

Igualmente, deberían recibir formación en gobernanza de datos y de sistemas de inteligencia artificial y en normativa como el estándar ISO 42001.

Muchas otras opciones

No se acaban aquí, las opciones, pudieran existir formaciones mixtas o dedicadas a aspectos particulares como la ciberseguridad, pero creo que lo dibujado más arriba traza un poco las opciones existentes y, sobre todo, destaca, que es lo que en el fondo pretendía con el post, que no es realista ni practico hablar de formación o alfabetización en inteligencia artificial sin más, sino que debemos saber de dónde partimos, a que colectivo nos dirigimos y que necesitamos realmente que sepan de la inteligencia artificial.

Conclusiones

Es muy necesario hoy en día formarnos, individualmente y como organizaciones en inteligencia artificial, pero a la hora de realizar una demanda de formación, conviene 'centrar el tiro' y saber qué pretendemos realmente.

La cadena de producción en computación: el viaje de la especialización de los procesadores

Termino con este post una serie un poco espontánea (no tenía decidido realmente hacer una serie, sino que ha salido así) que he dedicado al mundo del hardware y los procesadores, tema que, la verdad sea dicho, apenas había abordado antes en este blog.

Y mi interés sobre el particular ha surgido suscitado por las reflexiones sobre algunos episodios en que he participado del podcast 'Código abierto' y en que hemos hablado del tema, y de forma más inmediata por la lectura del libro 'Mastering NVIDIA CUDA and Tensor Cores' que explica la arquitectura de procesadores de NVIDIA y cómo se programa con ellos.

En este post, simplemente quiero resaltar una paradoja y una metáfora respecto a los procesadores.

La paradoja es que, a medida que queremos conseguir más potencia, acudimos a procesadores más sencillos en cierto sentido. La metáfora es la de una cadena de producción en computación.

Y todo ello, aderezado con una especie de arqueología tecnológica o 'memoria histórica' de la computación.

Recordando los microprocesadores para PC

Y empiezo un poco con esa memoria histórica, casi con esa nostalgia.

Pues si, no puedo dejar de recordar los tardíos años ochenta o principios de los noventa cuando asistimos, y en mi caso con mucha implicación, a la aparición y expansión súbita de los ordenadores personales, los famosos PC.

Recuerdo que mi primer ordenador personal, un Inves 640-X, incorporaba un microprocesador Intel 8088, aunque en aquel momento ya la mayoría de PCs venían dotados de un Intel 8086. Y si, para quien no lo recuerde y a lo mejor hoy en día le resulte extraño, Intel dominaba de forma aplastante el mundo de los microprocesadores para ordenador personal y marcaba completamente la pauta.

Todas las revistas de informática, abundantes en aquella época, y todos los aficionados, asistíamos con expectación a cada lanzamiento de un nuevo microprocesador de Intel. El siguiente de importancia fue el 80286. Luego vendría el 80386, hasta que Intel decidió cambiar un poco la marca y, al que debía llamarse, siguiendo la misma lógica, como 80596, decidió denominarlo 'Pentium'.

Más allá de la curiosidad y la nostalgia, lo relevante de cara a este post es hacer ver que cada nuevo microprocesador, que era más potente que el anterior, aparte de mejoras como acelerar la señal de reloj, se hacía más y más complejo, soportaba más y más instrucciones, se hacía físicamente más y más grande y, energéticamente, disipaba más y más calor.

Un poco como anticipo de lo que vendría después, y que en seguida comento, para algunos ordenadores un poquito más especializados y más potentes, se les dotaba del llamado coprocesador matemático, una especie de microprocesador pero ya no de propósito general sino especializado en operaciones matemáticas. 

Arquitecturas CISC y RISC

No recuerdo bien los años, pero creo que, aunque tiene antecedentes más antiguos, hacia los años 90 se comenzó a hablar con más fuerza del concepto de RISC. ¿Qué era eso?

Bueno, los microprocesadores como los de Intel, evolucionaban soportando más y más instrucciones y constituían, pues, lo que se denominaba CISC ('Complex Instruction Set Computers').

Sin embargo, RISC ('Reduced Instruction Set Computers'), y a pesar de buscar precisamente una mayor eficiencia en la computación, apostaba en la dirección contraria: procesadores con un juego de instrucciones pequeño (reducido) y que, aparte de otras optimizaciones y mejoras ya buscaba el paralelismo en la computación. Y, realmente, hablar de RISC se convirtió en una especie de sinónimo de altas prestaciones.

Si la memoria no me falla, más que a los ordenadores personales, ésta filosofía se aplicaba a servidores o a las entonces llamadas 'workstations' (típicamente de Hewlett-Packard o Sun Microsystems) que, aunque tenían características parecidas a los ordenadores personales, eran más potentes, utilizaban sistemas operativos UNIX y se las consideraba más del ámbito profesional que personal. 

Las GPU

Abandono un poco ya la memoria nostálgica para situarme en el presente. En este presente, y aunque ya están entre nosotros hace algunos años, son populares las famosas GPU ('Graphical Processing Units').

En cierto modo, las GPU son herederas de los coprocesadores matemáticos porque, en el fondo, eso es o que son. Salvo en casos muy particulares, las GPU no son una alternativa a las CPU ('Central Processsing Unit'), es decir, los microprocesadores tradicionales, sino unas compañeras de estos. La computación general suele correr a cargo de CPUs, pero ciertos tipos de cálculos, se delegan en GPUs.

¿Qué cálculos?

Pues las GPU están especializadas en operaciones algebraicas del mundo de los vectores, las matrices y los tensores. Se trata de un tipo de cálculos que son fundamentales en todo lo que tiene que ver con gráficos y movimiento y por eso las GPUs surgieron para apoyar el mundo de los videojuegos y aplicaciones similares, de ahí el nombre de 'gráfico' que puede sorprender hoy en día.

Y es que, no sólo el mundo de la imagen en movimiento se apoya en cálculos algebraicos, sino que también el 'machine learning' y muy particularmente el 'deep learning' se implementa, fundamentalmente con ese álgebra lineal en espacios vectoriales... y eso explica la popularidad y demanda actual de GPUs... y el éxito empresarial de NVIDIA.

Las GPUs apuestan muy decididamente por el paralelismo, condicionando, como vimos en un post anterior, la forma de programar con ellas en el bajo nivel. Pero hago notar que, en el fondo, en busca de la eficiencia computacional, sufren una enorme especialización: ya no son procesadores de propósito general como las CPU, sino procesadores muy especializados en computación algebraica paralela. 

La transacción: especialización a cambio de potencia.

Las TPU

Y un caso más particular son las TPU ('Tensor Processing Units') o, al menos, los 'tensor cores' de NVIDIA, que se centran en una única operación: la multiplicación de matrices con acumulación consiguiendo una espectacular eficiencia en esa operación.

Estamos ante una 'super-especialización' pero que tiene sentido porque se trata de una operación usada masivamente en el deep learning actual, que ya sabemos que es enormemente demandante, especialmente en el caso de los grandes modelos generativos.

Estamos extremando en este caso la transacción de especialización a cambio de potencia, pero sigue teniendo una total lógica técnica e incluso económica.

La especialización y las cadenas de producción en computación

Y esto me lleva a la metáfora. No he podido dejar de pensar en los principios de la organización científica de Taylor, origen de las cadenas de producción industriales.

En esas cadenas de producción, los trabajadores (y también las máquinas) dejan de ser personas o máquinas de propósito general, como ocurriría en el caso de la artesanía o del trabajo intelectual, para especializarse en tareas muy concretas, tareas que realizan una y otra vez de forma muy eficaz y, sobre todo, muy eficiente. 

Procesadores como las GPUs o las TPUs no dejan de ser, en la computación, algo así como los trabajadores especializados de una cadena de producción, en este caso una cadena de producción de la computación, mientas que las CPU se quedan un poco como los artesanos o intelectuales de esa computación.

Y, ante la demanda masiva de computación, procedente sobre todo de la inteligencia artificial, hemos debido poner en marcha una capacidad productiva en computación, altamente especializada y, por ello, altamente eficiente, pero apoyada en procesadores especializados.

Conclusiones

El conseguir unas mayores dosis de eficiencia en computación ha llevado, a lo largo de los años, a buscar esquemas de procesadores especializados en operaciones concretas y con altas dosis de paralelismo.

En ese sentido, y aunque sea metafóricamente, lo que buscamos son 'trabajadores especializados', y muy eficientes integrados en una suerte de cadena de producción de computación.

Artículos de este blog relacionados

• Una aparente paradoja: el retorno de la programación de bajo nivel
• El retorno del hardware: razones y perspectivas

Una aparente paradoja: el retorno de la programación de bajo nivel

En los dos últimos post he hablado de dos fenómenos, en apariencia independientes y casi contradictorios y que, precisamente, van a colisionar en este artículo. 

Hablo, por un lado, de la evolución del desarrollo software que explicaba en 'La evolución del desarrollo software: productividad frente a deskilling' y que nos muestra una clara evolución a una programación cada vez más alejada de los detalles técnicos y más centrada en la productividad y cercanía a las necesidades funcionales. Una programación, en fin, de alto nivel.

Por otro, en el último post, 'El retorno del hardware: razones y perspectivas', destacaba cómo el hardware, al que hacía años que apenas dábamos importancia, ha vuelto a cobrar valor técnico, económico y estratégico, debido en buena medida a las demandas técnicas y de volumen que impone la inteligencia artificial generativa.

En este post examino un fenómeno en cierto modo sorprendente y contradictorio: el retorno, no ya del hardware, sino de la programación de bajo nivel.

Programación de bajo nivel

Como paso previo, y por si algún lector no esta suficientemente advertido, aclarar a qué nos referimos con lo de la programación de bajo nivel.

La programación de bajo nivel es la creación de un software que trabaja en temas de detalle y, sobre todo, muy cerca del procesador, ya sea un microprocesador de tipo CPU ('Central Processing Unit') tradicional, o los modernos GPU ('Graphical Processing Unit') o TPU ('Tensor Processing Unit'). La programación de bajo nivel suele implicar conocer bien el hardware, tanto los procesadores como la estructura de registros y de la memoria o cómo relacionarse directamente con dispositivos y periféricos.

Con la programación de bajo nivel normalmente no podemos resolver grandes problemas funcionales, pero, a cambio, podemos conseguir nuevas capacidades y, sobre todo, si se hace bien, unas altísimas prestaciones y una gran optimización computacional. Y eso es así porque al trabajar muy cerca del hardware y conociendo cómo funciona, explotamos al máximo sus capacidades y, además, hacemos ´únicamente lo que se necesita'.

El software de alto nivel, por su lado, en su búsqueda de generalidad y facilidad de uso, añade ingentes cantidades de lógica adicional no estrictamente necesaria en muchos casos y, además, al alejarse del hardware no optimiza su uso. Prima la productividad y facilidad de uso frente a la optimización computacional.

¿Por que realizar programación de alto nivel?

En realidad lo acabamos de mencionar y lo vimos también en un post anterior: favorecemos la programación de alto nivel porque es muchísimo más productiva en términos de cantidad de software producido, porque además es más sencilla de llevar a cabo (lo que redunda en productividad y, además, elimina barreras de entrada de profesionales) y, finalmente, porque permite concentrarse más en los problemas de negocio o en lo que realmente queremos proporcionar.

Por eso, una vez que el hardware alcanzó una potencia tal que ya no nos exigía su optimización para tener buenos resultados de prestaciones, se ha ido favoreciendo la programación de alto nivel

¿Y por qué realizar programación de bajo nivel?

Y, entonces ¿Por qué podríamos interesados, a estas alturas, en hacer programación de bajo nivel?

Bueno, en algunos casos no hay más remedio. Por ejemplo, para relacionarse con un nuevo dispositivo o periférico, hay que comenzar trabajando en el bajo nivel, aunque luego, de cara a otros programadores se preparen ya APIs o conectores simplificados.

Un poco en esa misma línea, si estás programando un sistema operativo no tienes más remedio que enfrentarte al bajo nivel porque una de las funciones principales de un sistema operativo es precisamente relacionarse con el hardware y ofrecer, hacia el exterior, un modo abstracto, una máquina virtual que independice a aplicaciones y programadores de ese hardware. Los programadores de esas aplicaciones pueden trabajar en el alto nivel, pero los del sistema operativo están obligados a relacionarse con el bajo nivel.

Pero hay algo que me importa mucho más ahora mismo, en relación con lo que quiero exponer en este artículo: utilizas la programación de bajo nivel porque cuando quieres optimizar el funcionamiento, cuando quieres maximizar las prestaciones, cuando quieres 'exprimir al máximo' la capacidad del hardware, tienes que acercarte al hardware, tienes que conocerlo, tienes que, en fin, realizar programación de bajo nivel.

Nuevas arquitecturas de procesadores

Durante bastantes años, los procesadores, aunque evidentemente evolucionaban, y no poco, eran de tipo CPU.

Con el auge de aplicaciones de gran riqueza gráfica como los videojuegos, nacieron y cobraron importancia las GPU ('Graphical Processing Unit'). Pero la auténtica explosión ha venido de la mano del machine learning al 'descubrir' que las operaciones algebraicas que se utilizan en el mundo gráfico, son similares a las que se utilizan en machine learning, fundamentalmente en redes neuronales. En ambos mundos abundan las operaciones con vectores, matrices y tensores. Y las GPU lo que hacen es optimizar esas operaciones.

En un paso más allá en especialización, existen las TPU ('Tensor Processing Unit') o los 'tensor cores' de NVIDIA que, pese a que suenen a algo muy potente, en realidad se especializan en una única operación: la multiplicación de dos matrices y acumulación del resultado en una de ellas. En cierto modo, son elementos muy sencillos, pero altamente especializados y optimizados.

La nueva programación de bajo nivel

Aunque la programación de bajo nivel, pese a su escasa visibilidad, nunca se había ido, ahora cobra una gran importancia para explotar estos nuevos procesadores.

¿Por qué?

Pues porque estos procesadores son muy especializados pero, para que produzcan los resultados esperados, hay que programarlos conociendo cómo funcionan. Así, para explotar bien las GPU hay que convertir la resolución de nuestros problemas en operaciones de algebra lineal y, además ser capaces de definir la resolución de un problema en términos de unas funciones, los denominados 'kernel', en que la misma lógica pueda trabajar en paralelo sobre diferentes datos (por ejemplo, sobre diferentes partes de una misma matriz).

Más específico aún es el caso de los 'tensor cores' en que, para aprovecharlos, hay que ser capaces de identificar o forzar operaciones que consistan en una multiplicación de matrices seguidas por una acumulación.

Y esto no se puede hacer con sólo conocer un problema de negocio o la sintaxis de un lenguaje de programación. Para ello hay que comprender el hardware con que se trabaja y la mejor forma de obtener todo su rendimiento.

Es decir, hay que trabajar en el bajo nivel.

Deshaciendo la aparente contradicción

Y llega el momento de deshacer la aparente contradicción.

¿No habíamos dicho que la evolución del software nos conducía a una visión cada vez más alejada del hardware, una visión que en sus vertientes 'No Code' o 'Vibe coding' ni siquiera trabajaba con código fuente e incluso que en las soluciones de más alto nivel el desarrollador expresaba sus necesidades en lenguaje natural?

Si, lo habíamos dicho y así es.

Lo que ocurre que el trabajo en el bajo nivel lo realizan, comparativamente, muy pocas personas organizadas en equipos especializados. Esas pocas personas programan el software más exigente y, además, preparan componentes optimizados para su uso en el alto nivel por desarrolladores menos especializados.

Así, las típicas librerías python usadas en machine learning y deep learning, están fuertemente optimizadas a nivel interno, aunque el común de los programadores las utilicen directamente sin preocuparse de los detalles. Y no digamos ya nada cuando ni siquiera se trabaja con las librerías sino con componentes gráficos que las abstraen (caso del 'low-code / 'no-code') o cuando incluso es la inteligencia artificial la que general el código que invoca a las librerías, sin que el desarrollador sea necesariamente consciente de ello.

En el fondo, esa ha sido siempre la relación entre al bajo y el alto nivel: unos pocos equipos especializados trabajan en el bajo nivel, cerca del hardware, y preparan componentes optimizados reutilizables en el alto nivel.

Lo único que ocurre es que ahora, con la enorme demanda computacional existente y procedente de la inteligencia artificial, muy especialmente en su vertiente generativa., cobra nueva importancia el  contar con algunos de esos equipos especializados para sacar jugo a un hardware especializado y que, pese a las enormes inversiones, se nos está quedando corto en volumen. 

Conclusiones

La gran demanda computacional exigida por la inteligencia artificial generativa ha llevado al desarrollo de procesadores especializados a nivel hardware, pero el uso adecuado y óptimo de ese hardware implica el trabajo en el bajo nivel aunque luego los resultados puedan ser reutilizados vía librerías y APIs, en la programación de alto nivel.

El retorno del hardware: razones y perspectivas

¿No resulta llamativo la frecuencia con que ahora oímos hablar de asuntos que tienen que ver con el hardware? 

No paramos de escuchar hablar de GPUs, de NVIDIA, la empresa estrella del momento, del papel estratégico de la producción de semiconductores, de la lucha por las tierras raras y tantas cosas relacionadas con los aspectos físicos de la computación, con la microelectrónica y el hardware.

¿Qué está pasando?

El hardware como 'commodity'

Hasta no hace mucho, el hardware ha sido 'el hermano pobre' de la tecnología digital, algo de lo que se hablaba relativamente poco fuera de ámbitos especializados. 

Pasada ya hace mucho la fiebre de los ordenadores personales en que sí que nos volvíamos locos los aficionados a la informática conociendo las nuevas características del último microprocesador Intel, y ahora que la gran proliferación de servicios en la nube nos hace muchas veces casi invisible el hardware corporativo, al menos los servidores, durante muchos años apenas nos hemos fijado en el hardware.

A nivel de programación, y como revisamos en el reciente post 'La evolución del desarrollo software: productividad frente a deskilling' también nos hemos ido alejando de la realidad física que soportaba la computación, de los procesadores, las CPUs, las GPUs, etc.

Sabíamos que era necesario, claro, y que evolucionaba y mejoraba, pero lo valorábamos poco, le prestábamos poca atención y, seguramente, el número de profesionales, ya no digamos aficionados, del software, supera con mucho, con muchísimo, al de los dedicados al hardware.

Además nos acostumbramos a que el hardware fuese relativamente barato, en el caso de ordenadores personales o portátiles, y casi invisible en el caso de los servidores, por mor de los servicios en la nube.

En cierto modo, habíamos convertido al hardware en una 'commodity', necesario, pero sin valor diferencial.

Y de repente ha vuelto

Y de repente, en los últimos meses, quizá algún año, vuelve a ser importante. Vuelve a estar en el discurso técnico y en el geoestratégico. ¿Por qué?

Voy a aventurar cuatro razones:

• La escasez relativa de la capacidad de computación
• La escasez relativa de materiales concretos
• La especialización de la demanda
• Un conocimiento escaso y concentrado 

Veamos

La escasez relativa de capacidad de computación

La primera es que, lo que en su momento pudimos considerar abundante, la capacidad de computación, se nos ha vuelto escasa. 

Hablo de escasez relativa porque no es que no exista capacidad de computación. Existe mucha capacidad de computación distribuida en unidades relativamente modestas como ordenadores de sobremesa, portátiles, tablets y smartphones. Existe muchísima capacidad de computación concentrada en centros de Proceso de Datos corporativos y existe, sobre todo, una ingente capacidad de computación en los data centers de los grandes proveedores de la nube (Amazon, Microsoft, Google, IBM, etc)

Lo que pasa es que la demanda crece aun más. En parte por la digitalización creciente pero muy singularmente por la explosión de la inteligencia artificial basada en modelos muy demandantes de computación tanto en entrenamiento como en inferencia, y por la previsión de que esa demanda no vaya a hacer otra cosa que crecer y trasladarse a otros ámbitos como robots, vehículos, etc, la oferta de hardware parece que se nos está quedando corta, o amenaza con quedarse corta.

Y ya se sabe que, desde un punto de vista económico y estratégico, un recurso gana importancia cuando es escaso.

La escasez de materiales concretos

Ante la enorme demanda de microelectrónica y hardware cuando algunos de sus componentes es en sí mismos escasos, como las famosas tierras raras, se perciben como aún más escasos y, por tanto, con mucho mayor valor económico y geoestratégico. 

La especialización de la demanda de hardware

Quizá en menor medida, pero también influye creo, que ya no nos vale con un hardware más generalista, digamos una CPUs tradicionales agregadas mediante mecanismos de virtualización. Ahora los cálculos en el ámbito de la inteligencia artificial. de los videojuegos, de la realidad virtual o de la simulación,  nos reclaman procesadores especializados, procesadores especializados en los cálculos algebraicos y su realización de operaciones en paralelo (caso de los GPU, 'Graphical Processing Units') y especializados en alguna operación muy específica realizada con muchísima frecuencia (caso, por ejemplo, de las TPUs, ('Tensor Processing Units')).

La necesidad de esa especialización, de esa búsqueda de procesadores más potentes y especializados, realza y revitaliza la industria del hardware pero, además, le añade más valor diferencial. Y si no, que se lo digan a NVIDIA. 

La concentración y escasez de conocimientos

Además, y a nivel casi más geoestratégico que económico, la industria de los semiconductores está muy concentrada.

Está muy concentrada geográficamente, siendo tremendamente relevante el papel de Taiwan y está concentrada en empresas, siendo tremendamente especial el caso de la empresa holandesa ASML poseedora, hasta ahora en exclusiva, de la tecnología EUVL ('Extreme Ultra Violet Lithography').

Aunque esa concentración pudiera tener sentido económico como una forma de eficiencia considerando una cadena de suministro global, lo cierto es que es también un unto de fragilidad y, en el convulso mapa geoestratégico actual, un elemento de lucha competitiva, no ya de empresas, sino de grandes potencias.

A eso añadiría, aunque confieso que más como intuición que con base en datos, que creo que existen muy pocos profesionales en el mundo con conocimientos avanzados de microelectrónica y diseño hardware.

Perspectivas: los algoritmos frugales y la computación cuántica

¿Existe alguna vía para que se suavice esa demanda de hardware, incluso esa lucha competitiva por el mismo?

Sinceramente, a corto plazo no veo que la atención en el hardware y, sobre todo, la lucha competitiva y geoestratégica él mismo vaya a disminuir. No veo que la demanda vaya a bajar, sino todo lo contrario, y no veo mecanismos para aumentar de forma sencilla y eficiente la oferta.

Fantaseando un poco, no obstante, apuntaría a dos posibilidades, aunque la segunda no es de corto plazo.

La primera sería que la industria virase, pensando en este caso en la inteligencia artificial, del uso de los grandes modelos de lenguaje, a los denominados pequeños modelos de lenguaje y/o que se encontrase una algoritmia radicalmente diferente a la utilizada últimamente, muy apoyada en la arquitectura transformer, y que esa nueva algoritmia fuese muchísimo más frugal en necesidades de computación. No es que crea que esa es una posibilidad del todo realista en sí misma e, incluso, caso de conseguirse esa algoritmia, a lo mejor nos encontrábamos con más despliegues, más caso de uso con lo que, aunque cada modelo consumiese mucho menos, la demanda global podría seguir creciendo.

Otra posibilidad, pero no es de corto plazo, es la llegada real, con viabilidad comercial y a gran escala, de la computación cuántica. Dada su enormemente superior capacidad de computación para cierto tipo de aplicaciones (incluyendo el machine learning), eso podría llevar a una drástica disminución de demanda del hardware basado en semiconductores. Pero este escenario, caso de ser realista, no es inminente y, como mínimo, parece que habrá que esperar cinco años, si no diez, o quién sabe cuánto.

Conclusiones

El hardware parece que se ha vuelto a poner de moda. Y hay razones de aumento de demanda, de especialización y de escasez de recursos que justifican el aumento de su valor discursivo, económico y geoestratégico.

Y parece que, al menos durante unos pocos años, esa importancia se va a mantener.

La evolución del desarrollo software: productividad frente a deskilling

El desarrollo de software ha sido siempre una actividad que me ha encantado y con la que, en su momento, he disfrutado muchísimo. Y digo en su momento porque tanto en los últimos años de mis estudios universitarios, como en los primeros de mi carrera profesional, dediqué muchísimas horas a esta actividad, como aficionado como ingeniero de software.

Y he podido asistir, dada mi edad, a casi toda su historia (me perdí un poco del principio) y a cómo ha ido evolucionando. Y lo cierto es que la transformación es enorme. Ha cambiado en filosofía, lenguajes, herramientas y requisitos profesionales del desarrollador.

En este post quisiera revisar esa evolución, y lo que los cambios suponen, de bueno y de malo

Un análisis en cinco fases

Y, para ello, propongo identificar las fases principales de la evolución.

Que yo sepa, no existe ninguna forma de marco concreta para clasificar esta evolución de la forma de construir software, (aunque sí se habla a veces de generaciones, sobre todo tercera y cuarta, pero con base en mi percepción personal, hablaría de cinco fases, a saber:

• Fase 1: código máquina
• Fase 2: ensamblador
• Fase 3: lenguajes de alto nivel
• Fase 4: 'low-code' / 'no-code'
• Fase 5: 'vibe coding' o 'prompt based coding'

Veamos brevemente lo que significa y aporta cada una de ellas.

Fase 1: código máquina

En esta fase, que sinceramente creo que pocos desarrolladores han vivido salvo, como mucho, durante sus estudios, se trabaja directamente con el hardware, con el microprocesador y se expresa el programa en los famosos unos y ceros que caso nadie ha visto.

Es una programación muy, muy cercana al hardware, e implica conocer en detalle el microprocesador, sus registros, las instrucciones que maneja y cómo se codifican, las direcciones de la memoria etc. Los programas son, a poco que el programador sepa lo que hace, extraordinariamente eficientes en recursos computacionales y rápidos en ejecución, pero eso sí, son muy dificultosos de desarrollar y depurar y, por tanto, en general de un alcance muy modesto.  

Fase 2: ensamblador

En realidad, es muy similar a la anterior, pero ahora hay un cierto lenguaje, el ensamblador, que al menos expresa las instrucciones mediante nemónicos textuales (típicamente de tres letras) con lo que, aunque con criterios de hoy en día siguen siendo enormemente crípticos, para su momento fueron una gran aportación en cuanto a claridad.

Fase 3: lenguajes de alto nivel

Son, quizá, el primer tipo de lenguajes ampliamente conocidos. En ellos el lenguaje de programación se basa en formas textuales más o menos destiladas del inglés, pero circunscritos a una serie de instrucciones muy concretas y con una estructura en general muy bien definida. Aunque hable de una forma de inglés no tiene nada que ver con el lenguaje natural: se trata de lenguajes muy acotados, muy estructurados y muy ligados a gramáticas estrictas.

Introducen ya los tipos de datos, las variables, las estructuras de control del tipo de bucles y condiciones o la capacidad de crear funciones. Con el tiempo, con el auge de la orientación a objetos, se introduce también esta idea de los objetos (que unen datos y comportamiento) y a capacidad de crearlos y utilizarlos.

Son lenguajes ya independientes del microprocesador e incluso del sistema operativo en que se ejecutan y un programa auxiliar, el compilador o el intérprete según el caso, se encarga de traducir esas instrucciones textuales de alto nivel al código máquina.

Se fueron acompañando de entornos de desarrollo del tipo IDE ('Integrated Development Environment') que incluyen capacidades de control y organización del código, capacidades de depuración, ayudas, etc. 

En esta categoría caben casi todos los lenguajes de programación más conocidos, desde algunos más antiguos como COBOL o Pascal, y pasando por Basic, C, C++, Java o python, por decir algunos.

El salto de productividad es inmenso respecto a la programación en ensamblador, una productividad que se refuerza por la posibilidad de creación y reutilización de librerías de funciones u objetos que proporcionan, ya empaquetadas y listas para ser usadas, capacidades más o menos sofisticadas. Creo que es con base estos lenguajes que se produce el verdadero 'boom' del software.

Aunque en varios momentos me he referido a ellos en pasado, siguen estando muy presentes hoy en día, muy especialmente python.

Interludio: los lenguajes de cuarta generación 4GL

No los he llegado a proponer como una fase diferenciada, pero por encima de los lenguajes de alto nivel (que a estos efectos se consideran de tercera generación), proporcionan mayores niveles de abstracción y un enfoque algo más declarativo, normalmente orientados a software de características bastante comunes y estructuradas como la gestión de bases de datos.

Hay quien los considera como un antecedente de lo que veremos a continuación: el 'low-code'.

Fase 4: low-code / no-code

La fase 4 nos conduce a la filosofía y soluciones 'low-code' o, en su extremo, 'no-code'. 

La idea es que el desarrollador ya no trabaje con código fuente (que se expresa en un lenguaje de tercera generación) o que lo haga en la menor medida posible. ¿Cómo se consigue eso? Pues proporcionando entornos de desarrollo gráficos o semi-gráficos, donde con frecuencia los bloques de ejecución se representan por cuadrados o círculos, que se unen mediante líneas o flechas para representar una lógica completa. Además, el entorno de desarrollo ofrece ya una amplia librería (normalmente ampliable) de bloques constructivos

En general el desarrollo tiende a convertirse en 'dibujar' la lógica de ejecución complementada por la configuración (habitualmente mediante cuadros de diálogo) de los parámetros y variantes de ejecución de cada uno de los bloques constructivos, así como la definición de variables.

En los casos más extremos ('no-code') no es necesario incluir código fuente tradicional y en otros casos ('low-code') sí existen determinados puntos donde se complementa la lógica, digamos gráfica, con pequeños elementos de lenguaje de programación de tercera generación. 

Esta filosofía es cada vez más común para construir todo tipo de soluciones, pero, por citar algunas muy representativas, tendríamos, en el ámbito de la automatización, casi todos los entornos RPA ('Robotic Process Automation') o BPMS ('Business Process Management Systems'), así como soluciones de automatización de workflow (como Make o N8N) e, incluso, algún entorno de construcción de agentes IA como LangFlow. También es común, por ejemplo, en visualizadores de datos como Power BI.

En este salto, no es ya que nos hayamos alejado del hardware y el microprocesador, es que incluso nos hemos alejado de los lenguajes de programación como tales, si entendemos los lenguajes de programación como algo con base textual. Incluso, gran parte de la lógica detallada, viene resuelta por los bloques constructivos disponibles sinq ue el desarrollador la conozca en detalle, sino sólo por su comportamiento externo.

Fase 5: Vive coding o 'prompt based coding'

El último salto, es la creación de software a partir de prompts usando herramientas de inteligencia artificial generativa. En el primer post de este blog que dediqué al 'vibe coding', comentaba la diferenciación entre el uso de inteligencia artificial como una especie de ayuda o copiloto, lo que Addy Osmani denominaba 'Ingeniería de software asistida por IA' frente al uso de la IA para construir toda la aplicación, siendo esto último a lo que asignaba el término 'Vibe coding'.

En realidad, si usamos la IA como copiloto, estamos realmente reforzando una de las dos fases anteriores (lenguaje de alto nivel o 'low-code'/'no-code') pero no sería una fase realmente diferenciada. 

Lo que considero como una fase diferenciada es cuando usamos la herramienta para la generación completa de aplicaciones o módulos a partir de prompts en lenguaje natural.  Como en este caso la forma de actuar que tiene el desarrollador es únicamente mediante 'prompts', me he querido inventar el término 'prompt based coding'.

En este caso el alejamiento ya es total: el desarrollador no es que no conozca el hardware o el sistema operativo, y no es ya que no utilice un lenguaje de programación, es que, incluso, salvo que se preocupe por ello, hasta desconoce la lógica interna del software que ha generado o cómo está estructurado. El desarrollador, en teoría, se centra sólo en la necesidad, que expresa mediante lenguaje natural, no en los detalles internos del software.

Se trata de una fase probablemente poco madura en estos momentos y que hay que ver hasta dónde es capaz de llegar, pero, en teoría, es una fase de altísima productividad y, además, casi al alcance de cualquiera, una fase donde el propio término 'desarrollador', al menos tal y como lo hemos entendido hasta ahora, puede que pierda sentido.

Consecuencias

A medida que se avanza en las diferentes fases, creo que se producen los siguientes efectos:

• Se aumenta (y mucho) la productividad del desarrollo software
• Se baja la barrera de entrada (los conocimientos y la especialización necesarios) para crear software
• El desarrollador pierde conocimiento del detalle de lo que está haciendo (el hardware, el sistema operativo, las lógicas internas, etc)
• Debido a esa pérdida de conocimiento (y gestión) del detalle, en general el software generado es menos eficiente en el uso de recursos computacionales: memoria, tiempo de CPU, disco, etc 

En general, la evolución de la industria ha apostado por los dos primeros beneficios (productividad y bajada de la barrera de entrada) frente a los dos últimos inconvenientes (perdida de conocimiento y menor eficiencia en recursos computacionales).

Voy pararme un momento en dos aspectos.

La productividad y las barreras de entrada

En efecto, el gran beneficio de esta evolución es, sobre todo, la altísima mejora de productividad en la construcción de software, no sólo en cuanto a cantidad de código creado sino en cuanto a potencia y capacidades de las soluciones generadas. Por ejemplo, hace  20 o 30 años, hacer la interfaz de usuario (las ventanas, por entendernos) de un sistema, era tremendamente trabajoso... y hoy es casi trivial en algunos casos. 

A esto se une, especialmente en las dos últimas fases, en unos menores requisitos, una menor cualificación, para ser creador de software, llegándose ya hace unos años al concepto acuñado por Microsoft de 'Citizen developer' (un concepto muy ligado al 'low-code') en que ya parte del software empresarial podría ser creado, no por desarrolladores profesionales del departamento de IT, sino por profesionales del ámbito del negocio (ventas, marketing, operaciones, etc)

El deskilling

Sin embargo, ese menor conocimiento requerido supone en parte un peligro para el propio software en el sentido de que el desarrollador puede ser mucho menos capaz de hacer un software eficiente, escalable e incluso seguro, o que le puede costar depurar los errores más extraños. 

De cara al desarrollador, como profesión, el avance en estas fases, muy especialmente la última, pone en riesgo la profesión en sí misma, en riesgo de desaparición o, quizá más probable, de profunda redefinición y, quizá, sólo quizá, menor cualificación y por tanto consideración profesional.

En el fondo, se produce una forma particular de 'deskilling' (término del que he hablado en los dos últimos posts), en que el desarrollador cada vez sabe menos de sistemas, cada vez sabe menos, por supuesto del hardware, pero también sabe menos de las mejores arquitecturas, de los mejores criterios y mejores prácticas de construcción de software. Y eso es un riesgo potencial para la propia calidad del software y para su mantenibilidad y, quizá, un empobrecimiento personal y profesional del desarrollador.

Conclusiones

El desarrollo de software ha sufrido a lo largo de las últimas décadas, una enorme transformación en su forma de realización, una evolución que le ha conducido, a través de cinco fases, a recorrer un camino en el que ha ganado una enorme productividad y sencillez, pero a cambio de una menor eficiencia en recursos computacionales y en una progresiva descualificación técnica de los profesionales que la ejercen. 

La peligrosa combinación del 'automation blindness' y el 'deskilling' y cómo afrontarla

Una de las preocupaciones que surgen con la inteligencia artificial es, más allá de otras problemáticas éticas como la privacidad, los sesgos o la explicabilidad, cómo  va a afectarnos a nosotros, humanos, en nuestro propio desarrollo, en nuestras propias capacidades cognitivas, a medida que nos entreguemos a ella, que la utilicemos intensivamente tanto en el ámbito laboral como doméstico.

Y creo que, en efecto, existe a la vez un interrogante, porque realmente no estanos seguros, y un riesgo, porque creo que realmente podemos perder cosas valiosas por el camino. 

En este post quisiera mostrar cómo dos aspectos que ya he tratado en otros posts, se podrían combinar de una forma perjudicial y potencialmente peligrosa. Hablo de los así llamados 'automation blindness' y el 'deskilling'.

Veamos.

Recordando el 'automation blindness'

De 'automation blidness' hablé en el post anterior a éste titulado 'Automation blindness o el riesgo para human-in-the-loop'. Este fenómeno, en esencia consiste en que los humanos, cuando están apoyados en sus decisiones por sistemas automatizados, poco a poco se 'van confiando' y pasando de realizar una supervisión efectiva y responsable de las decisiones automatizadas, a confiar ciegamente en ellas eliminando, 'de facto', la supervisión e incluso su autonomía.

Se trata de un fenómeno no específico de la inteligencia artificial pero que se acentúa en sistemas inteligentes, tanto por su potencia, como por actuar en situaciones tradicionalmente reservadas al juicio humano.

Recordando la idea de 'deskilling'

Del 'deskilling' hablé brevemente hace un par de meses en el artículo 'Inteligencia artificial, capacidades y las tres olas hacia el desempleo'.  En este caso, de lo que hablamos es que, dado el efecto sustitutivo que la tecnología tiene respecto a  tareas humanas, a medida que vamos delegando en la tecnología esas tareas, perdemos la capacidad para llevarlas a cabo nosotros mismos, es decir, perdemos capacidades y habilidades. 

Se trata de un fenómeno que tampoco es exclusivo, ni mucho menos, de la inteligencia artificial. Lo que ocurre es que, en el pasado, las habilidades que delegábamos y perdíamos eran de naturaleza más bien manual, pero con la digitalización, y sobre todo con el advenimiento de la inteligencia artificial, estamos, cada vez más, delegando capacidades cognitivas y, eventualmente, perdiendo esas capacidades o al menos en riesgo de perderlas.

Una combinación doblemente peligrosa

Si veo ambos fenómenos, creo que cuando se combinan, y me parece muy fácil que se combinen, nos hallamos ante una situación peligrosa en un doble sentido, un sentido más operativo y práctico, y otro más cognitivo y profundo.

Un peligro operativo

En primer lugar, y desde un punto de vista que voy a denominar operativo, es peligrosa porque se pierde la supervisión real de los sistemas automatizados. Ya no es sólo que tendamos a confiarnos ('automation blindness'), es que podríamos incluso perder la capacidad real para entender y controlar un sistema automatizado ('deskilling'). Dado que, por desgracia, los sistemas automatizados pueden fallar, y más si se pretenden apoyar en inteligencia artificial generativa que, como ya analicé en otros posts, no conduce a comportamientos completamente predecibles ni sujetos a reglas, perder la capacidad de supervisión y control puede llevar a puntualmente a comportamientos del sistema incorrectos y eventualmente catastróficos.

Es cierto que los sistemas automatizados, sobre todos los de misión crítica, tienden a ser muy fiables, incluso con frecuencia mucho más que un humano, pero aún así, perder la capacidad última de decisión y control, me parece operativamente arriesgado.

Un riesgo cognitivo y ético

Pero quizá me preocupa más la segunda vertiente, la que voy a denominar cognitiva. En este caso, tiene mucho que ver con el 'deskilling', es decir, con la pérdida de capacidades cognitivas. Esa pérdida de capacidades cognitivas, por sí misma, me parece un empobrecimiento de la persona pero, además, en a medida que se confía más y más en sistemas automatizados, puede devenir en una menor autonomía, una mayor dependencia.

Es cierto que en el pasado, nos hemos deshecho de capacidades que hemos delegado en máquinas y tecnología, y no parece que nos haya ido mal ni que estemos descontentos. Incluso es posible, sólo posible, que a cambio de ceder algunas capacidades, resultemos potenciados en otras, que desarrollásemos nuevas habilidades. 

Pero, claro, hablamos de capacidades cognitivas, muy esenciales de lo que significa ser humano. Y  no sé si estamos dispuestos a asumir (yo, personalmente, no), esa suerte de degradación cognitiva o el riesgo de un incierto cambio de capacidades cognitivas.

Sin recetas, pero con un planteamiento a corto plazo

La verdad es que creo que nadie puede tener claro lo que va a ocurrir en el futuro, y cómo vamos a evolucionar. Es posible que, al final, los riesgos y peligros no sean tan grandes o, al menos, que sepamos encauzarlos y el resultado final sea bueno. Y como estamos ante un panorama incierto, es difícil saber cuál es el camino adecuado.

Sin embargo, pase lo que pase en el futuro, creo que los riesgos que he mencionado son reales y afectan a temas muy importantes, de seguridad y casi a nuestra propia naturaleza. Así que, si existen riesgos reales, pero tenemos poco clara la visión futura, creo que conviene actuar, al menos a corto plazo. Desde luego, creo que podemos, casi diría que debemos, utilizar, y utilizar mucho, una tecnología tan potente y versátil como es la inteligencia artificial. Pero debemos hacerlo de una forma consciente y responsable, responsable con los demás y con nosotros mismos. 

Y así, creo que cada uno de nosotros deberíamos exigirnos y esforzarnos en la supervisión de aquello que delegamos en la inteligencia artificial, desde grandes automatizaciones corporativas, hasta simples consultas a ChatGPT. Aunque nos cueste, aunque nuestra naturaleza nos impulse a ser cómodos y confiarnos, debemos esforzarnos conscientemente en ejercer el juicio crítico, el control y la autonomía. 

Y, además, deberíamos cuidar nuestras capacidades cognitivas, intentando no sólo no perderlas sino incluso aumentarlas. Y para ello, dado que no vamos a dejar de utilizar la inteligencia artificial, quizá debamos reforzar nuestras capacidades, y hacerlo conscientemente, mediante actividades en paralelo que cuiden y desarrollen esas capacidades: lectura, estudio, actividades artísticas, interacción humana, etc

Es cierto que pongo mucho énfasis en la responsabilidad individual, en el auto-cuidado cognitivo, es cierto que, además, lo que propongo exige acción consciente y puede que esforzada, y es cierto, finalmente, que puede que las cosas cambien, y que en unos años o que las valoremos de una forma diferente, pero ahora mismo, a corto plazo, creo que es lo mejor que podemos hacer... y hacerlo cada uno de nosotros.

Conclusiones

El uso intensivo de las tecnologías, muy en especial la inteligencia artificial, puede conducir, por un lado, a una confianza excesiva en de las decisiones automatizadas y, por otro, a una progresiva degradación de nuestras capacidades cognitivas.

La combinación de ambos fenómenos, creo que es peligrosa tanto desde un punto de vista operativo como humano, cognitivo y casi ético.

Existe mucha incertidumbre sobre el nivel de riesgo real o cómo afrontarlo pero, a corto plazo, lo que creo que debemos hacer es reforzar, conscientemente, nuestra supervisión de los sistemas y, sobre todo, nuestro propio desarrollo cognitivo.