Limpiando el desastre que dejan los desarrolladores rockstar de IA
(codingwithjesse.com)- El problema histórico de los codebases difíciles de entender que dejaron los “desarrolladores rockstar” se está convirtiendo, con la expansión del código generado por LLM, en una carga de mantenimiento para todo el equipo
- Los desarrolladores rockstar adoptaban rápidamente nuevas tecnologías, nuevos paradigmas y nuevas arquitecturas, y resolvían rápido los problemas difíciles, pero mostraban poco interés en escribir código que otras personas pudieran entender y con el que pudieran colaborar
- Los agentes LLM pueden producir decenas de miles de líneas de código en poco tiempo sin recordar el trabajo previo, y no se preocupan por si encaja con el sistema completo ni por si mejora la comprensibilidad
- Cuanto más aumenta el código generado, más crece la complejidad del sistema, y puede surgir una dinámica en la que se vuelva a depender de LLM para entenderlo
- Para construir software duradero, hace falta limitar el uso de LLM a la generación de pequeños fragmentos de código, dejar que las personas guíen el diseño y simplificar la arquitectura según la complejidad real del problema
La estructura que dejó el desarrollador rockstar
- Después de unirse al equipo, el desarrollador rockstar proponía ideas firmes sobre nuevas tecnologías, nuevos paradigmas y nuevas arquitecturas
- Reescribía gran parte de la arquitectura central de la empresa e introducía nuevos procesos de build, herramientas y lenguajes
- Rechazaba muchos pull requests y elevaba el estándar exigido al equipo, mientras los demás no podían mostrar si realmente entendían ese código
- Las tareas más difíciles se asignaban al desarrollador rockstar, y él las terminaba más rápido que los demás
- El resto del equipo avanzaba más lento mientras aprendía nuevas librerías y trataba de adaptarse a la forma de trabajar del desarrollador rockstar
- Años después, el desarrollador rockstar dejaba el equipo en busca de proyectos más grandes y difíciles en otra empresa
Lidiar con las secuelas
- El equipo que se quedaba heredaba los proyectos del desarrollador rockstar y terminaba enfrentándose a un código abrumador
- El flujo de datos era difícil de seguir, hasta el punto de sentirse como si alguien estuviera intentando encubrir un asesinato
- Empezaban por corregir bugs simples, pero solo lograr ejecutar el código en una laptop llevaba una semana
- La mitad del código estaba escrita en un lenguaje que no entendían, y la otra mitad usaba librerías de las que nunca habían oído hablar
- Le decían a su jefe que hacía falta reescribir el código, pero la idea era rechazada solo porque ese código lo había escrito el desarrollador rockstar
- Mientras se perdían en ese código caótico, se imaginaban irse mirando ofertas de empleo
Limpiar lo que dejó el rockstar
- Muchos equipos y agencias necesitan ordenar codebases dejados por este tipo de desarrolladores rockstar
- El proceso de entender y rescatar un codebase complejo se compara con desenredar una serie de luces enredadas para poder volver a usarla
- A los desarrolladores rockstar les gusta programar, aprender y usar nuevos paradigmas, y llevan sus capacidades al límite
- Intentan escribir el código más ingenioso posible y se concentran en moverse lo más rápido que puedan
- Escribir código con el que otras personas puedan colaborar termina siendo la prioridad más baja para ellos
La llegada de la inteligencia artificial
- En los últimos años, muchos equipos se han visto sobrepasados por una legión de desarrolladores rockstar
- Cada vez que alguien inicia un chat nuevo, aparece el riesgo de sumar otro desarrollador rockstar al equipo
- Los agentes no recuerdan lo que hicieron ayer y generan decenas de miles de líneas de código en cuestión de minutos
- Los agentes persiguen terminar tareas a una velocidad humanamente imposible
- No les importa si el código generado encaja con el resto del sistema ni si el sistema se vuelve más fácil de entender
- La IA viene con una caja de herramientas de buenas prácticas que puede no encajar con el contexto
- Incluso cuando la complejidad supera los beneficios, la IA insiste en medidas de seguridad excesivas, del tipo “belt and suspenders”
- Cuando se le pide una code review, produce una larga lista de mejoras con muchos puntos difíciles de aceptar
- Cada vez más personas sienten que, si no usan LLM, se quedarán atrás para siempre
- Pero dejar que los LLM escriban todo el código termina, en realidad, produciendo ese mismo rezago
Limpiar detrás de cientos de rockstars de IA
- Ordenar montones de código generado y caótico no es tan disfrutable como limpiar el código de un solo desarrollador rockstar
- Al menos un desarrollador rockstar tenía alguna intención de diseño y estaba tratando de hacer su mejor esfuerzo
- Un montón de código desordenado creado con vibe coding no fue escrito por un solo desarrollador artificial
- Se convierte en un codebase generado función por función o corrección de bug por corrección de bug, a través de múltiples chats y múltiples contextos
- Eso se parece a un codebase escrito por cientos de desarrolladores rockstar diferentes
- En algunos casos, la deuda técnica llega a ser tan grande que se vuelve imposible de pagar
Crear software que perdure
- Hay varias formas de usar LLM sin dejar que se comporten como desarrolladores rockstar
- Las personas pueden liderar la ingeniería y guiar a los LLM para que generen solo pequeños fragmentos de código cada vez
- Hay que asegurarse de que el software se escriba de una forma que cualquier miembro del equipo pueda entender y sobre la que pueda trabajar fácilmente
- Si el LLM se perdió sin entender qué está haciendo ni por qué, hay que bajar la velocidad
- Está bien avanzar más despacio para garantizar la calidad del software que se está generando
- Está bien seguir simplificando para evitar el overengineering hasta que la arquitectura coincida con la complejidad real del problema
- A veces está bien dejar el LLM guardado en la caja de herramientas y escribir el código directamente
- La artesanía siempre permanece en manos humanas; es un terreno que no se puede tercerizar a las máquinas
2 comentarios
Opiniones en Hacker News
La última frase, esa de que la artesanía siempre permanece en manos humanas y nunca puede subcontratarse a las máquinas, me preocupa un poco
En otras industrias la artesanía no ha muerto, pero sí ha sido desplazada por alternativas mucho más baratas y fáciles de conseguir. Todavía puedes comprar zapatos de cuero hechos a mano, pero poca gente quiere pagar más de $1000, y también puedes comprar una pintura hecha durante semanas, pero la mayoría compra decoración de pared y artículos varios en HomeGoods
La diferencia clave es la suposición de que es desechable, y por desgracia el software también se está volviendo cada vez más “desechable”, como otros productos. Si es una app simple de cuenta regresiva, da igual tirarla, pero el software que sostiene procesos de trabajo de larga duración no debería tratarse así
Si te enfocas en la artesanía del software, el problema puede parecer “lo que necesito para mi caso de uso” frente a “algo boutique, caro e innecesario”. En realidad debería ser “algo mantenible y confiable” frente a “algo que se puede tirar”
Independientemente de si esta tendencia beneficia a grandes proveedores de modelos como OpenAI o Anthropic, ese no es realmente el punto que quiero plantear aquí
Incluso un escritorio barato que llegó en una caja plana y que yo armé con un destornillador fue producido en masa en una fábrica, pero su diseño pudo haber incorporado mucha más artesanía experta que una pieza hecha a medida. La estructura ahí es invertir mucho al inicio en diseño y luego producir en masa con bajo costo marginal
El software, en su mayor parte, siempre ha estado en esa situación desde el comienzo. Cuando descargas Firefox, no hay un artesano haciendo un navegador web solo para ti; un servidor CDN en algún centro de datos simplemente te copia bytes desde caché
Lo que la IA amenaza es reemplazar una artesanía de inversión inicial de un tipo que no ha ocurrido a gran escala en otras industrias. Lo que la IA ha reemplazado con más éxito es software “artesanal” de bajo costo, un ámbito que hasta ahora prácticamente no existía porque nunca había sido económicamente viable
Por eso hay una palanca mucho mayor para invertir en calidad
También me cuesta estar de acuerdo con que el software sea desechable en ese mismo sentido. Si es para un problema temporal, puedes tirar el código y hacer otro cuando surja otro problema. Pero si es para un problema persistente, el código sigue ahí
Los tornillos alguna vez fueron objetos valiosos hechos a medida, y fabricar un solo buen tornillo requería una enorme cantidad de tiempo y esfuerzo. Incluso lo que hoy llamamos un tornillo mecánico solo podía fabricarlo una persona muy hábil con trabajo extremadamente intensivo
Pero las máquinas pueden transferir la artesanía. Si haces un tornillo realmente bueno, la máquina transfiere la calidad de ese tornillo a una gran cantidad de tornillos nuevos
En la actualidad, tornillos de todo tipo y calidad se han vuelto casi igualmente consumibles, y los tornillos que antes habrían requerido días o semanas de tallado manual hoy se producen por miles de millones
Veo a la IA como un torno sin husillo guía. Al principio hay que hacer los tornillos a mano, y después puedes transferir toda la calidad que seas capaz de producir a nuevos tornillos. Si logras hacer tornillos mejores, los pones en el torno y produces más tornillos mejores. Pero en el fondo sigues limitado por la calidad de los tornillos que puedes hacer tú mismo. Si solo puedes hacer una porquería chueca y llena de bultos, eso es lo único que saldrá de la máquina
Los desarrolladores de software crean propiedad intelectual única; no manufacturan unidades de software. Se parecen más a autores de libros o músicos
En software no existe un equivalente a la manufactura por unidad. Solo se copian y trasladan bits
Por lo tanto, en el contexto del software, “artesanía” significa cuánto cuidado pones en diseñar algo bueno. No va a desaparecer a menos que lleguemos al punto en que deje de importar la calidad del software que usamos, y no hay señales de que vayamos en esa dirección ahora mismo
Una comparación más adecuada podría ser la de los ingenieros que crean y mantienen el equipo de fabricación en una fábrica de zapatos. Están un nivel alejados del consumidor, pero claramente también hay artesanía ahí
Me gusta arreglar código hecho por IA o por outsourcing. La semana pasada me enteré de que un cliente había intentado crear una herramienta para su departamento con vibe coding, y el resultado fue una enorme basura de Next.js que necesitaba 10 GB de memoria solo para compilar, tenía miles de errores de lint y hasta logs de desarrollo ruidosos metidos en Git
Ahora nos toca arreglarlo, así que este tipo de cosas son básicamente trabajo gratis repetible de 10 mil a 50 mil euros. Si sabes lo que haces, es facilísimo; si no, es imposible. Que sigan trayendo más
Trabajo en respuesta a incidentes para pymes, y en los últimos años el trabajo ha crecido hasta un punto difícil de manejar, mientras mi cuenta bancaria se siente como el tesoro de un dragón
Siempre he creído que la seguridad debe integrarse y planearse desde el principio, y no quiero decir en absoluto que me alegre ver incidentes de seguridad
Pero el hecho de que personas con experiencia dudosa ahora puedan sacar apps en una hora ha sido una ganancia inesperada enorme para gente como yo
Esta forma de pensar consiste en ver a las personas como máquinas tragamonedas humanas en las que se puede seguir metiendo dinero
Me pregunto si los clientes llegan desde el principio buscando ayuda para llevarlo a producción, o si eres más bien el último recurso después de que el enfoque con IA fracasa por completo
También me pregunto si estos proyectos suelen colapsar de una forma típica, o si el fracaso suele ser más sutil
En la vida he conocido a unas cuantas personas que de verdad podrían llamarse brillantes. De esas que te hacen pensar: “¿Cómo demonios puede ser tan inteligente?”
Hay dos rasgos que se ven en la gente realmente inteligente, y por lo general son mutuamente excluyentes. Uno es no darse cuenta de lo inteligente que uno es. Para esa persona es sencillo, o es un tema que conoce, así que asume que cualquiera con un título en ciencias de la computación lo sabe, lo recuerda y lo entiende. He visto amigos hablar de corrido sobre matemáticas de criptografía y he pensado: “Aprobé esa clase, pero no diría que de verdad conozco el tema que acabas de mencionar”
El otro es la gente que es dolorosamente consciente, todo el tiempo, de que es más inteligente que la mayoría a su alrededor. Algunos se portan mal, y otros están cansados de estar rodeados de gente relativamente “tonta”. Con estos últimos puedo empatizar hasta cierto punto. Solo imagina vivir una vida en la que todo es claro, obvio y fácil de resolver, y aun así tener que ver a la humanidad repetir decisiones estúpidas una y otra vez aunque la respuesta se conoce desde hace mucho tiempo
Me vuelve loco ver a la gente dando vueltas sin rumbo, o haciendo X aunque sea obvio que hacerlo va a producir el mal resultado -Y. La mayoría simplemente ha aprendido a no decirlo en voz alta
En relaciones familiares cercanas esto es especialmente poco saludable. Lo veo tanto que siento que podría matar a alguien a punta de regaños
Pero ninguna de ellas era un desarrollador 10x que levantó un desastre gigantesco para que el equipo y yo tuviéramos que limpiarlo durante meses
Por más que uno lo intente, es difícil relacionarse con la mayoría de la gente, y a ellos les cuesta especialmente entenderme. La diferencia en experiencias vividas es enorme y a menudo difícil de superar
No todos pueden producir lo mismo, pero cualquiera puede volverse inteligente a su manera si decide seguir pensando más allá del promedio cultural
La mayoría ni siquiera se da cuenta de que puede hacerlo
Estas dos frases me llegaron
“Era tan difícil seguir el flujo de datos que parecía que alguien estaba tratando de encubrir un asesinato”
“Solo me tomó una semana lograr que el código corriera en la laptop”
Siempre pensé que yo era la única persona a la que le costaba entender el flujo de datos o levantar un entorno de desarrollo decente. El síndrome del impostor y, a veces, un ambiente tóxico que empuja la “velocidad” tampoco ayudaban
Me alegró saber que no era la única
Claude Code en la CLI ha hecho mucho más fácil que antes levantar apps y depurar problemas aleatorios de dependencias o de Docker. Antes tenía que aprender la arquitectura al mismo tiempo que resolvía por qué algo no funcionaba en mi máquina
Con código de IA es todavía peor. Porque en ese momento solo generaron algo que parecía plausible
Envidio un poco a la gente que tiene que limpiar lo que otros dejaron. Al menos se siente como resolver un rompecabezas
Mi trabajo actual es realmente aburrido. Son tareas tan simples que hasta un junior podría hacerlas, pero aun así dicen que necesitan a un desarrollador mid-level. No estoy diciendo que yo sea demasiado bueno para este trabajo, ni que la gente mid-level no haga este tipo de cosas. Solo que no logro obligarme a interesarme por el código que hace esta empresa. Es viejo, polvoso, y ni siquiera lo usa nadie importante. Los clientes compraron esta herramienta alguna vez y la siguen usando solo porque es tan poco interesante que ni siquiera les importa lo suficiente como para cambiarla
Me prometieron que pronto llegaría algo más alineado con mi experiencia, pero no parece que a una empresa tan estancada le vayan a llegar clientes así
No me sorprende que esta empresa esté perdiendo clientes y empleados. Pero tengo que pagar la hipoteca. Hoy me dijeron que quizá no extiendan mi contrato y, en la práctica, sonó a una amenaza para que asuma más responsabilidad y más trabajo por el mismo sueldo
Por desgracia, tengo que aguantar hasta encontrar un puesto nuevo que de verdad sea interesante. Ni siquiera necesito tanto dinero ni me importa en absoluto eso del “crecimiento”. Solo necesito lo suficiente para sobrevivir
Puede que este comentario no tenga mucho que ver, perdón. No tengo otro lugar donde desahogarme
Era L63, pero el trabajo que hacía era de un nivel que también podrían haber hecho personas L60~L61, y muchas veces sentía que estaba en uno de esos Bullshit Jobs de los que hablaba David Graeber. La compensación era generosa, pero cuando se acabaron las acciones del bono de entrada, vi que me estaba quedando en ese empleo solo por estabilidad
Me sentía como uno de esos ingenieros tomando el sol en la terraza de la oficina de Hooli mientras esperan a que sus acciones hagan vesting. Tenía 9 años de carrera y no me parecía que eso fuera lo mejor para mi trayectoria en ese momento
Eso sí, yo no tenía grandes obligaciones financieras, así que fue una decisión mucho más fácil
Productos basura hechos por empresas basura sobreviven parasitando la flojera y la falta de gusto de la mayoría, y los marketers monetizan eso
Ahora, para empeorarlo, todo el campo se está LLMizando y eso lo multiplica por 100. Vuelve el código imposible de mantener y, peor todavía, nos vuelve más tontos a todos
De verdad desearía que nunca hubiéramos descubierto esto
Me pregunto si te refieres simplemente a trabajar más horas y hacer tareas inútiles, si realmente hay más oportunidades de programar, o si de pronto esperan que demuestres que vales más
No es por minimizar lo que te pasó. Si es esto último, me pregunto si realmente podrías hacer algo con eso
Las primeras secciones sí me llegaron. Antes creo que yo era un desarrollador rockstar, pero me di cuenta de que eso no era algo bueno
Puede que pudiera terminar el trabajo 10 veces más rápido que mis colegas. Pero en algún momento entendí que no era porque yo fuera 10 veces más productivo que una persona normal, sino porque mi forma de trabajar hacía que la gente normal a mi alrededor fuera 1/10 de productiva
Después de eso bajé el ritmo, y fue un cambio positivo para mi vida en general. Convertirme en alguien que juega en equipo no me dio el mismo nivel de movilidad ascendente en esta industria de locos, pero fue sorprendentemente bueno para mi salud mental
En mi caso, por lo general era sobreabstraer cosas que no hacían falta, o construir algo para casos de uso que en realidad nunca ocurrían. Así que cada vez que siento que mi pensamiento se va demasiado hacia la abstracción excesiva, trato de acordarme de YAGNI y KISS
Este artículo tiene muy poco valor
Ni siquiera queda claro qué quiere decir, y solo parece una publicación para darse palmaditas en la espalda
Gran parte de lo que se llama la enorme cantidad de mal código dejada por un “desarrollador rockstar” en realidad fue el resultado de una complejidad que se fue acumulando poco a poco, durante mucho tiempo, a medida que cambiaban los requisitos
Además, muchas veces la gente cree que “está refactorizando por legibilidad”, cuando en realidad lo que pasa es que “reescribe el código y en el proceso llega a entenderlo”
Esperaba más contenido o ejemplos reales. El 90% del texto se va en que el autor se queje y defina el problema, y en el penúltimo párrafo aparece una solución vaga, como hecha a manotazos. Casi no tiene relevancia ni utilidad real
De verdad fue una estupidez haber presionado fuerte a dos ingenieros de producción para construir la infraestructura alrededor de los dos proyectos rentables que hice
Habría ganado mucho más dinero si simplemente hubiera hecho todo como un jefe 10x, con código espagueti, y luego me hubiera ido a Anthropic por un paquete de compensación de 9 cifras. Qué tonto fui, doblemente tonto
Al menos esa es la conclusión que yo saqué de esto
El código que se escribe normalmente tiene que ser mantenido por alguien que no es quien lo escribió. Así que, si escribes código que nadie entiende, eso termina en un fracaso de mantenimiento
Puede variar qué optimizas: código fácil de entender para el equipo, velocidad, excelencia técnica, etc.
Pero incluso si optimizas por excelencia técnica, si nadie más del equipo puede entender ese código, igual es un fracaso
He visto código sobreingenierizado
Opiniones en Lobste.rs
Este artículo no tiene muchos consejos realmente útiles
La expresión “desarrollador rockstar” siempre me ha parecido sospechosa, pero los desarrolladores sobresalientes sí existen. Solo que esa gente no actúa como se describe en el artículo: trabajan dentro del entorno existente tanto como pueden, mejoran la base de código, no meten cosas nuevas sin validar como si fueran juguetes, y al irse dejan todo en un estado más estable mediante pruebas, despliegues automatizados con scripts, linting, etc.
Aquí parece que IA fue agregada como si este comportamiento fuera a empeorar por su culpa; podría pasar, pero todavía no me parece algo suficientemente demostrado. Llevo décadas trabajando como consultor y he limpiado muchas bases de código desastrosas; a veces la causa eran personas que se pasaban de lanza, pero con más frecuencia eran equipos que simplemente no conocían una mejor forma de hacerlo. En ningún caso pensé “seguro esto lo hizo un desarrollador rockstar/ninja/de moda”
Ahora no solo hay que limpiar la basura que el chatbot dejó caer sobre tu cabeza, sino también arreglar lo que dejan detrás las personas a las que ni les importa
Solo dan ganas de esperar a que reviente la burbuja
Si en 2026 entras a una empresa y descubres que todavía usan create-react-app, me pregunto cuál sería en realidad la conducta recomendada. ¿Se supone que simplemente no digas nada?
Si es un proyecto viejo, encontraste deuda técnica. Todo el mundo la tiene. La mejor manera de convencer a otros de arreglarla es construir una justificación que tenga sentido para el negocio. Si funciona, ¿de verdad es un riesgo? Comparada con otra deuda técnica, ¿qué prioridad tiene? ¿Qué riesgos implícitos se están asumiendo por no actualizar? ¿Cuánto esfuerzo requiere la actualización?
Si el esfuerzo es bajo y tus colegas también quieren hacerlo, otra opción es simplemente hacerlo sin pedir permiso. Pero eso funciona mejor cuando tienes el apoyo de las personas afectadas por el cambio y cuando no interfiere con tus entregables. Puede que no sea algo para hacer en tu primera semana en la empresa
Por lo general, casi siempre es mejor preguntar e investigar por qué las cosas son así ahora, en vez de decir cómo “deberían ser”. Toda base de código con historia es el resultado de miles de decisiones que todavía no conoces. Hay que armarse de conocimiento y empatía
Yo ya lo odiaba desde 2020, cuando todavía parecía cool
Eso de que “los agentes no recuerdan nada de lo que hicieron ayer” es un problema solucionable. Se pueden usar enfoques de memoria y demás. No es algo universalmente bueno, pero va mejorando
Lo de que “no les importa si este código encaja bien con el resto del sistema” no coincide con mi experiencia. Normalmente, el código generado por LLM tiende a parecerse bastante al código similar del área relacionada. El código que leyó para orientarse suele reflejarse casi tal cual
Lo de que “no les importa si el sistema se vuelve más fácil de entender o peor” también puede resolverse. Puedes hacer que un LLM lo evalúe e ir reduciendo eso gradualmente. Qué hace que algo sea fácil de entender suele ser una propiedad no determinista del sistema, así que paradójicamente un LLM podría ser una forma más sencilla de medirlo que otras herramientas. En una sesión nueva, puedes preguntar “¿cuánta parte del sistema hay que entender para comprender este código recién agregado?” y optimizar para reducir ese alcance
La parte de que “la IA trae una caja de herramientas de buenas prácticas que quizá no encaja aquí” muchas veces se parece a entrenar a un desarrollador junior que llega a un proyecto nuevo con esos mismos ideales. A un junior se le explica verbalmente y se espera que recuerde y aplique ese conocimiento, pero con la IA puedes documentarlo en archivos AGENTS.md / CLAUDE.md y ese conocimiento sigue ahí
Lo de que “si le pides una revisión de código, te devuelve un montón de mejoras con las que no estás de acuerdo” en el caso de Codex está ajustado para mantener la lista pequeña, concisa y de alto valor. Otros modelos pueden ser distintos, pero al final eso también es un tema de instrucciones. Las cosas que te importan muchas veces vale la pena documentarlas, y usar IA hace que eso se vuelva necesario
Cuando lidias con rockstars, la mitad del problema es el ego, pero al menos un rockstar que dejaba código escrito por una persona tenía detrás reflexión e intención
En cambio, los “rockstars” que son poco más que un cascarón humano encima de la IA tienen la misma fanfarronería, o más, pero a veces ni siquiera entienden por completo la mitad de los problemas que dicen estar resolviendo
Si aplicas lo más posible un enfoque de programación funcional y construyes componentes independientes del contexto que puedan ensamblarse de distintas maneras, obtienes bastante palanca
Si separas bloques de construcción individuales que abstraen detalles de implementación de las tareas que dependen de un contexto específico, puedes reacomodar fácilmente esos bloques cuando cambian los requisitos o decides tomar otro enfoque. Además, puedes razonar sobre cada pieza de forma independiente sin conocer el contexto completo del ensamblado, y al ver cómo encajan esas piezas puedes entender la lógica de más alto nivel
Los lenguajes funcionales ofrecen una buena base para trabajar con LLM. Porque te llevan de forma natural a escribir código de un modo que limita el contexto. Eso reduce el alcance necesario para entender una funcionalidad específica del programa, lo cual ayuda tanto al modelo como a los usuarios humanos