Durante décadas asumimos que escribir software tenía un efecto secundario inevitable.
Mientras resolvías un problema…
…también aprendías.
Aprendías cómo estaba organizada la base de código.
Por qué cierta decisión arquitectónica existía.
Qué módulos eran frágiles.
Qué dependencias nunca había que tocar.
Qué partes del sistema llevaban diez años sin modificarse.
Ese aprendizaje no ocurría porque alguien te lo enseñara.
Ocurría porque el trabajo mismo te obligaba a recorrer el camino.
Los coding agents están cambiando esa dinámica.
Y un nuevo paper propone un nombre para esa consecuencia inesperada:
Knowledge Debt.
La idea es tan simple como incómoda.
Tu equipo puede estar produciendo más software… y entendiendo cada vez menos cómo funciona.
La deuda técnica tiene un primo
Todos conocemos la deuda técnica.
Tomás un atajo.
El sistema sigue funcionando.
Pero cada cambio futuro cuesta un poco más.
La Knowledge Debt funciona distinto.
El software puede estar perfectamente escrito.
Los tests pueden pasar.
La arquitectura puede seguir siendo excelente.
Lo que se degrada no es el código.
Es el conocimiento del equipo.
Y eso la hace mucho más difícil de detectar.
La deuda técnica termina apareciendo en producción.
La Knowledge Debt puede permanecer invisible durante meses.
Cómo aprendíamos antes
Pensá en un bug cualquiera hace cinco años.
Probablemente el proceso era algo así.
Bug
↓
Buscar dónde ocurre
↓
Leer archivos relacionados
↓
Seguir llamadas
↓
Entender la arquitectura
↓
Probar hipótesis
↓
Encontrar la causa
↓
Implementar el fix
El fix era solamente el resultado final.
La mayor parte del valor estaba en el camino.
Porque durante esas dos horas también aprendías:
- quién era dueño de ese módulo;
- por qué existía ese workaround extraño;
- qué componentes dependían entre sí;
- qué decisiones arquitectónicas habían sobrevivido durante años;
- dónde estaban realmente los límites del sistema.
Ese conocimiento quedaba en tu cabeza.
Y permanecía ahí para la próxima vez.
Cómo trabajamos hoy
Ahora imaginemos exactamente el mismo bug.
Bug
↓
Claude Code
↓
"Encontré el problema."
↓
"Ya está resuelto."
Cinco minutos.
Excelente productividad.
Pero hay una pregunta incómoda.
¿Qué aprendió realmente el desarrollador?
Muchas veces…
muy poco.
Revisar no es comprender
Una respuesta habitual es:
“No importa. Siempre puedo revisar el código generado.”
Pero revisar un diff no equivale a recorrer el proceso mental que llevó hasta él.
Es parecido a leer la solución de un ejercicio de matemática.
Podés entender cada línea.
Eso no significa que hubieras llegado por tu cuenta.
Ni que puedas resolver el próximo problema parecido sin ayuda.
La diferencia es enorme.
Los agentes nos muestran el destino.
Pero muchas veces nos saltean el viaje.
Y era justamente durante ese viaje donde se construía gran parte de la experiencia técnica.
El conocimiento incidental
Hay un concepto muy interesante en educación:
aprendizaje incidental.
Es todo aquello que aprendemos mientras hacemos otra cosa.
Cuando buscabas un bug…
aprendías arquitectura.
Cuando escribías tests…
aprendías cómo pensaban quienes construyeron ese sistema.
Cuando investigabas una regresión…
aprendías por qué ciertas decisiones nunca debían repetirse.
Nada de eso aparecía en el ticket.
Pero terminaba formando parte de tu modelo mental.
Los agentes eliminan gran parte de ese recorrido.
Y esa eficiencia tiene un costo.
Un ejemplo cotidiano
Supongamos que un agente resuelve un problema de autenticación.
El Pull Request es impecable.
Los tests pasan.
Todo funciona.
Seis meses después aparece un incidente relacionado.
El desarrollador que originalmente aceptó ese PR ahora tiene que investigarlo.
Pero nunca recorrió el camino que llevó a esa solución.
Nunca entendió:
- por qué se eligió OAuth sobre otro mecanismo;
- qué edge cases existían;
- qué alternativas descartó el agente;
- qué riesgos evaluó antes de implementar el cambio.
El conocimiento nunca llegó al equipo.
Llegó solamente el código.
La paradoja
Cuanto mejores son los coding agents…
…más fácil resulta acumular Knowledge Debt.
Porque el agente ya no solo genera código.
También:
- investiga;
- prueba hipótesis;
- navega la arquitectura;
- descarta soluciones incorrectas;
- sintetiza información.
Justamente las actividades que antes construían experiencia.
Paradójicamente, cuanto más competente es el agente, menos oportunidades tiene el desarrollador de construir ese mismo conocimiento por sí mismo.
¿Deberíamos dejar de usar agentes?
En absoluto.
La conclusión del paper no es que debamos volver atrás.
Sería tan absurdo como dejar de usar compiladores porque antes escribíamos ensamblador.
La productividad que aportan los coding agents es real.
La pregunta correcta no es si debemos utilizarlos.
Es cómo diseñamos workflows donde la productividad no sustituya al aprendizaje.
Porque escribir menos código puede ser una excelente noticia.
Aprender menos sobre el sistema, no.
Agentes que también enseñan
Creo que ahí aparece una oportunidad enorme.
Hasta ahora diseñamos agentes para producir resultados.
Quizás la próxima generación tenga otro objetivo.
Ayudar a desarrollar criterio.
Imaginemos que, además del Pull Request, el agente entregue algo como esto.
¿Por qué elegí esta solución?
↓
¿Qué alternativas descarté?
↓
¿Qué módulos recorrí?
↓
¿Qué riesgos encontré?
↓
¿Qué debería saber el próximo desarrollador?
Eso cambia completamente la experiencia.
El agente deja de ser únicamente un ejecutor.
Empieza a convertirse en un mentor.
Algunas prácticas que ya podemos adoptar
No hace falta esperar una nueva generación de herramientas.
Hay varias cosas que los equipos pueden empezar a hacer hoy.
Pedile al agente que explique antes de modificar
En lugar de:
“Arreglá este bug.”
Probá con:
“Explicame primero cuál creés que es la causa y recién después proponé un cambio.”
Eso obliga al desarrollador a validar el modelo mental antes del código.
Pedí alternativas
Una pregunta simple:
“¿Qué otras soluciones evaluaste y por qué las descartaste?”
Muchas veces enseña más que el diff final.
Rotá las revisiones
Aunque el código haya sido generado por IA.
Las revisiones siguen siendo uno de los mejores mecanismos de aprendizaje colectivo.
No solo para encontrar errores.
También para compartir modelos mentales.
Conservá el razonamiento
No solamente el código.
Guardar decisiones arquitectónicas, hipótesis descartadas y contexto termina siendo tan importante como guardar el Pull Request.
El código explica qué hicimos.
El razonamiento explica por qué.
Medí comprensión, no solo velocidad
Si la única métrica del equipo es:
- tickets cerrados;
- líneas modificadas;
- tiempo de entrega;
es muy fácil que la Knowledge Debt pase desapercibida durante meses.
Quizás también deberíamos preguntarnos:
- ¿Quién entiende este sistema?
- ¿Cuántas personas podrían diagnosticar un incidente crítico?
- ¿Qué conocimiento estamos construyendo además de software?
El desafío para los Engineering Managers
Creo que esta idea va mucho más allá de la ingeniería.
Durante años optimizamos el pipeline para producir software.
Ahora también tenemos que optimizarlo para producir conocimiento.
Porque los equipos no escalan únicamente compartiendo código.
Escalan compartiendo modelos mentales.
Y esos modelos se construyen resolviendo problemas.
No solamente aceptando soluciones.
La productividad es importante.
Pero un equipo que produce el doble de software mientras entiende la mitad de su sistema probablemente esté acumulando una deuda mucho más peligrosa que cualquier refactor pendiente.
Una nueva responsabilidad para los agentes
Hace unos meses discutíamos cuánto código podían escribir.
Después empezamos a hablar de memoria, knowledge graphs y runtimes.
Knowledge Debt agrega otra dimensión.
Quizás el mejor coding agent del futuro no sea el que escriba más código.
Sea el que deje al desarrollador entendiendo más del sistema cuando termina la sesión que cuando la empezó.
Ese sería un cambio enorme.
Porque significaría que la IA no solo aumenta la productividad.
También aumenta la experiencia del equipo.
Y creo que ese debería ser el verdadero objetivo.
No construir agentes que reemplacen el aprendizaje.
Sino agentes que lo aceleren.
Porque el software siempre podrá volver a escribirse.
El conocimiento que un equipo deja de construir es mucho más difícil de recuperar.