Las verdades incómodas de ser programador políglota

Introducción

Aprendí a programar en Caml, COBOL (sobre AS/400), C y Assembly, durante mis años de escuela. Disfrutaba de verdad entendiendo cómo hablarle a una máquina a bajo nivel. Me gustó el COBOL y el AS/400 con su espacio sin mouse: la navegación parecia compleja, pero la concentración en una sola pantalla era simple al mismo tiempo.

Lo que aprendi mas tarde es la parte que realmente cuenta hoy para mi carrera en ingenieria. Java, para sistemas tipados y muy escalables. Kotlin, para modernizar Java. Node.js, para proyectos web. Python, para tratamiento de datos y scripting. Y PHP… que sobre todo me enseñó por qué Node.js es mejor para la web.

Hoy se escribe mucho sobre por qué deberías ser programador políglota en la era de la IA, pero no lo suficiente sobre lo que cuesta. Seguramente, la industria con la IA va a empujar a los desarrolladores hacia el poliglotismo, sea por eleccion o no (“AI Coding Agents Are Removing Programming Language Barriers”). Si es un camino que quieres seguir, lo que importa hoy es tener una estrategia sobre qué aprender y explorar, en lugar de centrarte en un lenguaje o un stack concreto. Es también una forma de usar la IA como herramienta de aprendizaje, en vez de dejar que piense por ti.

Después de casi 3 años, vuelvo a traer mis notas de aprendizaje al blog, empezando con algo de nostalgia tras más de 10 años en tecnología.

#1 La carga mental y el cambio de contexto

Al final de una jornada de trabajo, el cambio de contexto puede ser agotador (una de los principales frustraciones del desarrollo con IA). Lo que hago para evitarlo es sencillo: organizo mis días por stack y por proyecto (un día, un contexto). Personalmente me ha resultado más eficiente que repartir cuatro proyectos entre cinco mañanas, y es el cambio que más me ha ayudado a mantener una buena concentracion (incluso antes de la IA).

Aun así, la IA lo ha aligerado, porque herramientas como Copilot en el IDE guardan la sintaxis que ya no tengo que memorizar al 100%, dejando espacio para otras cosas.

Otro truco es elegir un stack práctico y mantenible, y aquí me equivoqué durante un tiempo. Personalmente evito los frameworks SSR muy opinionated como Next o Nuxt; siento que esos frameworks vuelven complicados de mantener sitios que son simples. Ahora prefiero Astro, porque su puesta en marcha se parece a la de un sitio en HTML puro, lo cual es más simple para la carga mental. De hecho, este blog funciona con él, como conté en el artículo Astro Starter Blog I18n template.

#2 La falta de profundidad

Como generalista, a veces aprendes las profundidades de un lenguaje o un framework cuando te encuentras con problemas reales. Rendimiento, caché, seguridad… no en la documentación ni en un curso, sino en un incidente real de producción.

La verdad es que no llego tan hondo en el ecosistema técnico de cada lenguaje o stack que uso. No hay tiempo suficiente en una carrera para hacerlo cinco o mas veces.

He visto equipos construir una API en Node.js porque el desarrollo es más rápido, pero en cuanto escala y llega a grandes volúmenes de datos y de llamadas a la API (junto con otros problemas de mantenimiento), la necesidad de migrar a un ecosistema más estable y con mejor estructura se vuelve evidente. El entorno de migración de destino se evalúa tomando como referencia comportamientos y problemas reales, como cuando Uber pasó de Node.js a Go debido a requisitos técnicos que, en ocasiones, resultan difíciles de prever al inicio de un proyecto.

Aquí es donde la IA ha tenido más impacto para mí, siempre que haya un proceso y una orquestación alrededor. Uso la IA como experta en distintos dominios, por ejemplo:

para investigar y comparar soluciones,
para desarrollar pequeñas PoC y comparar rendimiento (a veces solo por curiosidad),
para revisar y cuestionar mi enfoque o idea,
para subir de versión una biblioteca o un framework obsoleto (un proceso doloroso y costoso),
y para encontrar casos límite de antemano en vez de en producción.

Preguntarle algo a un modelo de IA te da una respuesta (a veces demasiado complaciente, según el proveedor); pedirle que argumente en contra de una idea o un plan te da la profundidad de experiencia que no tuviste tiempo de construir, mientras aprendes al mismo tiempo.

#3 La búsqueda de empleo y el síndrome del impostor

Esta es la que la IA no puede arreglar, al menos (quizá) que la uses como coach de motivación…

Cada búsqueda de empleo, en años anteriores, traía de vuelta la misma frase, durante o después de la entrevista: No tienes X años en el stack Y o Buscamos a alguien con más experiencia en el lenguaje Z. Después varias veces, se queda grabado contigo.

Los títulos de ofertas de trabajo tampoco ayudan, ponen a la gente en cajas en las que el CV de un programador políglota e ingeniero curioso dificilmente encaja.

Pienso que el puesto adecuado es una correspondencia, no un filtro. Es una mezcla entre el tamaño de la empresa (una start-up o una grande), la etapa de vida del producto (un MVP/proyecto nuevo o uno establecido), sus objetivos y, por último, las capacidades del candidato. Cuando eso se alinea, la pregunta de los años por framework deja de ser el bloqueo. Este blog titulado El mito de los años de experiencia (The Years of Experience Myth) vale la pena leerlo para los escépticos.

Una respuesta práctica es construir algo en público: proyectos personales en GitHub, escribir, contribuciones open source. No va a hacer pasar un filtro automático necesariamente, pero sirve de vitrina para las capacidades en lugar de una cuenta de años. Este artículo es parte de ese proceso.

También me uní a la start-up Les Martines como cofundadora técnica, para desarrollar y mantener la aplicación móvil. La mision es perfecta para mí, por ahora como side project pasion: estar aprendiendo e innovando constantemente, con un impacto y un propósito reales para la comunidad que se ha construido dentro de la aplicación.

La IA como herramienta de aprendizaje, no para pensar por ti

Robert C. Martin viene defendiendo la versión más tajante de este argumento: que la IA programa mejor que tú y hay que asumirlo, y que ya no deberías leer código. El hilo de Hacker News sobre el segundo argumento vale tanto como la publicación original. Estés de acuerdo o no con él, algunos ingenieros senior ya no escriben código, y eso es un cambio real en la industria.

Llevo tiempo probando y mejorando pipelines de agentes, con distintos modelos frontier y con modelos open source. El resultado no fue simétrico. Para los modelos frontier de gran capacidad, un buen fichero AGENTS.md a veces basta para desarrollar buen código (con una buena base de código), o al menos una nueva funcionalidad operacional (Context-Augmented Code Generation: How Product Context Improves AI Coding Agent Decision Compliance by 49%). Para los modelos open source, en septiembre de 2026 (Qwen, DeepSeek…), la orquestación de la pipeline es la clave de los buenos resultados; dado que en algunos casos, dar demasiado contexto da peores resultados. Cuanto más pequeño o barato es el modelo, más tiene que venir la estructura de un sistema de orquestación a su alrededor para obtener resultados suficientemente buenos.

Más importante que el lenguaje o el stack técnico: un proyecto bien estructurado y bien documentado da mejores resultados con un agente que uno mal estructurado. La IA puede aprovecharse para aprender y aplicar buenas prácticas de código de calidad, probadas a lo largo de los años y en toda la industria:

la clean architecture y las prácticas de clean code mantienen a los agentes centrados en una capa cada vez durante el TDD,
las prácticas de TDD y BDD para agentes, para que cada funcionalidad esté claramente diseñada y cada trozo de código nuevo se pruebe con los escenarios correctos (How test-driven development amplifies AI success),
los quality gates como salvaguardas — tests unitarios, tests de integración, tests E2E, tests de rendimiento, medidas de cobertura de código… eso mantiene a los agentes en orden y mejora los resultados.

Entender aunque sea lo básico de estas prácticas ayuda a construir sistemas robustos. Los agentes de código también rinden mejor en entornos bien estructurados. Estas prácticas sobreviven a cualquier lenguaje o stack que vayas a aprender en el futuro.

Lo importante hoy es en entender cómo interactúan los sistemas entre sí, la arquitectura de sistemas y los protocolos, y por qué un lenguaje o un stack encaja mejor con un problema. Si todos los lenguajes mencionados en este artículo son olvidades dentro de veinte años (como es casi el caso de Caml y COBOL), el pensamiento crítico y las prácticas de calidad seguirán (con suerte) siendo validas en el futuro.