GDD - la era del "desarrollo impulsado por gaslighting"

• En tiempos recientes, los usuarios de computadoras repiten una gran cantidad de tareas sin sentido ajenas a su propia voluntad, siguiendo lo que la computadora les indica
• Los LLM están influyendo en la forma en que los desarrolladores diseñan APIs, y ya han surgido predicciones de que pronto la IA escribirá la mayor parte del código mientras los desarrolladores adoptan funciones sugeridas por la IA
• Por ejemplo, Soundslice añadió en la práctica una función que ChatGPT había indicado erróneamente
• Esto ocurre porque los LLM analizan innumerables APIs y proponen diseños intuitivos que probablemente serían lo primero que se le ocurriría a un desarrollador
• Los LLM no son adecuados para desarrollar ideas nuevas o enfoques únicos, pero en la mayoría de los casos puede ser efectivo seguir el diseño más obvio
• Ya hemos entrado en una era en la que la IA no solo guía el uso de herramientas, sino también la forma en que se diseñan

---

Gaslight-driven development

Tareas sin sentido normalizadas

• En los últimos 10 años, cualquiera que use computadoras ha repetido una y otra vez tareas esencialmente innecesarias como registrarse, verificar el correo, aceptar cookies e ingresar captchas
• Aunque no era lo que querían, los usuarios no tuvieron más opción que hacer lo que la computadora les pedía
• A través de estas tareas repetitivas, ya nos hemos acostumbrado en cierta medida a vivir obedeciendo lo que nos indican las máquinas

La realidad del desarrollo que los LLM están cambiando

• Últimamente, los LLM han empezado a opinar sobre cómo deberían verse las APIs y las interfaces
  • Incluso han aparecido pronósticos de que para septiembre de 2025 la IA escribirá el 90% de todo el código
• Como en el caso de Soundslice, ChatGPT asumió por error que existía una función que en realidad no existía y, como seguían llegando solicitudes de clientes, terminaron agregándola de verdad
• En Instant ocurrió algo similar: antes tx.update se usaba tanto para insert como para update, pero como los LLM seguían generando código con tx.create, al final añadieron también el método tx.create

Qué significa este fenómeno

• Es difícil juzgar si este cambio es positivo o negativo
• Por un lado, como los LLM han aprendido de una enorme cantidad de APIs, tienden a proponer la forma más “intuitiva” desde la perspectiva del desarrollador
• También es una nueva forma de probar una API desde la perspectiva de un principiante (newbie’s POV)
  • Antes, si el desarrollador se equivocaba, buscaba la documentación y lo corregía por su cuenta; ahora, como el LLM sigue proporcionando ejemplos de uso incorrectos, el desarrollador puede detectar el problema más rápido

Límites y dilemas

• Este enfoque no es adecuado para trabajos innovadores
  • Los LLM no entienden patrones poco familiares ni conceptos completamente nuevos
• Al final, en ámbitos como las APIs, lo “común” puede ser lo mejor
  • En la mayoría de los casos, en vez de diseñar algo complejo, conviene más una forma que tanto la IA como los desarrolladores puedan entender de manera intuitiva

Conclusión: el inicio de una nueva era

• La IA ya no se limita a usar las herramientas dadas, sino que empieza a tener opiniones sobre cómo deberían diseñarse las propias herramientas
• Y esas opiniones a menudo terminan gaslighteando a desarrolladores y organizaciones, como si “siempre hubiera sido así”
• En adelante, es muy posible que desarrollar de acuerdo con las expectativas y el sentido común de la IA se convierta en un estándar natural

[ffdd270]

A veces siento que al gran concepto de la dependencia de trayectoria le están clavando un clavo muy potente llamado dependencia de los LLM. Esa sensación de que estamos pasando de “porque lo venimos usando desde antes” a “porque al LLM le gusta”... al final, ¿en qué terminará todo esto?

[kandk]

Eso es algo que se viene usando desde hace tiempo, y el LLM lo aprendió...

[jujumilk3]

"Ahora puede apagar la computadora"

[rosen]

¡Una analogía perfecta!

[GN⁺]

Opinión de Hacker News

• En una situación donde un LLM recomienda endpoints de API que no existen, imaginé qué pasaría si uno simplemente implementara ese endpoint a propósito y devolviera el código de estado 421: Misdirected Request, aunque también existe la opción de usar el 501: Not Implemented real; si el matiz de 501 no encaja, propongo un nuevo código: 513: Your Coding Assistant Is Wrong
  Referencia wiki de códigos de estado HTTP
  • La idea de 513: Your Coding Assistant Is Wrong me dio muchísima risa, gracias por eso; por otro lado, también quisiera proponer HTTP 407 Hallucination, con el sentido de que el servidor entiende la solicitud, pero determina que no coincide con la realidad
  • Esta historia también me recordó un caso divertido de un letrero de advertencia que avisa que el GPS está equivocado
    Caso de GPS is wrong
  • Voto a favor de introducir el código de estado 513; si ya existe el código 418, no veo por qué no podría existir el 513
  • Si van a hacer este tipo de broma, ojalá usen una respuesta 418; estaría bien que se usara más
• Ver en tiempo real que varios usuarios están viendo la misma página es divertido, pero me costó muchísimo leer el texto por los indicadores de usuarios entrando y saliendo todo el tiempo
  • Tengo en la barra de marcadores un bookmarklet que elimina de una vez este tipo de elementos fijos o sticky; lo uso seguido porque hace desaparecer todos los elementos fijos/sticky de la página y también restaura el scroll
    (se proporciona código JavaScript)
  • A mí también me resultó incómodo, así que haciendo clic derecho, luego Inspect para abrir las herramientas de desarrollador, y pegando el siguiente código en la consola, desaparece esa zona donde se muestran los usuarios

    document.getElementById("presence")?.remove();
    

    Si tienes curiosidad por saber por qué el cerebro reacciona de forma tan sensible a ese movimiento, tiene que ver con el instinto de detectar depredadores
    Enlace al artículo científico, Referencia wiki de neurociencia
  • Me hizo pensar en un juego llamado Chess Royale; tuve una experiencia parecida con avatares y banderas, y aunque era un juego realmente muy bien hecho, Ubisoft lo cerró como suele pasar a veces; una gran obra que da pena haber perdido
    Captura de pantalla de Chess Royale
  • Creo que era esa página que antes estaba llena de cursores en el fondo; a este nivel, me parece un concepto de diseño deliberadamente distractor, casi como una broma
  • Traté de quitar elementos de la página con una herramienta como uBlock, pero terminé en una situación que se repetía rápidamente, como jugar al whac-a-mole
• En Instant, la función tx.update se encarga tanto de insertar como de actualizar entidades, pero el LLM seguía escribiendo código con tx.create, así que al final terminé creando también una función tx.create; me hizo pensar que, en este tipo de partes confusas, quizá no solo los LLM sino también desarrolladores reales han desperdiciado muchísimo tiempo inútilmente
  • Si de todos modos tx.create no existía originalmente, entonces nadie iba a perder tiempo con eso, ¿no?
• Si una función soporta tanto inserción como actualización, creo que sería más correcto llamarla put en vez de update; update puede llevar a confusión
  • En ese caso, creo que lo correcto sería upsert
  • El nombre put sugiere sobrescribir el contenido existente, mientras que upsert sí significa tanto insertar como actualizar
• Siento que el universo va a llegar a la muerte térmica antes de que yo cambie una sola línea de código porque un LLM escupió un texto equivocado; me parece a la vez absurdo y cómico tener que modificar código por una razón tan ridícula, y no me resulta aceptable
• No estoy de acuerdo con la tesis del post; desde el enfoque inicial ya me pregunto si de verdad tenemos que seguir lo que quiere la computadora
  También creo que razones como la verificación por correo o el registro de usuarios no surgieron porque la computadora lo exigiera, sino por decisiones de diseño tomadas por humanos
  • Me parece una interpretación generosa siquiera llamar a eso una “thesis” (tesis); en cuanto llegué a esa parte cerré la página de inmediato
• Hace poco tuve una conversación divertida con mi equipo sobre los principios de programación del futuro
  En adelante, más que centrarnos en la legibilidad del código, los principios SOLID o la complejidad, creo que será más importante qué tan bien puede mi IDE agentic indexar el contexto del código y qué tan buena capacidad de generación muestra el modelo sobre ese código
  Como la velocidad de cambio del código va a aumentar muchísimo, la mantenibilidad del código pasará a ser una métrica aún más clave, y creo que vendrá un mundo en el que recibirán más atención la alineación entre prompts y código, así como la utilidad de código que encaja bien casi por casualidad
• Si una persona estuviera difundiendo de forma constante, y con total seguridad, consejos nuevos de desarrollo sobre mi producto que en realidad son falsos, me pregunto si una empresa realmente optaría por agregar esas funciones imaginarias y luego escribir una entrada de blog perpleja al respecto
  • Me pregunto si, si yo directamente actuara como un LLM y cometiera errores absurdos mientras insisto con confianza, la gente igual me lo dejaría pasar
  • De hecho, me hace pensar si el Sr. Martin, autor de “Clean Code”, no tiene justo ese estilo
  • Si esa persona influyera sobre el 90% de mis clientes, probablemente sí terminaría introduciendo esa función imaginaria
  • La mayoría de las empresas seguramente afirmarían con total seguridad que esa función innecesaria sí es indispensable
• También se siente como el comienzo de una gran amistad con los LLM; trabajando como fractional CTO, lo que más me frustra es que cada cliente tiene convenciones de nombres distintas incluso para cosas triviales como los nombres de entornos
  Por ejemplo, en AWS está dev y prod, mientras que en Expo está test y production, así que al ir saltando entre varios proyectos uno termina gastando más energía mental de la que parece
  Supongo que los LLM deben enfrentar este problema a una escala muchísimo mayor
  Si pudiéramos usar en cosas realmente significativas esas sinapsis cerebrales que hoy se gastan en confusiones innecesarias de nombres/comportamientos de APIs, creo que eso sería lo ideal
  • Hay un chiste en ciencias de la computación que dice que existen tres problemas difíciles: invalidación de caché, poner nombres y errores off-by-one
    Por más inteligente que sea el LLM al poner nombres, como se basa en un incoherent stochastic process (proceso estocástico incoherente), el problema sigue ahí
    Y también quisiera preguntar si alguna vez se ha cuestionado seriamente por qué la nomenclatura de entornos no está unificada
    Como ex CTO, pienso que este tipo de cosas son señales de que hace falta mejorar la comunicación interna, los criterios y otros aspectos de la organización
    Como son puntos fáciles de corregir y además pueden mejorar la cultura real y la conciencia del equipo, diría que en vez de dejar algo así al LLM habría que atenderlo más directamente
• Como enlace relacionado
  Ver discusión previa en Hacker News

[dkmin]

Éxito viral de Soundslice