Tiempo estimado de lectura: 6 minutos.
Un día una compañera de laburo me dijo que la programación no era tan importante. Obviamente me tocó una fibra, ¿cómo que mi trabajo no era importante?
Estaba convencida de que la clave era el producto, el marketing, la presencia, que la gente llegara, se interesara y nos contratara. Y yo, como programador, obviamente pensaba que lo más importante era el código, la construcción perfecta de la plataforma, la arquitectura bien hecha, las buenas prácticas, todo prolijo.
Pero no. Con el tiempo me di cuenta de que, al principio, lo más importante no es el código. La posta es tener un producto que la gente quiera, que pueda comprar de alguna manera, aunque te escriban por WhatsApp. Algo que funcione para ellos. Después, cuando querés escalarlo y pasar de atender 10 pedidos a 10.000, ahí sí aparece la programación. Ahí es donde la tecnología multiplica, pero no reemplaza un producto flojo.
Y ahí apareció algo nuevo: esta guía que usamos hoy, que reemplaza una parte del “cómo programar” pero no reemplaza el pensamiento. Nos ayuda a ordenar ideas, a decidir dónde poner el foco, a planificar tareas, a entender cómo resolverlas. Pero la proactividad sigue siendo humana. Todavía no existe una guía que pueda reemplazar a una persona en el desarrollo de software entero de punta a punta.
Después me pasó algo muy concreto. Estábamos construyendo un beneficio que tenía descuentos basados en puntos: 500 puntos, 10% de descuento; 1000 puntos, 25%; y así. Eso estaba en la base de datos y ya tenía toda su lógica armada. Teníamos que agregar una pantalla nueva con un diseño distinto para mostrar justamente esos descuentos.
Y lo más rápido en ese momento, y lo que más sentido tenía desde el negocio, era hardcodear los valores. Era más rápido escribirlos directo en el código que leerlos de la base. Eso es totalmente antiintuitivo para cualquier programador. Vos querés que sea configurable, que venga dinámico, que siga las mejores prácticas. Pero ahí no era importante. Ahí queríamos validar, medir, saber si la gente realmente iba a usar esa nueva pantalla. Era un MVP. No importaba hacerlo “perfectito”. Importaba sacarlo y aprender. Ahí fue donde más claro vi que el código no era lo importante.
Ahí también se mezcla otro descubrimiento: las IA programan, sí, pero se equivocan. Mucho. No en todo, pero en cosas que pueden ser graves. Temas de seguridad, temas de performance, cosas que si vos no las tenés en cuenta, la IA tampoco las tiene. Errores que después son difíciles de corregir. Y cuando hay un error lógico, ahí sí se quedan trabadas. La IA puede tirar miles de soluciones, pero si el error depende del contexto particular de tu negocio, o de cómo resolviste algo en otro archivo, o de cómo pensaste una función… no lo va a encontrar.
Muchas veces las soluciones que encuentra son cosas que vio en StackOverflow o GitHub. Cosas generales. Pero los errores lógicos suelen estar en tu código, en tu forma de pensar, y si no ve el contexto entero, es difícil. Ahí el patrón se sale de lo común. Y leer todo eso sigue siendo más eficiente para un humano. A veces tardás 15 minutos en encontrar el error. Y una vez que lo encontrás, sí, ahí a la IA le podés pedir: “Acá está el error, está haciendo esto y esto, explícalo y arreglalo”. Y ahí lo resuelve. Pero ese paso previo todavía es humano.
Y encima está todo esto de la sobreingeniería. Uno hace mucha ingeniería sobre un código y muchas veces no sabés si lo que estás construyendo realmente se va a usar. Pasa incluso con software entero. Te mandás un sistema gigante y después nadie lo usa. Hasta que la gente no lo usa, hasta que no hay usuarios reales interactuando, no tiene sentido agregarle todas las buenas prácticas del mundo, toda la lógica extra, todos los tests, toda la configurabilidad. Hay cantidades de software así: impecables, cuidados… e inútiles, porque nadie los necesitaba.
Y una aclaración importante: los juniors no tienen este problema. Los juniors no buscan el código perfecto. Todavía no están en ese nivel. Este problema lo tienen los seniors. Los seniors son los que caen en la trampa del “perfecto antes de tiempo”. Los que quieren hacer la arquitectura completa antes de validar nada. Los que quieren diseñar todos los casos posibles antes de saber si la funcionalidad sirve o no. Ahí es donde más se pierde tiempo, energía y foco.
Por eso digo que la programación no se va a reemplazar. No la va a reemplazar una guía, no la va a reemplazar una IA que codee. Puede ayudar, puede acelerar, puede ordenar. Pero un software grande sigue necesitando muchas horas de varias personas. Es demasiado complejo. Y por más que alguien diga “lo hago por mi cuenta con IA”, es lo mismo que cocinar: todos podemos cocinar, pero no todos cocinamos bien. La diferencia entre cocinar vos y comer en un restaurante es enorme. Con el software pasa lo mismo.
Y además, cada vez hay más aplicaciones y cada vez son más complejas. Las simples ya no las va a hacer un programador: las va a hacer el propio usuario. Y aun así, herramientas como Excel, que no tienen código, que son no-code, la mayoría de la gente no las usa. Algunas sí, claro, pero el porcentaje es bajo.
La programación no importa ahora porque lo hace la IA. Lo que importa es resolver problemas y enfocarse en lo que mas valor puede dar. No importa si usas IA, si no la usas. No importa si programas o no. Al final, la programación no importa tanto.
La Ilustración es de Katerina Limpitsouni publicada en unDraw.