IA: incompetencia acelerada

 (slater.dev)
5 puntos por GN⁺ 2025-05-29 | 1 comentarios | Compartir por WhatsApp
  • En ingeniería de software, una dependencia excesiva de los LLM acelera rápidamente la incompetencia
  • Los LLM tienen límites que les impiden sustituir el pensamiento crítico y la capacidad de resolver problemas
  • El uso de LLM conlleva varios riesgos, como salidas incorrectas, errores de entrada, deterioro de la calidad del código, disminución de la capacidad de los desarrolladores y pérdida del disfrute de crear
  • Los LLM no pueden aportar capacidades esenciales de desarrollo como la teoría del programa y la entropía del programa
  • A largo plazo, la capacidad técnica y la profundidad de pensamiento son más importantes que nunca

Introducción

Desde la aparición de la IA y los LLM, que captaron la atención del público a finales de 2022, ha habido muchos debates
Como ingeniero de software con experiencia, expone dos problemas principales que ha observado en los LLM

La perspectiva de “LLM es mi amigo”

Los ingenieros que consideran al LLM como la mejor herramienta terminan poniendo la velocidad como valor supremo
Con un LLM se puede generar mucho código rápidamente, pero eso implica riesgos a largo plazo

Riesgos de usar LLM

  • Riesgo de salidas incorrectas: el LLM genera código claramente incorrecto (que no compila) y código con errores sutiles (como bugs lógicos)
    • Cuando personal sin capacidad de evaluación pide código fuente, es muy probable que reciba respuestas inadecuadas
  • Riesgo de entradas incorrectas: el LLM no cuestiona supuestos erróneos ni prompts con poco contexto
    • No distingue una pregunta correcta y tampoco puede empatizar con el problema XY (fracaso al identificar la causa raíz)
  • Disminución de la velocidad futura de desarrollo: la adopción de LLM aumenta rápidamente la deuda técnica y transforma internamente el código en una base de código confusa y difícil de mantener
  • Riesgo de infantilización del usuario: al desaparecer las oportunidades de resolver problemas y desarrollar el pensamiento, se acelera la atrofia de las capacidades del talento de desarrollo
    • Los desarrolladores senior no obtienen experiencias más profundas de resolución de problemas, y los junior ni siquiera llegan a formar sus habilidades
  • Pérdida de la alegría de crear: escribir código con LLM arrebata el estado de flow y el disfrute de crear, y leer y modificar código hecho por IA suele ser una experiencia muy dolorosa

La preocupación de “¿Perderé mi trabajo por la IA?”

Es muy poco probable
Existen dos capacidades de desarrollo que los LLM no pueden reemplazar: teoría del programa y entropía del programa

Teoría del programa

  • Como sostuvo Peter Naur, “programar es la actividad de construir una teoría del diseño”
    • El código fuente no es el resultado real; la comprensión colectiva (la teoría) es más importante
    • Si se les da el mismo problema a dos equipos con la misma capacidad y solo se entrega el código, el equipo que lo construyó directamente puede añadir funcionalidades con mucha más eficacia
    • En una base de código desconocida la productividad es baja, pero aumenta gradualmente a medida que se comprende la teoría interna del diseño

LLM y teoría del programa

  • Los LLM solo tienen memoria en contexto, por lo que no pueden interiorizar una teoría real del programa ni un diseño profundo
    • En la práctica, la verdadera esencia de programar (diseño y construcción de teoría) solo la adquieren los seres humanos

Entropía del programa

  • Fred Brooks llamó a la complejidad (entropía) la dificultad fundamental de la programación
    • El mantenimiento del software aumenta la complejidad, e incluso la mejor ejecución empuja al sistema hacia un envejecimiento irreversible

LLM y entropía del programa

  • Los LLM solo realizan predicción de tokens a nivel de texto y no pueden llevar a cabo pensamiento semántico al nivel de ideas, planos de diseño o requisitos
    • Cuanto más largas son las conversaciones o mayores los bloques de código, más repiten cambios innecesarios o extraños, aumentando todavía más la complejidad
    • Reducir la complejidad o resistirse a ella es una tarea que solo los humanos pueden realizar

Conclusión

A partir de las ideas de dos pioneros, se reafirma la naturaleza del diseño de software y de la complejidad
Si se espera que la IA mejore una carrera en desarrollo, hay que tener cuidado: podría en realidad acelerar la incompetencia
Como desarrollador con amplia experiencia y habilidades sólidas, hay que reconocer que los LLM no pueden reemplazar a los ingenieros humanos
El atractivo empresarial de adoptar IA está en reducir costos, pero en la práctica introduce nuevos riesgos y, si se usa en exceso, acumula costos adicionales y riesgos organizacionales a largo plazo
La importancia de la capacidad técnica y del pensamiento profundo no cambiará a largo plazo, y la IA debe usarse como herramienta mientras se sigue invirtiendo en las capacidades esenciales que ya eran importantes en 2019

Próximo artículo

En una publicación posterior se abordarán soluciones concretas para cada uno de estos riesgos

Referencias

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-05-29
Opinión de Hacker News
  • A veces se siente que la discusión sobre AI coding refleja la diferencia entre los ingenieros de software y los data scientists/ingenieros de machine learning
    De los ingenieros de software siempre se espera que construyan software predecible y que pase las pruebas, y además el tooling está mucho más desarrollado
    En cambio, para un ingeniero de machine learning es parte normal del día a día trabajar con modelos probabilísticos, y las pruebas suelen estar más centradas en métricas que en salidas específicas
    Por eso están más acostumbrados a que la IA no siempre sea confiable
    También abordan los asistentes de código con la idea de que, aunque solo den la respuesta correcta el 80% del tiempo, el 20% restante lo pueden detectar ellos mismos
  • En mi experiencia, aproximadamente la mitad de esto también se siente parecido
    Cuando trabajaba en Amazon, las soluciones basadas en ML eran muy útiles para problemas donde no existía un enfoque clásico
    Pero en una startup, sin entender filtrado o mapeo básicos, insistían solo en un enfoque basado en aprendizaje y seguían obteniendo resultados absurdos al estimar la actitud de una aeronave inmóvil
    Esta brecha entre ML y la ingeniería de software es clara, y ojalá hubiera una mejor forma de hacerla visible en el proceso de contratación
  • En el ambiente actual, se siente que la mentalidad de MLE se está aplicando a la fuerza a otros grupos
    En empresas que venden productos donde la precisión y la corrección son clave, he visto equipos de ML decir que 80~90% es suficiente, para frustración de los arquitectos
    Como en las discusiones de la pandemia sobre una tasa de mortalidad del 1%, vale la pena recordar que incluso porcentajes pequeños pueden tener un gran impacto
  • Se menciona la diferencia entre comportamiento determinista (Deterministic) y probabilístico (Probabilistic)
    Este texto se centra en una preocupación meta sobre la IA y la ingeniería de software: la gestión de la entropía (Entropy) del programa
    Gestionar la entropía es una parte enorme de construir productos de software, y aunque algún día la IA podría hacer esta parte fácilmente, por ahora muchas veces la empeora aún más
  • Actualmente curso una maestría en IA (especialmente ML) y, como SWE, estoy desarrollando músculos nuevos
    Veo a MLE desde una perspectiva más amplia de SWE, y hace falta entender todo: construir pipelines robustos, integrar modelos, despliegue, etc.
    Pero a la mayoría de los especialistas puros en MLE les falta la perspectiva de SWE, y muchas veces entienden ML sin tener intuición computacional
    Para ser realmente full-stack, es indispensable entender sistemas de bajo nivel, arquitectura, despliegue y también MLE
    Pero el mercado laboral casi siempre busca SWE o doctores en MLE; ojalá alguien me ofreciera una compensación por saber todo esto
  • Los ingenieros de software también aplican bastante pensamiento probabilístico en la práctica
    Por ejemplo, al rediseñar race conditions, predecir el p99 de llamadas a BD, o hacer pruebas A/B
  • En general coincido con lo que plantea el artículo, pero también he notado cambios positivos al usar LLM
    Como desarrollador senior con 30 años de experiencia, tener que leer código generado por IA significa que el desarrollo está pasando a un flujo centrado en code review
    Eso también ayuda al desarrollador individual a aprender la responsabilidad a nivel de equipo y a ganar experiencia leyendo código
    Además, para usar bien un LLM es indispensable entender la estructura jerárquica del problema
    Diseñar en detalle por secciones y luego implementar ayuda naturalmente a definir interfaces y límites
    El LLM es un catalizador que acelera el crecimiento de un junior hacia senior y le permite experimentar el aprendizaje de desarrolladores con experiencia
    La IA no va a reemplazar a los desarrolladores; al final se va a integrar como una herramienta
    • Siempre he pensado que uno debería leer más código del que escribe
      El código generado por LLM puede ser monótono, pero aun así es una oportunidad de aprendizaje
      He aprendido muchos modismos nuevos y llamadas de librerías a partir de código generado por LLM
      Mientras más senior eres, mejores prompts puedes dar, así que el LLM actúa como un catalizador aún más fuerte
    • La IA es muy buena para producir código tipo prototipo y copiar/pegar, pero no para revisar y hacer commit
    • Desde la perspectiva de la empresa, la IA no está ayudando a los juniors, sino sirviendo de excusa para eliminar su contratación y exigir a los seniors una productividad 10x con IA
      Los recortes siguen tanto en big tech como en mid-tech y small-tech
  • Se compara el debate sobre la IA con aquella vieja idea de si la impresión 3D reemplazaría toda la manufactura
    La postura es que la IA está más cerca de un cambio realista como ese que de la singularidad
    • La impresión 3D es una tecnología realmente genial e innovadora, pero el injection molding sigue existiendo
    • La impresión 3D no trajo la singularidad, pero en espacios de trabajo del conocimiento como la educación universitaria la IA ya está teniendo un gran impacto
      Se comparte la realidad de que formas de dar clases, tareas y cursos que antes parecían obvias están cambiando rápidamente en todo el mundo con la llegada de los LLM
    • La impresión 3D es un ejemplo de cambios e innovación enormes en industrias como la aeroespacial y espacial
      Sin SpaceX, muchas cosas realmente no habrían sido posibles
    • También es parecido a la expectativa de que Bitcoin reemplazaría a los bancos
      Al final, el resultado fue que los bancos salieron a vender productos financieros basados en Bitcoin
    • La impresión 3D y la IA tienen curvas de crecimiento completamente distintas
      La impresión 3D no se considera un reemplazo de la manufactura existente y se ha quedado en usos de prototipo/mockup/PoC
  • Los LLM son excelentes para escribir código, pero no pueden convertirse en el sujeto de la "responsabilidad"
    El código que aceptas sin entenderlo termina cobrando un precio alto después, cuando toca mantenerlo: deuda técnica
    Es como la ilusión de velocidad gratis; en realidad, la deuda técnica se acumula como si tuviera una tasa anual de alrededor del 40%
    La IA puede automatizar el tecleo, pero el pensamiento debe seguir siendo humano
    • Como el LLM no "entiende" de verdad, la comprensión real solo existe cuando el humano entiende el contexto del codebase y del sistema
    • Se propone reducir esa tasa de interés con testing y estructuración de subsistemas aislados (tdd, microservicios, etc.)
      Algunos sostienen que tdd y los microservicios, que no eran necesarios en el desarrollo tradicional, ganan más valor en la era de los LLM
    • Según la tarea, a veces la IA también puede ser muy mala incluso para escribir código
  • La experiencia de que el riesgo de entrada (Input Risk) era el mayor punto de dolor
    Una pequeña ambigüedad en el prompt puede desviar por completo el resultado, y cuando uno se da cuenta ya es difícil corregirlo a tiempo
    Fue por la ambigüedad del lenguaje humano que eventualmente surgieron los lenguajes formales
    Personalmente, al usar tooling de IA siento que mis habilidades están cayendo rápidamente, y de hecho he tenido casos donde gasté más tiempo y energía
    La IA es útil, pero parece haber un grupo que ve cómo pequeños errores se acumulan en problemas complejos y otro de managers/no técnicos que solo ven el resultado y dicen que ya hubo "reemplazo de funciones"
    [Experiencia detallada: comentario anterior]
    • Recomiendo una estructura donde la IA sea mi asistente y yo cargue directamente con la responsabilidad de calidad y mantenimiento
      Así como las calculadoras redujeron la capacidad de cálculo mental, la IA también puede degradar la escritura, la comunicación y la resolución de problemas
    • Se comparte la experiencia de que ingresar palabras ambiguas lleva a resultados ilógicos del LLM
      Por eso se usa el LLM solo para tareas pequeñas y claras, o para problemas que uno buscaría en StackOverflow
      Las respuestas no se toman como verdad absoluta, sino como guía
    • La IA ayuda a resolver algunos problemas más rápido, pero tampoco logra resolver problemas que se vuelven más complejos de lo necesario
      La capacidad humana de entender el plano general completo es clave para resistir la entropía
    • Un método que usa con frecuencia: primero pedirle al LLM que haga "3 rondas, 5 preguntas claras en cada una"
      Así se puede pulir mejor el tema y el contexto
      Ojalá este tip también le sirva a otras personas
    • Hay una intuición de que, después de esta era de hype, terminará redescubriéndose la importancia del control de calidad
      Ejemplo: la vieja guerra entre Coke y Pepsi
  • Hay quien dice que cuesta estar de acuerdo con la idea de que los LLM no manejan conceptualmente ideas, diagramas y especificaciones
    Si le preguntas al LLM por la intención del diseño, por ejemplo pidiéndole "dame una versión simplificada del código", también puede darte una segunda opinión bastante buena
    Si no preguntas, entonces no hay respuesta; y como la configuración por defecto también es una elección nuestra, se considera que esa afirmación no toca la esencia de la tecnología subyacente
    • Hay casos que muestran empíricamente de varias formas que el trabajo conceptual de los LLM ya existe
      En la realidad nadie puede entender un programa gigantesco completo en su cabeza, así que herramientas y lenguajes también evolucionaron con base en comprensión parcial
      Los LLM comparten ese mismo límite, así que dentro de ese marco humanos y LLM tienen limitaciones parecidas
    • Al revisar código de juniors, muchas veces el problema no es tanto la calidad del código sino la dirección que lleva
      Es una lástima que al LLM le cueste tener la capacidad de preguntar "¿por qué lo estás haciendo así?" respecto a esa dirección
    • Pregunta si usan herramientas automáticas para pasar de código a diagramas o si las hacen ustedes mismos
  • Se menciona la similitud con la idea de que software de mapas como Google/Apple Maps deteriora la capacidad humana de orientarse
    Hay parte de verdad, pero se piensa que la mayoría de la gente nunca fue buena para orientarse y que, más bien, la tecnología de mapas elevó en promedio la capacidad de ir de A→B
    Incluso para la minoría más hábil, la tecnología cumple un papel de apoyo más que de reemplazo de sus capacidades
    La IA probablemente traerá un cambio parecido a mayor escala: habrá puntos donde la capacidad se reduzca y se pierda, pero también habrá mucho que ganar
    • Los mapas no se pueden comparar con los LLM en términos de confiabilidad
      Los mapas casi siempre entregan el valor esperado, pero con el mismo prompt un LLM puede cambiar el resultado y se siente difícil confiar en él
      Así como hay gente que termina en un lago por confiar ciegamente en el mapa, confiar ciegamente en un LLM puede causar problemas mayores
    • Personalmente, usar software de mapas más bien ayuda a la memoria espacial
      Permite perderse libremente y retomar la ruta cuando hace falta, así que en realidad amplifica la experiencia
    • Google Maps es más de 90% más preciso que un taxista
      En cambio, la IA a veces ni siquiera supera a una persona común con apenas unos días en ese campo
    • Se duda de que haya evidencia para la afirmación de una "mejora del nivel promedio"
  • No se comparte la afirmación del autor de que "[la IA] no puede trabajar a nivel conceptual"
    Los LLM recientes claramente sí pueden trabajar a nivel conceptual (por ejemplo, traducción/aplicación de conceptos)
    Se afirma que entienden incluso conceptos que un humano no ha experimentado personalmente
    • Los LLM modelan conceptos mediante clusters de tokens
      Ejemplo: alrededor de "dog" se agrupan palabras relacionadas
      Pero no logran modelar composición, intención o razonamiento contrafactual
      Muestran fortaleza en preguntas parecidas a los datos de entrenamiento
      En áreas donde la conceptualización está bien definida, como la ingeniería de software, son útiles
    • Se agrega el ejemplo de que los humanos también pueden entender conceptos que no han vivido directamente
  • En la práctica, el 70% de los empleados hace su trabajo a medias, y a veces la IA incluso sale mejor parada
    Al final, quien no trabaja con ganas no cambia por usar IA, y solo quienes realmente aprenden crecen junto con ella
    • Se señala el límite de la narrativa egocéntrica de asumir que uno pertenece al 30%
    • Quien intenta usar IA para sacar la chamba por encima más bien se pone en riesgo de despido
      Si la IA hace mejor el trabajo, eso solo crea una justificación para reemplazar al responsable
    • Desde el punto de vista de una gran empresa, esta postura parece la más realista
      Incluso FSD (conducción autónoma) es mucho mejor que un conductor promedio no experto
  • Últimamente se comparte la sensación de que hace falta reconstruir 90s.dev como una comunidad sin IA, un espacio para la artesanía del software
    Se está pensando en formatos como foro, mailing list o multiblog
    Lista de correo temporal
    • Se piensa que, más que una estructura abierta a cualquiera, una basada en invitación y en un árbol de confianza de recomendaciones encaja mejor con una comunidad sostenible
      Ya hay casos exitosos en ciertas comunidades
    • También parece buena idea usar software clásico de foros de esa época con un diseño de nostalgia retro