Andrés, catorce años y una reunión incómoda
Andrés llevaba catorce años escribiendo código. Conocía tres lenguajes a fondo, dos frameworks de memoria y podía montar un servidor en veinte minutos con los ojos medio cerrados. Su mujer le decía que hablaba en sueños y que una vez dijo algo de una base de datos. Él no lo recordaba, pero tampoco lo descartaba.
Un martes de febrero, su jefe reunió al equipo en la sala grande. La que tiene las sillas que no son cómodas y el proyector que siempre falla. El proyector no falló esta vez. En la pantalla salió Jensen Huang, el de Nvidia, diciendo algo que Andrés no esperaba oír de un ingeniero: «Distinguid entre las tareas de vuestro trabajo y el propósito de vuestro trabajo. Las tareas pueden desaparecer.»
Andrés miró a Lucía, la de al lado. Lucía no miró a nadie.
Después de la reunión, en la máquina del café, Marcos dijo que era broma. Que siempre haría falta gente que escribiera código.
—Claro —dijo Lucía, removiendo el azúcar sin levantar la vista—. Como siempre hizo falta gente que copiara documentos a mano.
Marcos se llevó el café sin decir nada más.
Lo que Huang estaba diciendo de verdad
Huang no hablaba de despidos. Ni de robots. Hablaba de algo más sutil, que es lo que lo hacía incómodo. Hablaba de que escribir código es una tarea. Una tarea que cada vez hace mejor una máquina. Pero crear aplicaciones útiles —entender un problema, diseñar una solución, decidir qué construir y para quién— eso es un propósito. Y ese propósito sigue siendo humano.
La distinción parece filosófica hasta que la vives en una oficina real.
Andrés escribía código limpio, rápido, bien documentado. Pero si le preguntabas para qué servía lo que estaba construyendo, a veces se quedaba callado un segundo de más. Había tareas en su backlog que llevaban tres sprints ahí y que nadie sabía muy bien quién había pedido ni por qué.
Lucía, en cambio, tenía la costumbre de preguntar cosas molestas antes de escribir una sola línea. «¿Para qué es esto?» «¿Quién lo va a usar?» «¿Qué pasa si no lo hacemos?» No era muy popular en las reuniones de planificación. Pero sus proyectos funcionaban. Los de Andrés también funcionaban, técnicamente. La diferencia es que los de Lucía los usaba alguien.
El software que nadie usa
Hay una estadística que circula por los departamentos de tecnología y que nadie quiere mirar de frente: entre el cuarenta y el sesenta por ciento de las funcionalidades que se desarrollan en software empresarial no se utilizan nunca. Nunca. Se especifican, se diseñan, se programan, se testean, se despliegan. Y nadie las toca.
Eso es código escrito sin propósito. Tareas ejecutadas a la perfección que no resuelven nada.
Cuando alguien contrata un desarrollo a medida y la primera reunión se dedica entera a entender el negocio, sin abrir un editor, sin hablar de tecnología, hay quien se impacienta. «¿Cuándo empezamos a construir?» Pero esa reunión es la que separa el software que se usa del que acaba en un cajón digital.
La pregunta que importa
En la empresa de Andrés pasó algo. Empezaron a usar herramientas de inteligencia artificial para generar código. Al principio era para las partes repetitivas: formularios, validaciones, consultas a base de datos. Después fue para cosas más complejas. Un día, Andrés vio que una IA había escrito en tres minutos algo que a él le habría costado media mañana. Y estaba bien. Funcionaba. Pasaba los tests.
Se quedó mirando la pantalla. No con miedo, exactamente. Con algo parecido a cuando ves que alguien conduce mejor que tú por una carretera que conoces de memoria.
Marcos pidió una reunión con el jefe. Quería saber si iban a reducir plantilla. El jefe dijo que no. Que lo que iban a reducir era el tiempo dedicado a tareas mecánicas. Que ahora necesitaba gente que supiera qué construir, no solo cómo construirlo.
Marcos preguntó cuál era la diferencia.
Lucía, que pasaba por allí con un café, dijo sin pararse:
—La diferencia es que antes te pagaban por las manos. Ahora te pagan por la cabeza.
No era del todo exacto. Pero nadie la corrigió.
Lo que queda cuando la tarea desaparece
Hay empresas que siguen buscando programadores que escriban código rápido. Y hay empresas que buscan a alguien que entienda su problema antes de escribir nada. Las primeras contratan tareas. Las segundas contratan propósito.
Un chatbot que funciona no empieza por el código. Empieza por alguien que se sienta con el dueño del negocio y le pregunta: «¿Qué necesitan tus clientes a las once de la noche que ahora no tienen?». Un cuadro de mando que sirve no empieza con gráficos. Empieza con alguien que pregunta: «¿Qué decisión vas a tomar con este dato?». Una automatización que ahorra tiempo no empieza con flujos de trabajo. Empieza con alguien que observa durante una mañana cómo trabaja tu equipo y apunta las cosas que repiten sin darse cuenta.
Después viene el código. Pero el código es la tarea. Lo otro es el trabajo.
Un gesto pequeño
Andrés cambió. No de golpe, no con una revelación dramática. Simplemente empezó a hacer algo que antes no hacía: antes de escribir código, llamaba al usuario que iba a usarlo. Cinco minutos de conversación. «¿Qué necesitas exactamente?» «¿Cómo trabajas ahora?» «¿Qué te da dolor de cabeza?»
El código que escribía después era menos elegante que antes. A veces hasta más corto. Pero lo usaban.
Un día su mujer le dijo que había vuelto a hablar en sueños. Que esta vez había dicho algo de un cliente.
Andrés sonrió. Le pareció una mejora.
¿Tu software resuelve problemas o solo ejecuta tareas?
Si alguna vez has tenido la sensación de que la tecnología de tu empresa funciona pero no sirve, quizá el problema no sea el código. Una conversación breve puede aclarar mucho.
Hablemos