|
En un mundo enfebrecido por la IA, en el que a algunos iluminados les parece una buena idea usar el número de tokens que gasta un empleado como medida de productividad, Pau Ramon propone hacer justo lo contrario.
Un día a la semana, no usar la inteligencia artificial para nada. Ni agentes ni prompts, solo tu cerebro para pensar y tus dedos para ejecutar. Frente al token maxxing, token fasting o ayuno de IA.
La propuesta de Pau no es «una defensa del ábaco». Su objetivo no es prescindir de la IA sino usarla de la forma más efectiva a largo plazo.
Un estudio de Anthropic publicado a principios de este año que enfrentaba a desarrolladores con una tarea sobre una librería Python desconocida, comprobó que el grupo con asistencia de IA obtuvo un 17 % menos de dominio en la prueba posterior que el grupo que programó a mano.
No es que descubrieran petróleo, precisamente. Todos sabemos que la mejor manera de aprender algo es haciéndolo y, como Pau recuerda en su tweet, los humanos somos animales sensoriales. Por eso tomamos notas en clase para afianzar conceptos o aprendemos a conducir en un coche real, no en un simulador.
Otra de las razones que aduce Pau para defender el día sin IA es nuestra tendencia a solucionar un problema añadiendo cosas en vez de eliminarlas. Pau sostiene que la inteligencia artificial ha multiplicado este problema por cien.
Antes, como programar exigía una gran inversión de tiempo, teníamos un incentivo más fuerte para detenernos a pensar, a tratar de encontrar la solución óptima y evaluar soluciones ya existentes —open source o no— que pudieran ahorrarnos trabajo, antes de programar una sola línea de código.
Ahora, como generamos código de forma casi instantánea, estamos perdiendo la buena costumbre de pensar. Lanzamos nuestros bugs, modificaciones y nuevas funcionalidades a la IA sin mucha consideración. Total, es gratis.
Pero no es gratis. La IA no sufre la latencia que implica que nuestra lógica se ejecute a través de interminables capas de abstracción. Ni tampoco la complejidad de desplegarlas y gestionarlas en producción. Ni el dolor de tener que mantenerlas seis meses después e intentar averiguar cómo funcionan.
Algunos gurús se ríen de los que nos preocupamos por esas cosas. Aseguran que, más tarde o más temprano, la IA siempre entenderá el código que ha escrito previamente e identificará y resolverá automáticamente sus propias ineficiencias. Puede que en un futuro tengan razón, pero en mi presente los modelos abiertos inventan en el 21,7 % de las dependencias que recomiendan y el 45 % de las muestras de código generadas por IA contienen vulnerabilidades de seguridad.
De nuevo, señalar los problemas y limitaciones actuales de la IA no significa atacarla sino entenderla para usarla de forma más efectiva AHORA. Y es que, en un mundo donde cualquiera puede generar más código, quizás lo que distinga a los programadores profesionales sea su capacidad para conseguir que las aplicaciones funcionen con menos.
Menos código. Menos mantenimiento. Menos vulnerabilidades.
Pero la mejor aplicación de la propuesta de Pau es una que él no menciona, pero que a mí me interesa especialmente: es una manera de formar a los que empiezan.
Un programador con experiencia puede delegar parte del trabajo mecánico porque ya posee un modelo mental de lo que hay debajo, pero si eliminamos esas primeras tareas habituales en la carrera de cualquier técnico que implican leer —y tratar de entender— el código de otros, ¿de dónde saldrán los profesionales capaces de identificar un potencial error y arreglarlo?
He preguntado a muchos expertos en desarrollo con IA cómo podríamos transmitir ese know-how con el actual flujo de trabajo, pero ninguno ha sabido darme una respuesta. Quizás una manera podría ser combinar el día sin IA con sesiones de programación a pares, donde los más veteranos puedan explicar a sus nuevos compañeros por qué optan por una solución u otra.
Por eso, si yo montara una consultora informática hoy, todo el flujo de trabajo estaría diseñado alrededor de la IA, pero precisamente por eso, creo que también implementaría la práctica del token fasting.
Porque, aunque es probable que escribiéramos código más despacio, estoy seguro de que desarrollaríamos software más rápido. Y de forma más sostenible.
Porque sigo creyendo que este mundo no necesita profesionales que sepan quemar el máximo de tokens, sino capaces de reconocer cuándo una nueva abstracción o una línea adicional ya no aporta valor, sino que lo resta.
Porque quizá dentro de unos años la IA escriba, pruebe, despliegue y mantenga casi todo el código, pero mientras alguien tenga que responder cuando algo falle, el día sin tokens no será ni una penitencia ni una protesta sino un entrenamiento para que, cuando llegue el momento, haya alguien de guardia.
Y porque otra de las cosas que enseña la experiencia es que, tarde o temprano, ese momento llegará. Shit happens.
|
