Kan LLMs kwaliteitskode genereer? 'N 40,000-lyn eksperiment

Uitvoerende samestelling Ek het vier weke gedeeltelik (waarskynlik 80 uur in totaal) bestee aan die bou van 'n volledige reaktiewe UI-raamwerk met meer as 40 komponente, 'n router en die ondersteuning van interaktiewe webwerf met slegs LLM-genereerde kode, dit is duidelik . LLMs can produce quality code—but like human developers, they need the right guidance Belangrike bevindings On Code Quality: Goed spesifiseerde take lewer skoon eerste-pass kode Slegs spesifiseer of unieke vereistes veroorsaak slop implementasies Kode verval na verloop van tyd sonder doelbewuste refaktoring LLMs verdedigend oor-ingenieurswese wanneer gevra word om betroubaarheid te verbeter On The Development Process: Dit is moeilik om "goed spesifiseer" te wees wanneer 'n taak groot is Uitgebreide redenasie ("denken") produseer beter resultate, alhoewel soms lei tot sirkulêre of te uitgestrekte logika Verskeie LLM perspektiewe (sweeping modelle) bied waardevolle argitekturiese oorsig en debug hulp Struktureerde raamwerk gebruik, byvoorbeeld Bau.js of Lightview, voorkom slap beter as onbeperkte ontwikkeling Formele metrikes identifiseer objektief en lei die verwydering van kode kompleksiteit Bottom line: In baie opsigte gedra LLMs soos die gemiddelde van die mense wat hulle opgelei het - hulle maak soortgelyke foute, maar baie vinniger en op 'n groter skaal. Die uitdaging Vier weke gelede het ek besluit om 'n vraag te beantwoord wat in die ontwikkelingsgemeenskap heeltemal gedebatteer is: Kan LLMs wesenlike, produksie-gehalte kode genereer? Nie 'n speelgoedprogram nie. Nie 'n eenvoudige CRUD-program nie. 'N Volledige, moderne reaktiwiteit van die UI-raamwerk met baie voorgebou komponente, 'n router en 'n ondersteunende webwerf met: Tien duisende reëls van JavaScript, CSS en HTML Memory, performance, and security considerations Professionele UX en ontwikkelaar ervaring Ek het gekies om te bou ( die )—’n Reaktiewe UI raamwerk kombineer die beste funksies van Bau.js, HTMX, en Juris.js. Die beperking: 100% LLM-genereerde kode gebruik Anthropic se Claude (Opus 4.5, Sonnet 4.5) en Google se Gemini 3 Pro (Flash is nie vrygestel toe ek begin het nie). Lightview Kyk na.dev Begin met vrae, nie kode nie Ek het met Claude Opus begin: "Ek wil 'n reaktiewe UI-bibliotheek skep wat HTMX, Bau en Juris kombineer. Vir hypermedia, verkies ek geen spesiale attribuut name nie - net verbeterde gedrag. Ek wil ook string letterlike verwerking in HTML, 'n SPA-router, 'n UI-komponentbibliotheek met outomatiese aangepaste element skep, SEO-geaktiveerde programme sonder ekstra werk, en 'n webwerf om gebruikers te bevorder en te onderrig. "Ek wil 'n reaktiewe UI-bibliotheek skep wat HTMX, Bau en Juris kombineer. Vir hypermedia, verkies ek geen spesiale attribuut name nie - net verbeterde gedrag. Ek wil ook string letterlike verwerking in HTML, 'n SPA-router, 'n UI-komponentbibliotheek met outomatiese aangepaste element skep, SEO-geaktiveerde programme sonder ekstra werk, en 'n webwerf om gebruikers te bevorder en te onderrig. Claude het nie aanvanklik in die kode gedompel nie. : dozens of clarifying questions TypeScript of vanilla JavaScript? Watter UI-komponentbibliotheek vir styling? (Dit het opsies met voor- en nadele verskaf) Watter HTMX funksioneer spesifiek? Hosting preferences? Die roosterstrategie? 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. Even when reminded not to code yet, they forget after a few interactions. This happens with all models—Claude, Gemini, GPT. They seem especially triggered to start the generation process when given example code, even when examples are provided alongside questions rather than as implementation requests. Finding: LLMs have a strong bias toward premature code generation. Selfs wanneer hulle herinner word om nog nie te kodeer nie, vergeet hulle na 'n paar interaksies.Dit gebeur met alle modelle—Claude, Gemini, GPT. Hulle lyk veral aangemoedig om die generasieproses te begin wanneer voorbeeld kode gegee word, selfs wanneer voorbeelde langs vrae verskaf word eerder as as implementeringsaanvrae. Finding: LLMs have a strong bias toward premature code generation. Gids: As 'n LLM begin om kode te genereer voordat jy gereed is, annuleer die voltooiing onmiddellik en oorgedra: "Moenie kode nog genereer nie. Het jy meer vrae?" Jy moet hierdie herhaal baie keer as die LLM "vergeet" en draai terug na kode-generasie. Die Planning versus vinnige modus skiet in Antigravity of soortgelyke modes in ander IDE's moet help met hierdie, maar dit is ongemaklik om herhaaldelik te gebruik. 'N beter oplossing sou wees: as die gebruiker 'n vraag vra, moet die LLM aanvaar dat hulle wil bespreek, nie kode nie. If an LLM starts generating code before you're ready, cancel the completion immediately and redirect: "Don't generate code yet. Do you have more questions?" You may need to repeat this multiple times as the LLM "forgets" and drifts back toward code generation. The Planning vs Fast mode toggle in Antigravity or similar modes in other IDE’s should help with this, but it's inconvenient to use repeatedly. : as die gebruiker 'n vraag vra, moet die LLM aanvaar dat hulle bespreking wil hê, nie kode nie. Guidance: A better solution would be After an hour of back-and-forth, Claude finally said: "No more questions. Would you like me to generate an implementation plan since there will be many steps?" The resulting plan was comprehensive - a detailed Markdown file with checkboxes, design decisions, and considerations for: Kern Reaktiewe Biblioteek 40+ komponente van die UI Routing system 'N webwerf ... alhoewel die webwerf minder aandag gekry het - 'n gaping wat ek later sou hanteer Ek het geen materiële veranderinge aan hierdie plan gedoen nie, behalwe vir verduideliking op webwerf items en die toevoeging van een belangrike funksie, deklaratiewe gebeurtenis gating aan die einde van die ontwikkeling. The Build Begins With the plan in place, I hit my token limit on Opus. No problem—I switched to Gemini 3 (High), which had full context from the conversation plus the plan file. In 'n paar minute, Gemini geskep - die kern reaktiwiteit masjien - saam met twee voorbeeld lêers: 'n "Hello, World!" demo wat beide Bau-agtige sintaksie en vDOM-agtige sintaksie toon. lightview.js Then I made a mistake. "Bou die webwerf as 'n SPA," het ek gesê, sonder om te spesifiseer om Lightview self te gebruik. Toe ek teruggekeer het, was daar 'n pragtige webwerf wat in my blaaier hardloop. . React with Tailwind CSS Vind: LLMs sal die mees algemene / gewilde oplossing gebruik as jy nie anders spesifiseer nie. React + Tailwind is 'n uiters algemene patroon vir SPAs. Sonder uitdruklike riglyne om Lightview te gebruik - die raamwerk wat ek net gebou het - het die LLM standaard gesien wat dit die meeste keer in opleiding data gesien het. Vind: LLMs sal die mees algemene / gewilde oplossing gebruik as jy nie anders spesifiseer nie. React + Tailwind is 'n uiters algemene patroon vir SPAs. Sonder uitdruklike riglyne om Lightview te gebruik - die raamwerk wat ek net gebou het - het die LLM standaard gesien wat dit die meeste keer in opleiding data gesien het. Worse, toe ek gevra het om dit met Lightview te herbou, het ek vergeet om te sê "verwyder die bestaande webwerf eers." When asking an LLM to redo work, be explicit about the approach: Guidance: Delete the existing site and rebuild from scratch using Lightview vs Modify the existing site to use Lightview Wanneer jy 'n LLM vra om werk te herhaal, wees uitdruklik oor die benadering: Guidance: Delete the existing site and rebuild from scratch using Lightview vs Modify the existing site to use Lightview Die eerste is dikwels meer token-effektiewe vir groot veranderinge. Die tweede is beter vir gerichte regstellings. Die LLM sal nie outomaties die doeltreffende pad kies nie - jy moet dit rig. Die Tailwind verrassing Nadat Claude die webwerf met behulp van Lightview-komponente geskep het, het ek opgemerk dat dit nog vol Tailwind CSS-klasse was. "Wel," het Claude effektief verduidelik, "jy het DaisyUI vir die UI-komponente gekies, en DaisyUI vereis Tailwind as 'n afhanklikheid. Fair point—but I wasn't okay with it. I prefer semantic CSS classes and wanted the site to use classic CSS approaches. 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. Wanneer jy een tegnologie spesifiseer wat afhanklikhede het, sal LLMs daardie keuse uitbrei tot verwante dele van die projek. Finding: LLMs make reasonable but sometimes unwanted inferences. Gids: Wees uitdruklik oor wat jy nie wil hê nie, nie net wat jy wil hê nie. byvoorbeeld "Ek wil DaisyUI-komponente hê, maar gebruik net Tailwind vir hulle nie elders nie." 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: Ek het die ontwerp gehou en wou nie die lêers verwyder nie, so weer het ek deur 'n refaktor gely wat baie tokens verbruik het omdat dit soveel lêers aangeraak het. 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: Die iteratiewe dans 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: Claude het uitstekend gewerk in argitektuurvraagstukke en geskep skoon webwerf kode met Lightview komponente Gemini Pro het voortdurend probeer om plaaslike gereedskap en shell helper-skripte te gebruik om sy eie werk te ondersteun - waardevol vir spoed en token-doeltreffendheid. Switching perspektiewe het kragtig getoon: "Jy is 'n ander LLM. Wat is jou gedagtes?" het dikwels baanbrekende insigte of vinnige oplossings vir die foute wat een LLM het gedraai. Ek het gevind dat die ware winnaar Gemini Flash was. Dit het 'n wonderlike werk gedoen om kode te refaktoreer sonder om sintaksfoute in te voer en het minimale riglyne nodig gehad oor watter kode om te sit. Soms was ek skeptiek oor 'n verandering en sou dit sê. Soms sou Flash saamstem en aanpas en ander keer sou dit 'n rasionele regverdiging van sy keuse maak. En, praat oor vinnig ... wow! The Router Evolution Die router het ook werk nodig gehad. Claude het aanvanklik 'n hash-gebaseerde router ( die , etc.). This is entirely appropriate for an SPA—it's simple, reliable, and doesn't require server configuration. #/about #/docs But I had additional requirements I hadn't clearly stated: I wanted conventional paths ( , Soekmasjiene kan nou hashroutes hanteer, maar padgebaseerde routing is steeds skoonder vir indeksering en deel. /about /docs Vind: LLMs sal soms standaard na die eenvoudigste geldige oplossing. Hash-gebaseerde routing is makliker om te implementeer en werk sonder server-side konfigurasie. Aangesien ek nie gesê het ek wou pad-gebaseerde routing, sal die LLM die eenvoudiger benadering kies. Hash-gebaseerde routing is makliker om te implementeer en werk sonder server-side konfigurasie. Aangesien ek nie gesê het dat ek pad-gebaseerde routing wou hê nie, sal die LLM die eenvoudiger benadering kies. Finding: LLMs will sometimes default to the simplest valid solution. When I told Claude I needed conventional paths for SEO and deep linking, it very rapidly rewrote the router and came up with what I consider a clever solution—a hybrid approach that makes the SPA pages both deep-linkable and SEO-indexable without the complexity of server-side rendering. However, it did leave some of the original code in place which kind of obscured what was going on and was totally un-needed. I had to tell it to remove this code which supported the vestiges of hash-based routes. This code retention is the kind of thing that can lead to slop. I suppose many people would blame the LLM, but if I had been clear to start with and also said “completely re-write”, my guess is the vestiges would not have existed. Gids: Vir argitektuurpatrone, wees uitdruklik oor jou vereistes vroeg. Moenie aanvaar dat die LLM weet dat jy die meer komplekse maar SEO-vriendelike benadering wil hê nie. Spesifiseer: "Ek benodig padgebaseerde routing met Historie API vir SEO" eerder as net "Ek benodig routing." For architectural patterns, be explicit about your requirements early. Don't assume the LLM knows you want the more complex but SEO-friendly approach. Specify: "I need path-based routing with History API for SEO" rather than just "I need routing." Guidance: Gids: Ek het ook gevind dat LLMs defensief probeer om verenigbaarheid met vorige weergawes te verseker, dit kan lei tot te komplekse kode. Gids: Ek het ook gevind dat LLMs defensief probeer om verenigbaarheid met vorige weergawes te verseker, dit kan lei tot te komplekse kode. Vergelyk die getalle Die finale telling Project Size: 60 JavaScript lêers, 78 HTML lêers, 5 CSS lêers 41,405 totale reëls van kode (insluitend kommentaar en leegte) Meer as 40 persoonlike UI komponente 70+ webwerwe lêers 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 Inligting.js 603 775 K Instruksies vir lightview-x.js 1 van 251 20.2K lightview-router.js 182 3K Die webtuiste scored well on for performance without having had super focused optimization. Galery komponente Lighthouse Maar dan kom die kompleksiteit metrieke. The Slop Revealed Ek het Gemini Flash gevra om die kode te evalueer met behulp van drie formele metrikes: 'N Gekombineerde metrisis waar 0 is ononderhoudbaar en 100 is perfek gedokumenteer / skoon kode. 1. Maintainability Index (MI): Halstead Volume (meting van kode grootte en kompleksiteit) Cyclomatic Complexity Lines of code Hoe die densiteit Scores above 65 are considered healthy for library code. This metric gives you a single number to track code health over time. 'N ouer, maar nog steeds waardevolle metrisis wat die aantal lineair onafhanklike pads deur kode meet. 2. Cyclomatic Complexity: More potential bugs Moeilijker om grondig te toets (die metrieke kan jou eintlik vertel hoeveel jy dalk moet skryf) Meer kognitiewe las om te verstaan 'N Moderne metric wat die geestelike inspanning meet wat 'n mens nodig het om kode te verstaan. In teenstelling met ciklomatiese kompleksiteit (wat alle beheerstroom ewe behandel), straf kognitiewe kompleksiteit: 3. Cognitive Complexity: Gevestigde voorwaardes en boeke (dieper nesting = hoër straf) Booleaanse kettingbedryf Recursie Verwyder die lineêre vloei The thresholds: 0-15: skoon kode - maklik om te verstaan en te onderhou 16-25: Hoë friksie - refaktoring voorgestel om tegniese skuld te verminder 26+: Kritieke - onmiddellike aandag nodig, onderhoud nachtmerrie Vind: LLMs uitsteek in die skep van analitiese gereedskap. Gemini Flash het aanvanklik gesoek na 'n bestaande metriesbibliotheek, kon nie een vind nie, en het dan sy eie volledige analyser (metrics-analysis.js) geskryf met behulp van die Acorn JavaScript-parser - sonder om toestemming te vra. Gemini Flash het aanvanklik gesoek na 'n bestaande metriesbibliotheek, kon nie een vind nie, dan ( ) 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 Algehele gesondheid lyk goed: 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 Inligting.js 58 65.5 3.3 Die jaar goed Instruksies vir lightview-x.js 93 66.5 3.6 Die jaar goed lightview-router.js 27 68.6 2.1 Die jaar goed But drilling into individual functions told a different story. Two functions hit "Critical" status: (Geskryf deur Lightview-x.js) handleSrcAttribute Cognitive Complexity: 🛑 35 Cyclomatic Complexity: 🛑 22 Maintainability Index: 33.9 (Geskryf deur Lightview-x.js) Anonymous Template Processing Kognitiewe kompleksiteit: 31 Cyclomatic kompleksiteit: 13 This was slop. Technical debt waiting to become maintenance nightmares. Kan hy sy eie slop regmaak? Hier is waar dit interessant word. Die kode is geskep deur Claude Opus, Claude Sonnet, en Gemini 3 Pro 'n paar weke vroeër. clean it up? Gemini 3 Flash I asked Flash to refactor om sy kompleksiteit aan te spreek. Dit blyk 'n bietjie langer te neem as wat nodig is. So ek abortus en spandeer 'n bietjie tyd om sy denke proses te hersien. Daar was duidelike plekke wat dit gekantel of selfs in sirkels gegaan het, maar ek het dit gesê om voort te gaan. Nadat dit voltooi is, het ek die kode handmatig ondersoek en al die webwerwe gebiede wat hierdie funksie gebruik, grondig getest. Geen bugs gevind nie. handleSrcAttribute Kritieke Ontdekking #2: Gemini Flash "denk" uitgebreid. Terwyl die hersiening van al sy denke prosesse sal vervelig wees, blink belangrike insigte deur in die IDE. Wanneer 'n LLM blyk te steek in 'n loop, aborteer en hersien historiese gedagtes vir moontlike sidetracks en vertel om voort te gaan of te herleid as nodig. 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: After the fixes to , I asked for revised statistics to see the improvement. handleSrcAttribute Flash's Disappearing Act Unfortunately, Gemini Flash had deleted its file! It had to recreate the entire analyzer. metrics-analysis.js After Flash uses a script or analysis tool it creates, it often deletes the file assuming it is temporary. This happens even for files that take significant effort to create and that you might want to keep or reuse. Finding: Gemini Flash aggressively deletes temporary files. After Flash uses a script or analysis tool it creates, it often deletes the file assuming it is temporary. This happens even for files that take significant effort to create and that you might want to keep or reuse. Finding: Gemini Flash aggressively deletes temporary files. Gids: Sê Gemini om nut skripte te plaas in 'n spesifieke directory (soos /home/claude/tools/ of /home/claude/scripts/) en uitdruklik vra om dit te hou. Gids: Sê Gemini om nut skripte te plaas in 'n spesifieke directory (soos /home/claude/tools/ of /home/claude/scripts/) en uitdruklik vra om dit te hou. The Dev Dependencies Problem When I told Gemini to keep the metrics scripts permanently, another issue surfaced: it failed to officially install dev dependencies like (the JavaScript parser). acorn Flash simply assumed that because it found packages in , it could safely use them. The only reason was available was because I'd already installed a Markdown parser that depended on it. node_modules acorn Vind: LLMs bestuur nie altyd afhanklikhede behoorlik nie. Hulle sal alles wat beskikbaar is in node_modules gebruik sonder om te verifieer dat dit amptelik verklaar is in 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 Gids: Nadat 'n LLM nut skripte skep wat eksterne pakkette gebruik, vra uitdruklik: "Het jy al die vereiste afhanklikhede by package.json bygevoeg? After an LLM creates utility scripts that use external packages, explicitly ask: "Did you add all required dependencies to package.json? Please verify and install any that are missing." Better yet, review the script's imports and cross-check against your declared dependencies yourself. Guidance: The Refactoring Results With the analyzer recreated, Flash showed how it had decomposed the monolithic function into focused helpers: Kognitiewe inhoud (kognitiewe: 5) (cognitive: 5) parseElements (cognitive: 7) updateTargetContent (cognitive: 2) elementsFromSelector handleSrcAttribute orkestrator (kognitiewe: 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 die 10 -71% Cyclomatic Complexity 22 7 -68% Status Critical Slop Clean Code — Manual inspection and thorough website testing revealed zero bugs. The cost? A 0.5K increase in file size - negligible. 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 - template interpolation for text transformTextNode transformElementNode - attribuut interpolasie en recursie Results: Function Group Previous Max New Max Status MutationObserver Logic 31 🛑 6 ✅ Clean domToElements Logic 12 ⚠️ 6 ✅ Clean MutationObserver Logic 31 🛑 6 ✅ Clean domToElements Logic 12 jaar 6 ✅ skoon Finale biblioteekmetrieke After refactoring, lightview-x.js improved significantly: 93 → 103 (better decomposition) Functions: 66.5 → 66.8 Avg Maintainability: 3.6 → Avg Cognitive: 3.2 Die verhoogde funksie getal weerspieël gesonder modulariteit - komplekse logika gedelegeer aan gespesialiseerde, lae kompleksiteit helpers. 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 / 25 Die jaar goed lightview-x.js 103 0.0 / 66.8 / 93.5 0 / 3.2 / 23 Die jaar goed lightview-router.js 27 24.8 / 68.6 / 93.5 0 / 2.1 / 19 ⚖️ Good react.development.js 109 0.0 / 65.2 van 91.5 0 / 2 / 33 ⚖️ Good bau.js 79 11.2 / 71.3 / 92.9 0 / 1.5 van 20 ⚖️ Good htmx.js 335 0.0 / 65.3 van 92.9 0 / 3.4 / 116 Die jaar goed juris.js 360 21.2 / 70.1 / 96.5 0 / 2.6 / 51 ⚖️ Good 1. LLMs Mirror Human Behavior—For Better and Worse LLMs wys dieselfde tendense as gemiddelde ontwikkelaars: Vlug na kode sonder 'n volledige begrip Moenie nederlaag erken of hulp vroeg genoeg vra nie Generate defensive, over-engineered solutions when asked to improve reliability Maak skoonere kode met struktuur en raamwerke The difference? They do it . They can generate mountains of slop in hours that would take humans weeks. faster and at greater volume 2. Thinking Helps Extended reasoning (visible in "thinking" modes) shows alternatives, self-corrections, and occasional "oh but" moments. The thinking is usually fruitful, sometimes chaotic. Don’t just leave or do something else when tasks you belive are comple or critical are being conducted. The LLMs rarely say "I give up" or "Please give me guidance" - I wish they would more often. Watch the thinking flow and abort the response request if necessary. Read the thinking and redirect or just say continue, you will learn a lot. Multiple perspektiewe is kragtig When I told a second LLM, "You are a different LLM reviewing this code. What are your thoughts?", magic happened. Vind: LLMs is merkwaardig nie-verdedigend. Wanneer in die gesig staar met 'n implementering wat gekritiseer word as te abstrak, onvoldoende abstrak, of ineffektief, lei LLMs (Claude, Gemini, GPT) sal nie argumenteer nie. 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. Hierdie gedrag is eintlik : beyond what most humans provide Hoeveel menslike ontwikkelaars gee vinnige, gedetailleerde terugvoer sonder enige verdedigende gedrag? How many companies have experienced architects available for questioning by any developer at any time? Hoeveel kode evalueringsgesprekke gebeur sonder dat die ego betrokke raak? 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. Voordat of na die maak van veranderinge, verander LLMs doelbewus: 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. 4. Structure Prevents Slop 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: 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: When starting a project, based on what you want to accomplish ask for advice on: Guidance: The framework/library to use (React, Vue, Svelte, etc.) The architectural pattern (MVC, MVVM, component-based, etc.) Code organization preferences (feature-based vs. layer-based folders) Naming conventions Whether to use TypeScript or JSDoc for type safety Other libraries to use … no prevent re-invention. Don't say: "Build me a web app in JavaScript" Do say: "Build me a React application using functional components, hooks, TypeScript, and feature-based folder organization. Follow Airbnb style guide for naming." Hoe meer struktuur jy vooraf verskaf, hoe minder helling jy sal kry.Dit geld vir alle tale, nie net JavaScript nie. Wanneer jy 'n projek begin, op grond van wat jy wil bereik, vra vir advies oor: Guidance: The framework/library to use (React, Vue, Svelte, etc.) Die argitektuurpatroon (MVC, MVVM, komponentgebaseerde, ens.) Code organization preferences (feature-based vs. layer-based folders) Naming conventions Of om TypeScript of JSDoc te gebruik vir tipe sekuriteit Other libraries to use … no prevent re-invention. Don't say: "Build me a web app in JavaScript" Do say: "Build me a React application using functional components, hooks, TypeScript, and feature-based folder organization. Follow Airbnb style guide for naming." Hoe meer struktuur jy vooraf verskaf, hoe minder helling jy sal kry.Dit geld vir alle tale, nie net JavaScript nie. Metrika bied objektiewe waarheid 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. Vind: Formele sagteware metrikes kan ontwikkeling objektief lei. Identifying technical debt automatically Tracking code health over time Die hervorming van prioriteite Validating that "improvements" actually improve things Hulle is ideaal vir: Finding: Formal software metrics can guide development objectively. Identifying technical debt automatically Tracking code health over time Die hervorming van prioriteite Validating that "improvements" actually improve things Metrics lieg nie. Hulle het die helling wat my intuïsie gemis het, geïdentifiseer. Gids: Integreer metries in jou LLM-werkstroom: Run complexity metrics on all files. Identify functions with cognitive complexity > 15 or cyclomatic complexity > 10. After initial implementation: Prioritiseer refaktoring: Adreskritieke (kognitiewe > 26) funksies eerste, dan "High Friction" (16-25) funksies. Vra gerigte refaktoring: Moenie net sê 'verbeter dit nie'. Sê 'Refaktor handleSrcAttribute om kognitiewe kompleksiteit te verminder tot doelbereik'. After refactoring, re-run metrics. Ensure complexity actually decreased and maintainability increased. Sometimes ‘improvements’ just shuffle complexity around. Verify improvements: Before marking code as done, try to have all functions with a cognitive complexity 65. Set quality gates: 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: Prioritiseer refaktoring: Adreskritieke (kognitiewe > 26) funksies eerste, dan "High Friction" (16-25) funksies. Vra gerigte refaktoring: Moenie net sê 'verbeter dit nie'. Sê 'Refaktor handleSrcAttribute om kognitiewe kompleksiteit te verminder tot doelbereik'. After refactoring, re-run metrics. Ensure complexity actually decreased and maintainability increased. Sometimes ‘improvements’ just shuffle complexity around. Verify improvements: Before marking code as done, try to have all functions with a cognitive complexity 65. Set quality gates: The Verdict Na 40,000 lyn van LLM-genereerde kode, is ek versigtig optimisties. Maar soos menslike ontwikkelaars, het hulle nodig: Yes, LLMs can generate quality code. Clear, detailed specifications Strukturele beperkings (raamwerke, patrone) Reguliere hervestigingsgids Objective quality measurements Multiple perspectives on architectural decisions Die kritiek dat LLM's slop genereer, is nie verkeerd nie - maar dit is onvolledig. . unclear requirements, insufficient structure, and lack of quality enforcement Die verskil is iterasiesnelheid. Wat 'n menslike span maande kan neem om te bou en refaktor, kan LLMs in ure bereik. Looking Forward Ek is skeptiek dat die meeste mense die tyd sal verdra wat nodig is om duidelik en spesifiek te wees met LLMs - net soos hulle nie vandag doen nie wanneer produkbestuurders of ontwikkelaars gedetailleerde vereistes van besigheidspersoneel dryf. Hier is wat verander het: Die feedback loop het van weke tot ure ingedruk. We can now iterate and clean up faster when requirements evolve or prove insufficient. Soos kodering omgewings evolueer om LLM's in 'n beter struktuur te wraak - outomatiese metrikes, gedwonge patrone, multi-model oorsig - die gehalte sal verbeter. Die werklike vraag is nie of LLMs gehalte kode kan genereer nie.Dit is of ons hulle - en onsself - met die dissipline kan verskaf om dit konsekwent te doen. En, ek het 'n finale bekommernis ... as LLM's gebaseer is op geskiedenis en 'n neiging het om te hou met wat hulle weet, dan hoe sal ons die definisie en gebruik van dinge soos UI-biblioteke ontwikkel? Word ons vir ewig vasgesteek met React tensy ons iets anders vra? Of, is biblioteke 'n anachronisme? sal LLM's en beeld of video-modelle binnekort net die vereiste beeld van 'n gebruikersinterface met geen onderliggende kode genereer? Gegewe sy laat invoer in die spel en die verankering LLMs reeds het, hou ek nie hoë hoop vir die aanneming van Lightview nie, maar dit was 'n interessante eksperiment. https://lightview.dev