En pocas palabras: Para evitar la deuda cognitiva al usar asistentes de IA, el desarrollador Ankur Sethi propone, en un post del 2 de agosto de 2026, reescribir a mano —tecla por tecla— el código que genera el LLM en vez de copiarlo, así entendés cada línea de tu propio proyecto.
La deuda cognitiva código IA es lo que se te acumula cuando dejás que un asistente escriba tu código y de a poco perdés el entendimiento de cómo funciona. En un post del 2 de agosto de 2026, el desarrollador Ankur Sethi propone una solución medio incómoda para frenarla: reescribir a mano, tecla por tecla, lo que te genera el LLM.
La deuda cognitiva es la brecha entre el código que tenés en tu proyecto y lo que realmente entendés de él. Cuando un asistente como Claude Code o GitHub Copilot escribe una función y vos la pegás sin leerla, esa brecha crece. No es deuda técnica (código feo que después hay que refactorizar), es algo peor: vos mismo no sabés qué hace tu propio proyecto.
En 30 segundos
- Qué propone: reescribir a mano el código que genera el LLM en vez de copiarlo, para no perder comprensión del proyecto.
- Quién: Ankur Sethi, en su blog personal, el 2 de agosto de 2026.
- Por qué: revisar PRs generados por IA es tedioso y él prefiere entender el código antes que delegarlo entero a la “máquina de slop”.
- El costo: el propio autor admite que el método es “groseramente ineficiente”. Reescribís todo de nuevo.
- Para quién sirve: proyectos personales y código crítico donde querés retener el conocimiento, no boilerplate descartable.
¿Qué es la deuda cognitiva en el código IA y por qué pasa?
La deuda cognitiva código IA aparece cuando aceptás código generado por un modelo sin procesarlo mentalmente. Sethi lo plantea con un ejemplo propio: no tiene ganas de leerse toda la documentación de Django para agregar tags a su sitio, pero igual quiere entender cómo funciona la solución. Ese es el punto. Aburrido no es lo mismo que innecesario.
Conviene separar dos cosas que se mezclan seguido.
- Deuda técnica: el código funciona pero está mal escrito. Se paga refactorizando.
- Deuda cognitiva: el código puede estar perfecto, pero vos no sabés qué hace. Se paga cuando algo se rompe y no tenés idea de por dónde empezar.
Ponele que le pedís a Claude que te resuelva el sistema de tagging, te tira cuarenta líneas en dos segundos, las pegás, funciona, seguís con otra cosa, y tres semanas después cuando algo falla abrís ese archivo y te das cuenta de que no entendés una sola línea de lo que hay ahí. Eso es deuda cognitiva pura. Y a diferencia de la técnica, no la ves hasta que ya la estás pagando.
¿Por qué cuesta tanto revisar los PRs que genera la IA?
Revisar código generado por un LLM es tedioso porque suele venir excesivamente defensivo, mal comentado y con errores sutiles. Sethi lo dice sin vueltas: leerse cientos de líneas de código así no es divertido, y en un proyecto personal directamente no lo va a hacer. Tema relacionado: cuando trabajás con Claude.
Su descripción del 2026 es bastante ácida: “los robots levantan PRs, los humanos los revisan”. Un “brave new world” donde el desarrollador quedó del lado del que corrige. El problema con eso es real. ¿Alguien revisó de verdad esas cuarenta líneas antes de mergearlas? No, y muchas veces vos tampoco.
Ahí está la trampa. Como revisar es aburrido, la salida fácil es confiar y pegar. Y confiar y pegar es justo lo que dispara la deuda cognitiva. El review, que debería ser el freno, termina siendo el trámite que nadie quiere hacer bien.
¿Cómo funciona reescribir a mano el código del LLM?
La técnica es simple de explicar y molesta de aplicar: en vez de copiar y pegar lo que genera el modelo, lo tipeás vos, tecla por tecla, en tu editor (sí, todo). No es una metáfora ni un modo de “leer con atención”. Es reescritura literal.
La lógica es de aprendizaje motor. Cuando tipeás algo, tu cerebro lo procesa distinto que cuando lo pegás. Tenés que entender cada línea aunque sea un segundo, porque si no, no sabés ni qué escribir. El copy-paste es pasivo. La reescritura te obliga a pasar el código por la cabeza antes de que llegue al archivo.
Sethi es honesto sobre el costo. Llama a su propio método “groseramente ineficiente” (spoiler: lo es). Estás gastando tiempo en reescribir algo que ya tenías resuelto. El argumento es que ese tiempo no es desperdicio: es lo que recuperás de comprensión que el pegado te sacaba. Complementá con si generás código con ChatGPT.
¿Qué ganás reescribiendo en vez de copiar y pegar?
Reescribir el código a mano mejora la comprensión, te hace cazar bugs que el pegado te dejaría pasar y sube la retención a largo plazo. El costo es tiempo. Acá va la comparación directa entre los dos enfoques.
| Aspecto | Copiar y pegar | Reescribir a mano |
|---|---|---|
| Velocidad | Instantáneo | Lento, reescribís todo |
| Comprensión del código | Baja o nula | Alta, procesás cada línea |
| Detección de bugs sutiles | Se te escapan | Los notás al tipear |
| Retención a largo plazo | Se olvida rápido | Queda por memoria activa |
| Modificar el código después | Dependés del LLM otra vez | Lo tocás vos solo |
| Cuándo conviene | Boilerplate, scripts descartables | Features centrales, código que vas a mantener |
El beneficio menos obvio es el último de la tabla. Si entendés lo que escribiste, mañana lo modificás sin volver a abrir el chat. Si lo pegaste, cada cambio chico te devuelve a pedirle al modelo, y la dependencia se hace bola de nieve.
¿Vale la pena el tiempo extra de reescribir código IA?
Depende de qué estés escribiendo. Para Sethi, en proyectos personales la respuesta es sí, porque el placer está en el proceso, no en el resultado. Si el proyecto es tuyo y lo hacés por gusto, entender cómo funciona es medio el punto de hacerlo.
En un contexto de trabajo el cálculo cambia. El tema es que ahí el ROI se mide distinto: cuánto tiempo perdés reescribiendo contra cuántos bugs y horas de debugging futuro te ahorrás. Para código crítico que vas a mantener meses, la cuenta suele cerrar. Para un script que corrés una vez y tirás, reescribir es tiempo tirado.
Una regla práctica: si dentro de tres meses vas a tener que tocar ese código, entendelo hoy. Si no lo vas a volver a ver, pegalo y seguí. Cubrimos ese tema en detalle en con los modelos GPT más recientes.
¿Qué técnicas hacen más llevadero el retyping?
Reescribir no tiene que ser masoquismo puro. Hay formas de bajarle el costo sin perder el beneficio de procesar el código.
- Pantalla dividida: el output del LLM de un lado, tu editor del otro. Mirás y tipeás sin saltar de ventana.
- Comentá mientras tipeás: si escribís un comentario tuyo al lado de cada bloque, te forzás a entenderlo para poder resumirlo.
- Reescribí lo que importa, no todo: el boilerplate obvio pegalo; reescribí la lógica central, que es donde vive el entendimiento.
- Preguntale al modelo el “por qué”, no solo el “qué”: con Claude Code o el asistente que uses, pedile que te explique la decisión antes de tipearla.
Ojo con una cosa: si terminás pegando igual “para ir más rápido”, perdiste todo. La técnica solo sirve si la mano pasa por el teclado.
¿Cuándo conviene reescribir y cuándo no hace falta?
Reescribí cuando querés aprender, cuando el código es central para tu proyecto o cuando lo vas a mantener en el tiempo. Pegá sin culpa cuando es configuración trivial, un wrapper de API que no vas a tocar o un script descartable.
Sethi usa sus proyectos personales como caso: el tagging de Django lo quiere entender porque es parte de algo que le importa. Si tenés un proyecto propio que querés poner online, con un hosting como donweb.com para un sitio en Django o WordPress, entender tu propio stack te evita quedar atado al chat cada vez que algo se rompe en producción.
La otra punta es igual de válida. Iteración rápida, prototipos que vas a tirar, código que existe para probar una idea y nada más: ahí la “eficiencia” del pegado gana, porque no hay nada que retener.
Errores comunes al usar IA para programar
- Pegar y confiar sin leer: el clásico. Asumís que si compila está bien. Los bugs sutiles del código generado no siempre rompen al toque, aparecen después. Corrección: leé o reescribí lo que va a producción.
- Delegar features enteras de una: el “one-shot” de una funcionalidad completa deja al desarrollador desorientado, como reconoce Sethi de su propia experiencia. Corrección: pedile al LLM las partes aburridas, no el proyecto entero.
- Tratar el review como trámite: revisar un PR de IA por arriba es peor que no revisarlo, porque te da falsa seguridad. Corrección: si no vas a revisar en serio, reescribí; si vas a revisar, hacelo línea por línea.
- Aplicar reescritura a todo: reescribir el boilerplate a mano es perder tiempo sin ganar comprensión. Corrección: reservá el esfuerzo para la lógica que importa.
Preguntas Frecuentes
¿Qué es la deuda cognitiva en programación?
Es la brecha entre el código que tenés en tu proyecto y lo que realmente entendés de él. Crece cuando aceptás código generado por IA sin procesarlo mentalmente. Se paga cuando algo se rompe y no sabés cómo funciona tu propio proyecto. En usando asistentes como Gemini profundizamos sobre esto.
¿Cuál es la diferencia entre deuda técnica y deuda cognitiva?
La deuda técnica es código que funciona pero está mal escrito y se arregla refactorizando. La deuda cognitiva es distinta: el código puede estar impecable, pero vos no entendés qué hace. Una la pagás con trabajo de refactor, la otra con horas de debugging a ciegas.
¿Es mejor copiar o reescribir el código generado por IA?
Reescribir a mano da mejor comprensión y retención, pero es más lento. Copiar y pegar es instantáneo pero deja deuda cognitiva. La recomendación de Ankur Sethi es reescribir en proyectos personales y código central, y pegar solo boilerplate o scripts descartables.
¿Por qué reescribir código ayuda a entenderlo mejor?
Porque tipear obliga a procesar cada línea antes de escribirla, algo que el copy-paste se saltea. Es aprendizaje activo contra recepción pasiva. Al reescribir notás bugs y decisiones de diseño que pegando pasarías por alto.
¿Cuándo puedo confiar en el código de un asistente IA sin reescribirlo?
Cuando es código que no vas a mantener: boilerplate repetitivo, wrappers de API simples, scripts que corrés una vez y descartás, o prototipos rápidos. Si el código es central para tu proyecto o lo vas a modificar en el futuro, conviene entenderlo bien primero.
Conclusión
En 2026 la discusión ya no es si usar asistentes de código, sino cómo usarlos sin quedar afuera de tu propio proyecto. Lo que cambió con la propuesta de Ankur Sethi es el foco: en vez de optimizar la velocidad, propone optimizar la comprensión, aunque eso signifique reescribir a mano lo que la máquina te resolvió en dos segundos.
No es una receta para todo. Reescribir un boilerplate es tiempo perdido. Pero para el código que te importa, la lógica central, lo que vas a mantener, tipear en vez de pegar es la diferencia entre ser dueño de tu proyecto o ser el que corrige PRs de un robot. Elegí dónde poner el esfuerzo, y pegá el resto con la conciencia tranquila.