La IA facilita el código. No convirtió la ingeniería en commodity

La sintaxis se está abaratando. El criterio se está volviendo más valioso.

Últimamente escucho una idea cada vez más cómoda: saber programar, o incluso saber un lenguaje específico, se está volviendo un commodity.

Entiendo por qué suena convincente.

Hoy alguien puede abrir un asistente de IA, explicar lo que quiere, saltar de Python a JavaScript, de SQL a React, y conseguir algo funcionando sin conocer profundamente el lenguaje. Eso es nuevo. Es poderoso. Y sí, cambia el valor de memorizar sintaxis.

Pero creo que la conclusión está mal.

La IA volvió el código más abundante. No convirtió la ingeniería en commodity.

La parte peligrosa del código asistido por IA no es que el modelo pueda escribir código. Puede. La parte peligrosa es que empecemos a confundir una respuesta segura con una buena decisión.

Y esa diferencia importa más que nunca.

La conclusión incorrecta de un cambio real

No estoy argumentando contra las herramientas de IA para programar. Las uso agresivamente, y quiero usarlas más.

La IA debería ayudarnos a escribir más código, más rápido. Debería reducir fricción. Debería ayudarnos a explorar más lenguajes, comparar más alternativas, generar tests, documentar, refactorizar código aburrido y construir prototipos que de otra forma se quedarían en una libreta.

Eso es leverage.

Pero leverage no es lo mismo que criterio.

Las decisiones caras en software rara vez son de sintaxis. Son de arquitectura, dependencias, performance, seguridad, mantenibilidad, costo, escalabilidad, capacidad del equipo, contexto de negocio y dolor futuro de una decisión que parecía fácil cuando el modelo la sugirió.

Escribir código se está volviendo más barato.

Saber qué construir, por qué construirlo, cómo debería escalar y cuándo no construirlo se está volviendo más valioso.

Eso no es commodity. Eso es criterio.

La evidencia tiene más matices que el hype

Si querés la versión optimista de la historia, existe.

Google dijo en Cloud Next 2026 que 75% del nuevo código en Google ya es generado por IA y aprobado por ingenieros. Es una señal enorme. Pero la palabra importante no es generado. La palabra importante es aprobado.

La IA acelera el borrador. Los ingenieros siguen siendo responsables de aceptar.

La evidencia empírica apunta en la misma dirección. Una revisión y encuesta de 2026 sobre GenAI en desarrollo de software encontró el mayor impacto en implementación, testing, documentación y diseño, especialmente en tareas de boilerplate y documentación. Pero también encontró beneficios mucho menores en fases tempranas como planificación y requerimientos, y concluyó que el valor se desplaza hacia calidad de especificación, razonamiento arquitectónico y supervisión.

Esa es la asimetría.

La IA acelera más lo ejecutable que lo ambiguo.

Ayuda mucho cuando ya sabés cómo se ve algo bueno. Es bastante más débil cuando el problema difícil es decidir qué significa bueno.

METR hizo un experimento controlado con desarrolladores open source experimentados, trabajando sobre codebases maduras que ya conocían bien. En ese contexto, los desarrolladores tardaron 19% más cuando podían usar herramientas de IA, aunque esperaban ser más rápidos y todavía sintieron que habían sido más rápidos después.

Eso no significa que la IA no sirva. Significa que el contexto importa.

En sistemas complejos, el costo de promptear, revisar, corregir, reorientar y verificar puede comerse la supuesta ganancia de productividad. El modelo puede escribir el código, pero alguien todavía tiene que entender si ese código pertenece al sistema.

Un estudio revisado sobre GitHub Copilot en open source encontró un aumento neto en contribuciones a nivel proyecto, pero también más tiempo de coordinación. De nuevo, la lectura no es anti-IA. La lectura es que el software es colaborativo, contextual y acumulativo. Más código no es automáticamente más progreso.

Hay una razón por la que la comprensibilidad aparece tanto en investigación de software. Un estudio sobre code review señala que los desarrolladores pasan entre 58% y 70% de su tiempo leyendo código, y encontró que más de 42% de los comentarios de revisión se enfocan en mejorar la comprensibilidad.

Si gran parte del trabajo es leer, entender, coordinar y mantener, entonces reducir la ingeniería a tipear siempre fue una mala descripción.

La IA simplemente vuelve esa mala descripción más peligrosa.

Vibe coding es una cosa. Vibe architecture es otra.

No tengo problema con vibe coding cuando el objetivo es explorar.

Querés probar una idea. Crear una herramienta interna rápida. Aprender una librería. Romper algo y volver a armarlo. Usá IA agresivamente.

Ese es un buen caso de uso.

Pero hay una diferencia entre usar IA para acelerar tu pensamiento y usar IA para evitar pensar.

Lo primero te fortalece. Lo segundo te vuelve dependiente.

Y la dependencia rara vez aparece con un anuncio dramático. Aparece en frases pequeñas que suenan eficientes:

La IA me dijo que use esta librería.

La IA recomendó este framework.

La IA dijo que esta arquitectura es mejor.

La IA eligió el stack.

Al principio suena práctico. Pero a veces la eficiencia es simplemente pereza con mejor branding.

Elegir una librería no es una decisión neutral. Si estás trabajando con datos, elegir entre Pandas, Polars, Spark, DuckDB, BigQuery o un enfoque nativo del warehouse cambia costo, latencia, deployment, observabilidad, gobierno, escalabilidad y quién va a poder mantener la solución después de la primera demo.

La pregunta no es: qué librería es mejor.

La pregunta real es: mejor para qué.

¿Para 10.000 filas o para 500 millones?

¿Para exploración o para producción?

¿Para la laptop de un analista o para un pipeline en Airflow?

¿Para un análisis único o para un dashboard ejecutivo recurrente?

¿Para velocidad hoy o mantenibilidad el año que viene?

La IA puede ayudarte a comparar opciones. Pero vos todavía necesitás saber qué criterios importan.

Si no, el modelo no está asistiendo tu decisión. Está reemplazando tus criterios.

La documentación no murió. Cambió su rol.

Otro argumento que escucho es: ¿para qué leer documentación si la IA puede escribir el código?

Yo lo veo distinto.

La IA cambia por qué leemos documentación.

Antes leíamos documentación principalmente para recordar.

Ahora la leemos para juzgar.

El modelo puede darte un camino. La documentación te ayuda a saber si ese camino es válido.

El modelo puede generar sintaxis. La documentación te muestra las restricciones.

El modelo puede sugerir una implementación. La documentación te dice qué intención tuvieron los maintainers.

El modelo puede responder rápido. La documentación te ayuda a decidir si confiar en esa respuesta.

La superficie es más fácil. La complejidad de fondo no desapareció. Solo se volvió más fácil ignorarla.

Esa es la trampa.

Tratemos la respuesta de la IA como hipótesis, no como respuesta final

Acá sirve pensar de una forma más estructurada, más cercana a cómo trabajan los buenos equipos de resolución de problemas.

Las mejores culturas de problem solving no se construyen sobre confianza. Se construyen sobre estructura, hechos e hipótesis que se ponen a prueba.

Así deberíamos trabajar con IA.

Cuando la IA recomienda una librería, la siguiente pregunta no debería ser: ¿podés implementarlo?

La siguiente pregunta debería ser: ¿por qué esta?

Después: ¿qué alternativas descartaste? ¿Qué supuestos estás haciendo? ¿Qué se rompe a escala? ¿Qué implicancias de seguridad tiene? ¿Cuál es el costo de mantenimiento? ¿Qué pasa si el equipo solo sabe SQL? ¿Qué cambia si la latencia importa más que la simplicidad? ¿Qué cambia si esto tiene que vivir tres años?

Esa es la diferencia entre promptear y dirigir.

Un prompt débil le pide a la IA que elija.

Un prompt fuerte le da contexto de decisión.

Por ejemplo, esto es débil:

¿Qué librería de Python debería usar?

Esto es mucho mejor:

Necesito procesar 50 millones de filas por día, con un objetivo de latencia de cinco minutos. El workflow corre en Airflow, alimenta un dashboard ejecutivo y lo van a mantener analistas que saben Python y SQL. Compará Polars, Spark, DuckDB y BigQuery en costo, performance, mantenibilidad, modos de falla, complejidad de deployment y capacidad del equipo. Recomendá una opción, explicá tus supuestos y decime qué te haría cambiar de opinión.

El segundo prompt no es mejor porque sea más largo.

Es mejor porque contiene criterio.

La IA premia la claridad. Y la claridad viene de entender el problema.

Las mejores compañías no están diciendo: la IA escribe código, entonces ya no necesitamos gente técnica.

Están diciendo algo más interesante: la IA le da más leverage a la gente técnica, entonces necesitamos mejor criterio, mejores estándares y mejores operating models.

McKinsey lo plantea de forma clara: en una fábrica de desarrollo asistida por IA, los humanos fijan dirección, escriben requerimientos estructurados, definen criterios de aceptación, aportan contexto de arquitectura y sostienen la calidad. Los agentes pueden ayudar a generar, testear, revisar y documentar, pero necesitan restricciones claras y contexto rico.

Ese es el patrón real.

La herramienta no es el operating model.

El operating model es quién decide qué importa, quién aprueba la librería, quién es dueño de la arquitectura, quién revisa seguridad, quién define qué significa suficientemente bueno, quién documenta la lógica, quién mantiene el sistema seis meses después y quién explica la consecuencia de negocio cuando el output está mal.

El modelo no puede responder esas preguntas por la organización.

Los líderes sí.

Por eso también conviene ser cuidadosos con los benchmarks. UTBoost encontró que algunos resultados del leaderboard de SWE-bench estaban afectados por tests insuficientes, cambiando 24,4% de las entradas en SWE-bench Verified. Eso no vuelve inútiles a los benchmarks. Significa que pasar una suite de tests no es lo mismo que confiabilidad operativa.

El mismo problema aparece en repositorios reales. Un estudio de 2026 sobre commits generados por IA encontró cientos de miles de issues introducidos en repositorios de producción, mayormente code smells, y mostró que una parte relevante seguía viva en las últimas versiones observadas.

Otra vez, la conclusión no es que el código de IA sea malo.

La conclusión es que el código generado todavía necesita ingeniería.

Los estándares no pueden bajar porque la herramienta se volvió más fácil.

El verdadero commodity

Tal vez hoy conocer 20% de un lenguaje te permite resolver 80% de las tareas comunes.

Eso está buenísimo.

Pero la parte restante es donde viven los problemas reales: escala, seguridad, costo, arquitectura, edge cases, mantenibilidad, gobierno y fit con el negocio.

Justamente ahí es donde más importa el criterio.

Entonces no, no creo que programar sea el verdadero commodity.

El verdadero commodity es la ejecución acrítica.

Promptear sin entender.

Copiar sin leer.

Elegir sin criterios.

Shippear sin ownership.

Aceptar la primera respuesta porque se ve limpia.

Eso es el commodity.

No el código.

No la ingeniería.

No la curiosidad técnica.

No la documentación.

No la arquitectura.

No la capacidad de desafiar una respuesta.

La IA debería ser tu copiloto, no tu reemplazo.

Debería hacerte más rápido, más preciso y más ambicioso. No más pasivo.

El camino que quiero tomar

Quiero que la IA me ayude a escribir más código.

Quiero que me ayude a moverme más rápido entre lenguajes.

Quiero que me ayude a prototipar más ideas, comparar más soluciones, generar mejores tests, documentar decisiones y quitar fricción del trabajo que no merece atención humana.

Pero no quiero perder el músculo.

No quiero dejar de leer.

No quiero dejar de preguntar por qué.

No quiero aceptar una decisión técnica solo porque la respuesta suena segura.

El futuro no va a pertenecer a la persona que memorice cada función.

Pero tampoco va a pertenecer a la persona que delegue cada decisión en la IA.

Va a pertenecer a quien pueda dirigir inteligencia, humana y artificial.

Entonces la pregunta real no es: ¿la IA va a escribir más código?

Lo va a hacer.

La pregunta real es:

Cuando la IA te da una respuesta, ¿todavía sabés pensar?

Y más importante:

¿Qué camino querés tomar?

¿Consumidor de respuestas?

¿O director de mejores decisiones?