27 puntos por GN⁺ 2026-03-01 | 1 comentarios | Compartir por WhatsApp
  • Aunque los desarrolladores han aumentado su productividad al usar ampliamente herramientas de programación con IA, también se están generando costos cognitivos y organizacionales invisibles
  • Desde las primeras herramientas de asistencia como Copilot y Cursor, recientemente se ha evolucionado hacia agentes autónomos, cambiando a una estructura en la que los humanos ayudan a la IA
  • Sin embargo, el uso de delegación total provoca deuda cognitiva (cognitive debt) y deterioro de la capacidad de depuración, debilitando la capacidad de resolver problemas y de comprender el código de los desarrolladores
  • Una estructura en la que la IA escribe el código y los humanos solo lo revisan conduce al colapso de la ruta de formación de seniors y a la pérdida del estado de flujo creativo (flow), erosionando a largo plazo la capacidad técnica de la organización
  • Usar IA es indispensable, pero es necesario definir por cuenta propia un ‘umbral adecuado de uso’ y ajustarlo de forma que se mantengan la comprensión y el aprendizaje humanos

La evolución de la adopción de IA para programar

  • Herramientas como Copilot y Cursor, aparecidas entre 2022 y 2023, indexaban la base de código para ofrecer autocompletado y chat basados en contexto
    • Ya no hacía falta buscar en Google o StackOverflow, y se expandió el entorno de IDE con IA integrada
  • Después surgieron los flujos de trabajo con agentes, que cambiaron de una asistencia al humano a un modelo de desarrollo liderado por IA
    • Sin embargo, los agentes presentan problemas de confiabilidad, como bucles, alucinaciones y errores de dependencias
  • Desde Opus 4.5, el nivel de automatización aumentó, y en algunas empresas ya hay casos en los que los desarrolladores no escriben el código directamente
    • Ejemplo: el co-CEO de Spotify mencionó que los ingenieros dan instrucciones a Claude desde Slack para modificar y desplegar funciones

Deuda cognitiva y degradación de habilidades

  • Se citan los conceptos de ‘Digital Dementia’ de Manfred Spitzer y ‘Cognitive Debt’ de Margaret-Anne Storey
    • Si se delega a la IA el pensamiento repetitivo, las rutas cerebrales se debilitan y disminuye la comprensión del código
  • Estudio de Shen y Tamkin (2026): entre 52 desarrolladores, el grupo con asistencia de IA obtuvo 17% menos puntaje en comprensión conceptual, depuración y lectura de código
    • En particular, el deterioro en la capacidad de depuración fue más marcado, y bastó una hora de uso pasivo de IA para que apareciera una erosión medible de habilidades
  • Cuando la IA resuelve los desafíos en lugar de la persona, se induce un estado de ‘dark flow’ en vez de ‘flow’ real, reforzando la dependencia sin aprendizaje

La paradoja de la revisión de código y el colapso del seniority

  • Si la IA escribe el código y el humano solo lo revisa, aparece la paradoja de que desaparece la fuente misma de la capacidad de revisión
    • Los desarrolladores que dependen por completo de la IA trabajan rápido, pero obtienen las peores calificaciones de evaluación
  • Storey propone que “antes de desplegar cambios generados por IA, un humano debe comprenderlos completamente”
  • La IA puede dar a principiantes resultados de nivel senior, pero no deja de ser una copia sin comprensión
    • Los seniors pierden profundidad al no escribir directamente el código, y los juniors no crecen porque no atraviesan el proceso de prueba y error
    • Como resultado, colapsa el pipeline de formación de seniors

Errores de juicio de la dirección y efectos organizacionales secundarios

  • Ejecutivos de Microsoft, Anthropic y Google predicen que la IA reemplazará a los ingenieros en cuestión de meses
    • Google informó que, a finales de 2024, el 50% del código nuevo fue generado por IA
  • Pero estas cifras son exageraciones orientadas a vender IA o impulsar el precio de la acción, y no se pueden aplicar a organizaciones comunes
  • Algunas empresas miden el uso de IA como KPI y se lo imponen a los desarrolladores
    • Caso Reddit: los desarrolladores manipulaban el uso de IA con instrucciones sin sentido
    • Como resultado, entra en juego la ley de Goodhart, y en vez de mejorar la productividad solo queda la obediencia formal

El costo humano y la pérdida de creatividad

  • Escribir código ofrece la alegría de la concentración y la creación, pero revisar código generado por IA provoca fatiga mental
    • Cuando desaparece la recompensa dopaminérgica de crear, el burnout se acelera
    • El desarrollo se degrada a control de calidad (QA) y desaparece la satisfacción creativa
  • Se compara con una situación en la que la IA hace todo el arte y los humanos solo doblan la ropa

El umbral adecuado de uso de IA

  • La IA es una herramienta poderosa, pero ni usarla mucho ni usarla poco es bueno por sí mismo
    • El estudio de Shen y Tamkin muestra que, entre 6 patrones de interacción con IA,
      • la delegación total, la dependencia gradual y la delegación de depuración obstaculizan el aprendizaje
      • pedir explicaciones, hacer preguntas conceptuales y verificar después de programar de manera independiente preservan el aprendizaje
  • La clave es mantener la participación cognitiva; lo importante no es si se usa o no, sino cómo se usa
  • Si no se usa IA en absoluto, se pierde eficiencia en búsqueda, boilerplate y exploración; si se usa en exceso, se dañan la comprensión, la formación de seniors, la detección de bugs y la sensación de flujo

Un deterioro silencioso

  • En los indicadores, mejoran el número de PR, la cantidad de funciones y el cycle time, pero
    la habilidad técnica interna, la concentración y la capacidad de resolver problemas se debilitan poco a poco
  • Los desarrolladores se convierten en “robots de mantequilla” que solo hacen clic en aprobar sin entender la estructura creada por la IA
  • Simon Willison también comentó que, al no revisar una función creada por IA en su proyecto,
    “ya no entiende claramente cómo funciona por dentro”
  • Al final, no es la herramienta la que se degrada, sino el ser humano, y ese cambio ni se mide ni se gestiona
  • La dependencia de la IA avanza como una adicción, con el riesgo de derivar en una degradación técnica silenciosa pero real

1 comentarios

 
GN⁺ 2026-03-01
Comentarios en Hacker News
  • Sigo sintiendo que escribir código yo mismo y dibujar la estructura en mi cabeza es una de las partes más disfrutables de mi trabajo
    Incluso el refactor repetitivo o tedioso es, para mí, un proceso con sentido
    Esos momentos duros se convierten en material de aprendizaje que me ayuda a encontrar una mejor forma la próxima vez
    Queda como una esperanza de que algún día esta corriente vuelva

    • Coincido por completo. Parece que no hay mucha gente que piense así, pero no estás solo
      Creo que algún día volverá a reconocerse el valor de quienes conservaron la capacidad de elegir y juzgar por sí mismos
    • Me da risa cuando la gente dice “qué cómodo que la IA escriba todas las pruebas”
      Si el código es difícil de probar, entonces hay que cambiar la abstracción o la interfaz
      Las pruebas son la primera reutilización del código, así que si son incómodas en las pruebas, también lo serán en el uso real
    • A mí también se me hizo mucho más fácil hacer debugging porque escribo el código yo mismo
      Cuanto más mío es el código, más fácil me resulta imaginar en qué parte puede surgir el problema
      Por más logs que lance un LLM, no puede reemplazar ese tipo de intuición
    • Yo también uso Copilot sobre todo cuando trabajo en JavaScript de frontend
      Pero me preocupa si eso no terminará eliminando la motivación para mejorar el ecosistema frontend
    • Yo también amo programar en sí mismo
      Incluso disfruto hacer personalmente tareas que otros quieren dejar en manos de un LLM
      Me entristece ver cómo las empresas van quitándonos poco a poco esos pequeños placeres
  • Durante el último año usé mucho Claude Code, y últimamente he notado un cambio emocional entre mis colegas respecto al uso de la IA
    Escribí sobre los costos ocultos que aparecen cuando se usa la IA en exceso, y reuní datos de varias fuentes
    Todavía no hay datos concluyentes, pero parece que muchos desarrolladores sienten lo mismo

    • Me pareció una lectura interesante. En la línea de tiempo “hacia la AGI”, fue impactante la forma visual en que aparecía Xeno’s Arrow
      Pero la expresión “el software es solo una herramienta” siempre me ha sonado extraña
      Cuando una herramienta puede reemplazar el pensamiento, ¿todavía puede llamarse “herramienta”?
      Me gustó la honestidad de la expresión “adicción al prompting”. Pero también estaría bien explorar el lado de la adicción conductual
    • Coincido con todo lo que dice el texto. En especial, el problema es la naturaleza adictiva de la velocidad y la eficiencia
      Parece rápido y bajo control, pero poco a poco se va perdiendo el control
      Lo realmente difícil es encontrar “a qué ritmo sostenible conviene usarlo”
    • Me llamó mucho la atención la expresión “golpe de dopamina creativa
      Yo también escribí una entrada de blog sobre un tema parecido,
      pero desde la perspectiva de cómo un líder puede ayudar a una organización a encontrar un equilibrio sostenible
    • Yo también estuve a punto de escribir sobre este tema, pero me quedé solo en la investigación
      Busqué artículos sobre cómo la memoria de trabajo (working memory) y el sistema de recompensa afectan el aprendizaje y la concentración
      Por ejemplo, un artículo de Nature dice que la memoria de trabajo tiene reactividad dopaminérgica
      Y un artículo de Scientific American afirma que escribir a mano activa más áreas del cerebro
      Al final, la conclusión es que en tareas pasivas y de baja recompensa casi no aparecen esos beneficios cognitivos
      Por eso pienso que el criterio para usar IA debería ser “qué tan dolorosa y poco gratificante es la tarea”
  • Yo todavía escribo el código directamente y entiendo por completo el resultado
    No me importa la mejora de velocidad. Lo importante es esa sensación de pertenencia de que este es mi código
    Siempre pude haber externalizado el trabajo, pero eso me habría convertido en alguien que solo lee código

    • Si la velocidad y la eficiencia fueran tan importantes, ¿por qué meterían a los desarrolladores en oficinas abiertas ruidosas?
    • En realidad no hace falta preocuparse por la atrofia. Solo se atrofian las capacidades que dejan de ser necesarias
    • Me pregunto si en sus empresas les están obligando a usar estas herramientas.
      Yo y la mayoría de los desarrolladores a mi alrededor sentimos esa presión
    • En el mundo de IT siempre hubo cambios rápidos y adaptación. Ese tipo de terquedad no dura mucho
    • Yo también creo que quizá no ocurra una atrofia
      Usar teclado no me hace olvidar cómo escribir a mano, y comprar café no me hace olvidar cómo prepararlo
  • A principios de los 80 aprendí a programar en LSI-11 assembly y me memoricé todos los opcodes en octal
    Pero cuando aprendí FORTRAN 83, mi productividad subió diez veces, y no me arrepiento en absoluto de que esas habilidades se hayan atrofiado
    Algún día lenguajes como C++ o Java también se convertirán en habilidades que ya no harán falta

    • Pero creo que esa es una comparación equivocada
      La capacidad de razonamiento lógico que desarrollaste al trabajar con opcodes hizo más fácil aprender lenguajes después
      Ese tipo de pensamiento para tratar con lenguajes formales (formal language) es cognitivamente mucho más profundo que escribir prompts para un LLM
    • Todos los lenguajes de programación han sido lenguajes de expresión computacional precisa,
      mientras que colaborar con IA es un proceso de transmitir intención mediante lenguaje natural ambiguo
      A menos que uno escriba pseudocódigo en inglés, la precisión disminuye
    • Ahora no se trata solo de un cambio técnico, sino de un giro de la lógica al instinto (vibe)
      Y además esta vez viene acompañado del miedo a ser reemplazado
    • Cuando un LLM escribe el código, eso se parece más al papel de un PM que al de un programador
  • Si se siguen tres patrones para usar bien la IA, se puede obtener tanto productividad como aprendizaje
    Pero si se cae en los antipatrones, eso lleva a dependencia de la herramienta, ansiedad, deterioro de la capacidad de debugging y adicción a la recompensa inmediata
    Al final se forma un círculo vicioso de deterioro cognitivo

  • Hace poco entré a una empresa centrada en IA, y el ambiente es tal que casi está prohibido programar manualmente
    Le pedí a Claude que leyera la documentación de una API y generara un wrapper, y el resultado fue perfecto,
    pero yo no terminé entendiendo en absoluto la sensación ni la estructura de la API
    Ese estado de “puedo hacer mucho pero no sé nada” resulta incómodo y vacío
    No se acumula memoria refleja. Por eso conecté profundamente con lo que dice el texto

  • Estoy avanzando en varios side projects escritos por IA

    1. Un juego de supervivencia se terminó rápido, pero no le tengo apego
    2. Una webapp para MacOS funciona, pero la calidad de la UI es baja y pienso corregirla yo mismo
    3. Una librería utilitaria no la escribí yo directamente, pero aun así siento orgullo, de forma extraña
      Aun así, queda una sensación rara, como de “creo que está bien, pero no estoy seguro”
      En conclusión, incluso cuando se crea junto con IA, hace falta dejar tu propia huella para sentir logro
  • Llevo solo 8 meses programando, y aprendí gracias a la IA
    Pero cuando Claude escribe código, entiendo solo un 70%, y el resto simplemente lo dejo pasar
    La sensación de velocidad es adictiva, pero se debilita la capacidad de mantener toda la estructura en la cabeza
    Aun así, reconozco este trade-off, porque sin IA no habría podido crear lo que tengo ahora

    • El problema es que la IA puede enseñar hábitos ineficientes
      Por ejemplo, abusa de código de fallback innecesario
      Si no tienes experiencia, puede que ni siquiera te des cuenta de que eso está mal
    • El modelo no aprende. El reentrenamiento es lento, y los humanos crecen mucho más rápido
      El nivel actual de los LLM está más o menos en el de un desarrollador intern~junior
    • Puede servir pedirle al modelo que redacte un reporte de arquitectura y que se explique a sí mismo
      El cuello de botella no es el modelo, sino nuestra capacidad de validación
    • Claude Code tiene un “modo aprendizaje” que deja TODO(human) en el código mientras va explicando
  • Me pregunto si de verdad hace falta usar un LLM para la automatización de boilerplate
    ¿No bastaría con metaprogramación o scripts tradicionales?
    Además, rechazar la IA por principio también puede ser una especie de elección satisfactoria

    • Trabajando con otros desarrolladores, lo que he notado es que muchos pierden velocidad por falta de dominio de las herramientas
      Les fallan cosas básicas como usar mouse y teclado, navegar archivos o buscar comandos
      Por eso se vuelve fuerte la tentación de decir “mejor preguntémosle al LLM”
      Pero la solución real es mejorar el dominio de herramientas y aprender motores de plantillas
  • La IA puede causar atrofia de habilidades,
    pero si es en áreas en las que yo no quiero enfocarme, me parece bien
    Por ejemplo, no necesito conocer hasta las optimizaciones internas del compilador

    • Pero es difícil trazar con claridad las fronteras del dominio
      Para entender cómo interactúan los sistemas, también hace falta conocer en cierta medida cómo funciona un compilador
    • Me parece razonable el enfoque de Mitchell Hashimoto
      Dejarle al LLM las partes de las que uno no quiere preocuparse,
      y concentrar los recursos mentales en los problemas que de verdad importan