¿Cuántos lenguajes conoce?
¿Con qué rapidez escribe código?
¿Puede implementar una funcionalidad sin ayuda?
¿Domina un determinado framework?
¿Consigue resolver problemas difíciles?
Estas preguntas siguen siendo importantes.
Pero quizá estén dejando de medir aquello que realmente diferencia a un buen profesional.
La inteligencia artificial hizo posible generar funciones, pruebas, interfaces, consultas, documentación e incluso aplicaciones completas en pocos minutos. El código, que siempre fue una parte costosa de la producción de software, se está volviendo más rápido y barato de producir.
Esto crea una pregunta incómoda:
Si escribir código se vuelve cada vez más fácil, ¿programar continúa siendo la habilidad principal de un desarrollador?
La respuesta depende de lo que entendamos por programar.
Si programar significa solamente transformar instrucciones en código, probablemente no.
Si significa comprender problemas, modelar soluciones, tomar decisiones y construir sistemas confiables, entonces continúa siendo una capacidad central, pero de una forma mucho más amplia.
El código no perdió su importancia.
Perdió el monopolio sobre el valor del desarrollador.
El código nunca fue el producto final
Las empresas no contratan desarrolladores porque quieran poseer más líneas de código.
Los contratan porque necesitan vender un producto, automatizar un proceso, atender a un cliente, reducir un coste, proteger información o resolver algún problema.
El código es un medio.
En determinados momentos de la industria, este medio era tan difícil de producir que la capacidad de escribirlo se convirtió en el principal diferencial.
Esto tenía sentido.
Una persona capaz de traducir reglas de negocio en un sistema funcional poseía una competencia poco común.
Pero la producción de código se volvió más sencilla.
La documentación se hizo más accesible.
Los frameworks abstrajeron elementos complejos.
Los servicios en la nube eliminaron la necesidad de construir determinadas infraestructuras.
Las bibliotecas transformaron problemas completos en llamadas a funciones.
Las plataformas low-code simplificaron aplicaciones comunes.
Ahora, los modelos de inteligencia artificial pueden generar implementaciones a partir de descripciones en lenguaje natural.
Cada uno de estos cambios redujo el esfuerzo necesario para escribir determinadas partes de un sistema.
Ninguno eliminó la necesidad de ingeniería.
En realidad, al facilitar la construcción, aumentaron la cantidad de software que necesita ser comprendido, integrado, mantenido y protegido.
Producir código no equivale a producir software
Es posible generar mucho código sin construir un buen producto.
También es posible crear una funcionalidad que funciona sin construir una solución que debería existir.
Esta diferencia siempre estuvo presente.
La IA simplemente hizo que fuera más fácil percibirla.
Una herramienta puede crear una API.
Pero ¿quién decide si esa API debería existir?
Puede sugerir una arquitectura.
Pero ¿quién evalúa si es adecuada para el tamaño, el presupuesto y el riesgo del proyecto?
Puede escribir pruebas.
Pero ¿quién identifica qué comportamientos realmente deben protegerse?
Puede generar una consulta eficiente en un ejemplo pequeño.
Pero ¿quién comprende cómo se comportará con datos reales?
Puede ofrecer una respuesta técnicamente elegante al problema equivocado.
Cuanto más fácil se vuelve construir, más importante se vuelve elegir qué construir.
El desarrollador que solamente recibe requisitos y los convierte en código continúa siendo útil.
Pero el profesional que cuestiona esos requisitos, identifica contradicciones y propone una solución más sencilla produce un valor mucho mayor.
La adopción de IA ya es amplia, pero la confianza continúa siendo limitada
La encuesta de desarrolladores de Stack Overflow de 2025 recibió más de 49.000 respuestas de 177 países. Entre los participantes, el 84% afirmó utilizar o planear utilizar herramientas de IA en el desarrollo, y el 51% de los desarrolladores profesionales dijo usarlas diariamente.
Al mismo tiempo, el 46% afirmó desconfiar de la precisión de sus respuestas, frente a un 33% que manifestó confianza. Solamente el 3% indicó confiar mucho en los resultados.
La principal frustración, mencionada por el 66% de los participantes, fue recibir soluciones casi correctas. Otro 45% señaló que depurar código generado por IA puede consumir más tiempo.
Estos números revelan un cambio importante.
El profesional no desaparece porque la IA produzca código.
Su posición dentro del proceso está cambiando.
Antes, gran parte de su esfuerzo se concentraba en la creación.
Ahora también necesita orientar, contextualizar, verificar, corregir e integrar lo que fue producido.
La capacidad valiosa ya no consiste solamente en escribir.
Consiste en reconocer cuándo lo escrito no debería aceptarse.
De la creación a la supervisión
Un estudio longitudinal publicado en 2026 acompañó a profesionales de software durante seis meses para comprender cómo los asistentes de IA estaban modificando su trabajo.
Entre los participantes, el 82% afirmó dedicar menos tiempo a escribir código. Los investigadores identificaron una transferencia del esfuerzo desde la creación hacia la verificación y propusieron la expresión trabajo de ingeniería supervisora para describir la orientación, evaluación y corrección de resultados producidos por IA.
La expresión es útil porque demuestra que el trabajo no desaparece.
Cambia de naturaleza.
El desarrollador empieza a actuar menos como alguien que escribe cada instrucción y más como alguien que administra una capacidad de producción.
Esa capacidad puede generar mucho.
También puede generar muchas cosas incorrectas.
Supervisar una herramienta no significa limitarse a observarla mientras trabaja.
Significa proporcionar suficiente contexto.
Dividir correctamente el problema.
Establecer restricciones.
Definir criterios de aceptación.
Crear mecanismos de validación.
Reconocer inconsistencias.
Interrumpir caminos equivocados.
Asumir la responsabilidad por el resultado.
En otras palabras, el desarrollador comienza a ser evaluado menos por la cantidad de código que puede producir por sí solo y más por la calidad del sistema que consigue llevar hasta producción.
¿Quien no sabe programar puede verificar?
Existe, sin embargo, una trampa.
El cambio hacia la validación no significa que los fundamentos técnicos se hayan vuelto innecesarios.
Es difícil revisar algo que no sabemos construir.
Es difícil identificar una vulnerabilidad sin comprender cómo funcionan los datos, los permisos y los límites de confianza.
Es difícil evaluar una arquitectura sin conocer los costes de las alternativas.
Es difícil percibir una abstracción innecesaria sin haber visto abstracciones fracasar.
Una persona que no comprende programación puede utilizar IA para generar un prototipo.
En muchos casos, eso puede ser suficiente.
Pero cuanto mayor sea la responsabilidad del sistema, mayor será la necesidad de alguien capaz de comprender lo que existe debajo de la interfaz.
La IA reduce la barrera para crear software.
No elimina automáticamente la barrera para operar software confiable.
Por eso, afirmar que “ya nadie necesitará aprender a programar” es tan exagerado como decir que toda persona deberá escribir manualmente cada línea.
Los profesionales continuarán necesitando comprender código.
Quizá no necesiten producir cada línea.
La paradoja de la productividad
Existe una tendencia a tratar la productividad de la IA como una cuestión resuelta.
La realidad depende mucho más del contexto.
El informe DORA de 2025, basado en casi cinco mil profesionales de tecnología, encontró una adopción de IA cercana al 90%. Más del 80% de los participantes indicó mejoras de productividad, mientras que el 59% percibió una influencia positiva sobre la calidad del código.
Sin embargo, la conclusión central del estudio fue que la IA funciona como un amplificador. Fortalece a las organizaciones con buenas prácticas y amplía los problemas de los entornos fragmentados. Las mejoras individuales no se transforman automáticamente en mejores productos.
Otro estudio llegó a un resultado diferente.
En un experimento controlado realizado a comienzos de 2025, 16 desarrolladores experimentados trabajaron en 246 tareas reales dentro de proyectos de código abierto que conocían profundamente. Cuando pudieron utilizar herramientas de IA, tardaron, en promedio, un 19% más.
Los participantes creían estar trabajando más rápido.
Los datos mostraron lo contrario.
Este resultado no demuestra que la IA siempre reduzca la productividad. Los propios investigadores advirtieron que no debía generalizarse de esa forma.
En febrero de 2026, METR informó que datos posteriores presentaban señales de una mayor aceleración, pero que los cambios en el comportamiento de los participantes y el uso de varios agentes hacían que la estimación fuera poco fiable. Los investigadores consideraron probable que las herramientas ya fueran más útiles que a comienzos de 2025, sin afirmar un porcentaje definitivo.
Estos estudios no se contradicen necesariamente.
Muestran que la productividad depende de la tarea, el profesional, la herramienta, el sistema y la forma en que se mide el resultado.
Generar código más rápido no significa necesariamente entregar software con mayor rapidez.
El tiempo ahorrado durante la implementación puede reaparecer en la revisión, la integración, la seguridad, las pruebas o el mantenimiento.
La nueva habilidad principal puede ser formular
Los modelos de IA responden al contexto que reciben.
Cuando ese contexto es incompleto, contradictorio o incorrecto, su respuesta tiende a reproducir esos problemas.
Esto convierte la formulación del problema en una capacidad central.
El desarrollador necesita descubrir qué necesita realmente el usuario.
Separar los síntomas de las causas.
Transformar deseos vagos en comportamientos verificables.
Identificar restricciones que no fueron mencionadas.
Explicar al sistema —humano o artificial— qué debe hacerse y qué no puede ocurrir.
Durante mucho tiempo, la programación ya exigía estas capacidades.
La diferencia es que ahora una parte mayor de la implementación puede ser delegada.
Lo que no puede delegarse fácilmente es la responsabilidad de definir correctamente el problema.
Una IA puede implementar una mala especificación a una velocidad extraordinaria.
Eso no es una ventaja.
Es una forma más eficiente de producir desperdicio.
La arquitectura se vuelve menos visual y más cotidiana
La palabra arquitectura suele recordarnos diagramas, documentos y decisiones tomadas por profesionales muy experimentados.
Pero la arquitectura también ocurre en decisiones pequeñas.
¿Dónde debe estar esta regla?
¿Debería almacenarse este dato?
¿Este servicio realmente necesita existir?
¿Qué parte del sistema puede fallar?
¿Qué dependencia estamos creando?
¿Qué ocurrirá cuando aumente el volumen?
¿Cuánto costará mantener esta solución?
La inteligencia artificial puede sugerir respuestas.
Pero sus sugerencias suelen basarse en patrones generales.
La empresa vive dentro de un contexto específico.
Posee sistemas antiguos.
Restricciones financieras.
Competencias disponibles.
Exigencias jurídicas.
Plazos.
Riesgos.
Clientes.
Una arquitectura técnicamente sofisticada puede ser la peor decisión posible para un equipo pequeño.
Una solución sencilla puede ser inadecuada para un sistema crítico.
El desarrollador necesita comprender la diferencia.
Cuanto más código pueda producirse, más decisiones arquitectónicas se tomarán, incluso cuando nadie las llame arquitectura.
Validar es más que ejecutar pruebas
En un mundo de producción acelerada, la validación adquiere mayor importancia.
Pero validar no significa solamente confirmar que las pruebas están en verde.
Las pruebas también pueden estar equivocadas.
Pueden validar una interpretación incorrecta.
Pueden ignorar escenarios importantes.
Pueden haber sido generadas por la misma herramienta que creó la implementación y repetir las mismas suposiciones.
Validar exige cuestionar el sistema desde diferentes perspectivas.
¿La funcionalidad resuelve el problema?
¿El comportamiento es seguro?
¿Los datos están protegidos?
¿El coste es aceptable?
¿La experiencia del usuario tiene sentido?
¿La solución puede observarse en producción?
¿El equipo podrá mantenerla?
La capacidad de responder a estas preguntas será cada vez más importante a medida que los agentes asuman partes mayores de la implementación.
Un análisis publicado por DORA en marzo de 2026 observó que el tiempo ahorrado durante la generación inicial de código suele reaparecer en actividades de auditoría y verificación.
La profesión puede quedar menos concentrada en crear cada componente y más concentrada en demostrar que el sistema completo es correcto.
Comprender el negocio dejó de ser opcional
Un desarrollador que comprende solamente tecnología depende de otras personas para explicar por qué su trabajo es importante.
Esto siempre limitó su influencia.
Ahora también puede limitar su relevancia.
Si la IA puede transformar una descripción clara en una primera implementación, el mayor valor está en crear la descripción correcta.
Esto exige comprender clientes.
Procesos.
Ingresos.
Costes.
Riesgos.
Prioridades.
Una solución técnicamente perfecta puede destruir valor si resuelve un problema sin importancia.
Una solución más sencilla puede crear un impacto enorme si alcanza el punto correcto.
El conocimiento del negocio no significa abandonar la profundidad técnica.
Significa saber dónde aplicarla.
El desarrollador más valioso no será necesariamente quien conozca el mayor número de frameworks.
Puede ser quien consiga comprender un problema confuso y transformarlo en una solución sencilla, segura y económicamente razonable.
La comunicación también es ingeniería
El software es construido por personas que necesitan compartir contexto.
La IA no elimina esta necesidad.
Puede incluso aumentarla.
Cuando crece el volumen de producción, las decisiones necesitan documentarse.
Los límites deben explicarse.
Los riesgos deben comunicarse.
Los resultados deben traducirse para personas no técnicas.
Un desarrollador puede identificar un problema grave y, aun así, fracasar si no consigue demostrar su importancia.
Puede proponer una buena arquitectura y no conseguir construir consenso.
Puede escribir un código excelente para un equipo que no sabe cómo mantenerlo.
La comunicación no es una capacidad secundaria añadida a la ingeniería.
Es parte del mecanismo mediante el cual las decisiones técnicas se convierten en realidad.
La responsabilidad no puede delegarse
La IA puede sugerir.
Ejecutar.
Probar.
Revisar.
Pero no asume responsabilidad profesional de la misma forma que una persona.
Cuando un sistema falla, la empresa no puede finalizar el análisis diciendo que “lo hizo la herramienta”.
Alguien aprobó el resultado.
Alguien lo desplegó.
Alguien decidió que el nivel de verificación era suficiente.
La responsabilidad continuará siendo humana, incluso cuando gran parte de la ejecución no lo sea.
Esto aumenta el valor del criterio.
El profesional necesita saber cuándo aceptar velocidad y cuándo exigir cautela.
Cuándo una solución temporal es suficiente.
Cuándo una decisión necesita una revisión especializada.
Cuándo el riesgo no compensa el beneficio.
Estas decisiones no aparecen necesariamente en el código.
Pero determinan la calidad del software.
Entonces, ¿programar dejó de ser la habilidad principal?
Tal vez la pregunta esté mal formulada.
Programar nunca fue solamente escribir código.
Programar es descomponer problemas.
Representar reglas.
Crear modelos.
Definir estados.
Considerar excepciones.
Construir sistemas que se comporten de forma previsible.
La inteligencia artificial automatiza partes de ese trabajo, especialmente la traducción de una intención ya estructurada en una implementación.
Pero todavía existe mucho trabajo antes y después de esa traducción.
Descubrir la intención.
Cuestionarla.
Contextualizarla.
Evaluar la implementación.
Integrarla.
Operarla.
Corregirla.
Asumir la responsabilidad por ella.
Si consideramos todo esto como programación, entonces programar sigue siendo la habilidad principal.
Si reducimos la programación a la escritura manual de código, está dejando de ocupar el centro.
¿Qué debería aprender ahora un desarrollador?
Los fundamentos continúan siendo esenciales.
Estructuras de datos.
Redes.
Bases de datos.
Sistemas operativos.
Seguridad.
Arquitectura.
Pruebas.
Observabilidad.
Estos conocimientos permiten comprender lo que produce la herramienta.
Pero deben combinarse con otras capacidades.
Formulación de problemas.
Especificación.
Validación.
Comunicación.
Comprensión del negocio.
Priorización.
Toma de decisiones bajo incertidumbre.
Uso crítico de la IA.
El objetivo no es saber menos tecnología.
Es aplicar el conocimiento técnico en un nivel más alto.
La persona que solamente escribe código podrá competir con sistemas que escriben código.
La persona que comprende por qué el código debe existir, cómo debería funcionar y qué consecuencias puede producir utiliza esos sistemas como amplificadores.
El desarrollador no está dejando de programar
Está dejando de ser solamente el mecanógrafo de la solución.
Esto puede parecer una pérdida.
También puede ser una oportunidad.
Durante años, los profesionales se quejaron de pasar demasiado tiempo escribiendo código repetitivo, corrigiendo detalles mecánicos e implementando tareas sin comprender su propósito.
Ahora, parte de ese trabajo puede delegarse.
El tiempo liberado puede utilizarse para investigar mejor los problemas, hablar con usuarios, mejorar sistemas, reducir riesgos y crear soluciones más relevantes.
Pero esto no ocurrirá automáticamente.
Las empresas pueden utilizar la ganancia para aumentar la calidad.
O simplemente para aumentar la cantidad de entregas.
Los profesionales pueden utilizar la IA para ampliar su razonamiento.
O para evitar razonar.
La herramienta no decide.
La habilidad principal continúa siendo pensar
El código es una forma de pensamiento transformada en instrucciones.
Cuando producir esas instrucciones se vuelve más fácil, la calidad del pensamiento se vuelve más visible.
Un requisito mal comprendido genera código incorrecto con mayor rapidez.
Una mala arquitectura puede implementarse en pocos minutos.
Una vulnerabilidad puede repetirse en cientos de archivos.
La velocidad amplifica tanto la calidad como el error.
Por eso, el desarrollador del futuro no será valorado solamente por cuánto puede producir.
Será valorado por saber qué merece producirse.
Por percibir cuándo una respuesta está equivocada.
Por comprender sus consecuencias.
Por transformar posibilidades en decisiones.
Programar no dejó de importar.
Pero escribir código se está convirtiendo solamente en una parte de la programación.
La habilidad principal de un desarrollador nunca fue mover los dedos sobre un teclado.
Siempre fue transformar problemas confusos en sistemas comprensibles.
La diferencia es que ahora resulta más difícil confundir una cosa con la otra.