La IA multiplica a los buenos desarrolladores

14 min de lectura

La herramienta se volvió más lista. El trabajo, más senior.

La parte barata del desarrollo de software solía ser teclear. Ahora hasta eso se abarata mes a mes.

Eso no significa que el software se haya vuelto simple. Significa que el trabajo que siempre importó ya no está escondido detrás de boilerplate, andamiaje, búsqueda de sintaxis y refactors clericales.

Esto no es una anomalía histórica. El software lleva décadas subiendo por la escalera de abstracción. el compilador de Grace Hopper evitó que los desarrolladores tuvieran que pensar cada tarea en instrucciones de máquina. Después hicieron lo mismo los lenguajes, las bibliotecas estándar, los sistemas operativos, los frameworks y las herramientas. Spring quitó enormes cantidades de plomería empresarial. Vue quitó gran parte de la ceremonia frágil del navegador. Cada capa exitosa se extendió porque eliminó detalles que venían frenando a los desarrolladores.

Los asistentes de programación con IA son el paso más reciente de esa línea, no una ruptura sobrenatural con ella. Abstraen otra capa de fricción: recordar sintaxis, generar boilerplate, pegar piezas de framework, hacer refactors de primer borrador y explorar repositorios durante horas. El patrón viejo sigue igual. Cuando una capa de detalle se abarata, lo escaso pasa a ser el juicio en la capa superior.

Eso importa especialmente para quienes toman decisiones sin ser técnicos, porque muchos siguen leyendo cada nueva abstracción como prueba de que programar se está convirtiendo en trabajo de ensamblaje. No es así. El trabajo de ensamblaje se vuelve más predecible cuando se le quita juicio. El software se vuelve más potente cuando concentra el juicio en menos decisiones, pero mucho más importantes.

Y ese juicio suele estar mucho más cerca de los desarrolladores de lo que muchas organizaciones quieren admitir. La gente tratada como “simplemente programadores” suele ser la que mejor entiende cómo se comporta el negocio cuando toca bases de datos, integraciones, excepciones, datos de clientes, reportes y esos bordes feos que nunca aparecieron en la presentación. Puede que no tengan el título oficial de expertos de negocio. Aun así, muchas veces son quienes tienen la comprensión operativa más relevante de lo que el sistema realmente hace.

Esa es una de las mentiras centrales de The Last Batch, episodio 1: Never Missed a Run Publishes on June 18, 2026. Come back then. , nuestra telenovela sobre la industria del software, y vuelve a aparecer más adelante en la serie. Los SMEs oficiales conocen fragmentos, historia, rituales y lenguaje protector. Los desarrolladores saben dónde se ejecutan de verdad las reglas, de dónde salen de verdad los números y dónde se va a romper primero la realidad. Aun así, liderazgo se pone del lado de quienes llevan la etiqueta de SME y trata a los desarrolladores como manos. Ese patrón no es ficción en el sentido importante. Pasa todo el tiempo. A los desarrolladores se los relega como implementadores que supuestamente no pueden entender el negocio, aunque sean justamente quienes ven con más claridad cómo funciona de verdad.

Por eso reducir a los desarrolladores a simples codificadores es un error de gestión carísimo. Cuando la IA elimina más trabajo clerical de programación, lo que queda se ve todavía más claramente como trabajo de juicio: interpretar intención, reconciliar contradicciones, rastrear consecuencias y decirle a la organización verdades incómodas sobre sus propias operaciones.

La gente técnica normalmente ya lo sabe en los huesos. Ha visto este patrón suficientes veces como para reconocerlo al instante: la máquina mejora, la abstracción sube y la parte tonta del trabajo se encoge. La parte difícil no. Solo se vuelve más difícil fingir que siempre fue simple.

Lo que queda es la parte cara:

• decidir qué debe hacer el sistema
• decidir qué tradeoffs son aceptables
• detectar dónde la IA está equivocada con total seguridad
• saber qué hay que probar, observar y limitar
• entender cómo se comportará la nueva funcionalidad dentro de la realidad fea que ya existe

Por eso quienes mejor usan IA en software no suelen ser quienes escriben los prompts más ingeniosos. Suelen ser quienes tienen el modelo interno más rico de cómo fallan los sistemas.

El trabajo sí se movió hacia capas más altas

Si usas GitHub Copilot o Claude Code en serio durante unas semanas, el patrón se vuelve obvio.

El modelo puede escribir el handler de la ruta. Puede generar la base del test. Puede refactorizar la clase. Puede montar la UI. Puede explicar el módulo viejo. Incluso puede sugerir un arreglo de despliegue que se ve plausible.

Lo que no puede hacer de forma fiable es decidir si esa ruta debería vivir en este servicio, si el test está probando lo correcto, si el refactor aclara el dominio, si la UI está tapando un proceso roto o si el arreglo de despliegue está a punto de convertir un parche local en un problema global.

Por eso Building Products in the Age of AI importa. El cuello de botella se movió. La tecleada se encogió. El juicio no.

Por eso también un desarrollador fuerte y orientado a producto puede parecer de pronto casi sobrehumano. No porque la herramienta lo haya vuelto mágico. Sino porque la herramienta quitó fricción alrededor de un trabajo que esa persona ya sabía dirigir.

Un solo product developer competente puede cubrir hoy partes de trabajo que antes se repartían entre frontend, backend, QA, documentación y una parte del descubrimiento de producto. No de forma perfecta. No en todos los contextos. Pero sí con la frecuencia suficiente como para cambiar la economía del asunto.

La compresión es real.

La forma tradicional del equipo era, en parte, una respuesta al costo de coordinación y al costo de teclear. La IA pega sobre ambos.

Por qué los veteranos ganan un apalancamiento desproporcionado

La ventaja del desarrollador con experiencia no es mística. Es concreta.

Saben dónde miente el software.

Saben que una demo alegre todavía puede esconder un desastre transaccional. Saben que un unit test en verde todavía puede no ver el fallo de producción. Saben que la integración que “debería ser simple” suele ser la parte con veinte años de sedimentos encima. Saben qué bordes merecen paranoia y cuáles son puro adorno.

Cuando la IA propone tres opciones, el veterano suele tirar dos a la basura en segundos. No porque sea más inteligente en algún sentido abstracto. Sino porque ya vio fracasar esas dos opciones, a veces más de una vez, con otros nombres y con mejores diapositivas.

Ahí está el apalancamiento.

El modelo le da borradores instantáneos, alternativas instantáneas, andamiaje instantáneo y recuperación instantánea de contexto. La experiencia le dice dónde apretar, dónde desconfiar, dónde simplificar y dónde frenar a la máquina antes de que la velocidad se convierta en daño.

Aquí hay otra palanca que la gente con menos experiencia suele pasar por alto. Con suficientes años encima, no siempre hace falta leer cada línea a la vieja usanza para llegar a un hallazgo útil. Puedes interrogar la base de código a través del agente. Preguntar por qué existe un límite, qué se rompería si una regla cambiara de lugar, dónde está duplicado el estado, qué módulo posee de verdad una decisión. Y luego escuchar las respuestas como un mecánico experimentado escucha un motor. El valor no está en confiar a ciegas. El valor está en que la experiencia profunda te permite detectar verdad, evasión y olor estructural dentro de la propia conversación.

Ahí es donde mucha gente menos experimentada cae rápidamente en el ritual. Oye que el código generado puede estar mal, lo cual es cierto, y entonces salta a la respuesta automática: leerlo todo a mano y mandarlo a revisión por pull request. En la práctica eso suele convertirse en otra forma bien intencionada de teatro. El equipo mira diffs generados por IA que nadie sostiene por completo en la cabeza, deja algunos comentarios, aprueba y declara el riesgo gestionado. Como explica Los Pull Requests nunca fueron pensados para tu equipo, no se vuelven más significativos solo porque el código venga de un modelo.

El patrón más fuerte es otro. Usa el agente como interfaz de alta velocidad hacia el repositorio, usa tests y ejecución para fijar la realidad, y usa juicio experimentado para decidir qué respuestas son lo bastante sólidas como para confiar en ellas. Eso no es saltarse la revisión. Es mover la revisión al nivel donde la experiencia realmente se acumula.

Por eso The Gray Beard and the Machine conecta tanto con desarrolladores mayores. La herramienta no invalida las décadas. Las monetiza con más fuerza.

Y sí, esto cambia lo que una sola persona puede hacer.

Un desarrollador serio, con juicio de producto, disciplina de entrega, gusto decente de diseño y asistencia de IA, hoy puede construir cosas para las que hace poco habrías necesitado un equipo de producto entero. La conclusión honesta no es que los equipos siempre fueran una farsa. La conclusión honesta es que mucha estructura de equipo existía para gestionar fricción, traducción y costo de herramientas. Si quitas suficiente de eso, la persona que puede sostener el producto entero en la cabeza se vuelve brutalmente efectiva.

Por qué la inexperiencia produce sistemas Frankenstein

La persona menos experimentada también recibe velocidad. Eso es real. El problema es lo que hace con ella.

El asistente suena competente. Explica con seguridad. Se disculpa con elegancia. Incluso acepta críticas con un tono extrañamente halagador. “Tienes razón” puede ser la frase más peligrosa de toda la interfaz.

Entonces la persona sigue adelante.

Un patrón de repositorio sacado de un tutorial. Una capa de servicios de otro. Lenguaje orientado a eventos de un tercero. Una solución de estado en React copiada de un foro. Tests que sobre todo fijan detalles de implementación. Una capa de caché que nadie necesitaba. Una cola introducida porque el modelo decidió que quizás más adelante la escala importe. Tres convenciones de nombres. Cuatro estilos de abstracción. Un pequeño monstruo orgulloso cosido con ejemplos populares.

Todo se ve moderno. Nada pertenece a lo mismo.

Ese es el peligro real de la IA para los desarrolladores menos experimentados. No es pereza. No es debilidad moral. No es falta de esfuerzo.

Es falta de un modelo interno del sistema.

Sin conocimiento de sistemas, la persona no detecta cuándo la IA cambió de dialecto arquitectónico a mitad de frase. No distingue qué complejidad es esencial y cuál fue sugerida solo porque el modelo la vio cerca en otra parte. No distingue cuándo una suite de tests es decorativa en lugar de protectora. No distingue cuándo la base de código ya suena como cinco blog posts distintos discutiendo dentro de un armario.

Por eso Vibe Coding Isn’t Software Development no es una queja de señor mayor. Es una descripción de lo que pasa cuando la generación corre más rápido que el juicio.

Cuando el repositorio ya viene torcido

Esto importa porque los asistentes no solo generan fragmentos. Muchas veces generan trabajo completo. Endpoints. Tests. Refactors. Configuración. Documentación. Borradores de migración. Justamente por eso un repositorio malo se vuelve tan peligroso.

Si la base de código ya mezcla patrones, duplica reglas, vive sin tests y se explica con una maraña de archivos markdown que se contradicen, el asistente no llega como un senior severo a ordenar la casa. Normalmente empieza absorbiendo los malos hábitos del cuarto.

Lo he visto de forma directa en una base Python vibe-coded sin tests y con un montón de archivos de especificación de Claude tirando en direcciones distintas. El asistente intentaba recombinar una y otra vez exactamente lo que ya existía: patrones a medias, instrucciones contradictorias, abstracciones flojas y mucho pegamento escrito con confianza. Mezclaba responsabilidades porque el propio repositorio ya había normalizado esa mezcla.

Esa es la trampa que muchos líderes no técnicos no ven. Creen que la IA compensará una base de código débil porque el modelo parece más amplio que las personas que la construyeron. En la práctica, el modelo suele amplificar la cultura local del repositorio. Si la base enseña contradicción, el asistente aprende contradicción. Si la guía en markdown se contradice a sí misma, el asistente satisface una instrucción violando otras dos. Si no hay tests, no tiene ninguna razón seria para detenerse.

La salida no es otro montón de archivos de especificación más bonitos. La salida es darle realidad verificable al sistema.

En esa base Python, el progreso real empezó recién cuando usamos la propia IA para ayudar a construir tests, fijar el comportamiento y quitar contradicciones de la guía en markdown. En cuanto el repositorio tuvo restricciones ejecutables en lugar de deseos en competencia, el asistente se volvió mucho más útil. Seguía haciendo falta juicio. Simplemente tenía menos oportunidades para improvisar una coherencia equivocada.

La evidencia externa apunta en la misma dirección.

• El informe de GitClear Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality encontró más code churn, más código añadido y copiado, y menos reutilización.
• Anthropic advierte en Building effective agents que los sistemas con agentes pueden generar errores compuestos y subraya que los agentes de programación funcionan mejor cuando las soluciones son verificables mediante tests automatizados.
• OpenAI explica en Why language models hallucinate que los modelos producen salidas plausibles pero falsas y que están empujados estructuralmente a adivinar cuando faltan mejores restricciones y evaluación.

Si juntas esas tres cosas, la conclusión práctica es bastante brutal. Un asistente de IA en un repositorio desordenado no es una fuerza de limpieza. Es un acelerante con buenos modales. Si quieres que mejore la base en vez de profundizar la confusión, necesitas tests, menos instrucciones contradictorias y alguien con suficiente juicio de sistemas para distinguir entre consistencia local y corrección real.

La gente de proceso ahora optimiza la capa equivocada

Esa es la parte que debería preocupar a cada vendedor de frameworks, a cada adicto a la ceremonia y a cada gerente que todavía cree que entregar software consiste sobre todo en enrutar tickets entre especialistas humanos.

Durante veinte años, una gran parte de la cultura de proceso intentó “mejorar” la programación estandarizando handoffs:

• quién escribe requisitos
• quién los traduce a tickets
• quién los toma
• quién los revisa
• quién los aprueba
• quién reporta estado hacia arriba

Todo ese aparato ya era dudoso cuando teclear y montar andamiaje consumían mucho tiempo.

Con IA, empeora.

Ahora el trabajo puede vivir dentro de un bucle estrecho: idea, borrador, crítica, test, ajuste, despliegue. La parte cara no es mover trabajo entre roles. La parte cara es si la persona dentro del bucle tiene el juicio suficiente para conducirlo.

Así que cuando las organizaciones responden a la IA con más plantillas, más checkpoints, más separación de roles y más teatro de “gobernanza”, están optimizando la capa equivocada. Administran la carcasa clerical alrededor del desarrollo mientras la palanca real ya subió hacia síntesis, arquitectura, criterio de producto y juicio técnico.

Por eso mucho discurso sobre mejora de procesos va a envejecer mal. Ya estaba demasiado obsesionado con la actividad visible. Ahora además está defendiendo un flujo construido alrededor de un cuello de botella que ya no domina.

Si quieres entrega predecible, sigues necesitando tests, feedback, observabilidad y despliegue disciplinado. Sigues necesitando The Engine of Predictable Software Delivery. Pero necesitas menos teatro alrededor de la gente que hace el trabajo y más respeto por el juicio que esa gente trae al bucle.

Nadie fue reemplazado. El trabajo cambió.

El trabajo sigue siendo desarrollo de producto. Sigue siendo desarrollo de software. Sigue siendo trabajo desordenado, político, técnico y ambiguo.

Pero el centro de gravedad cambió.

Menos tiempo se va en teclear, traducir y montar estructuras. Más tiempo se va en encuadrar, probar, limitar, integrar y decidir. El nivel de abstracción subió. La demanda de juicio subió con él.

No es una historia sobre desarrolladores desapareciendo. Es una historia sobre abstracciones organizativas mediocres desapareciendo primero.

Quienes van a prosperar serán quienes puedan sostener intención de producto, comportamiento del sistema, realidad del usuario y consecuencias técnicas dentro de la misma conversación. A veces eso seguirá siendo un equipo. A veces será una sola persona alarmantemente capaz con una cadena de herramientas de IA y suficientes cicatrices como para desconfiar de una salida demasiado pulida.

Si quieres la versión telenovela de este patrón, nuestra serie sobre la industria del software The Last Batch, episodio 6: Outside the Door Publishes on July 23, 2026. Come back then. muestra lo que pasa cuando liderazgo decide que los “hired hands” pueden teclear, pero no juzgar. La tarjeta de acceso dice en voz alta la parte fea: la competencia es bienvenida hasta que amenaza la comodidad equivocada.

Ese es el cambio real.

La máquina no volvió obsoleto el juicio.

Solo volvió imposible esconder el juicio detrás del proceso.