La trampa del código servido: cómo los asistentes de IA están transformando a los programadores en operadores de una máquina que no entienden

Hay una escena que se repite en oficinas de software de Ciudad de México, São Paulo, Buenos Aires y Bogotá con la misma coreografía. Un desarrollador escribe media línea, el asistente completa las otras ocho, el código compila, la tarea se cierra, el ticket pasa a “hecho”. Nadie miente en esa escena: el trabajo salió más rápido. La pregunta que casi nadie hace —porque el ritmo del sprint no deja espacio para hacerla— es qué se aprendió en el proceso. Y la respuesta incómoda, la que esta semana quedó más expuesta que de costumbre, es que la respuesta puede ser: nada. O peor: se desaprendió.

Esa es la tensión que quiero desmontar acá. No la fácil —“la IA reemplaza programadores”— sino una más silenciosa y más peligrosa por ser gradual: los asistentes de código no reemplazan al programador de golpe; lo van vaciando. Lo convierten en un operador eficiente de una máquina cuya lógica interna deja de entender. Y venden ese vaciamiento como si fuera productividad. El truco retórico es exquisito porque la métrica que usan para medir el “éxito” —tareas por minuto, líneas por hora— es exactamente la métrica que oculta lo que se pierde. Como advirtió Katharine Hayhoe en otro contexto, no hay medición neutral: medir es elegir qué contar y, por lo tanto, qué dejar de contar.

La pregunta trampa: calidad o slop

Empecemos por el estudio de la semana, el que ordena buena parte del debate: una investigación con 150 desarrolladores que se pregunta si el código generado por IA es de “calidad” o es slop —esa palabra que ya circula en la industria para nombrar el código que compila, que funciona, que pasa los tests superficiales, y que sin embargo es basura estructural que se derrumba cuando el producto entra en carga real Is AI-generated code all slop and no substance? Depends who’s writing it.

Fíjense en el movimiento. La pregunta “¿calidad o slop?” parece crítica, escéptica, responsable. Pero es ella misma el sesgo. Al enmarcar el problema como una propiedad del código —¿es bueno o malo el output?— desvía la atención de la propiedad del programador: ¿qué le está pasando a su criterio, a su capacidad de comprensión, a su autonomía de debugging cuando delega sistemáticamente en la máquina? Un equipo puede producir código de “calidad” según los tests y, aun así, estar erosionando la competencia de sus desarrolladores. La calidad del entregable y la competencia del que lo entrega son dos ejes distintos, y la pregunta de la semana los colapsa en uno solo. Es un truco de encuadre: te hace discutir el sabor del plato para que no preguntes qué le pasa al cocinero que ya no sabe cocinar sin la receta pre-servida.

Y hay evidencia de que el cocinero se está atrofiando. Un estudio ampliamente comentado encontró que desarrolladores experimentados que usaron herramientas de IA para tareas en repositorios que conocían bien tardaron más tiempo del que creían haber ganado —percibían una aceleración que la medición objetiva no confirmaba Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. La brecha entre la productividad percibida y la real es el dato central: sentir que vas más rápido no es ir más rápido. Y la sensación de velocidad es precisamente lo que la herramienta está diseñada para producir, porque esa sensación es lo que renueva la suscripción.

La métrica no es del que la mide, es del que la vende

Acá está el nudo que me interesa para la lente de herramientas. Cuando un producto de software se mide por “tareas completadas por unidad de tiempo”, vale la pena preguntar quién eligió esa vara. Y la respuesta es que la eligieron —o al menos la promovieron con enorme éxito— los que venden las herramientas. GitHub publica cifras de que Copilot ayuda a completar tareas hasta 55% más rápido Research: quantifying GitHub Copilot’s impact on developer productivity and happiness. El número es real dentro de su propia definición. Pero “más rápido” es una métrica que el vendedor puede ganar por construcción, porque la herramienta está optimizada para exactamente esa variable: producir output plausible en menos tiempo.

Lo que no aparece en esas cifras es la variable de largo plazo: la comprensión del sistema, la capacidad de sostener una arquitectura en la cabeza, el debugging que requiere entender por qué algo falla y no solo pegar el stack trace en un chat. Esas competencias no se degradan en un trimestre; se degradan en años, silenciosamente, y para cuando se notan ya no hay una generación de desarrolladores que las tenga. La adopción de estos asistentes es masiva: más del 60% de los desarrolladores reporta usar herramientas de IA en su flujo de trabajo, según encuestas recientes de la industria 2024 Developer Survey. Cuando una práctica se vuelve infraestructura antes de que entendamos sus efectos formativos, la discusión sobre si adoptarla ya la perdimos; queda la discusión, más modesta, sobre cómo no ser destruidos por ella.

Es útil recordar acá una intuición vieja. La tecnología no es un instrumento que usamos desde afuera sin que nos toque; nos reconfigura mientras la usamos. Marshall McLuhan lo formuló como la distinción entre figura y fondo: prestamos toda la atención al contenido brillante —el código que aparece— y ninguna al medio que lo produce y a cómo ese medio nos reorganiza Understanding Media - Critical Edition. El asistente de código es el fondo perfecto: invisible mientras funciona, y funciona tan bien que dejamos de ver que nos está enseñando a no pensar.

“Sin costo adicional” no es gratis, es una estrategia de encierro

El segundo movimiento de la semana es económico, y es donde la etiqueta más inocente esconde la lógica más dura. Los proveedores anuncian funciones de IA “sin costo adicional”, integradas en planes que ya tenías Google is bringing Gemini CLI to your terminal — and it’s free. Suena a regalo. No es un regalo: es una estrategia.

Precio cero no significa costo cero. Significa que el costo se paga en otra moneda —integración, datos, dependencia— y que se paga después. La función “gratuita” profundiza la integración de la herramienta en tu flujo de trabajo hasta un punto en que salir se vuelve caro: tu equipo aprendió a trabajar de esa manera, tus pipelines la asumen, tu productividad medida (esa métrica del vendedor otra vez) cae en picada si la quitas. Eso es lock-in de plataforma, cierre de plataforma, y es el mecanismo clásico por el cual una herramienta se vuelve infraestructura de la cual ya no podés prescindir. Shoshana Zuboff describió esta lógica con precisión: la gratuidad aparente es el anzuelo de un modelo cuyo verdadero producto es la conducta del usuario capturada, predicha y modelada The Age of Surveillance Capitalism. En el caso de los asistentes de código, lo que se captura es aún más íntimo que la conducta de navegación: es la manera exacta en que resolvés problemas, tus patrones de razonamiento, tu forma de estructurar sistemas. La herramienta gratuita aprende de vos mientras te va desaprendiendo a vos.

Y el “sin costo adicional” tiene un segundo filo específico para América Latina. Cuando la versión gratuita es la puerta de entrada, la desigualdad se traslada al interior de la herramienta misma. El plan gratuito entrega el peor autocompletado, la cuota más limitada, la latencia más alta; la versión premium de alto rendimiento exige suscripciones en dólares que en moneda local son sencillamente impagables para el desarrollador promedio. El resultado es una percepción sesgada: el programador que solo conoce la versión gratuita cree que eso es la herramienta, y calibra sus expectativas —y su criterio— sobre una experiencia empobrecida. La brecha no es solo de acceso; es de imaginación técnica sobre lo que la tecnología puede hacer.

Los 650 mil millones y la dirección del río

Si querés saber hacia dónde va una tecnología, seguí el capital. Las grandes tecnológicas anunciaron planes de inversión en infraestructura de IA que suman cifras del orden de cientos de miles de millones de dólares para los próximos años Big Tech’s AI spending could top $320 billion this year. Esa magnitud no es un detalle contable: es una declaración de trayectoria. Se está construyendo un mundo donde la capacidad de generar código —y casi cualquier cosa— está centralizada en un puñado de centros de datos controlados por un puñado de corporaciones.

Kate Crawford lo documentó con crudeza: la IA no es “en la nube”, una abstracción etérea; es una industria pesada, extractiva, planetaria, que va desde la minería de litio hasta el trabajo invisible de anotadores mal pagados en el Sur global The Atlas of AI - Power, Politics, and the Planetary Costs. Cuando hablamos de la infraestructura donde vive tu asistente de código, hablamos de esa cadena material entera, y de una asimetría de poder donde América Latina aporta recursos y trabajo barato y recibe la herramienta terminada como servicio de suscripción. García Canclini nombró la ansiedad de fondo de esta configuración: la pregunta ya no es solo la explotación sino la irrelevancia, el miedo a “no ser necesarios para ocupar trabajos” Ciudadanos reemplazados por algoritmos. Para el desarrollador latinoamericano, el destete de habilidades y la centralización de infraestructura convergen en la misma amenaza: volverse prescindible frente a una máquina cuya lógica no controla y cuyos dueños están en otro hemisferio.

Frente a esa centralización, las alternativas abiertas —CodeLlama, StarCoder2 y los modelos de código que se pueden correr y auditar internamente— son la contracorriente. No son marginales por ser peores; son marginales porque nadan contra 650 mil millones de dólares de gravedad. Y sin embargo, para la región, son la única vía material hacia algo parecido a la soberanía técnica: modelos que un equipo puede alojar, entender, ajustar y auditar sin firmar la dependencia a una API que puede cambiar de precio, de términos o de disponibilidad mañana.

El slop como característica, no como falla

Quiero detenerme en un punto que suele tratarse como problema técnico transitorio y que es, en realidad, estructural. El slop —el código que funciona hasta que no— no es un defecto que las próximas versiones vayan a corregir del todo. Es una consecuencia predecible de la lógica de diseño de la herramienta.

Un asistente de código entrenado para maximizar la probabilidad del siguiente token produce, por construcción, código estadísticamente plausible: se parece al código correcto porque se parece al código que existe en su entrenamiento. Pero “parecerse al código correcto” y “ser correcto para este sistema, en este contexto, bajo esta carga” son cosas distintas, y la diferencia solo la puede juzgar alguien que entienda el sistema. Ahí está la trampa cerrándose sobre sí misma: la herramienta produce output que requiere criterio experto para evaluar, al mismo tiempo que erosiona el criterio experto necesario para evaluarlo. El estudio de los 150 desarrolladores muestra justamente esto: la calidad del código generado depende enormemente de quién lo escribe —o, más precisamente, de quién lo supervisa Is AI-generated code all slop and no substance? Depends who’s writing it. El senior que ya sabe usa la herramienta como acelerador. El junior que todavía no sabe la usa como muleta, y nunca aprende a caminar.

Esto tiene una consecuencia perversa para el pipeline de talento. Si el valor del asistente se realiza plenamente solo en manos de quien ya tiene la competencia profunda, pero la herramienta bloquea la adquisición de esa competencia en quien recién empieza, entonces estamos quemando la escalera por la que subimos. Los seniors de hoy se formaron leyendo código malo, rompiéndolo, entendiendo por qué se rompió. Los que empiezan hoy delegan ese aprendizaje en una máquina que les da la respuesta antes de que hayan tenido la oportunidad de equivocarse productivamente. La pedagogía del error —esa que Freire habría reconocido como el proceso donde el sujeto nombra el mundo en lugar de recibirlo depositado Pedagogía del oprimido— se cortocircuita. El asistente deposita código en el desarrollador como pedagogía bancaria deposita información en el alumno pasivo. Y el resultado es el mismo: consumo sin comprensión.

El contraargumento que hay que tomar en serio

Sería deshonesto no plantear la objeción fuerte, porque existe y tiene peso. Toda tecnología de abstracción genera esta ansiedad, dirá el escéptico de mi escepticismo. Cuando los compiladores reemplazaron el ensamblador, los viejos programadores se lamentaron de que la nueva generación no entendería la máquina “de verdad”. Cuando aparecieron los frameworks de alto nivel, se dijo que los desarrolladores web ya no sabrían lo que pasaba por debajo. Y sin embargo la industria no colapsó; simplemente subió el nivel de abstracción y liberó capacidad cognitiva para problemas de orden superior. ¿No es el asistente de código apenas el siguiente escalón de esa misma escalera de abstracción histórica?

El argumento merece respeto, pero creo que confunde dos cosas distintas. El compilador es una abstracción determinista y transparente: hace siempre lo mismo, se puede especificar, se puede aprender su comportamiento, y por debajo hay una capa que —si necesitás— podés inspeccionar y entender. El asistente de código es una abstracción probabilística y opaca: no hace siempre lo mismo, no se puede especificar su comportamiento, alucina, y no expone una capa inferior comprensible sino una caja negra estadística. Abstraer sobre un compilador es pararse sobre suelo firme que no necesitás ver. Abstraer sobre un modelo generativo es pararse sobre una niebla que a veces te sostiene y a veces te deja caer, sin que puedas saber de antemano cuál de las dos cosas va a hacer. La diferencia no es de grado sino de naturaleza. Y el criterio que necesitás para saber cuándo la niebla te sostiene y cuándo te deja caer es precisamente el criterio que la herramienta erosiona.

Hay un segundo matiz que la evidencia obliga a conceder. No todo es dependencia: para tareas repetitivas, boilerplate, código que ya escribiste mil veces, el asistente libera tiempo genuino sin costo formativo real —no aprendés nada nuevo escribiendo la misma configuración por milésima vez. El problema no es usar la herramienta; es la ausencia de un criterio para distinguir cuándo delegás trabajo mecánico y cuándo delegás el aprendizaje. Esa distinción no viene en el producto. Hay que construirla afuera, deliberadamente, contra la corriente del diseño que empuja a delegar todo por igual.

Las lentes LATAM: aplicabilidad y alternativas

Acá es donde el análisis abstracto tiene que aterrizar en la geografía concreta de la región, y donde dos de nuestras lentes hacen el trabajo más pesado.

Aplicabilidad. Para la industria tecnológica latinoamericana, el problema no es filosófico sino operativo, y tiene un nombre: la capacidad de los equipos para distinguir código de calidad de slop que compila. México exporta un 19,3% de alta tecnología sobre su manufactura total, la cifra más alta de las economías grandes de la región México (Mexico), y su industria de software y SaaS es la que más ha adoptado estos asistentes. Pero adopción no es criterio. Una empresa que impone Copilot a todo su equipo para subir la métrica de velocidad, sin protocolos de revisión de código asistida por IA, está optimizando exactamente la variable equivocada —la del vendedor— y firmando su propia deuda técnica futura. La recomendación material es incómoda porque va contra el ritmo del negocio: antes de imponer la herramienta, hay que construir el protocolo de revisión que la contrapese. Desacelerar la entrega a corto plazo para no vaciar la competencia del equipo a largo plazo es una decisión que ningún tablero de métricas por defecto va a recomendar, porque los tableros los diseñó quien vende la herramienta.

Argentina, con un ILIA de 67,5 y un ecosistema de talento históricamente fuerte pero golpeado por una economía que expulsa profesionales hacia plataformas globales Argentina (Argentina), enfrenta la versión aguda del problema: sus mejores desarrolladores migran —física o remotamente— hacia empleadores del Norte que miden productividad con la métrica del vendedor. El desarrollador argentino que compite en ese mercado tiene un incentivo directo a maximizar tareas por minuto, es decir, a acelerar su propio destete de habilidades para seguir siendo contratable en el corto plazo. La estructura económica premia exactamente la conducta que a mediano plazo lo vuelve prescindible. Es una trampa de doble fondo.

Y la brecha se ensancha hacia abajo. El Salvador, con un ILIA de 42,9 y una fracción del PIB per cápita de las economías grandes El Salvador (El Salvador), muestra el otro extremo: donde la infraestructura, el poder adquisitivo y la formación son más débiles, la única versión de estas herramientas disponible es la gratuita degradada, y la posibilidad de correr modelos abiertos internamente —que exige capacidad de cómputo y equipos técnicos formados— es más remota. La desigualdad regional no se reduce con estas herramientas; se refracta en su interior.

Alternativas. Frente a este cuadro, la alternativa no es luddita —nadie va a prohibir los asistentes, ni tendría sentido— sino doble. Primero, entrenamiento explícito en evaluación crítica de código generado y en arquitectura de software como competencias de primer orden, no como adornos. Saber evaluar lo que la máquina produce es la habilidad que la máquina no puede erosionar porque es la habilidad que la vigila. Segundo, la experimentación material con modelos abiertos —CodeLlama, StarCoder2— corridos en infraestructura propia o regional, que permiten a un equipo entender, auditar y ajustar la herramienta en lugar de consumirla como servicio opaco. Silvia Ribeiro y otros han insistido en que la soberanía tecnológica no es autarquía sino capacidad de decidir; correr tu propio modelo no te hace independiente del mundo, pero te hace dueño de la caja que hoy es negra. Es más lento, más caro por unidad, menos brillante en el demo. Es también la única vía que no termina en dependencia condenada a la obsolescencia.

Vale nombrar la anticipación aunque sea brevemente, porque es la lente que mira más lejos: la región haría bien en incorporar la evaluación de código generado como competencia acreditable explícita en la formación de talento técnico, y en construir estándares regionales que no dependan de la definición de “productividad” que dicta el vendedor. Anticipar acá significa negarse a que la métrica del vendedor se vuelva el estándar de facto por ausencia de una alternativa nuestra.

Lo que queda abierto

Vuelvo a la escena del principio, la del desarrollador que escribe media línea y recibe ocho. No hay villano en esa escena, y esa es la parte más difícil de asir. Nadie decidió vaciar a la próxima generación de programadores; la decisión emergió de mil elecciones racionales de corto plazo —cerrar el ticket, subir la métrica, renovar la suscripción gratuita— cada una de las cuales tenía sentido por separado y cuya suma es un destete silencioso. Así funcionan las tecnologías que reconfiguran: no por imposición sino por conveniencia acumulada, hasta que un día notás que ya no sabés hacer lo que antes hacías sin ellas, y que salir cuesta más que quedarte.

La pregunta que la semana deja abierta para América Latina no es si adoptar estos asistentes —eso ya está decidido por la gravedad del mercado— sino con qué criterio, construido por quién y midiendo qué. Si aceptamos la vara del vendedor —tareas por minuto— firmamos la dependencia y disfrazamos el deterioro de progreso. Si construimos nuestra propia vara —comprensión del sistema, autonomía de debugging, capacidad de evaluar lo generado— tenemos al menos la posibilidad de usar la herramienta sin ser usados por ella.

Quedan tres preguntas que no puedo cerrar y que la región tendrá que responder con hechos, no con ensayos. La primera: ¿puede una industria latinoamericana estructuralmente presionada por la velocidad y los costos permitirse el lujo de desacelerar para proteger la competencia de sus equipos, cuando la competencia global premia lo contrario? La segunda: ¿existe la voluntad institucional y el músculo técnico para invertir en modelos abiertos y en infraestructura propia, o la comodidad del servicio gratuito degradado terminará de fijar la dependencia? Y la tercera, la más incómoda: cuando la generación de desarrolladores que aún sabe hacer las cosas sin la máquina se retire, ¿quién quedará para evaluar el slop? Porque el día en que ya nadie tenga el criterio para distinguir el código bueno del código que solo se le parece, la máquina no habrá reemplazado al programador. Habrá hecho algo peor: lo habrá vuelto innecesario para sí mismo.