Pérdida de savviness con LLMs: ¿se te oxida el criterio?

En pocas palabras: Paolo Galeone, ingeniero de software, publicó en su blog en 2024 que los LLMs generan una pérdida de “savviness”: la comprensión práctica que se oxida al delegar el razonamiento en la IA, transformándote en un operador de prompts que no distingue código elegante de un parche.

Si alguna vez te pasó que abrís el editor, tirás un prompt, el modelo te escupe 200 líneas de código y sentís que no aprendiste un carajo, no estás solo. Paolo Galeone, un desarrollador con experiencia en software, publicó un descargo justo sobre esto. La pérdida de savviness con LLMs es la sensación de que tu astucia técnica se oxida mientras vos solo mirás la pantalla evaluando resultados ajenos.

Es lo que Galeone describe como perder la maña, la “comprensión práctica” que solo se gana con las manos en el teclado y los errores en carne propia. Porque usar IA para código no es como usar una calculadora —si delegás el razonamiento, perdés el músculo del pensamiento lógico que te llevó años entrenar— y cuando ese músculo se atrofia, lo que queda es un operador de prompts que no distingue una solución elegante de un parche sin sentido.

¿Qué significa “savviness” en programación y por qué los LLMs te la hacen perder?

“Savviness” no tiene una traducción exacta al español, pero la idea es “astucia práctica” o “maña”. En su artículo, Galeone la define como “la percepción, comprensión o agudeza, especialmente en asuntos prácticos” y la conecta con el aprendizaje basado en la acción. Hacer, pifiarla, aprender del error y repetir. Eso es lo que te vuelve canchero.

Ahora bien, cuando un modelo de lenguaje te da la respuesta correcta a la primera —o peor, vos detectás el error, lo señalás y el LLM lo corrige en segundos— ese ciclo de aprendizaje se corta. El cerebro no registra el tropiezo. Según Galeone, tiene la suerte de haber acumulado experiencia como para detectar cuándo el modelo la está pifiando, pero el problema es que los proveedores de LLMs se “roban” su astucia al entrenar a sus modelos. “Con los LLMs cada vez que hay un error, no aprendo”, escribe. Y lo peor es que sabe que sus correcciones van a parar a un dataset que hará que el próximo modelo ni siquiera cometa ese error, sacándole a él la oportunidad de reforzar su propio conocimiento. Relacionado: nuestra guía sobre seguridad en Microsoft Intune.

¿Cómo cambia el proceso de aprendizaje cuando delegamos todo en un modelo de lenguaje?

Ponele que siempre fuiste de los que se quedaban hasta las 3 AM debugueando un script en Python o mezclando tecnologías que no conocías solo por el placer de experimentar. Ese era Galeone antes de los LLMs. Ahora, según cuenta, la dinámica cambió a “prompt, evaluar salida, ajustar, repetir”. El flujo creativo desapareció y en su lugar quedó un proceso mecánico que describe como “aburrido” y carente de desafío.

La diferencia clave está en cómo se fija el conocimiento. Cuando vos leés la descripción de una fórmula matemática sin aplicarla, la información se evapora en horas. Es lo que pasa con los resúmenes. El autor lo explica así: usar un LLM para aprender es como leer un resumen sin ensuciarse las manos, “bastante inútil” para generar maña real. No hay manera de construir intuición si nunca chocaste contra la pared del error. Las ideas que antes surgían “de la nada” mientras hacías otra cosa —y te obligaban a correr al escritorio para implementarlas— ya no aparecen, porque el cerebro no está en tensión creativa. Está en modo espectador.

El costo de delegar: ¿cuánta deuda técnica generás sin darte cuenta al usar asistentes de IA?

Acá viene lo picante. Galeone no solo habla de la sensación personal de vacío: va directo al hueso de la productividad en desarrollo. Si alguna vez trabajaste en una empresa donde miden todo por cantidad de PRs mergeados, sabés que el incentivo para usar LLMs es enorme. Pero él sostiene que si alguna vez aparece una métrica de productividad real que contemple velocidad de ejecución, deuda técnica, mantenibilidad y costo total, los LLMs “no van a brillar”.

El problema no es que el código generado sea malo —de hecho él reconoce que la calidad mejora mes a mes— sino que se produce sin criterio humano. Se genera “deuda técnica interminable” porque nadie entiende del todo lo que se está subiendo a producción. Y cuando el desarrollador que aceptó el código se va del equipo o simplemente no le prestó atención, el siguiente en tocar ese módulo se encuentra con un Frankenstein sintético indescifrable. Ya lo cubrimos antes en el artículo completo sobre ChatGPT.

Eso sí: Galeone aclara que si ponés reglas, guardrails y documentos de diseño por adelantado, el modelo genera código similar al que él mismo escribiría. Pero ese “upfront design” justamente requiere el criterio y la astucia que él siente que está perdiendo. La presión corporativa, dice, es enorme: en el trabajo te empujan a usar estas herramientas “para no quedarte atrás”. ¿Atrás de qué, exactamente? La pregunta es retórica pero la respuesta está implícita: quedás atrás en velocidad bruta, pero adelantás años de deuda técnica que alguien va a tener que pagar.

Enfoque de aprendizaje	Sin LLMs (Savviness clásica)	Con LLMs (Delegación pasiva)
Adquisición de conocimiento	Estudiar, errar, debuggear, entender la raíz del problema	Leer la solución generada, confiar, implementar sin profundizar
Tipo de comprensión	Profunda y contextual: sabés por qué funciona y por qué falla	Superficial: identificás patrones pero no el mecanismo interno
Relación con el error	Fuente de aprendizaje: cada bug enseña algo nuevo	Obstáculo molesto: se reporta al LLM para que lo corrija sin analizarlo
Resultado a largo plazo	Intuición técnica, autonomía, capacidad de innovar desde cero	Dependencia del modelo, pérdida de creatividad, astucia oxidada

¿Hay manera de usar LLMs sin quedar en bolas de astucia técnica?

Sí, pero con condiciones. El propio Galeone lo descubrió sin querer. A pesar de todo el desencanto, se puso a configurar una máquina Linux para inferencia local. Y esa parte —elegir hardware, instalar drivers, pelearse con la terminal— fue “lo más divertido”. ¿Por qué? Porque lo hizo él. No le pidió a un LLM que le arme el setup. Usó la herramienta para lo que sirve (prototipado, aburrición automatizable) y mantuvo la parte artesanal para sí mismo.

Hay un par de estrategias que se desprenden de su experiencia y que cualquier persona técnica puede aplicar:

• Usá LLMs para prototipos y tareas repetitivas, pero iterá manualmente. Si el modelo tiró una arquitectura de base de datos, revisala, rompela y reescribila con tus propias manos al menos una vez.
• Forzate a entender cada línea que aceptás. Si no podés explicarle a un colega por qué el código funciona, borralo y empezá de nuevo (o pedile al LLM que te explique, pero sin copypastear).
• Mantené proyectos personales “offline” de IA. Como hizo Galeone al montar su máquina de inferencia local, destiná tiempo a construir cosas sin delegar para mantener el músculo entrenado.
• Aprendé de los errores del modelo tanto como de los tuyos. Cuando el LLM la pifia —y va a pifiar— no solo lo corrijas: investigá por qué se equivocó y qué supuesto incorrecto tenía detrás.
• Leé “Use Your Brain: Engineering Standards in the Age of LLMs”, el artículo que Galeone escribió y en el que propone justamente mantener estándares de ingeniería con cabeza humana al usar IA.

Ejemplos concretos de pérdida de savviness con LLMs

Imaginá esta escena: necesitás una query SQL para un reporte de ventas regionales. Le tirás el prompt a Claude, te devuelve un SELECT gigante con tres JOINs y una subconsulta. Lo probás, funciona. Pero no te diste cuenta de que una de las tablas que referenció el modelo no existe en tu entorno de staging —el LLM la inventó porque “sonaba razonable”— y vos aceptaste el output sin revisar el esquema real de la base. La query corrió en producción y rompió el dashboard. Conclusión: no aprendiste SQL, no aprendiste el esquema de tu propia base, y además generaste un incidente. Galeone lo llama “falta de craft”: no hay arte ni oficio en aceptar código sin comprenderlo. Te puede servir nuestra cobertura de la guía de modelos de lenguaje con razonamiento.

Otro ejemplo: el mismo Galeone relata que antes de la explosión de los LLMs, su placer culpable era mezclar tecnologías que no dominaba —un poco de Rust con frontend en Svelte, bases vectoriales con Python— solo para ver qué pasaba. Se quedaba horas, se frustraba, buscaba en documentación, aprendía. Ahora, con pedirle al modelo del mes que implemente la idea, el prototipo sale en minutos. ¿El costo? Cero diversión, cero desafío y cero aprendizaje profundo. Perdió la chispa.

Qué significa esta discusión para empresas y equipos tech en Latinoamérica

En la región hay una fiebre por “productivizar con IA” que omite un detalle: la deuda técnica se paga con tiempo de desarrolladores y plata de la empresa. Si un equipo argentino o colombiano empieza a aceptar pull requests generados por Copilot sin revisión humana profunda, el ahorro inicial de tiempo se va a transformar en meses de refactoring. Y no hablo de startups con presupuesto infinito: hablo de pymes que pagan servidores dedicados y servicios como donweb.com para mantener sus aplicaciones andando, y donde cada minuto de downtime cuesta guita real.

Galeone lo dice sin filtro: la presión por usar estas herramientas viene de un miedo a “quedarse atrás”. Pero ese miedo es una trampa. Las empresas de Latam tienen equipos más chicos y con menos redundancia: si la única persona que entiende un módulo se va, y ese módulo fue generado en un 80% por LLMs sin documentación ni comprensión humana, el quilombo es mucho peor que en una big tech con cientos de ingenieros. Acá no sobra nadie, y la astucia individual sigue siendo el activo más valioso del equipo.

Errores comunes al incorporar LLMs en el flujo de desarrollo

• Copiar y pegar sin leer. Es el error más básico y el más repetido. Confiar en que el output del modelo es correcto porque “se lee bien” es una receta para bugs difíciles de rastrear.
• No ajustar el contexto de seguridad y negocio. Los modelos no conocen las reglas de tu dominio ni las restricciones de compliance. Si no les das ese contexto, generan código que funciona pero que viola políticas internas.
• Medir productividad solo por líneas de código o PRs mergeados. La métrica favorita de los managers que no programan. Lo que parece velocidad hoy es trabajo extra para el futuro (vos o el pobre infeliz que herede tu repo).
• Delegar el diseño de arquitectura sin supervisión. Los LLMs proponen soluciones genéricas basadas en patrones populares. No entienden la carga real de tu sistema ni los costos de infraestructura.

Preguntas Frecuentes

¿Qué es la savviness en programación?

Es la astucia práctica y la comprensión profunda que se adquieren al programar de forma activa. La definición que usa Paolo Galeone en su artículo es “tener percepción, comprensión o agudeza, especialmente en asuntos prácticos”. Se desarrolla haciendo, equivocándose y corrigiendo: no se obtiene leyendo resúmenes ni evaluando código generado por un modelo.

¿Por qué siento que estoy perdiendo mis habilidades al usar ChatGPT o Copilot?

Porque el ciclo de aprendizaje basado en ensayo y error se rompe cuando delegás la generación de soluciones. Si no te enfrentás a los problemas ni entendés la raíz de los fallos, tu cerebro no consolida el conocimiento. El artículo de Galeone lo explica con claridad: al detectar un error y pasárselo al LLM para que lo corrija, vos no aprendés nada; simplemente administrás la herramienta. Sobre eso hablamos en el recurso completo sobre Google.

¿Es malo depender de la IA para escribir código?

Depende del uso. Usarla para automatizar tareas repetitivas o prototipar rápido no es malo en sí. El problema aparece cuando delegás el razonamiento y la toma de decisiones de diseño, porque dejás de ejercitar tu criterio técnico y generás dependencia. A largo plazo, eso te convierte en un operador de prompts en lugar de un ingeniero de software.

¿Cómo puedo evitar que los LLMs me quiten la astucia como programador?

Limitá la delegación a tareas que ya dominás y usá el output como punto de partida, no como producto final. Dedicá tiempo a proyectos personales sin asistencia de IA y forzate a entender cada línea de código que aceptás. La experiencia de Galeone configurando una máquina para inferencia local es un buen ejemplo: aplicar la IA para lo que sirve, pero mantener la parte artesanal en tus manos.

¿Qué dijo Paolo Galeone sobre la deuda técnica con los LLMs?

Galeone sostiene que si se mide la productividad real del desarrollo de software —incluyendo velocidad, mantenibilidad y costo— los LLMs “no van a brillar”. Afirma que su uso sin criterio humano genera “deuda técnica interminable”, porque se produce código rápido que nadie se toma el trabajo de entender en profundidad. La presión corporativa por usar estas herramientas empeora el problema.

Conclusión

El artículo de Paolo Galeone tocó un punto que conozco bien: la sensación de que programar se está convirtiendo en una tarea de supervisión vacía. La pérdida de savviness con LLMs no es un invento de nostálgicos del código artesanal, es el resultado lógico de delegar justo aquello que nos hacía buenos en esto: el error, la frustración, la chispa de entender un concepto complejo después de horas de pelea.

Lo que cambió respecto a años anteriores es que el código generado por modelos ya no es un desastre ilegible; es suficientemente bueno como para tentarnos a dejar de pensar críticamente sobre lo que estamos subiendo a producción. Y ahí está la trampa. La solución no es quemar las GPUs ni volver a programar en Notepad. Es ser eficiente con lo que automatizás y egoísta con lo que aprendés. El oficio no se delega. Se entrena, se cuida y se mantiene, y en un mercado donde todos corren por tirar más prompts, el que entiende el porqué detrás del output es el que va a seguir valiendo la pena.

Fuentes

• LLMs are making me lose my savviness – Paolo Galeone — Artículo original del ingeniero de software donde describe su pérdida de pasión y astucia técnica al usar modelos de lenguaje.
• Use Your Brain: Engineering Standards in the Age of LLMs – Paolo Galeone — Post del autor donde propone mantener rigor de ingeniería al usar inteligencia artificial.