Cómo la IA está cambiando la carrera dev

La pregunta de fondo no es si los LLMs escriben código. Eso ya lo viste. La pregunta real es otra: qué pasa con tu carrera cuando una parte de las tareas que antes justificaban tu puesto ahora se resuelven en minutos con una herramienta que cualquiera puede abrir en el navegador.

Ese cambio no afecta solo a la velocidad. También mueve la barra de lo que se espera de ti, cambia cómo te evalúan y, en algunos equipos, reduce el espacio para aprender haciendo. Si trabajas en software, probablemente ya notaste alguna de estas señales: tickets más chicos, más presión por entregar, menos paciencia para PRs largos y más preguntas del tipo “¿por qué no le pediste esto al modelo primero?”.

Qué está cambiando de verdad

Los LLMs no eliminaron el trabajo de ingeniería de software. Lo que hicieron fue desarmar varias tareas en piezas más pequeñas y más baratas. Antes, una persona junior podía pasar medio día armando un CRUD simple, buscando sintaxis, copiando patrones y corrigiendo errores básicos. Hoy, un modelo puede generar un primer borrador en segundos. Eso no significa que el problema esté resuelto, pero sí que el punto de entrada cambió.

En la práctica, el cambio más visible está en tres frentes: prototipado, escritura repetitiva y exploración. Un ejemplo simple: si antes tardabas 40 minutos en montar una función de validación con tests básicos, ahora puedes pedirle al modelo un esqueleto en 30 segundos y dedicar esos 40 minutos a revisar edge cases, arquitectura o integración con el resto del sistema. El tiempo no desaparece, se mueve.

De escribir código a dirigir trabajo

La habilidad valiosa ya no es solo “sé escribir esta función”. Cada vez pesa más “sé definir bien el problema, pedir una solución útil, revisar la salida y corregirla”. Eso suena más abstracto, pero en la práctica significa que tu valor se parece más al de una persona que coordina y valida que al de alguien que mecanografía más rápido.

Esto no afecta igual a todos. Si trabajas en una startup pequeña, puede que ya estés usando LLMs para cubrir huecos de documentación, soporte interno y tareas de mantenimiento. Si estás en una empresa grande, probablemente el cambio llegue más lento, pero igual llega: PRs asistidos, generación de tests, búsqueda semántica en repositorios y asistentes conectados a Jira o GitHub.

Qué tareas están bajo presión

Hay trabajos que el modelo hace suficientemente bien como para quitarles peso económico o de tiempo. Entre los más afectados están:

• boilerplate de componentes y endpoints
• tests unitarios básicos
• documentación inicial
• refactors mecánicos
• traducción de snippets entre lenguajes
• resúmenes de issues y PRs

No significa que esas tareas desaparezcan. Significa que el listón subió. Si antes entregar un endpoint funcional era suficiente para demostrar progreso, ahora te van a pedir que también expliques por qué esa solución es la correcta, cómo la probaste y qué riesgos quedan abiertos.

El impacto en tu carrera junior, mid y senior

La conversación cambia mucho según tu nivel. Si estás empezando, el problema no es solo que el modelo escriba código. El problema es que te puede quitar las repeticiones que antes te ayudaban a aprender. Si todo lo que haces es aceptar sugerencias sin entenderlas, avanzas en velocidad pero no en criterio.

Si estás en un nivel intermedio, la presión suele venir por productividad. Ya no basta con “hacer bien tu parte”. Ahora se espera que uses la IA para producir más, con menos fricción y con menos errores. Eso puede ser útil, pero también te empuja a convertirte en operador de herramientas en vez de ingeniero que toma decisiones.

Si ya eres senior, el riesgo es otro: que tu rol se vuelva demasiado difuso. Muchas empresas empiezan a asumir que, como la IA acelera la implementación, entonces el trabajo senior consiste solo en revisar resultados. Pero un buen senior no solo revisa. Define estándares, diseña sistemas, reduce riesgos y ayuda a otros a crecer. Esas tareas no se automatizan tan fácil.

El efecto en el aprendizaje

Hay una diferencia grande entre usar un LLM para desbloquearte y usarlo para saltarte el aprendizaje. Si tú le pides a la herramienta que te resuelva todo, puedes terminar con entregables aceptables y una comprensión pobre. Eso hoy puede pasar desapercibido. En seis meses, cuando tengas que depurar algo raro en producción, se nota.

Un ejemplo realista: una persona junior usa IA para generar tests de una API. Los tests pasan, el PR entra y el equipo sigue. Pero nadie revisó que los casos de error no cubren timeouts reales ni respuestas parciales. El día que el sistema falle en producción, la persona que aceptó el output sin entenderlo no va a saber dónde mirar.

Cómo usar LLMs sin perder criterio

La salida no es prohibirlos. Tampoco es delegarles todo. La salida práctica es aprender a usarlos como una herramienta de aceleración, no como reemplazo de pensamiento. Si haces eso, puedes ganar tiempo sin vaciar tu criterio técnico.

Una forma simple de ordenar esto es separar el trabajo en tres capas: definición, generación y validación. La IA puede ayudar en la segunda. Tú no deberías soltar la primera ni la tercera. Ahí está buena parte de tu valor profesional.

Un flujo de trabajo que sí sirve

Un flujo útil podría verse así:

1. defines el problema con restricciones claras
2. pides una propuesta inicial al modelo
3. comparas la propuesta con tu contexto real
4. ajustas arquitectura, nombres y trade-offs
5. escribes o corriges tests tú mismo
6. revisas seguridad, performance y mantenibilidad
7. documentas la decisión final

Ese orden importa. Si empiezas por “hazme esto” sin contexto, el modelo te devuelve algo plausible pero genérico. Si le das límites concretos, por ejemplo “usa TypeScript, no agregues dependencias nuevas, cubre errores 4xx y 5xx, y mantén la API actual”, la calidad mejora bastante.

Qué conviene automatizar y qué no

Hay cosas que sí tiene sentido delegar:

• generación de borradores de tests
• resúmenes de PRs largos
• ejemplos de uso para documentación
• refactors repetitivos
• scripts pequeños de migración

Y hay cosas que conviene mantener muy cerca de ti:

• decisiones de arquitectura
• manejo de datos sensibles
• lógica de negocio con impacto económico
• cambios que afectan observabilidad o seguridad
• cualquier cosa que, si falla, cueste horas de incidente

La clave no es la tarea en sí, sino el costo del error. Si el costo de equivocarte es bajo, usa IA para ir más rápido. Si el costo es alto, úsala como apoyo, no como piloto.

Qué pide el mercado ahora

Muchas ofertas ya no dicen explícitamente “experiencia con LLMs” como requisito duro, pero sí cambió el subtexto. Se espera que sepas moverte con herramientas asistidas, que reduzcas tiempo muerto y que conviertas una idea en algo visible más rápido. Eso afecta desde entrevistas hasta performance reviews.

También cambió el criterio de productividad. Antes te medían por líneas de código o por cantidad de tickets cerrados. Eso ya era un mal indicador, pero ahora es peor porque la IA infla esos números sin decir mucho sobre calidad. Un equipo puede cerrar más tickets y aun así dejar más deuda técnica.

Tabla de impacto por perfil

En mercados como Ecuador y otros países de Latinoamérica, además, hay una realidad concreta: muchas empresas quieren más output con menos contratación. La IA encaja perfecto en ese discurso. Por eso conviene que tú no te presentes solo como alguien que “usa ChatGPT”, sino como alguien que sabe cuándo la herramienta ayuda y cuándo mete ruido.

Cómo te vuelves más difícil de reemplazar

No se trata de hacerte “más humano” en abstracto. Se trata de fortalecer habilidades que la IA no cubre bien o cubre de forma incompleta:

• entender contexto de negocio
• negociar alcance con producto
• detectar riesgos antes de que exploten
• escribir buen código con estándares claros
• comunicar decisiones técnicas con números y trade-offs

Si puedes explicar por qué una solución reduce incidentes un 20%, o por qué evita dos horas de soporte por semana, tu valor deja de depender de cuántas líneas escribiste.

Qué puedes hacer desde esta semana

No hace falta rehacer toda tu carrera en una tarde. Sí conviene ajustar hábitos. La diferencia entre quedar atrapado y adaptarte suele estar en pequeñas prácticas repetidas.

Empieza por medir tu trabajo real. Durante una semana, anota cuántas horas pasas en tareas repetitivas, cuántas en diseño, cuántas en debugging y cuántas en comunicación. Si ves que el 40% de tu tiempo se va en tareas mecánicas, ahí tienes un buen candidato para usar IA sin culpa.

Luego, revisa cómo estás aprendiendo. Si cada vez que el modelo te da una respuesta tú la pegas sin entenderla, estás ahorrando minutos y perdiendo criterio. Si en cambio la usas para comparar enfoques, encontrar casos borde y acelerar la primera versión, estás construyendo músculo técnico.

1. Elige una tarea repetitiva por semana y automatízala con IA.
2. Oblígate a leer y explicar la salida antes de usarla.
3. Mide cuánto tiempo ahorras de verdad, no cuánto parece que ahorras.
4. Revisa al final del mes qué aprendiste que antes no sabías.
5. Comparte el flujo con tu equipo para evitar usos inconsistentes.

También ayuda definir reglas claras dentro del equipo. Por ejemplo, puedes acordar que toda sugerencia generada por IA debe pasar por revisión humana, que ningún cambio de seguridad se acepta sin tests y que los prompts usados en decisiones sensibles quedan documentados. Eso baja el caos y evita que la adopción dependa del entusiasmo de una sola persona.

Tabla resumen

Si quieres profundizar en cómo construir hábitos sanos alrededor de estas herramientas, la documentación oficial de OpenAI sobre prompting y buenas prácticas es un punto de partida útil: https://platform.openai.com/docs/guides/prompting. También vale la pena revisar la documentación de Anthropic sobre uso de Claude para trabajo técnico: https://docs.anthropic.com/.

La parte incómoda de todo esto es que la carrera dev ya no se parece tanto a “aprender un stack y repetirlo durante años”. Ahora se parece más a aprender a trabajar con una capa nueva de automatización que cambia cada pocos meses. Eso puede sentirse como pérdida de terreno, pero también abre espacio para quienes sepan combinar velocidad con criterio.

No necesitas competir con el modelo escribiendo más rápido que él. Necesitas hacer mejor lo que él no hace bien: entender contexto, tomar decisiones, detectar fallos y construir sistemas que no se rompan cuando el entusiasmo inicial se apaga.