¿Todavía hay que aprender a programar, con la IA escribiendo código?

Hace una década la respuesta a "¿debería aprender a programar?" era casi siempre sí, sin matices — el argumento era que el código iba a estar en todas partes y quien no lo entendiera quedaría afuera. Una IA hoy escribe una función correcta más rápido que la mayoría de las personas, así que ese argumento, tal como se planteaba entonces, ya no sostiene. Pero la pregunta que reemplaza a esa no es "¿para qué molestarse?" — es más específica, y la respuesta depende de quién la hace.

Lo que la IA sí resuelve

Escribir código a partir de una especificación clara es, en buena parte, un problema resuelto. Una función que convierte un formato de fecha, un endpoint CRUD estándar, una consulta que cruza dos tablas — eso se genera en segundos y, la mayoría de las veces, funciona. Si "programar" significara solo eso, la pregunta del título tendría una respuesta corta.

No significa solo eso.

Lo que sigue sin resolverse

• Decidir qué construir. La IA no sabe si el problema real del negocio es el que se le describió, o si el problema real es otro y nadie lo formuló bien todavía.
• Evaluar si el código generado es razonable. Sin saber leer código, no hay forma de notar que la solución propuesta es frágil, que abre un hueco de seguridad, o que resuelve el caso general y rompe con el 10% de los casos reales — que suelen ser los que importan.
• Depurar cuando algo falla en producción, con datos reales y sin el contexto ordenado de un ejemplo. Ahí es donde entender qué está pasando por dentro del sistema deja de ser opcional.
• Conectar piezas que ya existen. La mayoría del software real no se escribe desde cero: se integra con un sistema de pagos, una base de datos existente, un ERP, una API de terceros con su propia documentación imperfecta. Ese trabajo de integración es donde vive el criterio, no la sintaxis.

Entonces, ¿quién sí necesita aprender a programar?

No todo el mundo, y esa es la diferencia real con la respuesta de hace diez años.

Quien va a dirigir, evaluar o depender de un sistema técnico — un dueño de negocio con un producto digital, alguien que va a contratar desarrollo, un gerente que decide sobre tecnología sin ser el que construye — necesita entender lo suficiente para leer y cuestionar, no necesariamente para escribir producción. Sirve para hacer las preguntas correctas y para notar cuando una respuesta no cierra.

Quien va a construir software como oficio sigue necesitando la base completa: estructuras de datos, cómo se comporta un sistema bajo carga, por qué una decisión de arquitectura de hoy cuesta cara en tres años. La IA acelera la escritura del código; no reemplaza entender por qué una solución es mejor que otra, y esa comparación es la que un desarrollador con criterio hace todo el tiempo, generalmente sin notarlo.

Quien no va a tocar código nunca — y son la mayoría de las personas en la mayoría de los negocios — no necesita programar. Necesita alfabetización digital: entender qué es una base de datos, qué implica compartir un archivo con permisos abiertos, por qué "el sistema se cayó" tiene una causa y no es un evento aleatorio. Eso es un curso de un fin de semana, no una carrera.

Lo que cambia para quien está aprendiendo ahora

Aprender a programar en 2026 con una IA al lado tiene un riesgo puntual: es posible producir código que funciona sin entender por qué funciona, y esa deuda se cobra la primera vez que hay que modificarlo o que falla de una forma que el ejemplo no cubría. La forma de evitarlo no es ignorar la herramienta — es usarla después de poder resolver el problema sin ella, no en vez de aprender a resolverlo.

Nuestro enfoque

En id3a usamos IA para escribir código todos los días — sería raro no hacerlo. Lo que no delegamos es la parte que importa: qué se construye, por qué de esa forma, y qué pasa cuando algo sale distinto a lo esperado. Esa parte sigue siendo trabajo de personas que entienden el sistema completo, no solo la función que acaban de generar.

Conversemos sobre tu próximo proyecto