33 puntos por GN⁺ 2026-02-10 | 2 comentarios | Compartir por WhatsApp
  • Frente a la entusiasta adopción de las herramientas de generación de código con LLM en la industria, este texto subraya la importancia de pensar en el desarrollo de software
  • El código generado automáticamente es no determinista (non-deterministic) y su funcionamiento interno es opaco, por lo que es esencialmente distinto de la mecanización, que garantiza el mismo resultado cada vez
  • Los LLM aprenden de código existente de baja calidad, repiten los mismos errores y vuelven a alimentar ese aprendizaje, creando el problema de la "epistemología del ciempiés humano (human centipede epistemology)"
  • Cuando la generación de código se delega a agentes, en la revisión de PR se debilitan el contexto compartido y la responsabilidad, lo que perjudica la calidad del software
  • Los LLM pueden ser útiles en usos limitados como el prototipado, pero es riesgoso que los desarrolladores tercericen el acto mismo de pensar; sin comprensión, el mantenimiento es imposible

La incomodidad con la generación de código con LLM

  • Aunque durante mucho tiempo he seguido las últimas tendencias de la industria y he compartido con colegas novedades de CSS y JS, con la rápida expansión de la generación de código basada en LLM empecé a sentir la ansiedad de estar quedándome atrás
  • He usado Copilot y Claude como "spicy autocomplete" y como herramientas de apoyo para depuración, pero si se les pide algo mínimamente complejo, el resultado suele ser un desastre
  • Hay que darles suficiente contexto, pero si es demasiado se saturan, y uno termina escribiendo prompts largos para calmar el ego del LLM, como "eres un experto en sistemas distribuidos"
  • Muchas veces es más rápido escribir el código directamente que dedicar tiempo a pulir el prompt
  • Me pregunto por qué los ingenieros quieren abandonar la parte divertida de programar y dejar solo la parte aburrida de revisar

Réplica a la idea de que es "la repetición de la Revolución Industrial"

  • Así como la Revolución Industrial contribuyó al cambio climático, se puede ver un patrón similar en el enorme consumo energético de los centros de datos de IA
    • No toda la electricidad proviene de combustibles fósiles, pero generar imágenes como "shrimp Jesus" implica un desperdicio enorme de recursos
  • La mecanización abarató y masificó los bienes, pero también provocó una caída en la calidad, llevándonos a una realidad donde puedes comprar pantalones en SHEIN por menos que un café
    • Esto empeoró con el declive del trabajo calificado, el traslado de fábricas a países de salarios bajos y la explotación laboral
  • El código generado se parece a la moda rápida: a simple vista parece aceptable, pero con el tiempo queda lleno de agujeros, a menudo toma prestado código ajeno sin permiso y además perjudica al medio ambiente
  • La diferencia clave: la mecanización produce el mismo resultado cada vez y, cuando había problemas, se podía inspeccionar su interior; en cambio, la salida de un LLM es no determinista y su funcionamiento interno es opaco
    • Un proceso mecanizado que diera resultados distintos cada vez y mezclara alucinaciones (hallucinations) no sería útil

Réplica a la idea de que es "una nueva capa de abstracción"

  • Es cierto que al usar Java o Go ya no hace falta aprender ensamblador, y que el runtime se encarga de la recolección de basura y la asignación de memoria
  • Pero cuestiones como la arquitectura del sistema, el impacto sobre la ruta crítica, los trade-offs entre mantenibilidad y velocidad de despliegue, la compatibilidad entre navegadores y temas como accesibilidad, seguridad y rendimiento siguen siendo ámbitos en los que el desarrollador debe pensar por sí mismo
  • El punto donde los LLM hacen más daño es cuando el ingeniero terceriza el acto mismo de pensar necesario para desarrollar software
    • Como los LLM no tienen capacidad de razonamiento, si el desarrollador no piensa y el LLM tampoco piensa, nadie está pensando
  • Caso del escándalo Horizon: por errores del software de Post Office, empleados inocentes fueron encarcelados y 13 personas se suicidaron
    • La responsabilidad (accountability) sobre el software importa más que nunca

El problema de fondo es el código de baja calidad

  • Los desarrolladores humanos también están escribiendo código con mala accesibilidad, bajo rendimiento y dependencia excesiva de JavaScript
  • Los LLM se entrenan con ese código de baja calidad como datos de entrenamiento (sin consentimiento explícito) y vuelven a producir los mismos errores
  • Luego ese código deficiente generado por LLM vuelve a ser aprendido por otros LLM, en una estructura circular conocida como "epistemología del ciempiés humano (human centipede epistemology)"
  • Si se piensa en usuarios de tecnologías de asistencia, usuarios con mala conexión a internet o víctimas del sesgo racial del software de reconocimiento facial, queda claro que la calidad actual del software no es suficiente
  • En vez de aprender y mejorar como humanos, hemos tercerizado nuestros errores a algoritmos que no piensan

Revisión de PR y debilitamiento del contexto compartido

  • Mensaje central de la charla de Jessica Rose y Eda Eren en FFConf: "el código que no escribiste tú es código que no entiendes, y el código que no entiendes no lo puedes mantener"
  • En un PR escrito por un colega hay cierto nivel de confianza y proceso de pensamiento, pero en un PR generado por LLM no existe esa garantía
  • Los mantenedores de código abierto ya están viviendo una explosión de PR de baja calidad generados por LLM
  • Algunas empresas usan un método en el que, desde Slack, le piden a Claude cambios de código por chat y luego la misma persona aprueba el PR generado automáticamente
    • En ese caso, toda la responsabilidad recae en una sola persona revisora, y se pierde uno de los dos pares de ojos
    • También disminuye el contexto compartido (shared context) dentro del equipo
  • La revisión de PR no es solo para detectar bugs, sino también un proceso de compartir comprensión sobre el código y los cambios

No es oposición al progreso, sino al hype excesivo

  • No se trata de oponerse a los LLM en sí, sino a la marca de "inteligencia artificial"
    • Los LLM no son inteligentes; son una forma de aprendizaje automático
    • La "IA generativa" es una cadena de Márkov muy bien construida sobre la que la gente deposita expectativas excesivas
  • Tiene sentido usarlos para crear rápidamente prototipos, wireframes o demos interactivas
  • El problema es creer que con "vibe code" se puede construir software de nivel de producción, o delegar el propio proceso de pensamiento detrás de programar
  • Según la postura de Mikayla Maki en el blog de Zed, a los agentes hay que tratarlos como colaboradores externos en quienes no confías, usarlos solo para tareas que ya sabes hacer y considerar indispensable entender el código
  • Seguiré usando "spicy autocomplete", pero no tercerizaré el pensamiento, y hay que recordar por qué nos gustó este trabajo desde el principio

2 comentarios

 
crawler 2026-02-10

El código generado automáticamente es no determinista (non-deterministic)
En contra del branding de "inteligencia artificial"

De verdad, son las palabras más importantes...
En GeekNews también hay quienes lo comparan con una calculadora o una cámara; si incluso los desarrolladores tienen esa percepción, da miedo pensar cómo lo verá la gente en general.

 
GN⁺ 2026-02-10
Comentarios de Hacker News
  • Mientras la IA sea vista no como una "bicicleta para la mente" sino solo como un producto para maximizar las ganancias de las grandes empresas, creo que es difícil justificar el estado actual de la IA
    Una estructura que raspa datos, los procesa y los devuelve sin un proceso de aprendizaje real perjudica el desarrollo mental humano

    • No estoy de acuerdo. La discusión sobre la "mercantilización" es un tema de sostenibilidad económica, y la industria de la IA hoy está en una situación económicamente inestable
      Al final, lo clave es construir un modelo de ingresos; de lo contrario, no se pueden mantener LLM de alta calidad
    • ¿El problema de escanear libros y luego quemarlos no es culpa de la ley de derechos de autor?
  • Yo ya casi no hago edición manual. Si le paso solo la URL del ticket a Claude Code, resuelve la mayoría de las veces en un solo intento
    Creo que los equipos que inviertan en este enfoque serán mucho más productivos que los que no lo hagan
    Los LLM son una tecnología que da experiencias completamente distintas según la persona, y el grado de libertad del prompt es enorme

    • Esto solo funciona cuando no miras el código directamente. Le pedí generar código de svelte 5 para un proyecto nuevo y entregó código con versiones mezcladas
      Cuando hay que implementar un diseño específico, al final escribirlo yo mismo resulta más rápido
    • Quienes no usen Claude Code o Cursor al final corren el riesgo de quedarse atrás
    • Yo estoy del lado de revisar código hecho por IA, y me frustra porque la calidad es un desastre
    • Pienso lo mismo. Parece que esta gente no ha probado las herramientas que yo uso
  • Decir "no puedo entender código que no escribí yo" no es realista
    El objetivo del code review no es la identidad del autor, sino garantizar la confiabilidad del sistema
    Da igual si lo escribió un humano, una IA o incluso un golden retriever

    • Aunque no escribas el código tú mismo, puedes leerlo, depurarlo y entenderlo
      Pero en vez de gastar tiempo intentando entender un PR hecho por IA, siento que me conviene más lanzar yo mismo el prompt y obtener el resultado
    • Si code review, pair programming y TDD no sirven, me pregunto qué sí sería efectivo
    • El punto aquí es "el problema de que quien lo escribió no entienda el código"
      Si dependes de un LLM, el desarrollador pierde la oportunidad de aprender la estructura del proyecto y termina tratando el sistema como una caja negra
      Esta tendencia está convirtiendo a los desarrolladores en "prompt kiddies"
  • Me identifico con eso de "prefiero escribir el código yo mismo antes que perder tiempo afinando prompts"

    • Pero la historia cambia si el prompt se convierte en una habilidad reutilizable
      El problema no es la "generación", sino la generación no estructurada
      En vez de prompts improvisados, hay que enfocarse en una composición por unidades claras de habilidad
  • Eso de decirle a la IA "eres un experto en sistemas distribuidos" es una historia de la era GPT-3
    Hoy, gracias al fine-tuning y las técnicas de posprocesamiento, ya no hacen falta esos prompts basados en roles

  • Al ver el furor por la generación de código con LLM, me preocupaba estar quedándome atrás
    He usado Copilot y Claude solo como asistentes de autocompletado, pero el código complejo seguía saliendo mal
    Pero últimamente las herramientas basadas en agentes buscan en la base de código, encuentran material en la web y ajustan el contexto por sí solas
    Al final, el problema es de "gente que se queja sin entender bien la tecnología"

    • Si ves este hilo anterior de HN, la gente que dice "los LLM no pueden reproducir mi algoritmo" no publica sus prompts
      En realidad, es muy posible que simplemente les falte habilidad con los prompts
    • Los LLM no piensan; son modelos estadísticos
      Solo parecen "pensar" porque las herramientas alrededor automatizan la búsqueda y la ejecución
      Al final esto es automatización, no inteligencia
    • Se burlan de la idea de que "los prompts basados en roles ya son cosa del pasado" y que ahora estamos en una era centrada en agentes
    • "¿Entonces solo escribiste mal el prompt?", bromean
  • Últimamente muchos posts y comentarios en HN se sienten como si los hubiera escrito un LLM
    No hay nada nuevo, y la mayoría solo repite generalizaciones superficiales

    • (En tono sarcástico) "Sí, claro, totalmente cierto"
    • "¿De verdad lo estás leyendo bien?", responde otro
    • Cierran con la broma de "ya basta, salgan afuera y toquen el pasto"
  • Viendo las noticias recientes, la IA todavía no está lo suficientemente madura
    Por ejemplo: Microsoft recorta su meta de ingresos de Copilot y el caso de los problemas de seguridad de Moltbook
    Al final, la mayoría de la gente no confía en la IA
    La IA sirve para explorar ideas o escribir boilerplate, pero la capacidad de pensar sigue siendo lo esencial

    • La capacidad de pensar es una herramienta instintiva de supervivencia para los humanos
      La IA es la mayor tentación para reemplazar el pensamiento humano, pero a largo plazo corre el riesgo de debilitar ese músculo mental
      Si después de usarla un tiempo vuelves a programar a mano, sentirás que has perdido fluidez
    • Todavía es difícil juzgarlo
      Puede que Claude sea mejor que Copilot, y los problemas de seguridad de Moltbook podrían ser simplemente el destino de los servicios tempranos
      Al final, la respuesta se verá en la tasa de supervivencia de las empresas que adopten IA y las que no
  • Yo también antes pensaba que "la IA es una caja negra tonta", pero en los últimos 6 meses mi perspectiva cambió por completo
    Si aprendes a usarla bien, puede dar resultados sorprendentes
    Ahora veo la IA como un amplificador y la uso como una herramienta para expandir mis capacidades