Resumen Ejecutivo Pasé cuatro semanas a tiempo parcial (probablemente 80 horas en total) construyendo un marco de UI reactivo completo con más de 40 componentes, un router y soportando un sitio web interactivo utilizando sólo el código generado por LLM, es evidente. . LLMs can produce quality code—but like human developers, they need the right guidance Los principales hallazgos On Code Quality: Las tareas bien especificadas generan código de primer paso limpio Poorly specified or unique requirements produce sloppy implementations El código se degrada con el tiempo sin refactoring deliberado LLMs defensivamente sobre-ingeniería cuando se le pide para mejorar la fiabilidad On The Development Process: Es difícil ser “bien especificado” cuando una tarea es grande El razonamiento extendido ("pensamiento") produce mejores resultados, aunque a veces conduce a una lógica circular o demasiado expansiva. Varias perspectivas de LLM (modelos de intercambio) proporcionan valiosa revisión arquitectónica y asistencia para la depuración El uso estructurado del marco, por ejemplo, Bau.js o Lightview, evita la inclinación mejor que el desarrollo sin restricciones Las métricas formales identifican objetivamente y guían la eliminación de la complejidad del código Bottom line: En muchos sentidos, los LLMs se comportan como la media de los humanos que los entrenaron: cometen errores similares, pero mucho más rápidos y a mayor escala. El desafío Hace cuatro semanas, me decidí a responder a una pregunta que ha sido fuertemente debatida en la comunidad de desarrollo: ¿Pueden los LLM generar código sustancial y de calidad de producción? No es una aplicación de juguete.No es una simple aplicación CRUD.Un marco de interfaz de usuario reactivo completo y moderno con muchos componentes pre-construidos, un router y un sitio web compatible con: Decenas de miles de líneas de JavaScript, CSS y HTML Memoria, rendimiento y consideraciones de seguridad Experiencia profesional y desarrollador Decidí construir ( )—un marco de interfaz de usuario reactivo que combina las mejores características de Bau.js, HTMX y Juris.js. La restricción: 100% de código generado por LLM utilizando Claude de Anthropic (Opus 4.5, Sonnet 4.5) y Gemini 3 Pro de Google (Flash no fue lanzado cuando empecé). Lightview Página web.dev Comenzando con preguntas, no con código Comencé con Claude Opus: "Quiero crear una biblioteca de UI reactiva que combine HTMX, Bau y Juris. Para los hipermedios, prefiero no tener nombres de atributos especiales —sólo comportamiento mejorado. También quiero el procesamiento literal de cuerdas en HTML, un router SPA, una biblioteca de componentes de UI con creación automática de elementos personalizados, aplicaciones capacitadas para SEO sin trabajo adicional y un sitio web para promover y educar a los usuarios. "Quiero crear una biblioteca de UI reactiva que combine HTMX, Bau y Juris. Para los hipermedios, prefiero no tener nombres de atributos especiales —sólo comportamiento mejorado. También quiero el procesamiento literal de cuerdas en HTML, un router SPA, una biblioteca de componentes de UI con creación automática de elementos personalizados, aplicaciones capacitadas para SEO sin trabajo adicional y un sitio web para promover y educar a los usuarios. Claude no se sumergía inicialmente en el código. : dozens of clarifying questions ¿TypeScript o vanilla JavaScript? ¿Qué biblioteca de componentes de UI para el estilo? (Se proporcionó opciones con pros/cons) Which HTMX features specifically? ¿Preferencias de alojamiento? ¿Estrategia de Ruta? However, at times it started to write code before I thought it should be ready and I had to abort a response and redirect it. Descubrimiento: Los LLM tienen un fuerte vicio hacia la generación de código prematuro. Incluso cuando se les recuerda no codificar todavía, se olvidan después de unas pocas interacciones. Esto sucede con todos los modelos —Claude, Gemini, GPT. Parecen especialmente desencadenados para iniciar el proceso de generación cuando se da el código de ejemplo, incluso cuando se proporcionan ejemplos junto a preguntas en lugar de como solicitudes de implementación. Descubrimiento: Los LLM tienen un fuerte vicio hacia la generación de código prematuro. Incluso cuando se les recuerda no codificar todavía, se olvidan después de unas pocas interacciones. Esto sucede con todos los modelos —Claude, Gemini, GPT. Parecen especialmente desencadenados para iniciar el proceso de generación cuando se da el código de ejemplo, incluso cuando se proporcionan ejemplos junto a preguntas en lugar de como solicitudes de implementación. Guía: Si un LLM comienza a generar código antes de que esté listo, cancelar la finalización inmediatamente y redirigir: "No generar código todavía. ¿Tienes más preguntas?" Puede que necesite repetir esto varias veces como el LLM "olvida" y se desplaza hacia la generación de código. El cambio de modo Planificación vs. Modo rápido en Antigravidad o modos similares en otros IDE debería ayudar con esto, pero es incómodo usarlo repetidamente. Una mejor solución sería: si el usuario hace una pregunta, el LLM debería asumir que quieren discusión, no código. Sólo generar/modificar código cuando se le solicite explícitamente o después de pedir permiso. Si un LLM comienza a generar código antes de que esté listo, cancelar la finalización inmediatamente y redirigir: "No generar código todavía. ¿Tienes más preguntas?" Puede que tenga que repetir esto varias veces como el LLM "olvida" y se desliza hacia la generación de código. : si el usuario hace una pregunta, el LLM debe asumir que quieren la discusión, no el código. Guidance: A better solution would be Después de una hora de retroceso, Claude finalmente dijo: "No hay más preguntas. ¿Quieres que genere un plan de implementación ya que habrá muchos pasos?" El plan resultante fue completo - un archivo de Markdown detallado con cajas de verificación, decisiones de diseño y consideraciones para: Librería Reactiva Más de 40 componentes Routing system Un sitio web ... aunque el sitio web recibió menos atención - una brecha que abordaría más tarde No hice cambios sustanciales en este plan excepto para aclarar los elementos del sitio web y la adición de una característica importante, el evento declarativo en el final del desarrollo. The Build Begins Sin problema, cambié a Gemini 3 (Alto), que tenía el contexto completo de la conversación más el archivo de plan. En pocos minutos, Gemini generó el motor de reactividad del núcleo, junto con dos archivos de ejemplo: una demostración de "Hello, World!" que muestra tanto la sintaxis Bau-like como la sintaxis vDOM-like. lightview.js Entonces cometí un error. "Build the website as an SPA," I said, without specifying to use Lightview itself. I left for lunch. Cuando volví, había un hermoso sitio web en mi navegador. miré el código y mi corazón se hundió: . React with Tailwind CSS React + Tailwind is an extremely common pattern for SPAs. Without explicit guidance to use Lightview—the very framework I'd just built—the LLM defaulted to what it had seen most often in training data. Finding: LLMs will use the most common/popular solution if you don't specify otherwise. React + Tailwind es un patrón extremadamente común para los SPAs. Sin una orientación explícita para usar Lightview -el marco mismo que acabo de construir- el LLM estaba por defecto en lo que había visto con más frecuencia en los datos de entrenamiento. Finding: LLMs will use the most common/popular solution if you don't specify otherwise. Peor aún, cuando le pedí que lo reconstruyera con Lightview, me olvidé de decir "eliminar el sitio existente primero". Orientación: Al pedir a un LLM que realice el trabajo, sea explícito sobre el enfoque: Eliminar el sitio existente y reconstruirlo desde cero con Lightview vs Modify the existing site to use Lightview Al pedir a un LLM que realice el trabajo, sea explícito sobre el enfoque: Guidance: Eliminar el sitio existente y reconstruirlo desde cero con Lightview vs Modify the existing site to use Lightview El primero es a menudo más eficiente para los grandes cambios. El segundo es mejor para las correcciones dirigidas. El LLM no elegirá automáticamente el camino eficiente - usted necesita dirigirlo. La sorpresa del viento Después de que Claude generó el sitio web utilizando componentes de Lightview, noté que todavía estaba lleno de clases de CSS de Tailwind. "Well," Claude effectively explained, "you chose DaisyUI for the UI components, and DaisyUI requires Tailwind as a dependency. I assumed you were okay with Tailwind being used throughout the site." Prefiero las clases semánticas de CSS y quería que el sitio utilizara los enfoques CSS clásicos. Descubrimiento: Los LLM hacen inferencias razonables pero a veces no deseadas. Cuando especifica una tecnología que tiene dependencias, los LLM extenderán esa elección a partes relacionadas del proyecto. When you specify one technology that has dependencies, LLMs will extend that choice to related parts of the project. They're being logical, but they can't read your mind about preferences. Finding: LLMs make reasonable but sometimes unwanted inferences. Be explicit about what you don't want, not just what you do want. e.g. "I want DaisyUI components, but only use Tailwind for them not elsewhere." If you have strong preferences about architectural approaches, state them upfront. Guidance: Sea explícito sobre lo que no desea, no sólo lo que desea. por ejemplo: "Quiero componentes DaisyUI, pero solo usar Tailwind para ellos no en otro lugar." Guidance: I asked Claude to rewrite the site using classic CSS and semantic classes. I liked the design and did not want to delete the files, so once again I suffered through a refactor that consumed a lot of tokens since it touched so many files. I once again ran out of tokens and tired GPT-OSS bit hit syntax errors and had to switch to another IDE to keep working. When one LLM struggles with your codebase, switch back to one that was previously successful. Different models have different "understanding" of your project context. And, if you are using Antigravity when you run out of tokens, you can switch to MS Visual Code in the same directory and use a light GitHub Copilot account with Claude. Antigravity is based on Visual Code, so it works in a very similar manner. Guidance: When one LLM struggles with your codebase, switch back to one that was previously successful. Different models have different "understanding" of your project context. And, if you are using Antigravity when you run out of tokens, you can switch to MS Visual Code in the same directory and use a light GitHub Copilot account with Claude. Antigravity is based on Visual Code, so it works in a very similar manner. Guidance: La danza iterativa Over the next few weeks, I worked to build out the website and test/iterate on components, I worked across multiple LLMs as token limits reset. Claude, Gemini, back to Claude. Each brought different strengths and weaknesses: excelled at architectural questions and generated clean website code with Lightview components Claude Gemini Pro trató constantemente de usar herramientas locales y scripts de ayuda de cuchillo para apoyar su propio trabajo, valioso para la velocidad y la eficiencia de los tokens. Sin embargo, a veces falló con resultados catastróficos, muchos archivos se eliminaron o se corrompieron sin opción sino para volver atrás. Las perspectivas cambiantes se han demostrado poderosas: "Usted es un LLM diferente. ¿Cuáles son sus pensamientos?" a menudo produjo insights revolucionarios o correcciones rápidas a los errores en los que se ha girado un LLM. Encontré que el verdadero ganador era Gemini Flash. Hizo un trabajo increíble de refactorizar el código sin introducir errores de sintaxis y necesitaba una orientación mínima sobre qué código colocar dónde. A veces era escéptico de un cambio y lo diría. A veces, Flash estaría de acuerdo y ajustado y otras veces haría una justificación racional de su elección. The Router Evolution El router también necesitaba trabajo. Claude inicialmente implementó un router basado en hash ( , de Esto es perfectamente adecuado para un SPA: es simple, fiable y no requiere de configuración de servidor. #/about #/docs Pero tenía requisitos adicionales que no había indicado claramente: quería caminos convencionales ( , Los motores de búsqueda pueden manejar rutas hash ahora, pero el enrutamiento basado en la ruta sigue siendo más limpio para la indexación y el compartir. /about /docs Hash-based routing is easier to implement and works without server-side configuration. Since I did not say I wanted path-based routing, the LLM will choose the simpler approach. Finding: LLMs will sometimes default to the simplest valid solution. Hash-based routing is easier to implement and works without server-side configuration. Since I did not say I wanted path-based routing, the LLM will choose the simpler approach. Finding: LLMs will sometimes default to the simplest valid solution. Cuando le dije a Claude que necesitaba vías convencionales para SEO y enlaces profundos, reescribió muy rápidamente el router y vino con lo que considero una solución inteligente: un enfoque híbrido que hace que las páginas de SPA sean tanto profundamente enlazables como SEO-indexables sin la complejidad del renderizado del lado del servidor. Sin embargo, dejó algo del código original en su lugar que tipo de oculto lo que estaba sucediendo y era totalmente innecesario. Tuve que decirle que elimine este código que soportaba los vestigios de las rutas basadas en hash. Esta retención de código es el tipo de cosa que puede conducir a la caída. Supongo que muchas personas culparían al LLM, pero si hubiera estado claro para comenzar y también dije “reescribir completamente mi”, es que los vestigios no Guía: Para patrones arquitectónicos, sea explícito acerca de sus requisitos temprano. No suponga que el LLM sabe que desea el enfoque más complejo pero SEO-friendly. especifique: "Necesito enrutamiento basado en la ruta con la API de historia para SEO" en lugar de simplemente "Necesito enrutamiento". Para los patrones arquitectónicos, sea explícito acerca de sus requisitos temprano. No suponga que el LLM sabe que desea el enfoque más complejo pero SEO-friendly. especifique: "Necesito enrutamiento basado en la ruta con la API de historia para SEO" en lugar de simplemente "Necesito enrutamiento". Guidance: Guidance: I also found that LLMs defensively try to ensure compatibility with previous versions, this can lead to overly complex code. If you are writing from scratch you need to remind them that backward compatibility is not required. Guía: También encontré que los LLM intentan de forma defensiva asegurar la compatibilidad con versiones anteriores, lo que puede conducir a un código demasiado complejo. Comparando los números The Final Tally Project Size: 60 archivos JavaScript, 78 archivos HTML, 5 archivos CSS 41,405 líneas totales de código (incluyendo comentarios y espacios vacíos) Más de 40 componentes de UI personalizados 70+ website files At this point, files seemed reasonable - not overly complex. But intuition and my biased feelings about code after more than 40 years of software development isn't enough. I decided to run formal metrics on the core files. Core Libraries: File Lines Minified Size lightview.js 603 7.75K lightview-x.js 1,251 20.2K lightview-router.js 182 3K Enlace a LightView.js 603 775K lightview-x.js 1,251 20.2 K Instalación de Router.js 182 3K The website scored well on para el rendimiento sin tener una optimización super enfocada. component gallery Lighthouse Luego vinieron las métricas de complejidad. The Slop Revealed I asked Gemini Flash to evaluate the code using three formal metrics: Una métrica combinada donde 0 es insostenible y 100 es código perfectamente documentado / limpio. 1. Maintainability Index (MI): Halstead Volume (measure of code size and complexity) Complejidad ciclónica Lines of code Como la densidad Scores above 65 are considered healthy for library code. This metric gives you a single number to track code health over time. Una métrica más antigua pero aún valiosa que mide el número de caminos linealmente independientes a través del código. 2. Cyclomatic Complexity: Más bugs potenciales Harder to test thoroughly (the metric can actually tell you how many you might need to write) Más carga cognitiva para comprender Una métrica moderna que mide el esfuerzo mental que un ser humano necesita para comprender el código. A diferencia de la complejidad ciclomática (que trata todos los flujos de control igualmente), la complejidad cognitiva penaliza: 3. Cognitive Complexity: Condiciones y pendientes en nido (nido más profundo = sanción más alta) Boolean operator chains Recursion Breaks in linear flow The thresholds: 0-15: Código limpio - fácil de entender y mantener 16-25: Alta fricción - refactoring sugerido para reducir la deuda técnica 26+: Crítico - Atención inmediata necesaria, pesadilla de mantenimiento Gemini Flash initially searched for an existing metrics library, couldn't find one, then (en el ) using the Acorn JavaScript parser—without asking permission. This is both impressive and occasionally problematic. I cover the problem with this case later. Finding: LLMs excel at creating analysis tools. wrote its own complete analyzer metrics-analysis.js Gemini Flash initially searched for an existing metrics library, couldn't find one, then (en el ) using the Acorn JavaScript parser—without asking permission. This is both impressive and occasionally problematic. I cover the problem with this case later. Finding: LLMs excel at creating analysis tools. wrote its own complete analyzer metrics-analysis.js The Verdict Overall health looked good: File Functions Avg Maintainability Avg Cognitive Status lightview.js 58 65.5 3.3 ⚖️ Good lightview-x.js 93 66.5 3.6 ⚖️ Good lightview-router.js 27 68.6 2.1 ⚖️ Good lightview.js 58 65.5 3.3 ⚖️ Good lightview-x.js 93 66.5 3.6 ️ Buen lightview-router.js 27 68.6 2.1 ️ Buen But drilling into individual functions told a different story. Two functions hit "Critical" status: (lightview-x.js): handleSrcAttribute Cognitive Complexity: 🛑 35 Cyclomatic Complexity: 🛑 22 Maintainability Index: 33.9 (Lightview-x.js en la actualidad) Anonymous Template Processing Cognitive Complexity: 🛑 31 Complejidad ciclónica: 13 This was slop. Technical debt waiting to become maintenance nightmares. Can AI Fix Its Own Slop? El código fue generado por Claude Opus, Claude Sonnet y Gemini 3 Pro varias semanas antes. clean it up? Gemini 3 Flash I asked Flash to refactor para abordar su complejidad. Esto parecía tomar un poco más de tiempo de lo necesario. Así que aborté y pasé algún tiempo revisando su proceso de pensamiento. Había lugares obvios en los que fue rastreado o incluso fue en círculos, pero le dije que continuara. Después de que terminara, inspeccioné manualmente el código y probé minuciosamente todas las áreas del sitio web que usan esta característica. No se encontraron errores. handleSrcAttribute Gemini Flash "thinks" extensively. While reviewing all its thought processes would be tedious, important insights flash by in the IDE. When an LLM seems stuck in a loop, aborts and review historical thoughts for possible sidetracks and tell to continue or redirect as needed. Critical Discovery #2: Gemini Flash "thinks" extensively. While reviewing all its thought processes would be tedious, important insights flash by in the IDE. When an LLM seems stuck in a loop, aborts and review historical thoughts for possible sidetracks and tell to continue or redirect as needed. Critical Discovery #2: Después de la fijación de , I asked for revised statistics to see the improvement. handleSrcAttribute Flash's Disappearing Act Unfortunately, Gemini Flash had deleted its El archivo tuvo que recrear todo el analizador. metrics-analysis.js Descubrimiento: Gemini Flash elimina agresivamente los archivos temporales. Después de que Flash utilice un script o una herramienta de análisis que crea, a menudo elimina el archivo suponiendo que es temporal. Después de que Flash utilice un script o una herramienta de análisis que crea, a menudo elimina el archivo suponiendo que es temporal. Finding: Gemini Flash aggressively deletes temporary files. Tell Gemini to put utility scripts in a specific directory (like or ) and explicitly ask it to keep them. You can say: "Create this in /home/claude/tools/ and keep it for future use." Otherwise, you'll find yourself regenerating the same utilities multiple times. Guidance: /home/claude/tools/ /home/claude/scripts/ Dile a Gemini que coloque los scripts de utilidad en un directorio específico (como or Puedes decir: "Crear esto en /home/claude/tools/ y guardarlo para uso futuro". Guidance: /home/claude/tools/ /home/claude/scripts/ El problema de las dependencias Dev When I told Gemini to keep the metrics scripts permanently, another issue surfaced: it failed to officially install dev dependencies like (en el parser de JavaScript) acorn Flash simplemente supuso eso porque encontró paquetes en Se puede usar de forma segura.La única razón Estaba disponible porque ya había instalado un analizador de Markdown que dependía de él. node_modules acorn They'll use whatever's available in without verifying it's officially declared in . This creates fragile builds that break on fresh installs. Finding: LLMs don't always manage dependencies properly. node_modules package.json They'll use whatever's available in without verifying it's officially declared in . This creates fragile builds that break on fresh installs. Finding: LLMs don't always manage dependencies properly. node_modules package.json Guía: Después de que un LLM crea scripts de utilidad que utilizan paquetes externos, pregunte explícitamente: "¿Has añadido todas las dependencias necesarias a package.json? por favor verifique e instale cualquiera de las que faltan." Guía: Después de que un LLM crea scripts de utilidad que utilizan paquetes externos, pregunte explícitamente: "¿Has añadido todas las dependencias necesarias a package.json? por favor verifique e instale cualquiera de las que faltan." The Refactoring Results With the analyzer recreated, Flash showed how it had decomposed the monolithic function into focused helpers: Contenido (cognitivo: 5) ParseElementos (cognitivo: 5) (cognitive: 7) updateTargetContent (cognitive: 2) elementsFromSelector manualSrcAttribute orquestrator (cognitivo: 10) The Results Metric Before After Improvement Cognitive Complexity 35 🛑 10 ✅ -71% Cyclomatic Complexity 22 7 -68% Status Critical Slop Clean Code — Cognitive Complexity 35 🛑 10 -71% Complejidad ciclónica 22 7 -68% Status Critical Slop Código limpio — La inspección manual y las pruebas minuciosas del sitio web revelaron cero errores. el costo? un aumento de 0.5K en el tamaño del archivo - insignificante. Emboldened, I tackled the template processing logic. Since it spanned multiple functions, this required more extensive refactoring: Extracted Functions: - iteration logic collectNodesFromMutations - scanning logic processAddedNode transformTextNode - Interpolación de plantillas para texto - attribute interpolation and recursion transformElementNode Results: Function Group Previous Max New Max Status MutationObserver Logic 31 🛑 6 ✅ Clean domToElements Logic 12 ⚠️ 6 ✅ Clean MutationObserver Logic 31 6 ✅ limpio Lógica doméstica 12 ⚠️ 6 ✅ Clean Metrología de la Biblioteca Final Después de refactoring, lightview-x.js mejoró significativamente: 93 → 103 (better decomposition) Functions: 66.5 → 66.8 Avg Maintainability: 3.6 → Avg Cognitive: 3.2 All critical slop eliminated. The increased function count reflects healthier modularity - complex logic delegated to specialized, low-complexity helpers. In fact, it is as good or better than established frameworks from a metrics perspective: File Functions Maintainability (min/avg/max) Cognitive (min/avg/max) Status lightview.js 58 7.2 / 65.5 / 92.9 0 / 3.4 / 25 ⚖️ Good lightview-x.js 103 0.0 / 66.8 / 93.5 0 / 3.2 / 23 ⚖️ Good lightview-router.js 27 24.8 / 68.6 / 93.5 0 / 2.1 / 19 ⚖️ Good react.development.js 109 0.0 / 65.2 / 91.5 0 / 2.2 / 33 ⚖️ Good bau.js 79 11.2 / 71.3 / 92.9 0 / 1.5 / 20 ⚖️ Good htmx.js 335 0.0 / 65.3 / 92.9 0 / 3.4 / 116 ⚖️ Good juris.js 360 21.2 / 70.1 / 96.5 0 / 2.6 / 51 ⚖️ Good lightview.js 58 7.2 / 65.5 / 92.9 0 / 3.4 / 25 ️ Buen lightview-x.js 103 0.0 / 66.8 / 93.5 0 / 3.2 / 23 ⚖️ Good lightview-router.js 27 24.8 / 68.6 / 93.5 0 / 2.1 / 19 ️ Buen react.development.js 109 0.0 / 65.2 / 91.5 0 / 2.2 / 33 ⚖️ Good bau.js 79 11.2 / 71.3 / 92.9 0 / 1.5 / 20 ⚖️ Good htmx.js 335 0.0 / 65.3 / 92.9 0 / 3.4 / 116 ⚖️ Good juris.js 360 21.2 / 70.1 / 96.5 0 / 2.6 / 51 ️ Buen 1. LLMs Mirror Human Behavior—For Better and Worse Los LLM exhiben las mismas tendencias que los desarrolladores promedio: Rush a código sin comprensión completa No admita la derrota ni pida ayuda lo suficientemente pronto Generar soluciones defensivas, sobre-ingenieras cuando se les solicite para mejorar la fiabilidad Produce cleaner code with structure and frameworks La diferencia es que lo hacen . They can generate mountains of slop in hours that would take humans weeks. faster and at greater volume 2. Thinking Helps El razonamiento extendido (visible en los modos de "pensamiento") muestra alternativas, auto-correcciones y momentos ocasionales de "oh pero". El pensamiento suele ser fructífero, a veces caótico. No simplemente dejes o hagas otra cosa cuando las tareas que crees que son complejas o críticas se están llevando a cabo. Los LLM rara vez dicen "Me dejo" o "Por favor, déme orientación" - me gustaría que lo hicieran más a menudo. Mira el flujo de pensamiento y abortar la solicitud de respuesta si es necesario. Lea el pensamiento y redirigir o simplemente decir que continúe, aprenderás mucho. 3. Multiple Perspectives Are Powerful Cuando le dije a un segundo LLM, "Usted es un LLM diferente revisando este código. When faced with an implementation that's critiqued as too abstract, insufficiently abstract, or inefficient, leading LLMs (Claude, Gemini, GPT) won't argue. They'll do a rapid, thorough analysis and return with honest pros/cons of current versus alternative approaches. Finding: LLMs are remarkably non-defensive. When faced with an implementation that's critiqued as too abstract, insufficiently abstract, or inefficient, leading LLMs (Claude, Gemini, GPT) won't argue. They'll do a rapid, thorough analysis and return with honest pros/cons of current versus alternative approaches. Finding: LLMs are remarkably non-defensive. This behavior is actually : beyond what most humans provide How many human developers give rapid, detailed feedback without any defensive behavior? How many companies have experienced architects available for questioning by any developer at any time? How many code review conversations happen without ego getting involved? Orientación: Antes o después de hacer cambios, cambiar los LLM deliberadamente: Make progress with one LLM (e.g., Claude builds a feature) Switch to another (e.g., Gemini) and say: "You are a different LLM reviewing this implementation. What are your thoughts on the architecture, potential issues, and alternative approaches?" Then switch back to the first and ask what it thinks now! This is especially valuable before committing to major architectural decisions or after implementing complex algorithms. The second opinion costs just a few tokens but can save hours of refactoring later. Before OR after making changes, switch LLMs deliberately: Guidance: Make progress with one LLM (e.g., Claude builds a feature) Switch to another (e.g., Gemini) and say: "You are a different LLM reviewing this implementation. What are your thoughts on the architecture, potential issues, and alternative approaches?" Then switch back to the first and ask what it thinks now! This is especially valuable before committing to major architectural decisions or after implementing complex algorithms. The second opinion costs just a few tokens but can save hours of refactoring later. La estructura previene el deslizamiento Telling an LLM to use "vanilla JavaScript " without constraints invites slop. Vanilla JavaScript is a wonderful but inherently loose language through which a sometimes sloppy or inconsistent browser API is exposed. Without constraints, it's easy to create unmaintainable code—for both humans and LLMs. Specifying a framework (Bau.js, React, Vue, Svelte, etc.) provides guardrails that lead to cleaner, more maintainable code. Finding: Decir a un LLM que use "vanilla JavaScript" sin restricciones invita a la inclinación. Vanilla JavaScript es un lenguaje maravilloso pero inherentemente suave a través del cual se expone una API de navegador a veces desagradable o inconsistente. Sin restricciones, es fácil crear código insostenible - tanto para humanos como para LLMs. Especificar un marco (Bau.js, React, Vue, Svelte, etc.) proporciona rastros que conducen a un código más limpio y más mantenible. Finding: When starting a project, based on what you want to accomplish ask for advice on: Guidance: El marco/biblioteca a utilizar (React, Vue, Svelte, etc.) The architectural pattern (MVC, MVVM, component-based, etc.) Code organization preferences (feature-based vs. layer-based folders) Nombres de convenciones Whether to use TypeScript or JSDoc for type safety Otras bibliotecas para usar... no impiden la reinvención. No digas: "Build me a web app in JavaScript" No digas: "Build me a React application using functional components, hooks, TypeScript, and feature-based folder organization. The more structure you provide upfront, the less slop you'll get. This applies to all languages, not just JavaScript. When starting a project, based on what you want to accomplish ask for advice on: Guidance: El marco/biblioteca a utilizar (React, Vue, Svelte, etc.) The architectural pattern (MVC, MVVM, component-based, etc.) Code organization preferences (feature-based vs. layer-based folders) Nombres de convenciones ¿Usar TypeScript o JSDoc para la seguridad de tipo? Otras bibliotecas para usar... no impiden la reinvención. No digas: "Build me a web app in JavaScript" No digas: "Build me a React application using functional components, hooks, TypeScript, and feature-based folder organization. The more structure you provide upfront, the less slop you'll get. This applies to all languages, not just JavaScript. Las métricas proporcionan una verdad objetiva I love that formal software metrics can guide LLM development. They're often considered too dull, mechanical, difficult or costly to obtain for human development, but in an LLM-enhanced IDE with an LLM that can write code to do formal source analysis (no need for an IDE plugin subscription), they should get far more attention than they do. They're perfect for: Finding: Formal software metrics can guide development objectively. Identifying technical debt automatically Tracking code health over time Guiding refactoring priorities Validating that "improvements" actually improve things They're perfect for: Finding: Formal software metrics can guide development objectively. Identifying technical debt automatically Tracking code health over time Guía de prioridades de refactorización Validar que las “mejoras” realmente mejoran las cosas Las métricas no mienten.Identificaron la pendiente que mi intuición había perdido. Orientación: Integre las métricas en su flujo de trabajo LLM: Run complexity metrics on all files. Identify functions with cognitive complexity > 15 or cyclomatic complexity > 10. After initial implementation: Address Critical (cognitive > 26) functions first, then "High Friction" (16-25) functions. Prioritize refactoring: Don't just say ‘improve this’. Say ‘Refactor handleSrcAttribute to reduce cognitive complexity to target range’. Request targeted refactoring: After refactoring, re-run metrics. Ensure complexity actually decreased and maintainability increased. Sometimes ‘improvements’ just shuffle complexity around. Verify improvements: Establecimiento de puertas de calidad: Antes de marcar el código como hecho, trate de tener todas las funciones con una complejidad cognitiva < 15 e índice de mantenimiento > 65. Integrate metrics into your LLM workflow: Guidance: Run complexity metrics on all files. Identify functions with cognitive complexity > 15 or cyclomatic complexity > 10. After initial implementation: Address Critical (cognitive > 26) functions first, then "High Friction" (16-25) functions. Prioritize refactoring: Solicite refactoring dirigido: No digas simplemente “mejore esto”.Diga “Refactor handleSrcAttribute para reducir la complejidad cognitiva al rango objetivo”. After refactoring, re-run metrics. Ensure complexity actually decreased and maintainability increased. Sometimes ‘improvements’ just shuffle complexity around. Verify improvements: Establecimiento de puertas de calidad: Antes de marcar el código como hecho, trate de tener todas las funciones con una complejidad cognitiva < 15 e índice de mantenimiento > 65. La sentencia Después de 40.000 líneas de código generado por LLM, soy prudentemente optimista. But like human developers, they need: Yes, LLMs can generate quality code. Especificaciones claras y detalladas Condiciones estructurales (marcos, patrones) Guía de refactorización regular Objective quality measurements Multiple perspectives on architectural decisions The criticism that LLMs generate slop isn't wrong—but it's incomplete. They generate slop for the same reasons humans do: . unclear requirements, insufficient structure, and lack of quality enforcement The difference is iteration speed. What might take a human team months to build and refactor, LLMs can accomplish in hours. The cleanup work remains, but the initial generation accelerates dramatically. Looking Forward I'm skeptical that most humans will tolerate the time required to be clear and specific with LLMs - just as they don't today when product managers or developers push for detailed requirements from business staff. The desire to "vibe code" and iterate will persist. Pero aquí está lo que ha cambiado: El ciclo de retroalimentación se ha comprimido de semanas a horas. We can now iterate and clean up faster when requirements evolve or prove insufficient. A medida que los entornos de codificación evolucionen para envolver los LLM en una mejor estructura - métricas automatizadas, patrones aplicados, revisiones de modelos múltiples - la calidad mejorará. La verdadera pregunta no es si los LLM pueden generar código de calidad. es si podemos proporcionarles - y nosotros mismos - con la disciplina para hacerlo de manera consistente. Y, tengo una última preocupación ... si los LLM se basan en la historia y tienden a adherirse a lo que saben, ¿cómo vamos a evolucionar la definición y el uso de cosas como las bibliotecas de interfaz de usuario? ¿Estamos siempre atrapados con React a menos que pidan algo diferente? O, ¿son las bibliotecas un anacronismo? ¿Los LLM y los modelos de imagen o vídeo pronto generarán la imagen requerida de una interfaz de usuario sin código subyacente? Dada su entrada tardía en el juego y los LLM de anclaje ya tienen, no tengo grandes esperanzas para la adopción de Lightview, pero fue un experimento interesante. https://lightview.dev
