¿Qué diablos está pasando ahora mismo?

• En la industria del software, el burnout de los ingenieros se está agravando, y en particular los ingenieros junior están causando problemas de calidad de código y colaboración por el abuso de herramientas de IA
• La retroalimentación de los ingenieros senior, en vez de usarse como oportunidad de aprendizaje, se convierte en un nuevo prompt para la IA, y el "código escrito por IA" termina consumiendo la revisión de todo el equipo
• En algunas organizaciones, el código incompleto generado por IA se presenta como si fuera un “logro”, creando un ambiente que fomenta la dependencia de la IA
• El autor, a partir de su experiencia directa, sintió malestar y extrañeza al recibir respuestas de código generadas por IA, y critica que la IA más bien está dañando la cultura de aprendizaje y mentoría
• También enfatiza que el ecosistema de startups de IA terminará siendo insostenible por su falta de viabilidad económica, consumo eléctrico y problemas ambientales, y que la situación actual no es muy distinta del fraude de “el emperador está desnudo”

---

Introducción: un entorno de ingeniería inquietante

• Últimamente, el burnout entre los ingenieros se ha intensificado
• En las organizaciones, se espera que los ingenieros senior revisen y contribuyan a "funciones basadas en vibra (meme)" que en la práctica ni siquiera funcionan
• Según mi experiencia, los mejores ingenieros siempre tienen entusiasmo por ayudar a que los nuevos miembros del equipo crezcan

• Pero, en lugar de que esa retroalimentación se use como una oportunidad de crecimiento, los desarrolladores junior simplemente la usan como el siguiente prompt para una IA generativa
• De hecho, he visto directamente muchos casos de ingenieros junior usando herramientas de LLM (modelos de lenguaje de gran tamaño) hasta un nivel que ya roza el abuso

Casos reales dentro de la organización: los daños del abuso de la IA

• Recientemente, en un town hall de la empresa, vi a ingenieros junior presentar demos de nuevo trabajo
• Ni siquiera parecía que entendieran bien el propósito o el funcionamiento de las funciones
• Pero en organizaciones grandes, el foco suele ponerse en escenificar el “éxito” sin importar el resultado real
• Cuando un senior manager mostró públicamente sus casos de uso de IA, explicó con orgullo: “estas son 4 mil líneas de código escritas por Claude”, y recibió aplausos

• Yo mismo recibí una solicitud para hacer una pequeña mejora a una función existente y, al revisar el código, le pedí contexto al ingeniero junior que la había modificado recientemente
• Le envié la URL del commit en GitHub con mi pregunta, pero parece que metió ese contenido en un LLM y luego copió y pegó la respuesta que recibió
• En ese proceso sentí una extraña sensación de desajuste e incomodidad

La pendiente de la IA y los límites de la revisión de código

• A través del caso de un amigo, confirmé que realmente está ocurriendo un desperdicio de tiempo en el que varios ingenieros pasan un mes entero revisando e intentando fusionar código generado automáticamente por un LLM (vibe-coded PRs)
• Otro amigo también contó que terminó agotado de revisar repetidamente “código chapucero” hecho por IA
• Gracias a la IA no se mejora la calidad del código ni se aprende más; solo aumenta el trabajo repetitivo

La cultura de desarrollo y el verdadero valor del crecimiento humano

• Todos los ingenieros crecen paso a paso gracias a sus colegas y mentores
• Enseñar directamente y ayudar a otros a crecer es la esencia de la cultura de la ingeniería de software
• Pero incluso esa inversión empieza a parecer vacía cuando el resultado termina copiándose de inmediato como datos de entrenamiento del “modelo más reciente”
• Entonces surge una pregunta fundamental: ¿sería mejor entrenar solo al modelo en lugar de formar a un ingeniero junior?

• Ese sería un panorama muy sombrío.

El experimento de no usar IA y la conclusión

• Propone de manera directa un experimento: “dejen de usar IA por un tiempo”
• Él mismo, al reiniciar recientemente su computadora, canceló su suscripción a Claude Pro
• Hacer unas cuantas búsquedas y leer Stack Overflow y la documentación oficial le permitió llegar a conclusiones mucho más confiables
• Llegó a pensar que su propio juicio era superior en precisión y confiabilidad a los resultados que entregan los LLM.

El valor económico de las herramientas de IA generativa y sus límites esenciales

• Plantea la pregunta: “¿la IA realmente sirve?”
• Objetivamente, la situación da pie a serias dudas sobre su valor
• El proceso típico de una startup de IA sería el siguiente:
  • Se aplica “IA” a un campo ya existente, y aparece una startup con el argumento de la eficiencia
  • La startup de IA logra atraer inversión de capital de riesgo
  • Paga tarifas de uso a empresas proveedoras de IA (como OpenAI)
  • La propia startup de IA no logra generar ganancias
• Viéndolo solo desde ese proceso, no parece tan distinto del ecosistema tradicional de VC, pero la diferencia clave es que ni siquiera los proveedores del servicio (como OpenAI) siguen generando ganancias todavía
• La tecnología en sí es intrínsecamente ineficiente, con una estructura poco favorable para escalar masivamente
• El consumo excesivo de electricidad y los efectos ambientales también son un problema serio

Cierre: la necesidad de reconocer la realidad

• Uno puede desear que la ley de Moore resurja, o esperar que todos se hagan ricos antes de que el universo se enfríe
• Pero si miramos la realidad de frente, el negocio de la IA generativa es una especie de fantasía, un fenómeno de “el emperador está desnudo”

[ahwjdekf]

La preocupación de que, después de una guerra mundial con bombas nucleares, la humanidad vuelva a una era primitiva sigue muy vigente hoy en el campo del desarrollo de software, que está en la vanguardia de la tecnología.

[dicebattle]

Parece que bastaría con frenar un poco el vibe coding excesivo. Para asistentes y para escribir algunos algoritmos simples pero detallados, da la impresión de que hay pocas cosas tan buenas como esta.

[GN⁺]

Comentarios de Hacker News

• Se enfatiza que introducir IA en una organización no es solo un problema técnico, sino de gestión del cambio. Solo se pueden ver efectos reales cuando un equipo competente, basado en la confianza y la transparencia, crea procesos que combinan de forma equilibrada la experiencia humana y las fortalezas de los LLM. Ya están surgiendo casos de equipos pequeños que logran grandes resultados con IA. Sin embargo, en la mayoría de las organizaciones, especialmente en las grandes empresas, no existe una cultura organizacional sana, así que la IA termina amplificando esa toxicidad. Entre los ejecutivos hay quienes malinterpretan los "Story Point" como si fueran simplemente una unidad de tiempo y ven la IA solo como una herramienta para reducir todo a la mitad. En el fondo, están desconectados del proceso mismo de crear software mantenible y perciben la IA como una vía improvisada para aumentar ganancias. Un estudio reciente, según el cual el 95% de los proyectos piloto de IA no logró alcanzar ROI, también se presenta como un ejemplo de la incompetencia de la dirección moderna

  • Tal vez la IA simplemente está sobrevalorada. Expresa curiosidad sobre a qué equipos concretos se refieren cuando se habla de "equipos pequeños logrando grandes resultados con IA"
  • Transmite cansancio ante la actitud de exonerar a la IA diciendo simplemente que "solo son problemas que ya existían". Considera que el deterioro de la salud mental o los problemas de cultura organizacional causados por la IA también son responsabilidad de la herramienta en sí. A diferencia de la idea de que las herramientas y los sistemas no tienen responsabilidad, piensa que en la práctica sí influyen
  • Le parece decepcionante que se hable de "equipos pequeños haciendo grandes cosas" solo con historias de éxito, sin casos concretos
  • Considera que introducir IA en una organización gerencial que ya está hecha un desastre es como poner rifles automáticos en manos de una banda de vikingos. Solo acelera el momento en que la organización se derrumba. Recalca que la tecnología no es el núcleo del problema, sino el fracaso social y ético de la mayoría de los integrantes, o de una minoría de gerentes clave
  • Menciona que hay muchos directivos que entienden mal los "Story Point" como tiempo, y dice que ha visto ese error en todos los roles con los que se ha topado hasta ahora: desarrollo, QA, PM y ejecutivos

• Se habla de la aparición de los "Prompstitudes" (empleados que dependen solo de prompts). Cuenta que una vez un colega solo le lanzó una respuesta de ChatGPT que había inferido su opinión, y sintió algo parecido a esa "sensación de invasión" mencionada en el artículo. Más que incompetentes, le parecen personas demasiado dependientes de los LLM, como ancianos en un casino que solo siguen jalando la palanca de una tragamonedas

• Comparte una experiencia reciente en la que se sintió incómodo al hablar con un colega porque era evidente que le estaba devolviendo resultados de ChatGPT. Piensa que habría sido mejor que simplemente lo ignoraran. El problema empeoraba porque el LLM afirmaba con mucha seguridad cosas equivocadas. Detalles pequeños, como diferencias mínimas en nombres entre configuración e implementación, pueden confundir por completo a un LLM. A diferencia de un humano, un LLM no aprende ni toma conciencia de sus errores, así que puede seguir arrastrándose en la dirección equivocada. Incluso siente que emocionalmente es más llevadero lidiar con mal código humano

  • Antes trabajó con un PM que escribía PRD con IA. Cuando le preguntaban por el contenido respondía: "No lo sé, lo escribió la IA". Al final, el PM renunció a transmitir ideas reales y se quedó solo con la actuación de producir documentos. Toda la comprensión e interpretación de requisitos terminó recayendo sobre él, así que dejó el equipo
  • Muestra acuerdo con la parte de que "el LLM se equivoca con mucha confianza". Igual que ciertos colegas carismáticos que aparentan saber, los LLM a menudo dicen cosas erróneas de forma convincente
  • Cuenta una experiencia muy extraña de esta semana. Le pidió a Claude que revisara una propuesta interna sobre una especificación técnica que él mismo no dominaba del todo, y Claude marcó muchos errores. Luego se lo pasó a la persona responsable de esa especificación dentro de la empresa advirtiendo que "esto lo sugirió un LLM, así que puede ser una tontería", pero esa persona también metió su mensaje en un LLM, obtuvo una respuesta y se la devolvió para preguntarle. Al final sintió que todos se habían convertido en asistentes de la IA. Si ese es el futuro del desarrollo de software, no le entusiasma
  • Considera que el mal código humano es mucho mejor que el mal código de LLM. Al menos en el código humano se puede inferir el contexto de lo que se intentaba hacer. En cambio, el código generado por LLM puede estar roto de principio a fin, e incluso inventar funciones o conceptos que ni existen. Los humanos normalmente no escriben código tan desligado de la realidad. Para entender código de LLM, a veces parece que hubiera que volver a aprender toda la codebase
  • Sobre la expresión de que el LLM "cree que no comete errores", señala que un LLM ni cree, ni piensa, ni siente. Solo encadena tokens de lenguaje estadísticamente plausibles y añade un poco de aleatoriedad para imitar creatividad

• Frente a la pregunta de si "¿las herramientas de IA realmente sirven?", dice que a él le ayudan porque las usa de forma distinta a la mayoría. Programa desde 1983 y ahora está retirado, así que suele trabajar solo. Ha probado varias herramientas, pero hoy usa solo ChatGPT y Perplexity. No les pide que escriban el código directamente; usa el código que sugieren como referencia o punto de partida. A veces reutiliza bloques completos, pero la mayor parte del tiempo los modifica o reescribe. Cuando un LLM empieza a producir resultados cada vez peores, simplemente corta y prueba otro enfoque. Dice que le da escalofríos imaginar a un ingeniero junior limitándose a copiar código de LLM. Para él, el mayor valor es como un "StackOverflow que responde al instante". Puede hacer cualquier pregunta tonta sin pena y obtener una respuesta aceptable rápido. Recientemente aprendió a implementar PassKey en iOS usando código de ejemplo de ChatGPT como punto de partida, estudiándolo línea por línea. El código con el que empezó y el resultado final que tiene ahora son completamente distintos, y gracias al proceso su comprensión técnica se profundizó

  • Dice que usa la IA exactamente de la misma manera. Está casi terminando un proyecto personal sobre el que no sabía nada al empezar, y ahora ya entiende bien la codebase
  • También la usa de forma parecida en tareas pequeñas o proyectos personales. El LLM escribe primero un "código desechable", y al explorar sus límites puede entender mejor el dominio del problema. Al final, eso le permite implementar por su cuenta con más confianza

• Siente que los LLM son muy buenos para responder preguntas técnicas o proponer enfoques nuevos. Incluso un principiante puede preguntar libremente sin sentirse juzgado ni estrellarse contra una pared, como pasaría en Stack Overflow. Copilot destaca por su autocompletado, que acelera la escritura de código y completa comentarios de documentación o líneas de código. Estas pequeñas ayudas se pueden revisar fácilmente. Pero cuando se le encarga a un LLM código complejo de punta a punta, se genera caos y la experiencia termina siendo más de depuración que de productividad. Cree que si un principiante depende demasiado de los LLM, le será difícil desarrollar habilidades reales de ingeniería

• Personalmente, dice que usa Zed para programar como hobby porque la IA no actúa como si fuera demasiado lista. Puede invocar las funciones de IA de manera suave solo cuando las necesita, y el resto del tiempo simplemente programa él mismo. En el trabajo, la IA de VSCode le interrumpe demasiado. Hay dos problemas: primero, la interacción se rompe con mucha facilidad (hacer clic en popups, insertar por accidente autocompletados enormes); segundo, le corta el flujo. A veces el autocompletado con IA es útil, quizá en un tercio de los casos, pero el resto del tiempo le rompe el hilo de pensamiento y le dispersa la concentración porque tiene que revisar el resultado de la IA. En Zed no le pasa eso, y siente que recuperó el placer de programar. Al final, el problema no está tanto en la función de IA en sí, sino en cómo está implementada

  • Dice que también se identifica mucho con Zed. Solía jugar con JupyterLab o Kate, pero cambió después de usar Zed. En Zed, el IDE/editor es el centro, mientras que funciones adicionales como IA o kernels de Jupyter solo apoyan silenciosamente cuando se necesitan. Esas funciones extra no interfieren con la edición de texto o la programación en sí. Cree que el equipo de Zed encontró un muy buen equilibrio

• Siente que la IA es muy útil para crear prototipos de UX. En poco tiempo puede producir resultados clicables, iterar varias veces para orientar la dirección y después desechar ese código y desarrollar de nuevo. Ese enfoque ayuda a no desperdiciar demasiado tiempo desde temprano en una dirección equivocada. Aun así, piensa que todavía falta bastante para que la IA construya por completo una app significativa

  • Recibe mucha ayuda de la IA en áreas que no suele tocar, por ejemplo scripts de PowerShell. Cuenta que una vez necesitó un script para reportar configuraciones del registro y Claude se lo hizo perfectamente, ahorrándole una hora
  • También siente algo similar: la IA es excelente explicando errores. Le ayuda mucho para encontrar soluciones correctas o pensar en ideas nuevas
  • Señala que es importante eso de "desechar el prototipo y desarrollar de nuevo", pero en la realidad los PM suelen olvidar esa parte y el prototipo termina entrando a producción. Aun así, si alguien encontró una forma de usarlo bien, eso le parece positivo
  • Pregunta si podría contar con más detalle sobre ese caso de uso, el proceso y las herramientas, porque cree que podría ayudar de manera práctica a él y a su equipo

• Considera que la IA para él es solo una herramienta más. No se considera un desarrollador de alto nivel, pero la usa en proyectos personales pidiéndole ideas y feedback cuando se atora. Lo importante, dice, es no delegarle la escritura del código a la IA, salvo boilerplate muy simple. Disfruta escribir el código él mismo por la satisfacción de resolver problemas, crear y aprender

  • Dice que su proyecto reciente no habría podido terminarlo si la IA no le hubiera escrito código directamente. Desde el setup completo del repositorio hasta el PoC, aunque fuera tosco, se volvió posible. Sin experiencia en Django, JS ni desarrollo web, gracias a la IA pudo obtener al inicio algo funcional aunque imperfecto, y poco a poco lo ha ido mejorando mientras aumenta su entendimiento

• Cuenta una anécdota incómoda de una revisión de código reciente. Vio una función compleja llamada "prepareData" que mezclaba y filtraba arreglos multidimensionales, y cuando le preguntó al compañero "¿qué hace esto?", este le respondió que mejor se lo preguntara al LLM para ahorrar tiempo. Le decepcionó esa actitud de no responder ni siquiera la pregunta más básica para hacer una revisión de código

  • Propone en tono algo humorístico que uno podría preguntarle al LLM, devolverle la respuesta al compañero y, tras 20 rondas de feedback, si él no entiende, entonces decirle que también se lo pregunte al LLM

• Expresa preocupación por que dentro de 10 años los desarrolladores junior quieran volverse seniors sin haber pasado por la experiencia de escribir código directamente

  • En realidad, dice, ese fenómeno empezó antes de la IA. Ya era difícil entrar si no se tenían más de 10 años de experiencia, y la industria ha fracasado en el upskilling de las generaciones jóvenes. Incluso cuando una empresa intenta formar juniors de manera constante, en cada crisis despide primero a los juniors y luego vuelve a contratar seniors con urgencia, repitiendo el mismo ciclo
  • Menciona en broma que ahora ya puedes ser senior con solo 3 años, y que en vez de 10 años, en 3 ya casi llegas a staff engineer
  • Señala que el concepto de "vibe coding" apareció hace unos 9 meses, y que en menos de 2 años probablemente la gente dejará de escribir o mantener código directamente
  • Aun así, cree que siempre existirá software escrito por desarrolladores con verdadera experiencia, y mientras el código de LLM no sea perfecto, seguirá habiendo demanda por código de alta calidad
  • Considera que hay demasiados desarrolladores junior y no suficientes problemas valiosos donde puedan ganar experiencia real, por lo que les cuesta pasar al siguiente nivel. Antes al menos se les podían encargar PoC o scripts baratos, pero ahora que la IA puede cubrir razonablemente ese tipo de tareas, las oportunidades se reducen. Añade que incluso antes ya había muchos juniors y pocos puestos

[happyiminjay]

En las primeras etapas del desarrollo, para configurar entornos y desarrollar módulos en unidades pequeñas de function, la IA es muy efectiva, pero fuera de eso, el vibe coding de meterle código y prompts a golpes es un desastre desde la perspectiva del mantenimiento. Puede que las primeras veces funcione, pero al final, cada vez que surge un problema, hay que intentar N veces hasta que la IA resuelva su propio problema, y persiste el miedo de no saber qué otros bugs podría provocar esa solución.

[ulsoft]

Dependiendo de la capacidad del desarrollador
si alguien con bases sólidas lo usa, puede aprovechar la IA para lograr desarrollo de alta calidad
si no tiene bases, el barco termina yéndose por otro rumbo
es como la diferencia entre un cocinero con fundamentos y uno sin ellos