Haceme un sistema
La inteligencia artificial escribe código y lo hace cada vez mejor.
Hoy podemos explicarle lo que necesitamos y verla crear una pantalla, modificar una base de datos, escribir una API, encontrar un error o desarrollar en algunos minutos algo que hasta hace muy poco podía llevarnos varias horas de trabajo. Incluso, como ya conté en otra nota, integramos CODEX Noticia relacionada: lambdasinews-news-25 o COPILOT, o el mismo Claude Code a nuestro VSCode y listo, hasta organiza lotes de prueba para nuestros programas.
Entonces aparece una conclusión bastante tentadora: Si la Inteligencia Artificial programa, ya no necesitamos programadores.
Y llevándola un poco más lejos: ¿Para qué necesitamos un Analista de Sistemas?
No tengo la respuesta sobre qué ocurrirá dentro de diez o veinte años (aunque al paso que vamos, debería decir 2 o 3 años). Probablemente muchas de las tareas que hoy realizamos hayan cambiado completamente para entonces. Pero mirando lo que tenemos hoy, creo que estamos confundiendo programar con desarrollar un sistema.
La máquina del carpintero
Algo parecido ocurrió innumerables veces con el avance de la tecnología. Durante siglos, un carpintero preparaba una pieza utilizando serrucho, cepillo de mano, formón y otras herramientas manuales. Hoy puede dimensionar un tablero con una sierra circular de mesa, obtener caras perfectamente planas con una garlopa, llevar una pieza a un espesor uniforme con una regruesadora o realizar cortes y mecanizados repetitivos con una fresadora e incluso con un router CNC. La máquina reemplazó una enorme cantidad de trabajo manual y, en muchas operaciones, consigue además una precisión y una repetibilidad difíciles de alcanzar trabajando exclusivamente a mano. ¿Significa eso que dejó de hacer falta el carpintero? Todo lo contrario. Alguien todavía tiene que elegir la madera, interpretar las medidas, decidir cómo construir el mueble, dónde realizar cada corte, qué unión utilizar y en qué orden ejecutar el trabajo. La máquina sabe hacer el corte. El carpintero sabe por qué hay que hacerlo ahí.
Aún así, alguien todavía tenía que saber qué mueble quería construir.
- Qué madera utilizar.
- Qué medidas debía tener.
- Cómo unir sus partes.
- En qué orden trabajar.
Y, fundamentalmente, reconocer cuándo aquello que estaba produciendo estaba bien o estaba mal.
Lo mismo ocurrió en el campo. Trabajos que requerían decenas de personas hoy pueden ser realizados por una sola arriba de una máquina extraordinariamente sofisticada. Yo fui testigo del arado de un lote, colgando una bolsa blanca en el extremo para poder seguir la línea y hacer surcos parejos y paralelos. Hoy la sembradora lo hace automáticamente por GPS.
La tecnología reemplazó trabajo humano. Pero también multiplicó enormemente la capacidad de la persona que aprendió a utilizarla. Quizás con la Inteligencia Artificial esté ocurriendo algo parecido.
Antes del código hay un problema
Supongamos que mañana queremos desarrollar un nuevo sistema comercial. Podemos abrir una herramienta de Inteligencia Artificial y escribir: Creame un sistema de gestión comercial. Seguramente algo va a crear.
Pero inmediatamente empiezan las preguntas.
- ¿Cómo funciona nuestra empresa?
- ¿Qué es un cliente?
- ¿Qué documentos emitimos?
- ¿Cómo facturamos?
- ¿Qué impuestos intervienen?
- ¿Cómo manejamos una cuenta corriente?
- ¿Qué permisos tendrá cada usuario?
- ¿Qué ocurre cuando anulamos una operación?
- ¿Qué información necesitamos conservar?
- ¿Qué cosas jamás deberían poder modificarse?
- ¿Qué excepciones existen?
De repente descubrimos que el problema más difícil no era escribir el código. Era explicar qué tenía que hacer el sistema.
Las reglas de negocio
En lo personal, en los últimos años mi forma de programar cambió muchísimo gracias al desarrollo asistido por IA y cada vez dedico más tiempo a algo que, curiosamente, no es programar: escribir reglas de negocio.
Una buena instrucción puede producir buen código y, por supuesto, un buen sistema. Una instrucción ambigua puede producir código perfectamente escrito que hace exactamente algo que no queríamos.
La IA necesita contexto. Necesita saber qué puede hacer, qué no puede hacer, qué condiciones debe respetar y qué debería ocurrir frente a cada situación. Estimados colegas: ¿No les suena al ciclo de vida de un sistema? Aprendimos que buena parte del ciclo de vida de un sistema debía dedicarse al análisis y al diseño, y no solamente al desarrollo y las pruebas. Pero hace años que cambiamos nuestra perspectiva. Erróneamente "diseñábamos" directamente mientras programábamos.
El famoso prompt importa, por supuesto. Pero en un desarrollo serio rápidamente deja de alcanzar con saber escribir un prompt bonito. Hay que saber describir un problema.
Alguien tiene que tomar decisiones
Antes o durante el desarrollo tendremos que decidir qué tecnología utilizar.
- ¿PHP? ¿Python? ¿Java? ¿.NET? ¿Otra?
- ¿Qué motor de base de datos? ¿MySQL? ¿PostgreSQL? ¿SQL Server?
- ¿Será una aplicación de escritorio, web o móvil?
- Si es web, ¿cómo vamos a separar frontend y backend?
- ¿Cómo se autenticarán los usuarios?
- ¿Dónde vamos a alojarla?
- ¿Qué capacidad necesita el servidor?
- ¿Cómo hacemos los backups?
- ¿Qué exponemos a Internet?
- ¿Qué protegemos mediante firewall?
- ¿Cómo actualizamos el sistema sin interrumpir a quienes están trabajando?
- ¿Cómo registramos errores?
- ¿Cómo protegemos los datos?
Podemos preguntarle todo esto a una IA. De hecho, seguramente deberíamos hacerlo. Pero alguien finalmente tiene que tomar las decisiones. Y para poder decidir entre las alternativas hay que comprender qué estamos construyendo.
La IA también se equivoca
Hay además un fenómeno particularmente interesante. La IA puede entregarnos una solución con una seguridad sorprendente. Puede escribir código impecablemente presentado, explicarnos por qué funciona y hasta felicitarnos por la arquitectura que acabamos de elegir. Y puede estar equivocada.
Si quien está del otro lado no tiene conocimientos suficientes para detectar el problema, tendremos una situación bastante peligrosa: código que nadie escribió y que nadie comprende funcionando en producción.
Por eso la capacidad de revisar, cuestionar y probar lo que produce una IA empieza a ser tan importante como antes lo era la capacidad de escribirlo.
Entonces, ¿desaparecerán los programadores?
No lo sé. Y desconfiaría bastante de cualquiera que asegure saber exactamente cómo será nuestra profesión dentro de veinte años. Lo que sí estamos viendo es que está cambiando. Una persona asistida por Inteligencia Artificial puede producir hoy muchísimo más software que hace algunos años. Y de mucha más calidad. Tareas repetitivas pueden automatizarse. Código que antes escribíamos manualmente ahora puede generarse. Problemas que nos llevaban horas pueden resolverse en minutos. Negar semejante transformación sería absurdo. Pero quizás haya que distinguir entre escribir código y construir sistemas.
¿Y el Analista de Sistemas?
Acá aparece la paradoja que más me interesa. Cuanto mejor programa la Inteligencia Artificial, menos tiempo necesitamos dedicar a explicarle a una computadora cómo escribir el código. Pero quizás necesitemos dedicar mucho más tiempo a explicarle qué queremos construir. Entender una organización, escuchar a un usuario, descubrir una necesidad que ni siquiera está correctamente expresada y transformarla en procesos.
Definir reglas de negocio. Incluso hoy en día me encuentro usando una IA para esto y otra para el desarrollo. No me imagino prescindiendo de la IA. El mismo pensamiento lo tuve cuando abandoné el libro de Peter Norton para empezar a buscar ASM en Google.
Elegir tecnologías, diseñar una arquitectura, evaluar riesgos, probar resultados, sin duda que se agiliza con la IA, pero aún debemos ser nosotros los que veamos el bosque. La IA es muy buena identificando cada árbol.
Y finalmente determinar si aquello que construimos realmente resuelve el problema original. Todo eso también es desarrollar software.
Una herramienta extraordinaria
Personalmente no veo a la Inteligencia Artificial como una competidora a la que tengamos que ganarle. De la misma manera que no imagino en mi empresa a un programador sin sus cuentas IA. Sería como si aquel carpintero hubiera decidido competir contra su nueva máquina para demostrar quién podía cortar más rápido una tabla (o mejor). Probablemente perdió antes de empezar. La verdadera oportunidad apareció cuando aprendió a utilizarla. Con la IA quizás ocurra exactamente lo mismo.
No se trata de demostrar que podemos programar mejor que ella. Se trata de aprender a utilizar una herramienta que multiplica extraordinariamente nuestra capacidad para analizar, diseñar y construir. Porque detrás de cada sistema todavía existe una pregunta que alguien debe responder: ¿Qué problema estamos tratando de resolver?
Y al menos por ahora, antes de comenzar a escribir código, sigue siendo una muy buena idea que haya un ser humano capaz de entender la respuesta.
JB