De los lenguajes de programación a los agentes de IA: toda abstracción crea una nueva deuda
“Si no sabes assembly, nunca serás un buen programador.”
Esta es de las antiguas... Cuando los lenguajes de alto nivel comenzaron a surgir, había quienes los miraban con desconfianza, pensando que programar lejos del metal era «traicionar el movimiento». Personalmente, siempre imaginé a unos programadores old-school con capa y gorro de mago.
Hoy, la discusión se ha puesto un traje nuevo:
“Si usas Copilot, ChatGPT, Cursor, Claude Code o cualquier otro agente de código, nunca aprenderás de verdad.”
La idea aquí es sencilla: la IA generativa no es solo un superautocomplete. Los grandes modelos de lenguaje —o LLM, para los amigos— y los agentes de código son como nuevas capas en esta cebolla de la ingeniería de software, igual que lo fueron los lenguajes de alto nivel, los frameworks y la cloud.
Y, como toda buena abstracción, resuelven algunos problemas antiguos, pero vienen con esas famosas deudas técnicas de regalo.
Te invito, querido lector o querida lectora, a ponerte las gafas de ingeniería y ver la IA no como antagonista ni como una solución milagrosa, sino como una capa más que cambia el campo de batalla, por decirlo de algún modo.
Aquí no hablaremos de «la IA reemplazando a los desarrolladores» ni compararemos herramientas. Vamos a explorar la responsabilidad técnica de esta nueva capa: qué hacer con lo que genera la IA y qué tipo de deuda puede traer.
Vamos a repasar la historia de otras abstracciones en el software y, al final, afrontar esta realidad: el problema no es que la IA escriba código, sino aceptarlo sin entenderlo y sin validarlo.
Si quieres ver el texto original de esta idea en otro formato, también fue publicado como artículo en la plataforma Arandu de DWCorp bajo el título “Da linguagem de programação aos agentes de IA: toda abstração cria uma nova dívida”.
TL;DR
- La IA —LLM y agentes de código— es una nueva abstracción de programación, no solo una feature del IDE.
- Toda abstracción aporta ganancias de productividad y nuevas deudas: confianza, validación, seguridad, autoría y mantenimiento.
- El riesgo no está en usar IA, sino en aceptar código generado sin entenderlo, probarlo ni revisarlo.
- La IA no convierte automáticamente a nadie en senior; amplifica las prácticas que ya existían en el equipo.
- Usar la IA con responsabilidad significa tratarla como un compañero junior muy rápido: útil, pero necesita supervisión.
1. La IA no es solo autocomplete: es una nueva abstracción de programación
Hoy en día, abrir el IDE implica contar con la compañía de alguna IA:
- Copilot sugiriendo bloques completos de código;
- ChatGPT o Claude Code explicando una función extraña;
- Cursor reescribiendo módulos enteros;
- agentes de código intentando dominar varios archivos al mismo tiempo.
Es tentador pensar que todo esto sirve únicamente para «escribir más rápido». Pero hay algo más profundo.
De la misma manera que:
- los lenguajes de alto nivel abstrajeron el hardware;
- los frameworks abstrajeron detalles de infraestructura y protocolos;
- la cloud abstrajo racks, datacenters, cables y switches...
Los LLM y los agentes de código comienzan a abstraer partes de la propia programación. Dejamos de centrarnos en cómo escribir cada línea y pasamos a decir qué queremos que exista en el código.
No es simplemente un «autocomplete inteligente». Es como decir:
“Aquí está el requisito. Construye algo que parezca resolverlo.”
Y con cada nueva capa de abstracción vuelve a ocurrir lo de siempre:
- ganamos: la construcción se vuelve más rápida;
- pagamos: aparecen nuevas deudas.
El resto de este texto explorará cómo esta nueva capa de IA cambia el juego de la ingeniería y qué tipo de deuda técnica puede causar si la usamos sin criterio.
2. Línea de tiempo de las abstracciones: cada solución trajo una nueva deuda
Antes de centrarnos en la IA, echemos un vistazo a la fila de abstracciones que ya pasó frente a nosotros. Siempre ocurre lo mismo: subimos un nivel, ganamos potencia, pero también creamos nuevas formas de equivocarnos.
2.1. De los lenguajes de bajo nivel a los lenguajes de alto nivel
Salimos de un mundo en el que todo se hacía con assembly o C, cerca del sistema operativo, y pasamos a Java, C#, Python, Ruby, Go, Kotlin y compañía.
Ganancias claras:
- desarrollo mucho más rápido;
- portabilidad entre plataformas;
- código más expresivo y legible;
- bibliotecas reutilizables para prácticamente todo.
Pero la factura llegó.
Nuevas deudas:
- no siempre sabemos qué hacen el compilador o el runtime por detrás;
- los bugs aparecen solo en producción y no sabemos por qué;
- se creó una cultura peligrosa:
- «si compila, está bien».
Este pensamiento es un ejemplo clásico de deuda de confianza: confiamos en el intermediario y dejamos de validar.
2.2. Frameworks y ORM: eliminando la repetición, creando acoplamiento
Después llegaron los frameworks y los ORM. Spring, Rails, Django, ASP.NET, Hibernate, Entity Framework: la fiesta estaba servida.
Ganancias:
- productividad en aumento: CRUD, routing, validación e inyección de dependencias en bandeja;
- menos boilerplate y más foco en la regla de negocio;
- convenciones que alinean al equipo sin tanto bla, bla, bla.
Y ahí viene la cuenta:
Nuevas deudas:
- queries terribles escondidas detrás de API bonitas;
- dificultad para optimizar sin entender el SQL generado;
- fuerte acoplamiento al framework —«si quieres cambiarlo, prácticamente tienes que reescribir el sistema»—;
- «magia» que funciona hasta que... deja de funcionar.
Aquí el trade-off típico es:
Velocidad ahora frente a control detallado y flexibilidad después.
2.3. Cloud y DevOps: infraestructura como servicio, complejidad como contrato
Después, la infraestructura salió del rack y se trasladó a AWS, Azure, GCP y compañía.
Ganancias:
- escalar sin comprar servidores físicos;
- automatización de deploy, pipelines y observabilidad;
- equipos más enfocados en el producto y menos en el hardware.
¿Y las deudas?
- costes inesperados por dejar encendido un clúster gigantesco;
- lock-in con los servicios del proveedor;
- topologías de red y seguridad complejas;
- incidentes que involucran la mitad del sistema interno y la mitad de un servicio gestionado.
Una vez más, la abstracción aumenta el poder, pero esconde la complejidad detrás de contratos.
2.4. La IA entra en la fila: otra capa por encima de todo esto
En este escenario aparece la IA como nueva abstracción de programación:
- no es una ruptura total;
- es otro paso en la dirección de subir el nivel del «lenguaje» con el que interactuamos con el ordenador.
En lugar de programarlo todo, delegas parte de la responsabilidad en un agente de IA.
El trade-off ahora es otro:
- menos esfuerzo al escribir;
- más esfuerzo al verificar.
3. ¿Qué cambia con la IA como abstracción de programación?
3.1. La diferencia entre «escribir menos» y «pensar de otra manera»
Con la IA generando código, arquitectura inicial, tests y documentación, el cuello de botella cambia:
- antes: «¿cómo voy a implementar esto?»;
- ahora: «¿cómo voy a garantizar que esto es correcto, seguro y sostenible?»
La IA no es solo un autocomplete. Se convierte en algo parecido a:
- «monta este módulo de autenticación»;
- «refactoriza este servicio como microservicios»;
- «crea tests para esta clase».
Exige un tipo diferente de razonamiento por parte del desarrollador. Ya no solo estás construyendo; estás especificando, auditando y corrigiendo un sistema que “construye” por ti.
3.2. Especificar mejor, revisar mejor
Imagina:
«Implementa autenticación con JWT en este proyecto Spring Boot.»
La IA genera algo que parece increíble:
- código bien formateado;
- endpoints organizados;
- ejemplos de payload.
Sin embargo:
- ¿sigue las políticas de seguridad de tu empresa?
- ¿está alineado con el sistema?
- ¿respeta los requisitos no funcionales?
«No lo sé» no puede ser la respuesta aquí.
El papel del desarrollador cambia de:
- «voy a implementarlo todo» a
- «voy a especificarlo y comprobar después si lo que recibí encaja con el contexto».
La metáfora es:
Trata a la IA como un becario muy rápido y muy seguro de sí mismo.
Acierta muchas cosas, pero la revisión es esencial.
3.3. La IA como un compilador con esteroides
Piensa en la IA como un «compilador anabolizado».
- El compilador traduce de alto nivel a un ejecutable.
- La IA traduce del lenguaje natural al código.
En ambos casos:
- subes de nivel;
- delegas la traducción en una herramienta.
Cuanto más delegas, más necesitas ser capaz de:
- leer el resultado;
- identificar inconsistencias;
- probar rápidamente.
Si no entiendes lo que hacen el compilador o la IA, estás metido en un buen lío.
4. Las nuevas deudas creadas por la IA —sin drama, pero con realismo—
Dejémoslo claro: toda abstracción crea nuevas deudas. Con la IA ocurre lo mismo. La cuestión no es «tener o no tener deuda», sino qué deudas estás adquiriendo sin siquiera darte cuenta.
4.1. Deuda de confianza: parece correcto frente a es correcto
Las herramientas de IA son peligrosamente convincentes.
El código:
- compila;
- funciona en el camino feliz;
- parece estar bien hecho.
Esto activa un sesgo:
«Si parece bueno, debe estar bien.»
Pero por debajo puede haber:
- API desactualizadas;
- errores sutiles de lógica;
- problemas de concurrencia y seguridad.
Un ejemplo: la IA genera la paginación para una API:
- funciona en los casos comunes;
- pero ignora detalles como la ordenación estable y los grandes volúmenes.
Esto es deuda de corrección. El código está «casi bien» y ese «casi» es lo que termina atrapándote.
4.2. Deuda de validación: ¿los tests se convierten en una etapa opcional?
Los equipos sin cultura de testing pueden empeorar con la IA:
- antes: poco código y pocos tests;
- ahora: mucho código y los mismos pocos tests.
La trampa:
«Deja que la IA genere los tests.»
Pero:
- los tests solo cubren el camino feliz;
- se ignoran los casos límite;
- los tests solo validan lo que ya se hizo.
Buenas prácticas:
- ejecutar los tests después de aceptar el código;
- validar manualmente los casos límite;
- revisar los tests sugeridos.
Si los tests se convierten en «algo que la IA hace sola», tenemos deuda de validación.
4.3. Deuda de seguridad: copiar sin contexto es una invitación a las vulnerabilidades
La IA suele basar sus respuestas de seguridad en:
- ejemplos genéricos;
- patrones desactualizados;
- suposiciones simplistas.
Riesgos habituales:
- sanitización incompleta de entradas;
- configuraciones de autenticación «de tutorial» que llegan a producción;
- datos sensibles en los logs.
La IA ayuda, pero no sustituye la revisión de seguridad ni las políticas de la empresa.
Copiar una solución «de caja», sin adaptarla, es crear deuda de seguridad.
4.4. Deuda de autoría: ¿quién entenderá este código dentro de seis meses?
Otro tipo de deuda es la deuda de autoría.
Escenario:
- fragmento de código generado por IA;
- aceptado con prisa;
- nadie lo entiende profundamente.
Seis meses después:
- aparece un bug crítico;
- nadie quiere tocarlo porque no lo entiende;
- el refactor tarda porque nadie se siente responsable.
Para prevenirlo:
- documentar las decisiones técnicas;
- registrar el razonamiento;
- alguien debe ser responsable de entender el fragmento.
Si todo es «código de nadie», el mantenimiento se convierte en un problema.
4.5. Deuda de mantenimiento: escalar el código malo resulta más barato
Sin IA, un desarrollador descuidado ya puede causar bastante daño. Con IA, hace mucho más en menos tiempo.
Eso es lo que convierte a la IA en un amplificador de la cultura:
- si el equipo ya aceptaba código malo;
- la IA solo acelera el caos.
Es habitual ver sprints «milagrosos»:
- muchas entregas aparentes;
- la velocity se dispara;
- el backlog queda vacío.
Después llega la factura:
- bugs regresivos;
- las nuevas features tardan más;
- miedo a refactorizar.
El viejo trade-off:
velocidad inmediata frente a coste de mantenimiento futuro.
5. La IA no crea buenos ni malos ingenieros: amplifica lo que ya existe
5.1. El desarrollador cuidadoso frente al desarrollador en piloto automático
Mismo escenario, dos desarrolladores diferentes usando la misma IA.
Desarrollador A —cuidadoso—:
- usa la IA para generar tests y comprobar su comprensión;
- cuestiona y adapta el resultado al contexto del sistema;
- reescribe cuando es necesario.
Desarrollador B —en piloto automático—:
- copia la primera respuesta;
- no ejecuta los tests;
- no revisa.
La misma herramienta. El resultado:
- Desarrollador A: aumenta la productividad y mantiene la calidad;
- Desarrollador B: aumenta la productividad aparente, pero crece la deuda.
La IA no convierte a nadie en senior. Aumenta la distancia entre las buenas y las malas prácticas.
5.2. La ilusión de seniority instantánea
Es un error pensar que la IA «da poderes de senior» a cualquiera:
- un junior con IA escribe código «sofisticado»;
- incluso puede superar los code reviews si todo el mundo está en piloto automático.
Pero ¿qué diferencia a un senior?
- entender los trade-offs de arquitectura;
- leer logs y stack traces;
- diseñar buenas interfaces entre módulos;
- lidiar con fallos en producción.
Nada de eso viene «de regalo» con la IA.
La seniority continúa estando relacionada con el criterio, no con la cantidad de código.
5.3. Dónde la ingeniería de software sigue siendo insustituible
Hay cosas que la IA no hace bien:
- entender las restricciones del negocio;
- conocer el legado organizacional y la política interna;
- negociar con stakeholders y recortar alcance.
La IA es excelente para:
- sugerir alternativas;
- automatizar tareas;
- explicar código legacy.
La decisión que cada equipo debe tomar es:
¿Vamos a usar el tiempo de la IA para hacer más ingeniería de verdad
o para llenar el backlog con features irrelevantes?
6. Cómo usar la IA como abstracción con responsabilidad técnica
No es una guía de prompt engineering, pero estas actitudes ayudan.
6.1. Tratar a la IA como un compañero junior muy rápido
Una práctica útil:
No aceptes de la IA lo que no aceptarías de un becario.
Esto incluye:
- código sin tests para partes críticas;
- ausencia total de logging o métricas;
- incumplimiento de los estándares del proyecto;
- uso de bibliotecas que el equipo no adopta.
Si no dejarías que un junior hiciera merge directamente en main, no lo hagas con la IA.
6.2. Validar siempre: los tests, la observabilidad y la revisión siguen siendo esenciales
Algunos principios son todavía más importantes:
- ningún cambio sin ejecutar los tests;
- revisión humana del código generado siempre que sea posible;
- comprobación mínima de seguridad para lo que sea externo;
- cuidado con el código que maneja datos sensibles.
La tentación de pensar «si compila y funciona en el happy path, está listo» aumenta con la IA, pero es precisamente cuando más necesitas:
- buenos tests automatizados;
- observabilidad —logs, métricas y traces—;
- una revisión cuidadosa.
6.3. Explicar el sistema a la IA... y a ti mismo
Un efecto secundario interesante es que los buenos prompts exigen claridad.
Para que la IA ayude, explica:
- el contexto del sistema;
- las restricciones;
- ejemplos y casos límite.
Muchas veces descubres:
- requisitos mal definidos;
- un flujo de dominio confuso.
Por ejemplo:
Al describir un flujo para pedir un refactor, te das cuenta de que tres servicios modifican el mismo estado.
Solo este ejercicio ya representa una ganancia, incluso antes de aceptar el código generado.
6.4. Cultura de equipo: acuerdos claros sobre el uso de la IA
Cada equipo debe responder:
- ¿Dónde podemos usar la IA con mayor libertad?
- ¿Dónde está restringido su uso por motivos de seguridad, compliance o criticidad?
- ¿Cómo documentaremos los fragmentos generados por IA?
- ¿Cuál es nuestro proceso de revisión y testing para la IA?
Restringir demasiado vuelve rígido el trabajo. Liberarlo por completo crea deudas.
El uso de la IA no debe ser una decisión aislada, sino formar parte de los acuerdos del equipo.
6.5. Actualizar las habilidades fundamentales, no abandonarlas
La IA no es una excusa para abandonar los fundamentos. De hecho, algunos se vuelven más importantes:
- lectura cuidadosa del código;
- diseño de sistemas y modelos de dominio;
- tests automatizados;
- seguridad y rendimiento sólidos.
La IA puede ayudar a:
- pedir explicaciones de conceptos;
- generar ejemplos;
- comparar enfoques;
pero es fundamental entender de verdad.
7. Conclusión: el código puede generarse; la responsabilidad, no
La historia de la ingeniería de software muestra que la IA es otra capa en la pila de abstracciones:
- los lenguajes de alto nivel abstrajeron la máquina;
- los frameworks y ORM abstrajeron los detalles repetitivos;
- la cloud abstrajo la infraestructura física;
- ahora, la IA comienza a abstraer partes de la programación.
En todos los casos:
- ganamos productividad;
- creamos deudas.
Con la IA, las deudas aparecen en:
- confianza —«parece correcto frente a es correcto»—;
- validación —tests opcionales—;
- seguridad —patrones genéricos sin contexto—;
- autoría —código sin dueño—;
- mantenimiento —escala del código malo—.
El problema no es que la IA escriba código.
Es aceptar código sin entenderlo, sin probarlo y sin validarlo.
Usar la IA con responsabilidad significa:
- revisar como responsable —porque lo eres—;
- cuestionar las respuestas, especialmente las que suenan demasiado seguras;
- fortalecer tus bases para evaluar mejor las sugerencias;
- ajustar las prácticas a esta nueva realidad.
La IA escribe rápido.
La deuda que crea o evita todavía depende de quién firma.
Para continuar la conversación, intercambiar experiencias y conocer cómo otras personas están afrontando esto en la práctica, vale la pena seguir a la comunidad Software Craftsmanship Brasília en Participa en la comunidad SCCB y consultar también los próximos eventos y encuentros técnicos.
Próximos pasos
Algunas ideas prácticas para tu día a día:
- Observa tu propio uso de la IA durante una semana
- Anota en qué tipos de tareas la utilizas más: generar código, explicar, refactorizar o probar.
-
Reflexiona sobre cuándo estás siendo cuidadoso y cuándo simplemente «aceptas porque parece bueno».
-
Acuerda un experimento con el equipo
- Elijan una parte del sistema para usar la IA de forma deliberada, con criterios claros de revisión y testing.
-
Después de uno o dos sprints, conversen sobre qué mejoró y qué empeoró.
-
Fortalece un fundamento técnico
- Elige un tema —tests, diseño de dominio o seguridad básica— y usa la IA como apoyo para estudiar, pero no aceptes todo sin comprobarlo.
-
Intenta explicar lo que aprendiste, por escrito o a otra persona.
-
Revisa al menos un fragmento generado por IA en un sistema real
- Toma una parte del código que sabes que nació con IA.
-
Vuelve a leerla, refactorízala, escribe mejores tests y documenta las decisiones técnicas.
-
Debate el papel de la IA en el flujo de trabajo de tu equipo
- Lleven el tema a una retrospectiva o a una charla técnica interna.
- Hablen abiertamente sobre miedos, expectativas y prácticas recomendadas para usar la IA como nueva abstracción de programación.
