El pluriespecialista y la IA

Llevamos ya dos años utilizando modelos IA en nuestro trabajo. Primero de forma muy limitada y poco a poco incorporándola en procesos de trabajo y dándole un uso cada vez más intenso. Pero donde el impacto ha sido más fuerte ha sido en el desarrollo de software. Con los últimos modelos de IA estamos ya muy cerca de la programación en lengua natural y el cambio modifica el modo de trabajar en sí mismo.

La incorporación de la IA y la mejora de la productividad

En lo fundamental nada parece cambiar demasiado. Es verdad que no hace falta un dominio profundo de los lenguajes de programación, aunque sí, al menos por el momento, el conocimiento suficiente como para entender las propuestas de código que nos hace la IA. E importa, sobre todo, tener una idea clara previa de las funcionalidades y de los itinerarios de uso que van a configurar la experiencia de uso de los usuarios.

Sin embargo, si combinamos ésto, que no parece dramático, con la reducción del número de horas necesario para desarrollar una aplicación, llegamos a una situación en la que el hacker tal y cómo lo definía Juan Urrutia hace 20 años, como un pluriespecialista sin espíritu de finura, sustituye con ventaja al desarrollador de formación universitaria.

De hecho, la clave para obtener productividad de la incorporación de IA al desarrollo no se puede basar en mejorar la velocidad de producción del desarrollador. Lo que nos dicen los estudios es que cuanto mejor sea un desarrollador menos productividad le aporta la IA.

¿Dónde está entonces el aumento de productividad? En que una sola persona -o los miembros de un equipo, si la dimensión del proyecto lo exige- combinen conocimiento del tema de fondo de la app, sensibilidad para las expectativas del usuario y un dominio amateur de las técnicas de programación. En el ejemplo típico se trata de sustituir el equipo formado por un experto y un desarrolador que saben cada uno el 90% de todo el saber establecido de su especialidad, por un bricoleur con espíritu de trabajo amateur y conocimientos globales -pero suficientes- de ambas cosas y algunas más.

Los «peros» que no tocan

Si Code is poetry, la IA no pasa de reguetonera. A veces, no limpia lo suficiente el código que hemos descartado. En otras ocasiones toma un camino gratuitamente barroco para realizar un proceso que le hemos explicado una forma relativamente lineal. Da igual. Funciona. Y en apps de trabajo normales, la ciclotimia codificada no modifica de forma perceptible la velocidad de ejecución ni el volumen de recursos consumidos por el programa.

Podemos prescindir del sentimiento de orgullo por la belleza del código mientras no perdamos el conocimiento para retocarlo o modificarlo cuando queramos. El hacker, el bricoleur, sabe que, como decía Juan:

La cuestión.. radica en... romper con la relación entre esfuerzo y mérito.

Juan Urrutia «El esfuerzo y la gracia», 10 de julio de 2012

De dónde sale el «trabajo amateur»?

El aporte del hacker es puro «trabajo amateur», es decir, trabajo en el que su formación académica seguramente sólo le haya aportado las bases, no la erudición del especialista. El hacker programa sin ser un desarrollador -pero sabiendo plantear y estructurar un programa- y diseña aplicaciones sin necesidad de que ser un especialista en procesos pero si un buen conocedor apasionado por el tema que la app pretende resolver. Su aporte es, como señalaba Juan:

Una forma de trabajo amateur hecha posible mediante la formación de pluriespecialistas que se verán a sí mismos como remedos de un vividor Oscar Wilde curiosamente modesto y extrañamente solidario.

Juan Urrutia «Paísaje después de una batalla», 3 de abril de 2011

¿Cómo formar pluriespecialistas?

Cómo formar pluriespecialistas es la gran pregunta de nuestra época. En próximos artículos en este blog intentaremos aportar las respuestas que hemos ganado con la práctica.