Cómo cambia la carrera de software con LLM

Si trabajas en software, ya lo notaste: una parte del trabajo que antes te tomaba horas ahora se resuelve en minutos con un LLM. No hablamos solo de escribir funciones simples. También están entrando en revisión de código, generación de tests, documentación, refactors pequeños y hasta en la exploración inicial de bugs. Eso cambia la carrera, pero no la borra. Cambia qué tareas valen más y cuáles se vuelven más baratas.

La pregunta útil no es si los LLM van a “reemplazar a los developers”. La pregunta real es qué parte de tu trabajo ya está siendo absorbida, qué parte sigue requiriendo criterio humano y cómo te posicionas para no quedarte en la capa más automatizable. Si estás en LatAm, además, esto pega con una realidad concreta: equipos más chicos, más presión por entregar y menos tolerancia a perfiles que solo saben teclear tickets sin entender el sistema completo.

Qué tareas ya están absorbiendo los LLM

Los LLM ya son buenos en tareas con contexto acotado, patrones repetidos y validación rápida. Ahí es donde más están erosionando trabajo de ingeniería. No porque “piensen” mejor que tú, sino porque pueden producir una primera versión aceptable en segundos y porque muchas tareas de software se parecen mucho entre sí.

Un ejemplo simple: crear un endpoint CRUD con validaciones básicas, tests unitarios y un DTO. Hace dos años eso podía tomarte una mañana si estabas saltando entre documentación, ejemplos y tu propia memoria. Hoy puedes pedirle al modelo un borrador, ajustar nombres, revisar edge cases y tener algo funcional en menos de una hora. Lo mismo pasa con scripts de migración, transformaciones de datos, regex complejas, snippets de SQL y tests de borde.

Tareas donde el impacto ya se nota

Hay varias tareas que ya muestran una caída clara en el valor marginal de escribirlas a mano:

• Boilerplate de APIs y componentes UI.
• Tests unitarios básicos para casos obvios.
• Resúmenes de logs y trazas.
• Documentación inicial de funciones y módulos.
• Refactors mecánicos, como renombrar variables o mover lógica repetida.
• Traducción entre lenguajes o frameworks parecidos.

No significa que el LLM lo haga perfecto. Significa que el costo de producir un primer borrador bajó tanto que tu ventaja ya no está en escribir rápido desde cero. Tu ventaja está en saber qué pedir, qué corregir y qué no aceptar.

También hay una capa menos obvia: el trabajo de exploración. Antes, cuando no sabías cómo abordar una integración, tenías que leer docs, probar y fallar varias veces. Ahora un LLM puede darte un mapa inicial. Eso reduce el tiempo de ramp-up en tareas nuevas, y por eso equipos enteros están moviendo parte del descubrimiento técnico hacia la IA.

Lo que dicen los datos y la práctica

No hace falta exagerar para ver el cambio. GitHub publicó que los desarrolladores que usan Copilot completan una tarea de programación de referencia hasta 55% más rápido en ciertos experimentos internos, según su documentación y estudios asociados. Puedes revisarlo en la documentación oficial de GitHub Copilot: https://docs.github.com/en/copilot

Ese dato no significa que todo el trabajo sea 55% más rápido. Significa que, en tareas bien acotadas, la asistencia ya mueve la aguja. En la práctica, eso se traduce en menos tiempo escribiendo código repetitivo y más tiempo revisando decisiones, integrando piezas y resolviendo ambigüedad.

Otro cambio visible es la forma en que se hacen PRs. Antes un junior podía pasar bastante tiempo armando una solución completa. Ahora muchas veces llega con una propuesta generada por IA, y el valor real está en la calidad de la revisión, no en la cantidad de líneas escritas. Eso presiona a quienes solo aportaban velocidad manual.

Qué partes del trabajo siguen siendo diferenciales

Aquí está la parte que de verdad importa: los LLM son muy buenos en producir texto de software, pero no son buenos en asumir responsabilidad por un sistema real. No conocen tus restricciones de negocio, tus incidentes pasados, tus deudas técnicas ni el costo de equivocarte en producción. Ahí sigue tu ventaja.

Tu valor no está en escribir más código. Está en entender qué código debe existir, por qué existe y qué riesgo trae. Si una decisión técnica afecta pagos, autenticación, performance o privacidad, el problema no es generar la función. El problema es decidir el contrato, el borde de error, la estrategia de despliegue y el plan de rollback.

Criterio técnico y contexto de negocio

Los LLM pueden sugerir una solución plausible, pero no pueden priorizar bien sin contexto. Tú sí puedes hacerlo si entiendes el producto. Por ejemplo, no es lo mismo optimizar una pantalla interna usada por 20 personas que una API de checkout que procesa miles de transacciones al día. En el primer caso toleras una solución más simple. En el segundo, un error pequeño cuesta dinero y soporte.

Eso vuelve más valiosa la habilidad de traducir necesidades de negocio a decisiones técnicas. Si sabes preguntar bien, proponer trade-offs y detectar riesgos antes de escribir código, te vuelves mucho más difícil de reemplazar que alguien que solo entrega tickets.

Arquitectura, integración y responsabilidad

Un LLM puede ayudarte a escribir una clase o una función. No puede hacerse cargo de una arquitectura completa en producción. No entiende por sí solo cómo conviven observabilidad, colas, cachés, límites de tasa, permisos, costos de infraestructura y mantenimiento a largo plazo.

En sistemas reales, gran parte del trabajo está en integrar piezas que no fueron pensadas juntas. Ahí aparecen problemas como consistencia eventual, contratos rotos, timeouts, retries duplicados y degradación gradual. Ese tipo de decisiones requiere experiencia, no solo generación de código.

Cómo cambia tu perfil si usas LLM bien

Si usas LLM como apoyo, tu trabajo se mueve hacia arriba en la cadena de valor. Pasas menos tiempo en ejecución mecánica y más tiempo en diseño, validación y coordinación. Eso no te hace menos técnico. Te hace más responsable de la calidad del resultado final.

La diferencia entre un perfil fuerte y uno débil ya no está tanto en memorizar sintaxis. Está en formular buenas restricciones, detectar errores sutiles y revisar código con criterio. Un developer que sabe usar LLM para acelerar sin perder rigor puede producir más, pero también puede caer en una trampa: aceptar código que “parece correcto” pero falla en casos reales.

Qué cambia en tu día a día

En la práctica, tu rutina puede verse así:

1. Definir el problema con más precisión antes de abrir el editor.
2. Pedirle al LLM una propuesta inicial con restricciones claras.
3. Revisar la solución contra requisitos reales, no contra una respuesta bonita.
4. Escribir tests para los casos que el modelo no cubre bien.
5. Validar performance, seguridad y observabilidad antes de mergear.

Ese flujo no te quita trabajo. Te cambia el tipo de trabajo. Menos tipeo, más juicio.

Qué habilidades empiezan a pesar más

Si quieres seguir siendo valioso, estas habilidades suben de peso:

• Lectura de sistemas y debugging en producción.
• Diseño de APIs y contratos estables.
• Testing de integración y end-to-end.
• Observabilidad: logs, métricas y tracing.
• Seguridad básica: auth, secrets, permisos, input validation.
• Comunicación técnica con producto, QA y soporte.
• Capacidad de descomponer problemas ambiguos.

No necesitas dominar todo a nivel experto mañana. Pero sí conviene reconocer que el mercado está premiando más a quien resuelve problemas completos que a quien solo escribe funciones aisladas.

Qué hacer para no quedar relegado

La mejor respuesta no es pelearte con los LLM ni usarlos para todo sin filtro. Es construir una estrategia de trabajo donde la IA acelera lo repetitivo y tú concentras energía en decisiones, revisión y dominio del sistema. Si te quedas solo en “usar ChatGPT para programar”, corres el riesgo de volverte intercambiable.

Piensa en tu carrera como una mezcla de velocidad, criterio y contexto. Los LLM elevan la velocidad de casi todos. Entonces tu diferencial tiene que crecer en criterio y contexto. Eso aplica tanto si trabajas en una startup en Quito como si colaboras remoto para una empresa en México, Chile o Estados Unidos.

Plan práctico de 30 días

Puedes empezar con algo concreto:

• Semana 1: identifica 5 tareas repetitivas que haces todas las semanas y prueba automatizarlas con LLM.
• Semana 2: toma un módulo real y pide al modelo una refactorización con tests, luego compara con tu propia solución.
• Semana 3: revisa un incidente pasado y usa LLM para resumir causa raíz, pero valida cada paso con logs y métricas reales.
• Semana 4: mejora una habilidad de alto valor, como debugging, diseño de APIs o observabilidad.

Si haces esto con disciplina, vas a notar rápido dónde la IA te ahorra tiempo y dónde todavía necesitas criterio humano.

Cómo usar LLM sin perder nivel

Hay una forma sana de usarlos: como copiloto, no como piloto automático. Eso implica que tú sigues siendo responsable de la arquitectura, del comportamiento en producción y de la calidad del código.

Un buen hábito es pedir siempre tres cosas al modelo: una solución, los riesgos y los casos borde. Si solo te da código, te falta contexto. Si te da explicación pero no pruebas, también te falta algo. La calidad de tu revisión es lo que protege tu carrera.

Lo que sí conviene aprender ahora

Hay habilidades que no dependen de una moda puntual. Si las refuerzas, te vuelves más resistente a cualquier ola de automatización. No importa si mañana el LLM de turno se llama Claude, GPT o algo distinto. El patrón se repite: se automatiza lo repetible y se valora más el juicio.

Habilidades técnicas con mayor retorno

1. Debugging serio: saber seguir una falla desde el síntoma hasta la causa raíz.
2. Testing útil: no solo unit tests, también integración y contract tests.
3. Diseño de sistemas: entender colas, cachés, consistencia y escalabilidad.
4. SQL y datos: muchos equipos siguen dependiendo de consultas bien hechas.
5. Seguridad básica: auth, autorización, secrets y validación de inputs.
6. Observabilidad: saber leer métricas, logs y traces para decidir rápido.

La razón es simple: estas habilidades conectan el código con la realidad. Y la realidad sigue siendo más complicada que el texto que genera un modelo.

Habilidades humanas que siguen pesando

También hay habilidades menos glamorosas pero muy rentables:

• Hacer buenas preguntas.
• Negociar alcance.
• Explicar trade-offs sin humo.
• Coordinar con producto, QA y soporte.
• Priorizar deuda técnica con criterio.

En equipos pequeños, estas habilidades suelen marcar más diferencia que saber la última sintaxis del framework de moda. En equipos grandes, además, te ayudan a moverte entre áreas y a no quedar atrapado en una tarea fácil de automatizar.

Tabla resumen

La carrera de software no está desapareciendo. Está cambiando de forma. Si antes tu valor estaba muy atado a escribir código rápido, ahora tu valor depende más de entender sistemas, validar decisiones y resolver problemas que no caben en un prompt corto. Esa es la parte que todavía no se puede delegar por completo.

Si hoy te sientes erosionado por los LLM, no significa que tu carrera esté acabada. Significa que una parte de tu trabajo dejó de ser diferencial. La salida no es resistirte al cambio. La salida es mover tu perfil hacia donde todavía hay escasez: criterio, integración, debugging, negocio y responsabilidad.