A estas alturas de la película, seguramente te parecerá un artículo lleno de obviedades sobre la IA. Aun así, quiero centrarme en la aceleración que veo en la pérdida de empatía con el usuario final.
Me explico, y es aquí donde vienen las obviedades que todos ya hemos escuchado:
Desarrollar funcionalidades es muy barato.
La IA es un multiplicador de buenos y malos hábitos.
La multitarea y las opciones recomendadas constantes inducen a la fatiga de decisión.
Entorno de hiperproductividad. Si no estás cerrando tickets, ¿a qué dedicas tu tiempo?
Todo esto no es ni bueno ni malo en sí mismo. Lo interesante es cómo encajan para estar llevando a los equipos de desarrollo a trabajar en modo factoría al 100%. De hecho, ya se está utilizando ese nombre sin ningún pudor. Y sabemos que cómo llamamos a las cosas condiciona nuestra percepción de ellas.
Llevábamos años, incluso décadas, luchando por un discurso que valorara a los equipos de desarrollo más allá de producir software (ser una factoría). Entender el negocio, el producto, el propósito, el porqué de las peticiones, la problemática del usuario, etc. En definitiva, desarrollar empatía con el usuario final y alinearse con el negocio.
Siento que, a día de hoy, todo eso se está perdiendo a pasos agigantados. ¿Es culpa de la IA? Pues, obviamente, no, pero está creando el caldo de cultivo perfecto para potenciar cierto tipo de comportamientos.
Pongo algunos ejemplos:
Antes, al tener que desarrollar cada funcionalidad a mano, nos veíamos obligados a dedicarle mucho más esfuerzo mental. Esto hacía que quisiéramos sentirnos seguros de que esa inversión de tiempo iba a merecer la pena. Haciendo preguntas, entendiendo el problema, investigando opciones, etc. Ahora, cualquier cosa que hagamos requiere prácticamente un esfuerzo equivalente. Solo tenemos que pasarle el ticket al agente para que analice el repo, implemente, pruebe, cree la PR y pase al siguiente ticket.
Por tanto, nos convertimos en devoradores de tickets, pongan lo que pongan.
Hemos cambiado inconscientemente “¿Tiene sentido hacer esto?” por “¿Puede hacerlo el agente?”
Esa persona que evita las reuniones, las interacciones con los usuarios, entender el negocio, etc., siempre ha existido. Ahora, con la IA como potenciadora de hábitos, este tipo de desarrollador está más feliz que nunca en modo factoría.
Ahora podemos ser extraordinariamente productivos técnicamente y estar completamente desconectados del problema que estamos resolviendo.
Aquí se mezclan varios factores. Fatiga productiva y de decisión.
La primera se deriva de un contexto hiperproductivo. Si no estás cerrando tickets, ¿qué estás haciendo? Ahora mismo no se incentiva el buen análisis. Si un desarrollador dedica una mañana a hablar con usuarios y, como consecuencia, decide no desarrollar una funcionalidad, ¿cómo medimos esa productividad? Todas las métricas se centran en el cierre de tareas, lo que favorece de nuevo el “whatever...”
A día de hoy, parece que pensar sale caro.
Por otra parte, la facilidad que nos dan los agentes para aceptar las soluciones “Recomendadas” por defecto hace que, al cabo del día, aceptemos cualquier cosa sin dedicarle un mínimo de razonamiento crítico. Utilizar skills como grill-me o similares puede ayudar a ser más consciente de las decisiones a las que deberías prestar más atención, aunque aun así, puedes seguir aceptando cualquier cosa que te proponga el modelo.
Hasta ahora hemos tratado la fricción en el desarrollo como algo negativo. Queremos reducir tiempos, automatizar tareas, mejorar el developer experience, etc.
Pero había una fricción cognitiva útil.
No se trata de volver a reuniones eternas, burocracia o documentos de 30 páginas. Se trata de eliminar la fricción mecánica y mantener la fricción intelectual.
Fricción que queremos eliminar: código repetitivo, búsqueda de información, configuración, tareas repetitivas, generación de pruebas básicas, documentación mecánica...
Fricción que quizá queremos conservar: cuestionar requisitos, discutir trade-offs, entender al usuario, decidir prioridades, analizar consecuencias.
Automate execution. Don’t automate understanding.
No quiero ponerme tremendista, pero todo esto es lo que hace precisamente que perdamos nuestro valor humano dentro de todo el proceso.
No sé si llamar «factoría» al equipo de desarrollo es algo intencional o no, pero es lo que nos hará más rápidamente sustituibles. Hará que nos convirtamos en commodity o en un “mal necesario” rápidamente.
Si definimos nuestro valor como la capacidad de transformar requisitos en código, estamos eligiendo competir precisamente en la parte del proceso en la que la IA está avanzando más rápido.
Cada vez hay menos motivos por los que un Product Owner con un buen harness tiene que depender del equipo de desarrollo. Si nuestra aportación se limita a recibir requisitos suficientemente detallados y convertirlos en software funcionando, cada vez habrá menos razones para que alguien necesite que seamos nosotros quienes hagamos esa traducción.
Por eso, tenemos que poner mucho más foco en desarrollar la empatía con el usuario y entender bien el negocio.
En definitiva, ser más “Fall business Persona” y menos factoría.