El programador en la era de la IA no desaparece: evoluciona. Esa es la idea central que Ana, ingeniera de AWS con experiencia previa en Amazon, desarrolla al repasar la historia de la programación y proponer cinco características del builder moderno. Si te preguntas si estás estudiando el área correcta, esto es para ti.
¿La IA va a quitarme el trabajo como programador?
La pregunta que muchos nos hacemos es si la IA nos dejará sin empleo, y la respuesta honesta es que tal vez sí, si no cambiamos [00:30]. Pero la pregunta correcta es otra: ¿la IA me vuelve obsoleto? Y ahí la respuesta es más positiva. No te vuelve obsoleto, siempre que evoluciones.
¿La IA reemplazará a los programadores? No a quienes evolucionan. La IA genera código rápido, pero tú decides qué construir, por qué y si lo que produce tiene sentido. Esa responsabilidad no cambió.
Para entender por qué, Ana propone una breve recapitulación histórica, porque los programadores siempre hemos evolucionado junto a nuestras herramientas.
¿Cómo evolucionaron la programación y sus herramientas?
Cada avance generó el mismo miedo: "ahora cualquiera podrá programar". Nunca pasó. La lista de saltos que menciona la clase lo demuestra:
- En los años 50, el assembly exigía conocer las instrucciones de máquina; para escribir "Hola" tenías que indicar en qué espacio de memoria iba cada letra [01:30].
- Luego llegaron los compiladores, que traducían un simple
print "hola" a lenguaje de máquina [02:00].
- En los 60 apareció la programación estructurada, con loops
for, manejo de errores y breaks, para reemplazar los go to [03:00].
- En los 80 surgió la programación orientada a objetos, donde un usuario tenía nombre, email y podía iniciar sesión, definiendo características y comportamiento [03:30].
- Después vino el paso de los monolitos a los microservicios [05:00].
Un dato concreto de su experiencia: hasta fines de los 90 e inicios de los 2000, Amazon era un monolito, una sola aplicación con catálogo, ventas y envíos, donde si algo fallaba, todo fallaba [05:00].
¿Por qué surgió la computación en la nube?
Antes necesitabas comprar servidores físicos, llenar un formulario y esperar semanas o meses, y al llegar quizá ya no era lo que necesitabas [05:30]. La nube cambió eso: hoy haces clic en un botón, obtienes un servidor o base de datos, pagas solo por lo que usas y apagas lo que no [06:00].
Hasta la forma de escribir código evolucionó: del editor de texto simple y la terminal de los 70, al resaltado de sintaxis, autocomplete, IntelliSense y las extensiones de VS Code [07:00]. Ana recorrió Frontpage, Notepad, Dreamweaver, Eclipse e IntelliJ hasta llegar ahí [07:30].
¿Qué es un builder moderno o programador renacentista?
La analogía central es el Renacimiento: personas que conectaban ideas de áreas distintas, eran ingenieras, médicas y artistas a la vez, curiosas, que construían, fallaban y volvían a intentar [09:00]. El builder moderno adopta esa misma mentalidad: trabajar en varias áreas al mismo tiempo. Ana empezó como programadora de backend, pero con Cloud Code, Codex y Kiro ahora escribe frontend, algo que antes le tomaba meses aprender [09:30].
¿Qué es un polímata en programación? Es quien aprende muchos temas distintos. "Poli" significa muchos y "mata", del griego, significa aprender. Como Da Vinci: pintor, médico, ingeniero e inventor, sin ver fronteras entre disciplinas.
El trabajo sigue siendo tuyo, no de la herramienta. La IA puede escribir el código, pero tú decides qué construir y por qué.
¿Cuáles son las 5 características del programador moderno?
Estas son las cinco cualidades que, según la clase, te mantienen relevante y puedes incorporar hoy.
¿Por qué importan la curiosidad y equivocarse?
La curiosidad no es decir "qué genial" y seguir scrolleando, sino profundizar, preguntarte por qué las cosas funcionan y no quedarte con la primera respuesta [10:30]. Cada herramienta que existe nació porque alguien se preguntó: "¿y si esto se pudiera hacer mejor?" [11:30].
Pero la curiosidad no basta: hay que estar dispuesto a fallar. Aquí Ana usa una analogía potente sobre la growth mindset: aprender un idioma es igual, puedes estudiar gramática y ver clases, pero solo aprendes de verdad cuando conversas, cometes errores y alguien te corrige [12:30]. Con el software pasa lo mismo: aprendes construyendo, rompiendo cosas y arreglándolas.
¿Qué significa pensar en sistemas y comunicar mejor?
Pensar en sistemas es ver el panorama completo: un cambio en tu base de datos afecta a los servicios que la usan, y cada API o cola es parte de algo mayor [13:30]. Antes de escribir, pregúntate: ¿qué depende de esto?, ¿qué se rompe si cambio algo?
La comunicación cobra un peso nuevo. El lenguaje natural es ambiguo, y ahora la interacción humano-máquina también lo es [15:00]. La calidad de lo que escribes define la calidad de lo que recibes. En AWS trabajan con tres formas de reducir esa ambigüedad:
- El desarrollo por especificaciones: escribir con detalle qué funcionalidad quieres, no solo "agrega autenticación", sino con qué campos y niveles de autorización [16:00].
- El razonamiento automatizado, que verifica matemáticamente que tu código hace lo que dice [16:30].
- Los tests automatizados, para validar que lo generado es correcto.
Si no puedes explicar lo que quieres, la IA tampoco podrá generarlo.
¿Por qué el ownership sigue siendo tuyo?
El sentido de propiedad, o ownership como dicen en Amazon, significa ser responsable de la calidad de tu software [17:00]. Aquí aparece el problema real: generar código es mucho más rápido que revisarlo [17:30]. No pongas en producción lo que no entiendes.
Como dice Ana: no dejes que tus amigos revisen basura generada por IA. La primera línea de revisión eres tú [18:00]. En Amazon, además, eres quien está de plantón: si algo falla a las tres de la mañana, es tu problema.
¿Cómo expandir tu T con la IA?
El polímata se logra de dos formas. La "I" latina es profundidad y especialización en un área [19:30]. La forma de T suma a esa profundidad una comprensión amplia y superficial de las demás áreas y de cómo tu especialidad las afecta [20:00].
La invitación es usar la IA para ampliar tu T: si eres de backend, pídele que genere el frontend y haz preguntas para entender el porqué. La barrera para expandir tu T nunca fue tan baja.
El programador en la era de la IA no delega su trabajo y se va a descansar: usa la IA para aprender, como un compañero de equipo paciente que no se cansa de tus preguntas [22:00]. ¿Qué proyecto personal te gustaría sacar del papel este fin de semana? Cuéntalo en los comentarios.
