LLMs están erosionando mi carrera como ingeniero de software y no sé qué hacer

LLMs están erosionando mi carrera como ingeniero de software y no sé qué hacer

Soy un ingeniero de software, completando 10 años de experiencia profesional este año. Empecé mi carrera como ingeniero de frontend web (era más fácil para mí depurar el código frontend entonces, así que elegí esa ruta), pero pronto pasé a (web) backend y nunca miré atrás.

A través de una serie de coincidencias, una vez que entré en el mundo del backend, terminé trabajando en roles de desarrollo de software en los dominios de la finanza, contabilidad y tratamiento de pagos, donde tenía gran autonomía y una relación candida y sincera con los gerentes de productos y los stakeholders.

Aprendí mucho sobre el dominio y cómo escribir programas efectivos para él: PCI compliance, registros de contabilidad a doble entrada, escrow, reconciliación, ciclos de pago, idempotencia de transferencias bancarias, etc.

Era obvio que debería concentrar mi carrera en convertirme en un experto en ese dominio para distinguirme como profesional y diferenciarme en un campo que mostraba señales de un creciente necesidad de especialistas en dominio.

El primer pilar a erosionarse: el conocimiento domain-specific

El año pasado, fui contratado por una empresa en el campo de la finanza. Hasta entonces, había trabajado en empresas que tenían un fuerte componente de pago y de finanza en sus operaciones/oferta, pero que no eran empresas enfocadas exclusivamente en la finanza.

Esa empresa también abrazó con entusiasmo la IA, por lo que obtuve cuentas de ChatGPT y Claude Enterprise desde el primer día y fui animado a usarlos para mi investigación, exploración y hasta el código, aunque con una advertencia de que debería revisar y poseer cada una de las líneas que entraban en producción.

Uno de mis primeros proyectos involucró la reestructuración del sistema de pago en línea de antiguo, que era un desastre. Me contrataron (entre otras cosas) por mi experiencia previa en construirlo y me confiaron el proyecto.

Diferente de las otras empresas que había trabajado hasta entonces, querían que los "Documentos de Diseño" que escribo antes de codificar fueran legibles tanto para los ingenieros como para los gerentes de productos - por lo tanto no deberían ser una exploración técnica profunda y deberían ser más de una visión arquitectónica. Escribí mi primer uno con un mínimo de ayuda de la IA - incluso llamé a los LLM "pájaros estocásticos" en ese momento, una visión que ya no sostengo - y lo entregué.

Valoré mi conocimiento y pensé que ningún LLM podría reemplazarlo.

Luego mi gerente me contactó: aunque estás entregando el código a un buen ritmo, estás tomando demasiado tiempo en entregar esos Documentos de Diseño. ¿Estás usando la IA? Deberías usar más IA.

"No funcionará nunca", pensé en mi cabeza, pero acepté. Los modelos en ese momento no eran tan buenos como los que tenemos ahora, pero proporcionaban un buen acelerador para mi escritura y hasta la toma de decisiones.

Y entonces empecé a darme cuenta: toda la conocimiento que he acumulado en los años: los trade-off entre las implementaciones, cómo funciona el adquisición, cómo estructurar la idempotencia para prevenir las dobles cargas, todo, se estaba volviendo inútil. Aunque los modelos todavía necesitaban un poco de guía, podían conectar los puntos entre sí sobre cómo estructurar tales sistemas, que era la parte más difícil que solo desarrolla en tu mente después de años de experiencia práctica.

Eso fue mi primer shock

.

Pero seguro, pensé, pueden hacerlo porque hay muchos artículos en línea sobre cómo funciona todo eso junto con toda la documentación técnica, y tenemos posts en blogs que explican cómo aplicar los herramientas técnicas al dominio. Para los seres humanos, puede requerir mucho tiempo para aprender todo eso, pero es datos de entrenamiento para los modelos que pueden aprender.

Lo que los modelos nunca serán capaces de hacer bien, y donde los seres humanos brillarán, es el depuración! He acumulado una buena experiencia en depurar las condiciones de carrera y los sistemas distribuidos en producción. Eso era mi pase para la ocupación a largo plazo.

El segundo pilar a erosionarse: la depuración y los sistemas distribuidos

Así que, después de los LLM se convirtieron en buenos en escribir documentos y ayudar a planificar las implementaciones reales, se convirtieron en buenos en el código. Empezó en la segunda mitad del 2025 con la hipótesis Claude Code, luego Codex llegó