Volver al blog

¿Qué significa ser programador cuando la IA escribe código?

El rol del programador no se termina cuando una IA puede escribir código. Cambia hacia el criterio, los fundamentos, la responsabilidad y la experiencia que se gana al poner decisiones a prueba.

Hay una pregunta que me viene acompañando cada vez que trabajo con un agente de IA: si puede escribir en minutos algo que antes me llevaba una tarde, ¿qué significa ahora ser programador?

No me parece una pregunta cómoda. Tampoco creo que se responda diciendo que «la IA es solo una herramienta», como si no hubiera cambiado nada. Cambió mucho. A veces le describo una tarea, vuelvo con un café y ya tengo una propuesta de implementación, pruebas y una explicación de lo que hizo. Sería absurdo fingir que escribir código ocupa el mismo lugar de antes.

Pero cuando miro esa propuesta todavía tengo que decidir si entendió el problema, si el cambio encaja con el sistema y si estoy dispuesto a responder por él. Ahí empieza, para mí, la parte más interesante del oficio.

El trabajo empieza antes del código

Imaginá que alguien pide: «Necesitamos que el usuario pueda cambiar su correo». Parece una tarea pequeña. Hasta que aparecen las preguntas: ¿hay que verificar la dirección nueva?, ¿qué pasa con una sesión abierta?, ¿cómo se avisa al correo anterior?, ¿qué ocurre si otra persona intenta tomar la cuenta?

Una IA puede proponer una solución enseguida. Si yo no aclaro esas condiciones, también puede completar los vacíos con supuestos perfectamente razonables... y equivocados para este producto.

Programar siempre incluyó entender qué se está intentando resolver. Ahora ese trabajo se ve más, porque la implementación puede llegar antes de que hayamos terminado de pensar. Expresar bien un problema no es encontrar un prompt mágico. Es hablar con las personas involucradas, reconocer restricciones y acordar qué tendría que pasar para considerar que el cambio funciona.

Entender sigue siendo una habilidad práctica

Si el código aparece tan rápido, puede tentar la idea de que ya no hace falta aprender cómo funciona. A mí me pasa lo contrario: cuanto más delego, más necesito fundamentos para revisar.

Necesito poder seguir un dato de un extremo al otro, entender qué hace una consulta, reconocer una condición que falla en un caso límite y distinguir una prueba útil de otra que solo confirma el camino feliz. No para escribir cada línea por orgullo, sino para saber qué estoy aceptando.

El problema más difícil de detectar no suele ser una respuesta disparatada. Es una respuesta casi correcta. En la encuesta de desarrolladores de Stack Overflow de 2025, muchos participantes señalaron justamente la frustración de recibir soluciones que parecen acertadas pero requieren correcciones. No es una medida de todos los equipos, pero sí una experiencia que reconozco: lo prolijo puede darnos una falsa sensación de seguridad.

Por eso aprender estructuras de datos, redes, bases de datos, pruebas o diseño de sistemas no se volvió una ceremonia antigua. Es lo que permite hacer buenas preguntas cuando la pantalla ya está llena de respuestas.

El criterio aparece cuando hay que elegir

Un agente puede ofrecer tres maneras de resolver el mismo pedido. Una es rápida y deja deuda técnica. Otra es más general, pero agrega complejidad que quizá nunca necesitemos. La tercera toca menos piezas, aunque obliga a aceptar una limitación.

¿Cuál es la correcta? Depende del producto, del equipo, del tiempo disponible y del costo de equivocarnos. No hay un modelo que conozca automáticamente todas esas prioridades.

Ahí entiendo el criterio no como una intuición misteriosa, sino como la capacidad de relacionar una decisión técnica con sus consecuencias. A veces la mejor solución es la más simple. A veces conviene detenerse y diseñar algo más sólido. A veces hay que decir que todavía no entendimos el problema y no escribir nada.

La IA nos da más opciones y las entrega más rápido. Eso hace que elegir bien importe más, no menos.

La responsabilidad no se delega con el teclado

Cuando algo falla en producción, poco consuelo ofrece decir que «lo hizo el agente». Alguien aprobó el cambio, decidió cómo probarlo y lo puso frente a personas reales.

No significa que una persona deba cargar sola con todo: los sistemas son trabajo de equipos y organizaciones. Significa que usar IA no borra nuestra obligación de establecer límites, revisar riesgos, observar lo que pasa después del despliegue y corregir cuando nos equivocamos.

El informe DORA de 2025 describe a la IA como un amplificador de las fortalezas y debilidades de una organización. Me parece una imagen útil. Un equipo que entiende lo que construye puede acelerar; uno que no revisa sus decisiones también puede acelerar, pero hacia problemas más grandes.

La experiencia se gana mirando qué pasó después

Durante mucho tiempo asociamos experiencia con años programando o con haber escrito miles de líneas. Esas cosas pueden ayudar, pero no alcanzan. Para mí, la experiencia aparece cuando tomás una decisión, ves cómo se comporta en el mundo real y ajustás lo que creías saber.

Eso no desaparece con la IA. Cambia el recorrido. Puedo formular una hipótesis, pedirle a un agente una implementación, revisarla, probarla y observar cómo responde el sistema. Si me salteo la revisión y la observación, termino produciendo más sin necesariamente aprender más.

Pienso especialmente en quienes recién empiezan. No necesitan escribir todo a mano para demostrar que son «programadores de verdad». Pero sí necesitan oportunidades para investigar un error, defender una decisión, equivocarse con apoyo y entender por qué una solución que parecía buena no lo era. Si automatizamos también esas oportunidades, después nos vamos a preguntar de dónde saldrá el criterio de los próximos años.

Tampoco creo que el destino de cada programador sea convertirse en «gerente de agentes». Habrá momentos para delegar una tarea completa y otros para abrir el editor, explorar una idea o escribir una pieza crítica por cuenta propia. Saber elegir entre esas formas de trabajar también es parte del oficio.

Quizá ser programador con IA se parezca menos a producir instrucciones y más a sostener una conversación seria con la realidad: entender un problema, construir una respuesta, comprobarla y hacerse cargo del resultado. La herramienta puede escribir cada vez más. El criterio, los fundamentos, la responsabilidad y la experiencia siguen siendo algo que tenemos que cultivar nosotros.

Hablé de esta pregunta también en el video del canal. Me interesa saber cómo la estás viviendo vos: ¿qué parte de tu trabajo cambió más desde que empezaste a programar con IA?