En julio pasado, escribí un artículo sobre cómo la ingeniería de software puede verse afectada por la creciente integración de herramientas de asistente de código basadas en LLM. Desafortunadamente para mí, estaba escribiendo ese artículo inmediatamente después del primer lanzamiento importante y funcionalmente avanzado de Claude Code. Si bien Claude Code existía técnicamente en febrero de 2024, no fue hasta mayo de 2025 que se amplió para ofrecer el tipo de sofisticación en el código de asistencia que poseen él y algunas de las otras herramientas de asistente de código. Debido a esto, mis pensamientos en ese artículo realmente no tomaron en cuenta algunos de los cambios que hemos visto desde entonces.
Ahora voy a echar un nuevo vistazo a la situación en el uso de herramientas de código basadas en LLM y ver dónde nos encontramos. En particular, quiero pensar en las implicaciones de esta tecnología sobre cómo hacemos nuestro trabajo ahora y en el futuro.
1. Funcionalidad
¿A qué se debe esa sofisticación de la que hablo? Bueno, he usado algunas soluciones de asistente de código diferentes (Github Copilot, Claude Code) en mi propio trabajo y he consultado a ingenieros de software que también han probado otras (Cursor, Replit, etc.). Tienen distintos niveles de capacidad, pero algunos de los elementos clave incluyen:
poder acceder a todos los archivos de su proyecto, buscarlos y analizar su contenido juntos poder escribir fragmentos importantes de código o archivos completos en su proyecto utilizando LLM de “razonamiento” que dividen las tareas en fragmentos y las procesan individualmente, mientras narran el procesamiento de esos fragmentos a las herramientas del agente de usuario, donde los modelos pueden llamar de forma independiente a diferentes software para completar tareas que el LLM no puede hacer bien (incluida la búsqueda en la web)
Nada de esto requiere un cambio en la forma en que entendemos el LLM como entidad y su estructura, pero estamos agregando cosas al LLM básico que amplían algunas de sus capacidades. Los LLM de “razonamiento” en realidad simplemente implican diferentes estrategias para incitar y permitir que se realicen y combinen múltiples hilos de trabajo de LLM. Si bien el LLM sigue siendo el mismo componente básico, los combinamos de diferentes maneras y permitimos diferentes aplicaciones prácticas, por lo que ahora son más útiles y efectivos en la tarea específica de escribir código.
Esto no pretende disminuir las desventajas de estas herramientas o de los LLM en general. He hablado de numerosas formas en que la tecnología LLM tiene graves externalidades negativas. Pero no creo que podamos decir, en el estrecho espacio de la ingeniería de software, que esta tecnología no funcione. Está claro que no es perfecto (todavía me siento muy frustrado cuando escribo código y le hago una pregunta a un asistente de código y todo se estropea), pero la tecnología que tenemos hoy es capaz de cumplir una función útil.
2. Cómo responde la gente
Mientras hablo con amigos en el ámbito del aprendizaje automático y la ingeniería de software sobre esta situación, escucho algunas perspectivas diferentes. Algunas personas están adoptando con entusiasmo los asistentes de código de IA en todas las formas posibles. Le darán un aviso a la herramienta y le permitirán escribir el código, y volverán más tarde para revisarlo, o harán que la herramienta haga la revisión por sí misma. Crearán varios LLM para colaborar en temas, revisando el trabajo de los demás y produciendo grandes cantidades de código mientras los humanos duermen. Esta es una forma de lo que los lectores pueden conocer como “codificación de vibraciones”. Para estas personas, verse libres de escribir código ellos mismos es un bien puro y están entusiasmados con los aumentos de productividad que pueden lograr. Escribir código, para ellos, siempre fue principalmente un medio para lograr un fin, y no les importa prescindir de esa labor. Están produciendo nuevo software a velocidades nunca antes previstas y, en general, satisface sus necesidades.
Por otro lado, están los que considero “artesanos”. Estos son desarrolladores e ingenieros a quienes les encanta el trabajo de pensar en código y escribir código, y disfrutan el viaje tanto como el destino, si no más. Para estas personas, la llegada de los asistentes de código de IA es profundamente preocupante. Cuando disfrutas tu trabajo porque requiere consideración, creatividad y resiliencia, y disfrutas del trabajo duro, es alarmante enfrentarte a un nuevo paradigma que sugiere que ninguna de estas habilidades de tu parte es necesaria o deseable. Algunos de los ingenieros de software más talentosos y capacitados que conozco han hablado de querer dejar toda la profesión en lugar de verse empujados a un paradigma de codificación de vibraciones en su trabajo diario, donde solicitar y leer revisiones de código constituye la mayor parte de sus responsabilidades.
El último artículo de Vicki Boykis aborda esto de manera reflexiva: su consejo para aquellos de nosotros que nos sentimos deprimidos por la dirección de nuestro campo es redoblar nuestros esfuerzos para encontrar formas de calmar la picazón de querer ser creativos y darle sentido a nuestro trabajo. Aprecio el valor que le da a estas habilidades y sentimientos, pero sugiere que ni siquiera ella ve el trabajo real de mantener el carácter central al que nos hemos acostumbrado.
Esta teoría es, por supuesto, un espectro, poblado por personas que pueden disfrutar un poco de la codificación, pero que están de acuerdo con transferir la mayor parte de ese trabajo, o personas a las que realmente les gusta codificar, pero reconocen que las presiones comerciales requieren que adapten sus procesos para incluir más IA. Donde quiera que esté, muchos, si no la mayoría, de nosotros estamos preocupados por cómo este cambio afectará nuestras carreras y perspectivas laborales, así como el estado del campo de la ingeniería de software en su conjunto.
La seducción
Pero ¿qué es lo que realmente estamos viviendo? ¿Cómo es sentarse frente a su teclado y hacer girar su IDE en esta nueva era? Hay algo extrañamente seductor en tener una pequeña herramienta al costado de la pantalla que puede realizar una tarea por usted.
Sabes que el asistente probablemente pueda escribir la siguiente función que necesitas agregar a tu código. Incluso si no lo ha usado usted mismo, habrá escuchado a sus compañeros hablar maravillas de sus capacidades. Y, de todos modos, ¿cuál es la desventaja? ¿Por qué no optar por el asistente de código y hacer que realice una pequeña tarea?
Es posible que le preocupe la seguridad laboral: ¿se quedará obsoleto a medida que herramientas como esta aumenten su capacidad o encontremos formas más efectivas de usarlas? ¿Perderás las habilidades que has adquirido a lo largo de tu carrera si dejas de usarlas a diario y dejas que la IA realice las tareas? Nadie puede decir si estas son preocupaciones reales, porque todavía no sabemos con certeza cómo evolucionará el lugar de trabajo de los ingenieros de software a largo plazo.
Es posible que también conozca las implicaciones más amplias de la IA generativa. Estás diciendo implícitamente: “este trabajo que necesito hacer vale los costos negativos de esta tecnología”. Al elegir hacer clic en el botón de chat del asistente de código, está decidiendo que su caso de uso vale la pena. Esto vale la pena el uso de agua. Vale la pena apoyar e impulsar una industria y una tecnología que, en otras áreas, es responsable de importantes impactos sociales, políticos y culturales negativos. Estás diciendo: “Creo que vale la pena conseguir una herramienta para escribir el código que necesito para completar este proyecto”.
Pero incluso cuando se le llama la atención sobre estas compensaciones, sigue siendo difícil. Estás sentado mirando tu código y una parte de ti dice: “Podría hacer esto. Podría escribir este componente de este código. Sé cómo escribir esta función”. Pero tienes este pequeño error, esta pequeña picazón en forma de ventana de chat al costado de la pantalla o un comando de terminal esperando. “Me tomará 3 horas escribir esta clase, hacerla funcionar y escribir las pruebas. Pero hombre, podría simplemente presionar ese botón. Ese botón está justo ahí. Presione ese botón, y esto estará hecho en unos minutos, y luego puedo pasar a lo siguiente. Incluso podría funcionar mejor de lo que escribiría. Mi jefe estará feliz. Podría progresar y avanzar, así que ¿por qué no simplemente hacer que la herramienta de IA haga el trabajo?”
Hay muchas razones por las que te dan vueltas en la cabeza, porque conoces los costes de utilizar esta tecnología, pero esa seducción sigue ahí. La racionalización comienza: usted puede preguntarse: “bueno, ¿mi único uso de esto realmente hace alguna diferencia? Después de todo, solo soy un usuario”. Esta es una pregunta razonable, por supuesto. ¿Cuánta diferencia puede hacer un mensaje? Su único mensaje realmente no requiere tantos recursos, y otros alrededor del mundo están usando esta tecnología mucho más para esfuerzos mucho menos valiosos.
Por otro lado, un mensaje probablemente nunca sea solo uno: ¿qué pasa si te diriges hacia una pendiente resbaladiza donde esto se convierte en una parte rutinaria de tu trabajo? Si tus habilidades se atrofian, ¿eso te hará más dependiente de la herramienta?
¿Esto realmente ya depende de ti? ¿Siente que puede seguir trabajando en ingeniería de software y no utilizar estas herramientas? Es muy posible que mantener la productividad y la relevancia en el trabajo requiera seguir usando las herramientas del asistente de código. ¿Es su responsabilidad personal frenar la marea de herramientas de código de IA, frente a multitudes que adoptan con entusiasmo esta tecnología para todos los casos de uso posibles? En un equilibrio entre evitar por principios la tecnología que tiene efectos sociales negativos y seguir pudiendo alimentar a su familia, ¿qué se supone que debe hacer un individuo? Para la mayoría de nosotros, la supervivencia material tiene que prevalecer.
3. ¿Y ahora qué?
Este espacio mental es un lugar difícil desde el cual operar. Estamos siendo testigos de un cambio significativo en la forma en que se realiza nuestro trabajo y cada uno de nosotros está decidiendo cómo nos adaptamos a él. Para muchos, es emocionalmente agotador ver cómo este campo cambia tan dramáticamente, enfrentando la incertidumbre sobre lo que esto significa para nosotros y el mundo que nos rodea.
¿Cómo pensaban nuestros antepasados en los primeros días de la programación informática que sería este campo en el futuro? En, digamos, la década de 1960, cuando la gente operaba mainframes del tamaño de una habitación y escribía código con tarjetas perforadas, ¿podrían haber imaginado el ecosistema de código abierto de Python? Así es como pienso sobre la escala de cambio que es potencialmente posible para nosotros ahora, y puede ocurrir a un ritmo rápido.
Los asistentes de código de IA parecen haber llegado para quedarse, de una forma u otra. El futuro económico más amplio de los grandes actores de los LLM puede ser precario, por razones que he escrito antes, pero eso no necesariamente nos impide tener acceso a algunos tipos de herramientas de asistente de código, a través de LLM de código abierto y herramientas como https://ampcode.com/, https://opencode.ai/ o https://www.tabbyml.com/. Si los modelos nunca mejoran de lo que son hoy, seguirán siendo funcionalmente útiles.
Nuestros trabajos van a cambiar porque estas nuevas herramientas están disponibles y tenemos que descubrir cómo evolucionaremos. No creo que nuestros empleos vayan a desaparecer, simplemente van a cambiar. Nos acostumbraremos a utilizar asistentes de inteligencia artificial en nuestra codificación y, como resultado, queda por ver cómo funciona el día a día. ¿Limitará la inercia institucional la cantidad de cambios que vemos en nuestros lugares de trabajo? ¿Seguirá habiendo lugar para la creatividad y la artesanía en el desarrollo y la codificación de software? En los lugares de trabajo, las personas ya reciben evaluaciones de desempeño en función de si usan la IA lo suficiente como para complacer a la gerencia, por lo que no tenemos mucho tiempo para pensar en ello.
A nivel personal, ¿cómo vamos a afrontar las implicaciones éticas de nuestra participación en esta industria y las formas en que están cambiando? Nadie puede responder eso por ti, por supuesto. Es muy posible que algunas personas renuncien y cambien de carrera, mientras que otras encontrarán una manera de vivir con el nuevo paradigma.
Estamos en un vínculo específico entre lo que la economía y las condiciones materiales esperan o exigen de nosotros, y las implicaciones éticas de esas demandas. La gran mayoría de nosotros necesitamos mantener a nuestras familias y no estamos en condiciones de negarnos a cumplir. Creo que muchos de nosotros vamos a tener que afrontar una disonancia cognitiva sobre estos dos lados.
La conciencia y la conciencia de los costos de nuestro sistema son importantes, incluso si nos causan malestar. Fingir que los problemas de la IA generativa no existen no es una solución. Como saben los científicos sociales, interrogar honestamente las dinámicas, fallas y estructuras de poder del sistema en el que nos encontramos es un requisito previo para mejorar ese sistema, aunque sea de manera incremental. No podemos volver a meter al genio de la IA generativa en la botella, pero tampoco necesariamente tenemos que aceptar el peor de los casos en cuanto a efectos sociales, culturales, ambientales y políticos. El cambio estructural, no la elección individual, es la única manera de mejorar significativamente los sistemas, y si estamos informados sobre los problemas éticos podemos participar en esfuerzos sistémicos hacia la mejora.
Lea más de mi trabajo en www.stephaniekirmer.com. También hablaré en ODSC East a finales de abril de 2026, sobre el tema de las estrategias de evaluación para el desarrollo de LLM.