Los LLM están erosionando mi carrera en ingeniería de software y no sé qué hacer

Percibida erosión de las carreras de software

• Muchos ingenieros senior sienten que ventajas fundamentales —habilidad para depurar, experiencia en el dominio, calidad del código— se están comoditizando, ya que los LLM ahora pueden resolver errores de una sola vez, escribir documentos de diseño y generar prototipos funcionales.
• Algunos informan presión de la dirección para “usar más IA” y medir la productividad por tokens, líneas de código o número de tickets, lo que los hace sentirse como supervisores de “granjas de slop” en lugar de constructores.
• Otros señalan que este pesimismo resulta familiar de oleadas anteriores (deslocalización, web, nube) y argumentan que la demanda de buenos ingenieros sigue existiendo, solo que con expectativas cambiadas.

Experiencia de dominio vs habilidades generalistas

• Un bando: el conocimiento profundo del dominio (finanzas, impuestos, simulación, procesamiento de señales, sanidad, regulación) sigue siendo una fuerte ventaja defensiva; los LLM fallan rutinariamente en reglas sutiles, casos límite y prácticas específicas de cada institución.
• La postura opuesta: “el conocimiento de dominio se puede promptizar”; los principios amplios de ingeniería y la capacidad de orquestar agentes importarán más que la experiencia de nicho que los LLM pueden leer de la documentación.
• Varios señalan que igualmente se necesitarán expertos de dominio para interpretar regulaciones, negociar con reguladores y asumir el riesgo legal —tareas que no se pueden delegar fácilmente a modelos.

Capacidades y límites de los LLM

• Los usuarios intensivos reportan ganancias reales: refactors más rápidos, detección de errores complejos, generación de pruebas, edición de YAML/config, pruebas de concepto de ingeniería de datos e incluso código no trivial de matemáticas/física con verificación visual.
• Al mismo tiempo, los modelos de frontera todavía:
  • Alucinan APIs, regulaciones, fechas o requisitos de cumplimiento.
  • Producen demasiado código, duplican lógica e ignoran patrones arquitectónicos salvo que estén fuertemente restringidos.
  • Fallan gravemente cuando se los empuja fuera de dominios ya transitados o cuando las especificaciones son ambiguas.
• Muchos subrayan la “habilidad de conducción”: los desarrolladores experimentados obtienen grandes beneficios; los juniors y los no desarrolladores a menudo producen sistemas frágiles e incoherentes.

Calidad del código, arquitectura y “AI slop”

• Preocupación generalizada de que la dirección aceptará “slop” de IA de grado C porque es más rápido y barato, aunque la deuda técnica y las tasas de fallo aumenten silenciosamente.
• Otros dicen que la arquitectura y la claridad importan aún más ahora, porque tanto agentes como humanos trabajan mejor sobre sistemas bien estructurados, y los LLM pueden ayudar a imponer patrones si se guían con cuidado.
• Varios describen un nuevo antipatrón: PR enormes generados de una sola vez por agentes, seguidos de largos y dolorosos ciclos de revisión humana que anulan la mayor parte de las ganancias de velocidad.

Seguridad, regulación y responsabilidad

• En dominios regulados (fintech, sanidad, aviación, PCI, GDPR, AML), los comentaristas relatan que los LLM:
  • Malinterpretan o inventan requisitos legales.
  • Proponen diseños no conformes que suspenderían auditorías o crearían responsabilidades graves.
• El consenso aquí: el desarrollo agente totalmente autónomo es imprudente; los humanos deben seguir siendo responsables del código y del cumplimiento, y los reguladores/auditores aún no están preparados para la IA.
• Algunos prevén futuros “juicios por slop de IA” tras incidentes graves, lo que podría endurecer la práctica en torno a herramientas deterministas más revisión humana.

Implicaciones económicas y sociales

• Temor amplio de que los LLM reduzcan la plantilla de cuello blanco: menos ingenieros dando soporte a más áreas de producto, salarios tecnológicos normalizándose a la baja y los juniors quedándose fuera.
• Otros sostienen que surgirán nuevos sectores y herramientas (como con cambios tecnológicos anteriores), y que la demanda total de software y automatización puede crecer más rápido que la productividad individual.
• Algunos extrapolan a escenarios “post-trabajo”, cuestionando qué sistema económico sostendría a miles de millones si la mayor parte del trabajo intelectual pudiera automatizarse; las sugerencias van desde UBI hasta impuestos sobre la riqueza o “poseer capital o tierra”.

Estrategias de afrontamiento, valores y alternativas

• Consejo común:
  • Apoyarse en la IA como una “herramienta poderosa”, no como reemplazo: aprender a manejarla, construir herramientas deterministas para agentes, centrarse en arquitectura, pruebas y diseño de sistemas.
  • Cambiar la identidad de “programador” a “ingeniero” o “resolutor de problemas”: trabajar en requisitos, intención y restricciones más que en pulsaciones de teclado.
  • Mantener o profundizar la experiencia de dominio y las habilidades blandas (comunicación, juicio sobre riesgos, trabajo con legal/cumplimiento, comprensión del cliente).
• Una minoría vocal se siente repelida por el nuevo estilo de trabajo (“vibe coding”, supervisar robots) y contempla salir hacia oficios, carpintería, agricultura u otros oficios manuales; otros advierten que esas rutas también son duras, concurridas y arriesgadas.
• Varios señalan una pérdida de alegría: programar pasa de ser un oficio a ser un proceso de editar y supervisar la salida de una máquina, lo que plantea preocupaciones sobre el agotamiento y la desilusión masiva antes de que otros sectores sientan plenamente el impacto de la IA.