IA en el desarrollo de software: cómo cambia el rol del ingeniero

Una charla sobre cómo está cambiando el oficio

En la conferencia “AI Dev 26 x SF: Andrew Ng: The Future of Software Engineering”, Andrew Ng plantea cómo los modelos capaces de generar código podrían cambiar la ingeniería de software. La pregunta que suele aparecer primero es inquietante: ¿van a desaparecer los ingenieros de software y los desarrolladores? La charla propone mirar también qué partes del oficio podrían cambiar. En este artículo resumo esa perspectiva y la pongo en diálogo con estudios publicados y con mi experiencia desarrollando software.

Ng es una figura reconocida en inteligencia artificial y aprendizaje automático. Las redes neuronales son una familia de métodos dentro del machine learning, que a su vez forma parte de la inteligencia artificial. En mi página sobre Machine Learning explico cómo abordo estos modelos desde sus fundamentos. Aquí me centro en otra cuestión: cómo los LLM pueden cambiar el proceso cotidiano de construir software.

La tesis que extraigo de la charla no es que la profesión vaya a desaparecer, sino que su centro de gravedad puede desplazarse. Si un modelo produce una primera versión del código, el trabajo humano sigue siendo necesario antes —para definir el problema— y después —para revisar, probar e integrar la solución—. Es una hipótesis sobre cómo evoluciona el oficio, no una descripción que se aplique ya a todos los equipos.

De escribir cada línea a dirigir el proceso

En muchos flujos de trabajo, una parte importante del desarrollo consiste en traducir una necesidad a código: analizar el problema, implementar funciones, conectar módulos y corregir errores. Con un LLM, parte de esa primera implementación puede delegarse: en lugar de empezar siempre con un archivo vacío, el desarrollador describe el objetivo, aporta contexto y pide una propuesta de solución. Eso no elimina el análisis ni las correcciones; el código generado sirve como punto de partida, no como garantía de que el trabajo esté terminado.

El cambio, por tanto, no se limita a escribir menos. También modifica la secuencia del trabajo:

1. Entender qué problema se quiere resolver.
2. Dividirlo en tareas concretas y acotadas.
3. Proporcionar al modelo el contexto necesario y pedir una implementación.
4. Revisar el resultado, ejecutarlo y comprobarlo con pruebas.
5. Corregirlo e integrarlo en el sistema solo cuando cumple los requisitos.

En este flujo, la claridad al definir las tareas cobra más importancia. Una petición ambigua puede producir código plausible que no resuelva la necesidad real. Cuanto mejor se entiende el sistema y sus restricciones, más útil puede ser la colaboración con el modelo.

¿Qué dicen los estudios sobre el impacto de la IA?

La idea de que el trabajo se desplaza desde escribir código hacia analizar, orientar y revisar es una hipótesis plausible, pero no una conclusión universal. Los estudios disponibles miden tareas y poblaciones distintas; sus resultados muestran beneficios en algunos contextos y contrapartidas en otros.

En un experimento controlado con GitHub Copilot, los participantes completaron una tarea acotada —implementar un servidor HTTP en JavaScript— un 55,8 % más rápido cuando podían utilizar el asistente. El resultado demuestra una aceleración en esa tarea y bajo esas condiciones; no permite concluir que cualquier proyecto, desarrollador o etapa del desarrollo vaya a acelerarse en la misma medida.

El informe DORA 2024 asocia la adopción de IA con mayor productividad individual, fluidez del trabajo y satisfacción. También informa de asociaciones negativas con la estabilidad y el rendimiento de la entrega de software. Son resultados de un estudio sobre equipos y organizaciones, no una prueba de que la IA cause por sí sola cada uno de esos efectos: ayudan a distinguir la productividad percibida de los resultados globales de entrega.

Desde una perspectiva más amplia, el estudio de Humlum y Vestergaard, “Still Waters, Rapid Currents: Early Labor Market Transformation under Generative AI”, analiza la adopción de chatbots en distintos sectores de Dinamarca. En su versión revisada en marzo de 2026, no detecta efectos en horas trabajadas o ingresos durante el periodo analizado, pero sí documenta reorganización de tareas y nuevas actividades de supervisión e integración de IA. Como no se centra en desarrolladores, aporta contexto sobre la transformación del trabajo, no una medida directa de la ingeniería de software.

En conjunto, estos resultados no prueban que los ingenieros hayan dejado de programar para convertirse en supervisores o arquitectos. Sí muestran que el efecto de la IA depende de la tarea y el entorno, y que sus beneficios en una fase pueden coexistir con costes o riesgos en otras. La charla de Ng aporta una interpretación sobre la posible evolución del oficio; los estudios permiten contrastarla, pero todavía no justifican generalizarla a todos los equipos.

Si quisiera comprobar ese cambio en un proyecto concreto, mediría algo más que la velocidad de generación. Compararía tareas de alcance similar con criterios de aceptación definidos y registraría el tiempo de análisis, implementación, revisión y pruebas; también comprobaría reutilización de componentes, defectos y regresiones. Así podría saber si en ese contexto cambió realmente el reparto del esfuerzo y si el resultado mantuvo la calidad. Sería evidencia útil para ese proyecto, no una conclusión universal.

El contexto técnico cambia la respuesta

No basta con explicar el resultado que queremos. También hay que describir cómo está construido el proyecto y qué reglas debe respetar la solución. Por ejemplo, si queremos mostrar qué profesores están vinculados a un estudio, no es suficiente pedir “añade los profesores del estudio”. Conviene explicar que profesores y estudios son tipos de contenido, cómo se relacionan y qué campo almacena esa relación.

En un modelo de contenido Drupal, por ejemplo, podríamos indicar que un estudio puede tener varios profesores —una relación uno a muchos— y que la referencia se guarda en un campo de referencia a contenido concreto. También habría que aclarar en qué tipo de contenido está ese campo, qué entidad debe consultarse y cómo espera el proyecto presentar los resultados.

Además del modelo de datos, se puede pedir primero que investigue el propio proyecto antes de tocar código. Si queremos mostrar los estudios con una presentación determinada, la tarea puede empezar así: localiza si ya existe en el proyecto un componente o patrón visual parecido, explica dónde se usa y evalúa si sirve para este caso. Con ese análisis podemos decidir si conviene reutilizarlo o si hay razones para crear una variante.

Después se puede encargar la implementación y pedir que informe qué componente reutilizó y en qué archivos lo conectó. La revisión debe confirmar que la solución efectivamente reutiliza el patrón existente y no ha creado por accidente una visualización paralela, o que, si creó una nueva, haya una razón clara. No basta con que el modelo afirme que reutilizó el sistema: hay que comprobar las referencias en el código y probar la presentación.

Si se omite este análisis, existe el riesgo de duplicar funcionalidades. El modelo puede no haber recibido el contexto donde ya existe una solución parecida y crear otra implementación con un enfoque distinto. El resultado quizá funcione, pero mantener dos versiones de la misma capacidad aumenta la complejidad: los cambios futuros deben aplicarse en más de un sitio y las implementaciones pueden acabar comportándose de forma diferente.

Los modelos tienen límites en la cantidad de información que pueden considerar y no conocen automáticamente todo el historial ni todas las decisiones del proyecto. Por eso hay que seleccionar el contexto relevante y, cuando sea necesario, pedirles que exploren el repositorio antes de proponer cambios. Esa etapa reduce el riesgo de implementar una solución paralela o incompatible; después, todavía hay que comprobar que el código respeta lo encontrado.

Elegir el modelo adecuado para cada tarea

En el trabajo diario también importa decidir qué modelo utilizar. No todas las tareas necesitan el modelo más potente y costoso. Para cambios pequeños y bien delimitados, un modelo más económico puede ser suficiente; reservar uno de mayor capacidad para problemas complejos puede ser una forma más razonable de gestionar el presupuesto o la cuota disponible.

No hay una única opción que sea barata y la mejor para cualquier tarea. Un modelo puede dar muy buen resultado escribiendo pruebas o haciendo cambios sencillos, pero quedarse corto al analizar una arquitectura amplia, seguir dependencias entre módulos o resolver un problema con mucho contexto. En esos casos puede ser necesario recurrir a otro modelo con más capacidad, mejores herramientas o mayor margen de contexto.

Por eso, conocer los modelos disponibles y sus fortalezas se convierte en otra habilidad del proceso: estimar la dificultad de la tarea, asignarla al modelo apropiado y comprobar si la elección funcionó. No se trata de escoger siempre el modelo más avanzado, sino de equilibrar calidad, tiempo y coste según lo que haya que resolver. Como las capacidades y los precios cambian con rapidez, conviene evaluar opciones con tareas reales del propio proyecto en vez de asumir que una clasificación sirve para siempre.

Para orientarse entre modelos, Artificial Analysis permite comparar rendimiento en evaluaciones, coste, velocidad, latencia y ventana de contexto. BenchLM reúne rankings y comparativas; al usarlo, conviene revisar su metodología y el nivel de evidencia que acompaña a cada puntuación. Para programación y agentes que modifican repositorios, el leaderboard de SWE-bench compara resultados en tareas basadas en problemas reales de GitHub. Estas referencias ayudan a acotar opciones, pero no predicen necesariamente cuál funcionará mejor en nuestro proyecto: cada benchmark usa tareas, entornos y criterios propios, por lo que la decisión final debe contrastarse con pruebas del trabajo real.

Una respuesta probable no es necesariamente verdadera

También ayuda recordar qué tipo de sistema estamos utilizando. Un LLM estima una distribución de probabilidad para el siguiente token a partir del texto previo y el contexto recibido; el método de generación determina cómo se elige entre las continuaciones posibles. Esta naturaleza predictiva ayuda a explicar sus capacidades, pero también por qué una respuesta fluida no equivale a una afirmación verificada.

Que una respuesta sea probable no significa que sea verdadera. Un modelo puede producir una explicación coherente y un fragmento de código convincente aunque parta de una premisa equivocada, confunda una API o desconozca una decisión particular del proyecto. La fluidez de la respuesta tampoco mide su exactitud. La importancia de evaluar los resultados también aparece al comparar modelos de Machine Learning: el modelo más complejo no siempre ofrece el mejor resultado.

Esto no significa que todo lo estadístico sea impreciso ni que los modelos no puedan ser muy útiles. Significa que su salida debe tratarse como una propuesta cuya validez hay que comprobar. En desarrollo, esa comprobación consiste en contrastar la respuesta con la documentación y el código existentes, ejecutar pruebas y verificar el comportamiento real.

El ingeniero como integrador de piezas

Una de las ideas sugerentes de la charla es que el trabajo futuro podría parecerse más a conectar componentes que a construirlos todos desde cero. El software siempre ha consistido en crear piezas y hacer que funcionen juntas; lo que puede cambiar es la proporción entre ambas actividades.

Los modelos pueden generar funciones, pruebas, documentación o adaptadores. Sin embargo, alguien debe decidir qué piezas hacen falta, cómo se relacionan y si el conjunto responde a la arquitectura del proyecto. En sistemas reales, una solución localmente correcta puede no encajar con las convenciones, dependencias, requisitos de seguridad o necesidades de mantenimiento del producto.

Por eso, “conectar piezas” no significa limitarse a pegar resultados. Requiere comprender las fronteras entre componentes, los contratos que comparten y las consecuencias de introducir cambios. Además, esas piezas no siempre viven en el mismo repositorio o en la misma infraestructura. Cuando una aplicación consulta una API, por ejemplo, está conectando servicios que pueden estar desarrollados, desplegados y operados por separado. En mi guía sobre arquitecturas headless con Drupal y Next.js describo un caso de integración de este tipo.

Esto puede acercar parte del trabajo del ingeniero al de la arquitectura de software. No significa que todos vayan a asumir por completo el rol de arquitecto, sino que será aún más importante pensar en cómo se organizan los componentes, cómo se comunican y qué infraestructura necesitan para funcionar juntos. También puede implicar participar más en el montaje y la configuración de esa infraestructura, no solo escribir el código que consume los servicios.

Para guiar bien al modelo en este tipo de tareas hay que poder explicarle dónde están las piezas, qué responsabilidades tiene cada servicio, cómo se autentican y qué restricciones existen en los despliegues. La capacidad de ver el sistema completo —incluidas sus fronteras entre repositorios, APIs e infraestructura— sigue siendo esencial.

¿Puede un modelo revisar el código de otro modelo?

Ng también abre la puerta a que los propios modelos participen en la revisión del código que generan. Un modelo puede analizar una implementación, señalar casos límite, proponer pruebas o detectar inconsistencias. Incluso se puede pedir a otro modelo que examine la respuesta inicial desde una perspectiva distinta.

Ese apoyo puede ser útil, pero no convierte la revisión en un trámite automático. Dos modelos pueden compartir puntos ciegos, pasar por alto un requisito no expresado o coincidir en una solución incorrecta. Además, que el código compile o pase unas pruebas no demuestra por sí solo que sea seguro, mantenible o adecuado para quienes lo usarán.

Me ha ocurrido en varias ocasiones: el modelo ha recomendado una corrección que parecía razonable de forma aislada, pero que no era válida dentro del contexto concreto del proyecto. Si hubiera aplicado la propuesta sin comprobar sus efectos, habría dejado de funcionar la funcionalidad afectada. La explicación estadísticamente más probable o una recomendación bien argumentada no garantizan que el cambio respete las dependencias y decisiones existentes.

Por eso, revisar no consiste únicamente en preguntarle a otro modelo si el código está bien. Hay que ejecutar la aplicación, probar el caso que se intenta resolver y comprobar que no se han roto comportamientos relacionados. El conocimiento del contexto sirve tanto para dar instrucciones como para evaluar críticamente las respuestas.

La revisión asistida por IA funciona mejor como una capa adicional de comprobación. Las pruebas automatizadas, el análisis estático, la lectura crítica del cambio y el conocimiento del dominio siguen formando parte de la validación. La responsabilidad de decidir qué se integra y se publica continúa en manos del equipo.

Lo que sigue siendo responsabilidad del desarrollador

Si la generación de código se vuelve más barata y rápida, otras habilidades ganan peso:

• Definir el problema: distinguir la necesidad real de la primera solución que se nos ocurre.
• Descomponer el trabajo: convertir objetivos amplios en tareas pequeñas, verificables y con límites claros.
• Aportar contexto: explicar al modelo cómo funciona el proyecto, qué convenciones debe respetar y qué restricciones existen.
• Diseñar e interconectar componentes: comprender contratos entre APIs y servicios, incluso cuando viven en repositorios o infraestructuras diferentes, y valorar qué necesita su despliegue.
• Evaluar resultados: comprobar el comportamiento con pruebas y revisar los casos que el modelo quizá no haya considerado.
• Tomar decisiones técnicas: valorar dependencias, seguridad, rendimiento, accesibilidad y coste de mantenimiento.
• Asumir la responsabilidad: entender el cambio antes de integrarlo y poder explicar por qué es correcto.

Estas tareas no son completamente nuevas. En un equipo de ingeniería ya era necesario comprender requisitos, revisar código ajeno y validar cambios. Lo que cambia es que, cuando aumenta la cantidad de código generado, también aumenta la importancia de saber especificar y evaluar ese código.

El riesgo de dejar de aprender a programar

Hay otro cambio posible que me preocupa: que, al poder delegar cada vez más implementación en un modelo, algunas personas pierdan la motivación para aprender a programar. Si una herramienta genera una función en segundos, puede parecer poco práctico dedicar tiempo a entender cómo se construye. Pero esa decisión podría debilitar precisamente las capacidades necesarias para utilizar bien la herramienta.

En mi caso, programar no ha sido solo una forma de producir software. También ha sido una actividad que disfruto: me gusta aprender lenguajes y frameworks, probar tecnologías nuevas e implementarlas en proyectos. Si el desarrollo se reduce a describir tareas y aceptar resultados, existe el riesgo de perder parte de esa exploración y del aprendizaje que se produce al escribir, equivocarse y depurar código.

Además, aprender a programar proporciona modelos mentales para analizar una solución. Quien ha implementado y depurado código suele tener más herramientas para reconocer una abstracción inadecuada, seguir el flujo de datos o cuestionar una propuesta que parece correcta, pero no encaja con el sistema. Sin esa experiencia, puede ser más difícil aportar el contexto preciso que necesita el modelo y detectar cuándo su respuesta introduce un fallo.

Por eso, me parece posible que uno de los retos para quienes se incorporen a la profesión sea mantener suficiente práctica directa de programación. No porque haya que rechazar los LLM ni escribir todo a mano, sino porque delegar una implementación no equivale a comprenderla. La experiencia práctica seguirá siendo una base importante para formular tareas, revisar cambios y decidir cuándo no aceptar una sugerencia.

Una transformación, no la desaparición de la profesión

Mi lectura de la charla de Andrew Ng y de los estudios revisados es que estamos ante una posible evolución del oficio, no ante una desaparición demostrada. Los modelos pueden asumir parte de la implementación y acelerar tareas concretas, pero no conocen automáticamente el propósito del producto, las decisiones históricas del sistema ni las consecuencias de cada cambio.

Es razonable prepararse para dedicar más atención a orientar el proceso: decidir qué construir, distribuir el trabajo entre personas y herramientas, conectar las piezas y verificar que el resultado merece llegar a producción. Escribir código seguirá siendo parte del trabajo; lo que podría cambiar es cuánto pesa esa actividad frente al análisis, la integración y la validación.

Con la evidencia disponible no podemos asegurar que esta transformación vaya a darse igual en todos los equipos. La pregunta práctica es cómo usar estas herramientas para avanzar cuando aportan valor, sin renunciar a entender, probar y responsabilizarnos del software que construimos.