Los lenguajes de programación importan menos. La ingeniería de software importa más.

¿Siguen importando los lenguajes de programación en la era de la IA? Menos como medida de quién puede producir código y más como conjunto de restricciones del sistema. La IA genera Java, Go, Python, Rust o TypeScript bajo demanda. No elimina sus diferencias de runtime, memoria, concurrencia, seguridad, ecosistema y mantenimiento. La sintaxis se abarata. El criterio de ingeniería, no.

Por eso la frase «los lenguajes de programación ya no importan» acierta de la forma menos útil. Los equipos escriben menos código rutinario a mano y producen más software con agentes. Pero cuanto más rápido llega el código, más valor tiene saber qué debe existir, cómo encajan las piezas, qué hará el runtime bajo presión y cómo podrá otra persona cambiar el sistema sin miedo dentro de dos años.

¿Qué significa realmente que los lenguajes importan menos?

Significa que cae el valor de mercado de traducir un requisito claro a sintaxis válida. No significa que las decisiones de implementación sean intercambiables. Un agente puede traducir una transformación de datos de Python a Go en minutos. Decidir si esa transformación pertenece a un request handler, un worker de cola, una consulta SQL, un stream processor o no debería existir es otra clase de trabajo.

GitHub encuestó a 2.000 personas de equipos de software enterprise en Estados Unidos, Brasil, Alemania e India. Entre el 60% y el 71% dijo que la IA facilitaba adoptar un lenguaje nuevo o entender una base de código existente. Es una erosión real de la barrera lingüística. No demuestra que hayan desaparecido las consecuencias de elegir un lenguaje.

¿De verdad los desarrolladores escriben menos código a mano?

No existe un contador global de código humano frente a código generado por IA; cualquier porcentaje universal sería teatro. La dirección sí aparece en los estudios de uso. La Developer Survey 2025 de Stack Overflow indicó que el 84% usaba o planeaba usar herramientas de IA. Entre quienes ya las integraban parcialmente, escribir código era el uso más habitual, con un 59%.

Dentro de Anthropic—un proveedor, no una población neutral—132 ingenieros e investigadores declararon usar Claude en el 59% de su trabajo y ganar un 50% de productividad. Anthropic también observó un aumento del 67% en pull requests mergeadas por ingeniero y día. La señal útil no es el uplift exacto y autodeclarado. Es la forma del cambio: algo menos de tiempo por tarea, mucho más output y un 27% del trabajo asistido que, sin IA, no se habría hecho.

Un estudio anterior de Anthropic sobre 500.000 interacciones de programación clasificó el 79% de las conversaciones de Claude Code como automatización y el 21% como aumento. En junio de 2026, un análisis de unas 400.000 sesiones describió la división con mayor precisión: las personas tomaban la mayoría de decisiones de planificación—qué hacer—y Claude la mayoría de decisiones de ejecución—cómo hacerlo.

¿La IA hace menos importante la experiencia en software?

No. Cambia qué experiencia produce retorno.

En la investigación de Anthropic de junio de 2026, las sesiones calificadas como novatas alcanzaron éxito verificado el 15% de las veces. Las intermedias o expertas llegaron al 28–33%. Los investigadores vieron que cuanto más conocimiento de dominio aportaba una persona, más trabajo completaba el agente por instrucción. Su conclusión es directa: dirigir un agente hacia el éxito dependía más del dominio de la materia que de saber escribir código.

"Cuando el código abunda, el criterio se convierte en el input escaso. Ya no gana quien teclea más implementación, sino quien decide qué construir, limita al agente y demuestra que el resultado merece ejecutarse."

Eso no significa que todo arquitecto gane y todo programador pierda. La arquitectura sin feedback de implementación acaba en PowerPoint. Los mejores ingenieros siguen suficientemente cerca del código, traces, bases de datos, colas, pipelines e incidentes para detectar cuándo el modelo del sistema es incorrecto. Simplemente gastan menos atención escasa en teclear lo predecible.

¿Por qué parece contradictoria la evidencia sobre productividad?

Porque «la IA hace más rápido al developer» no es un único experimento. Familiaridad con la tarea, generación de herramienta, calidad del repositorio, experiencia, latencia de review y ejecución paralela cambian el resultado.

El estudio controlado de METR de principios de 2025 encontró que desarrolladores open source expertos tardaban un 19% más con IA en codebases que conocían profundamente. En febrero de 2026, METR comunicó que datos posteriores apuntaban a aceleración, pero advirtió que los sesgos de selección y la medición de tiempo hacían débil la estimación. Su actualización honesta dice que a comienzos de 2026 era probable que la IA acelerase más, pero no podía medirse con fiabilidad cuánto.

DORA 2025 resuelve parte de la aparente contradicción: la IA es un amplificador. Encontró relación positiva con throughput y performance de producto, mientras la relación con la estabilidad de delivery seguía siendo negativa. En claro: la IA empuja más cambios por el sistema y expone tests débiles, batches demasiado grandes, feedback lento y platform engineering inmaduro.

La pregunta correcta no es «¿cuánto acelera la IA a un desarrollador?», sino «¿qué ocurre con todo el sistema de delivery cuando sube el throughput de implementación?». Si review, tests, decisiones de arquitectura, seguridad, despliegues y observabilidad no escalan al mismo ritmo, la empresa produce más riesgo semanal, no más valor.

¿Por qué siguen importando los lenguajes de programación?

Porque un lenguaje no es solo sintaxis. Es un conjunto de defaults y garantías que permanece cuando el agente cierra el pull request.

El comportamiento del runtime sigue llegando a la factura

Garbage collection, tiempo de arranque, warm-up del JIT, event loops, scheduling de threads, runtimes async, tamaño del binario y límites FFI afectan a latencia, coste cloud, despliegue y modos de fallo. Un LLM escribe ambas implementaciones. Producción sigue pagando la elegida.

El modelo de memoria sigue llegando a seguridad

El equipo de Android de Google ofrece una comparación real poco frecuente. En 2025, las vulnerabilidades de memory safety bajaron por primera vez del 20% del total de Android al mover nuevo desarrollo nativo hacia Rust. Google estimó una densidad de vulnerabilidades de memory safety más de 1.000 veces menor en Rust que en su histórico C y C++. Los cambios en Rust tuvieron además una tasa de rollback cuatro veces menor y pasaron un 25% menos de tiempo en code review.

Son cifras específicas de Android; no deben pegarse sobre cualquier equipo. Aun así, destruyen la idea de que el lenguaje ya no importa. CISA también recomienda lenguajes memory-safe para nuevas líneas de producto y migración gradual de componentes expuestos o privilegiados. La IA facilita escribir ambos; no deroga sus modelos de seguridad.

Los sistemas de tipos y concurrencia siguen moldeando los fallos

Un compilador que dificulta expresar estados inválidos cambia lo que un agente puede entregar por accidente. Ownership, nullability, tipos algebraicos, límites de efectos, structured concurrency y detección de carreras no son preferencias estéticas. Mueven defectos de producción a generación o compilación, donde cuestan menos.

El ecosistema sigue decidiendo si puedes operar el resultado

Madurez de paquetes, respuesta de seguridad, drivers de base de datos, tooling de observabilidad, soporte cloud, contratación, cadence de releases y gobernanza pesan más que si el agente puede generar una función. Un lenguaje con un benchmark perfecto y un ecosistema operativo fino puede ser la opción cara.

¿Qué gana importancia frente a dominar sintaxis?

1. Diseño de sistemas: límites, propiedad de datos, aislamiento de fallos, consistencia, contratos de integración y capacidad de cambiar una parte sin entenderlo todo.
2. Lectura del runtime: saber en qué se convierte el código: allocaciones, syscalls, procesos, threads, event loops, conexiones, locks, cachés y colas.
3. Arquitectura con evidencia: fitness functions, reglas de dependencia, contract tests, presupuestos de rendimiento, threat models y observabilidad que vuelven ejecutable el diagrama.
4. Modelado de dominio: reglas que el modelo no infiere de un ticket: quién posee el dinero, cuándo un pedido es final, qué significa borrar y qué transiciones son legales.
5. Verificación: tests, análisis estático, review, fuzzing, carga, migraciones, rollback y telemetría. La generación escala solo si el rechazo también escala.
6. Mantenibilidad: naming, cohesión, interfaces pequeñas, decisiones documentadas, pocas dependencias y una codebase que un humano nuevo entiende sin ver el prompt original.
7. Liderazgo técnico: acotar, secuenciar riesgo, establecer estándares, decidir qué no automatizar y conservar ownership dentro del equipo.

Esto amplía nuestro argumento anterior: en los agentes de código, el cuello de botella es el contexto y no la inteligencia. El contexto dice qué existe. El criterio de ingeniería decide qué debería existir y cómo probar que es seguro.

¿Cómo debería elegir lenguaje un CTO hoy?

Para el sistema y la organización, no para el agente. Los agentes reducen el coste de la sintaxis desconocida, así que el equipo puede dar más peso a las propiedades que permanecen.

El stack de moda rara vez es la respuesta. Suele ser un stack principal aburrido que el equipo puede operar, más una excepción deliberada donde otro runtime o modelo de seguridad produzca valor medible. La IA abarata implementar esas excepciones. No abarata poseerlas a cero.

¿Cómo mantener el código generado por IA?

1. Escribe restricciones antes que prompts. Límites de arquitectura, requisitos no funcionales, dependencias prohibidas, reglas de datos y tests de aceptación deben vivir en el repo.
2. Mantén pequeños los cambios. Una intención acotada por pull request. Los diffs enormes convierten el review humano en aprobación ceremonial.
3. Haz ejecutable la arquitectura. Tests de dependencia, linters, schemas, API contracts, policy-as-code y budgets de rendimiento deben fallar automáticamente.
4. Prueba propiedades, no solo ejemplos. Pregunta qué debe seguir siendo verdad con input inválido, reintentos, concurrencia, fallos parciales y ataques.
5. Revisa el diseño antes del diff. Una implementación perfecta del límite equivocado sigue siendo incorrecta. Aprueba el plan y después deja ejecutar al agente.
6. Mide resultados del sistema. Change-failure rate, review, defectos escapados, carga de incidentes, coste por tarea exitosa y tiempo de recuperación; no líneas generadas.
7. Borra agresivamente. La IA abarata añadir código. Un equipo fuerte prueba ideas con esa velocidad y elimina la implementación perdedora, su dependencia y su abstracción.

Si tu base de código generada por IA ya crece deprisa, empieza por nuestra checklist de QA para código generado por IA o la checklist operativa de production-readiness. No se trata de demostrar que el agente escribió mal código. Se trata de demostrar que el sistema es seguro de poseer.

¿Qué debería contratar una empresa para un equipo AI-first?

Personas capaces de moverse entre niveles. Explican la regla de negocio, dibujan el flujo de datos, predicen la consecuencia de runtime, inspeccionan código generado, diseñan el test, leen el trace de producción y hacen comprensible el trade-off para negocio. Un especialista puro en sintaxis es más sustituible. Quien asume outcomes entre capas gana valor.

Para juniors, esto no significa saltarse fundamentos. No puedes revisar memoria, concurrencia, bases de datos o seguridad si nunca aprendiste a verlos. Usa IA para acelerar la práctica, no para evitar construir un modelo mental. Para seniors, significa convertir criterio tácito en restricciones visibles en el repo que puedan seguir agentes y compañeros menos experimentados.

Fuentes y notas de investigación

• Anthropic, Agentic coding and persistent returns to expertise, 16 de junio de 2026 — unas 400.000 sesiones; datos del proveedor y límites de clasificación declarados por sus autores.
• Anthropic, How AI is transforming work at Anthropic, 2 de diciembre de 2025 — encuesta interna, entrevistas y uso; no representa a todos los developers.
• DORA, State of AI-assisted Software Development 2025 — IA como amplificador del sistema de delivery.
• Stack Overflow Developer Survey 2025: AI — adopción y confianza; más de 49.000 respuestas totales.
• METR, actualización del experimento de productividad, 24 de febrero de 2026 — por qué el speedup posterior sigue siendo incierto.
• GitHub, encuesta enterprise sobre herramientas de IA, actualizada el 15 de abril de 2025 — percepción de cambio de lenguaje y comprensión de codebases.
• Google Android Security, Rust in Android, 13 de noviembre de 2025 — datos específicos de Android sobre seguridad, rollback y review.