Blogs de Festeros.es

La discusión sobre si la tarea de escribir código ejecutable va a seguir siendo o no una actividad humana se está acelerando a cuenta de las últimas herramientas de machine learning desarrolladas y puestas a disposición de los usuarios por algunas compañías. Probarlas es sencillo: basta con un pequeño prompt escrito en lenguaje perfectamente comprensible por un ser humano, para hacer que un asistente genere una serie de líneas de código, con instrucciones incluidas si se desea, que un desarrollador puede simplemente copiar y pegar.

A principios de diciembre, la revista Nature dedicó un artículo académico a evaluar una competición entre desarrolladores humanos y la herramienta AlphaCode creada por Deep Mind, y concluyó que era capaz de superar a muchos desarrolladores humanos en tareas relativamente complejas. En su número de enero de 2023, la prestigiosa Communications of the ACM publicó un artículo de opinión de Matt Welsh titulado «The end of programing« en el que se afirmaba que la programación tal y como la conocemos estaba obsoleta, y que la nueva unidad atómica de la computación eran «los modelos de inteligencia artificial masivos, previamente entrenados y altamente adaptables», algo que presentaba como «una enorme oportunidad, repleta de enormes riesgos».

Al artículo de Welsh en CACM contestó hace pocos días con sumo hartazgo Joe McKendrick, de ZDNet, en «It’s the end of programming as we know it – again«, afirmando que desde hace ya varias décadas, tecnologías como las herramientas CASE, 4GL, la programación orientada a objetos, las arquitecturas orientadas a servicios (SOA), los microservicios, los servicios en la nube, la plataforma como servicio (PaaS), la computación sin servidor o el low code / no code han afirmado ser capaces de eliminar las onerosas cargas derivadas del desarrollo de software y amenazar la seguridad laboral de los profesionales de este ámbito, para finalmente dar como resultado que su demanda en el mercado, su carga de trabajo y la búsqueda de sus habilidades no hagan más que aumentar.

En sentido contrario, un estudio de Stanford demostró recientemente que el hecho de escribir código utilizando para ello un asistente como GitHub Copilot no implica escribir mejor código, sino precisamente incurrir, en promedio, en un mayor número de vulnerabilidades y en código menos seguro.

¿Qué pueden esperar, entonces, los profesionales del desarrollo de software en el futuro? La conocida página «Will robots take my job?» afirma, cuando introducimos como categoría «computer programmers«, a los que atribuye un salario medio de unos $93K, que su riesgo de ser automatizados está en un escaso 41%, muy por debajo de muchísimas otras categorías profesionales. En categorías relacionadas, como «computer system analysts«, a los que calcula un sueldo promedio de $99K, establece un riesgo de automatización mucho menor, de un 10%, y para «computer and information research scientists«, a los que sitúa en salarios medios de $131K, un minúsculo 4%. Finalmente, para los definidos como «computer and information systems managers«, que tienden a salirse ya de nuestro análisis y a no definir tanto su actividad en base a la escritura de código, y a los que sitúa en escalas salariales en torno a los $159K, les otorga un riesgo de automatización de un 6%.

En mi opinión, partimos de un problema de definiciones: escribir código es muy sencillo. En la práctica, es mucho más sencillo escribir código en un lenguaje determinado que hablar un idioma, dado que los idiomas están plagados de inconsistencias, excepciones, reglas arbitrarias y tildes diacríticas, y los lenguajes de programación son, por necesidad imperiosa, generalmente precisos e inequívocos. Entender cómo se definen variables, cómo se establecen condicionales y cómo se definen bucles en un lenguaje de programación lleva muy poco tiempo, y escribir un programa razonablemente sencillo es una tarea que puede llevarse a cabo en no mucho tiempo. Sin embargo, la curva de la experiencia que va desde el simple manejo del lenguaje de programación a ser capaz de convertir ideas en código ejecutable de una manera adecuada y con una competencia profesional a buen nivel es muy, muy prolongada, y muchos profesionales no llegan nunca a completarla.

¿Qué ocurre cuando intentamos trasladar ese esquema de aprendizaje al ámbito del machine learning? Sencillamente, que nos resultará relativamente sencillo adiestrar a un algoritmo para que, partiendo de una base de datos con infinidad de ejemplos, sea capaz de programar, pero muy difícil conseguir que lo haga de una manera comparable a como lo hace un desarrollador con experiencia. Los repositorios que se suelen utilizar para adiestrar este tipo de herramientas están plagados de ejemplos código bueno, pero también de código mediocre o malo, lo que redunda en que el resultado obtenido no tenga siempre la calidad que esperamos de él.

¿Y de cara al futuro? ¿Qué ocurre cuando estos algoritmos, a base de correcciones sucesivas, de filtrado consistente de sus repositorios de aprendizaje y de mejora de sus sistemas de evaluación, van avanzando en sus prestaciones? Posiblemente seamos capaces de obtener una herramienta que maneje el lenguaje de forma muy competente y que obtenga resultados elegantes, pero por el momento, no estamos aún ahí, y mi impresión es que estamos aún lejos de estarlo.

¿Debemos seguir tratando de enseñar a los niños a programar? La respuesta a esa pregunta es un categórico sí. Primero, porque programar ayuda a estructurar ideas, a ordenar los pensamientos y a definir tareas, y es, por tanto, una muy buena manera de enseñar cosas. Segundo, porque es una habilidad que siempre tendrá aplicaciones interesantes. Y tercero, porque nos nos dirigimos a entornos – estamos ya en ellos, en realidad – en el que prácticamente en todo momento estaremos rodeados de objetos programables, y es bueno ser capaces de entendernos con ellos y de hablar su lenguaje.

¿Opiniones?

Publicado con licencia Creative Commons 3.0 España