Hace un año la pregunta era si ibas a usar IA para programar. Hoy la pregunta que importa es otra: ¿en qué parte de tu día la estás dejando decidir por vos sin darte cuenta? Ahí es donde un dev senior se diferencia de alguien que recién empieza: no en cuánto código genera con Copilot, sino en cuándo decide no usarlo.
La conversación pública sobre IA en desarrollo quedó estancada en dos bandos: los que dicen que reemplaza programadores y los que dicen que es magia que te hace diez veces más productivo. Ninguno de los dos describe lo que pasa en tu día a día real: la IA te ahorra tiempo en cosas puntuales, te hace más lento en otras que ni notás, y en algunas te mete errores que vas a pagar tres sprints después.
Dónde la IA te hace ganar tiempo de verdad
Hay usos donde el ahorro es real y medible. Boilerplate, tests unitarios sobre código que ya existe, documentación de funciones que no cambian seguido, traducir un error críptico de un stack trace a algo entendible, o escribir la primera versión de un script de migración que después vas a revisar línea por línea. En todo esto, la IA hace en tres minutos lo que a vos te tomaría veinte, y el riesgo de que la respuesta esté mal es bajo porque el contexto es acotado.
El patrón común en estos casos es que el problema está bien definido y el costo de un error es fácil de detectar. Si el test que generó la IA no compila, lo ves al toque. Si la documentación quedó mal, un reviewer lo nota en la primera pasada. El riesgo es chico porque hay una red de seguridad cerca.
Dónde te está costando más de lo que pensás
El problema aparece en las decisiones de diseño: elegir entre dos formas de estructurar un servicio, decidir si un dato va en Postgres o en Redis, definir el contrato de una API que van a consumir tres equipos distintos. Ahí la IA te va a dar una respuesta con la misma confianza que te da un fix de un typo, aunque no tenga ni idea del contexto real de tu sistema: cuánto tráfico maneja, qué restricciones tiene tu cliente, qué deuda técnica ya existe. La respuesta suena sólida. El problema es que suena sólida incluso cuando está mal.
Un caso concreto: le pedís a un asistente de IA que te sugiera cómo paginar un endpoint que devuelve resultados de búsqueda. Te va a proponer offset y limit, que es la respuesta de manual. Pero si tu tabla tiene millones de filas y usuarios que buscan en tiempo real, esa paginación te va a generar queries cada vez más lentas a medida que el usuario avanza de página, y eso solo lo sabés vos, porque conocés el volumen real de datos y el patrón de uso. La IA no tiene ese contexto salvo que se lo des, y aun dándoselo, no siempre lo prioriza bien.
El costo que nadie factura: perder la fricción que te hace pensar
Hay una parte más difícil de medir que el tiempo ahorrado o los bugs introducidos: la fricción productiva que perdés. Cuando escribís código a mano y te trabás, ese trabarte es información: te dice que el problema es más complejo de lo que pensabas, o que tu diseño tiene un supuesto raro. Cuando la IA te resuelve el bloqueo antes de que termines de sentirlo, te salteás esa señal. Con el tiempo, eso se traduce en menos intuición para detectar cuándo un problema huele mal, porque dejaste de pasar por el momento incómodo donde esa intuición se construye.
Esto no es un argumento para dejar de usar IA. Es un argumento para ser deliberado sobre cuándo la dejás resolver algo por vos y cuándo elegís pelearte con el problema aunque tengas la solución a un prompt de distancia. Un senior que vale la pena contratar sabe distinguir esos dos momentos. Uno que no, termina dependiendo de la herramienta para razonar sobre problemas que hace dos años resolvía solo.
Cómo lo estoy usando yo, y por qué eso importa más que cualquier reporte
Los reportes de GitHub o JetBrains sirven para ver la tendencia general, pero tu caso es el único dato que realmente te sirve para decidir cómo trabajar. Probá esto durante dos semanas: anotá, tarea por tarea, si usaste IA y cuánto tiempo te tomó completarla comparado con la última vez que hiciste algo similar sin ayuda. No hace falta una planilla elaborada, alcanza con una nota rápida en tu task tracker. Vas a encontrar patrones que ningún reporte de la industria te va a poder dar: capaz que la IA te ahorra media hora en debugging pero te frena cuando estás diseñando, o al revés.
El punto real
La IA no te vuelve mejor developer por usarla más. Te vuelve mejor developer si la usás con criterio: sabiendo en qué tareas confiarle la primera versión, en cuáles pelearte vos con el problema a propósito, y en cuáles simplemente no la vas a usar porque el contexto que necesitás no cabe en un prompt. Esa distinción, y no la cantidad de líneas que generás por día, es lo que un buen tech lead nota cuando revisa tu trabajo.
