Izpilddirektora kopsavilkums Es pavadīju četras nedēļas nepilna laika (iespējams, 80 stundas kopumā) veidojot pilnīgu reaktīvo UI sistēmu ar 40+ komponentiem, maršrutētāju un atbalstu interaktīvai tīmekļa vietnei, izmantojot tikai LLM ģenerētu kodu, tas ir acīmredzams. . LLMs can produce quality code—but like human developers, they need the right guidance Galvenie atklājumi On Code Quality: Labi norādītie uzdevumi nodrošina tīru pirmā ceļojuma kodu Slikti noteiktas vai unikālas prasības rada slinks īstenošanu Code degrades over time without deliberate refactoring LLM aizstāvīgi pār-inženieris, ja tiek prasīts, lai uzlabotu uzticamību On The Development Process: Ir grūti būt “labi norādītam”, kad uzdevums ir liels Plašāka domāšana (“domāšana”) rada labākus rezultātus, lai gan dažreiz tas noved pie apļveida vai pārāk plašas loģikas. Vairākas LLM perspektīvas (apmaiņas modeļi) nodrošina vērtīgu arhitektūras pārskatu un labošanas palīdzību Structured framework use, e.g. Bau.js or Lightview, prevent slop better than unconstrained development Formālās metrikas objektīvi identificē un vada koda sarežģītības noņemšanu Bottom line: Daudzējādā ziņā LLM uzvedas kā vidējais cilvēks, kurš tos apmācīja - viņi pieļauj līdzīgas kļūdas, bet daudz ātrāk un lielākā mērogā. The Challenge Pirms četriem nedēļām es nolēmu atbildēt uz jautājumu, kas ir karsti apspriests attīstības kopienā: Vai LLM var radīt materiālu, ražošanas kvalitātes kodu? Not a toy application. Not a simple CRUD app. A complete, modern reactive UI framework with lots of pre-built components, a router and a supporting website with: Desmitiem tūkstošu līniju JavaScript, CSS un HTML Atmiņa, veiktspēja un drošības apsvērumi Profesionāla UX un izstrādātāja pieredze Es izvēlējos būvēt (Tā kā )—reaktīva UI sistēma, kas apvieno Bau.js, HTMX un Juris.js labākās funkcijas. ierobežojums: 100% LLM ģenerēts kods, izmantojot Anthropic Claude (Opus 4.5, Sonnet 4.5) un Google Gemini 3 Pro (Flash netika izlaists, kad es sāku). Lightview Lāčplēsis.dev Starting With Questions, Not Code I began with Claude Opus: "Es gribu izveidot reaktīvu UI bibliotēku, kas apvieno HTMX, Bau un Juris. Hipermediālam es dodu priekšroku ne īpašiem atribūtu nosaukumiem - tikai uzlabotai uzvedībai. Es arī gribu string literal apstrādi HTML, SPA maršrutētāju, UI komponentu bibliotēku ar automātisku pielāgotu elementu izveidi, SEO-iespējamas lietotnes bez papildu darba un tīmekļa vietni, lai veicinātu un izglītotu lietotājus. "Es gribu izveidot reaktīvu UI bibliotēku, kas apvieno HTMX, Bau un Juris. Hipermediālam es dodu priekšroku ne īpašiem atribūtu nosaukumiem - tikai uzlabotai uzvedībai. Es arī gribu string literal apstrādi HTML, SPA maršrutētāju, UI komponentu bibliotēku ar automātisku pielāgotu elementu izveidi, SEO-iespējamas lietotnes bez papildu darba un tīmekļa vietni, lai veicinātu un izglītotu lietotājus. Claude sākotnēji nav iegremdējusies kodā. : dozens of clarifying questions TypeScript vai vaniljas JavaScript? Kura UI sastāvdaļu bibliotēka ir paredzēta styling? (Tas nodrošināja iespējas ar priekšrocībām / trūkumiem) Which HTMX features specifically? Mājokļu preferences? Maršruta stratēģija ? Tomēr reizēm tas sāka rakstīt kodu, pirms es domāju, ka tam vajadzētu būt gatavam, un man bija jāizbeidz atbilde un jāpāradresē. Atklāšana: LLM ir spēcīgs aizspriedums pret priekšlaicīgu koda ģenerāciju. Pat tad, kad tiek atgādināts, ka vēl nav jākodē, viņi aizmirst pēc dažām mijiedarbībām. Tas notiek ar visiem modeļiem – Claude, Gemini, GPT. Tie, šķiet, ir īpaši aktivizēti, lai sāktu ģenerācijas procesu, kad tiek dota parauga koda, pat tad, kad piemēri tiek sniegti kopā ar jautājumiem, nevis kā īstenošanas pieprasījumi. Pat tad, kad tiek atgādināts, ka vēl nevajag kodēt, viņi aizmirst pēc dažām mijiedarbībām.Tas notiek ar visiem modeļiem-Claude, Gemini, GPT. Tie, šķiet, ir īpaši aktivizēti, lai sāktu ģenerēšanas procesu, kad tiek dota parauga kods, pat tad, ja piemēri tiek sniegti kopā ar jautājumiem, nevis kā īstenošanas pieprasījumi. Finding: LLMs have a strong bias toward premature code generation. Vadlīnijas: Ja LLM sāk ģenerēt kodu, pirms esat gatavs, nekavējoties atceliet pabeigšanu un novirziet: "Vēl nav ģenerēts kods. Vai jums ir vairāk jautājumu?" Jums var būt nepieciešams atkārtot šo vairākas reizes, jo LLM "aizmirst" un atgriežas pie koda ģenerēšanas. Plānošana pret Ātrā režīma maiņa Antigravitācijā vai līdzīgos režīmos citos IDE vajadzētu palīdzēt ar to, bet tas ir neērti izmantot atkārtoti. Labāks risinājums būtu: ja lietotājs uzdod jautājumu, LLM vajadzētu pieņemt, ka viņi vēlas diskusiju, nevis kodu. 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. : ja lietotājs uzdod jautājumu, LLM vajadzētu pieņemt, ka viņi vēlas diskusiju, nevis kodu. Guidance: A better solution would be Pēc stundas atpakaļ un atpakaļ, Claude beidzot teica: "Nav vairāk jautājumu. vai jūs vēlaties, lai es izveidotu īstenošanas plānu, jo būs daudz soļu?" The resulting plan was comprehensive - a detailed Markdown file with checkboxes, design decisions, and considerations for: Core reactive library 40+ UI components Routing system Tīmekļa vietne ... lai gan tīmekļa vietne saņēma mazāk uzmanības - plaisa, kuru es vēlāk novērstu Es neesmu izdarījis nekādas būtiskas izmaiņas šajā plānā, izņemot tīmekļa vietnes elementu precizēšanu un vienas galvenās funkcijas pievienošanu, deklaratīvo notikumu gating attīstības beigās. Būvniecība sākas 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. Within minutes, Gemini generated - kodola reaktivitātes dzinējs - kopā ar diviem paraugu failiem: "Hello, World!" demo, kas parāda gan Bau līdzīgu sintaksi, gan vDOM līdzīgu sintaksi. lightview.js Then I made a mistake. "Izveidojiet tīmekļa vietni kā SPA," es teicu, nenorādot, lai izmantotu pašu Lightview. Kad es atgriezos, manā pārlūkprogrammā darbojās skaista tīmekļa vietne. es paskatījos uz kodu un mana sirds nokrita: . React with Tailwind CSS Atklāšana: LLM izmantos visbiežāk/populārāko risinājumu, ja jūs nenorādīsiet citādi. React + Tailwind ir ārkārtīgi izplatīts SPAs modelis. Bez skaidras vadlīnijas par Lightview izmantošanu - pati sistēma, ko es tikko būvēju - LLM pēc noklusējuma bija tas, ko tas visbiežāk bija redzējis apmācību datos. 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. Sliktāk, kad es lūdzu to atjaunot ar Lightview, es aizmirsu teikt "izdzēst esošo vietni vispirms." 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 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 Pirmais bieži vien ir efektīvāks par lielām izmaiņām. otrs ir labāks par mērķtiecīgiem labojumiem. LLM automātiski neizvēlas efektīvu ceļu - jums tas ir jāvada. The Tailwind Surprise One issue caught me off-guard. After Claude generated the website using Lightview components, I noticed it was still full of Tailwind CSS classes. I asked Claude about this. "Nu," Claude efektīvi paskaidroja, "jūs izvēlējāties DaisyUI UI komponentiem, un DaisyUI prasa Tailwind kā atkarību. Es dodu priekšroku semantiskām CSS klasēm un gribēju, lai vietne izmantotu klasiskās CSS pieejas. 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. Kad jūs norādāt vienu tehnoloģiju, kurai ir atkarības, LLM paplašinās šo izvēli attiecībā uz saistītām projekta daļām. Finding: LLMs make reasonable but sometimes unwanted inferences. Vadlīnijas: Esiet skaidrs par to, ko nevēlaties, ne tikai to, ko vēlaties. piemēram, "Es vēlos DaisyUI komponentus, bet izmantojiet tikai Tailwind tiem, nevis citur." Esiet skaidrs par to, ko nevēlaties, ne tikai to, ko vēlaties. piemēram, "Es vēlos DaisyUI komponentus, bet izmantojiet Tailwind tikai tiem, nevis citur." Guidance: Es lūdzu Claude pārrakstīt vietni, izmantojot klasiskās CSS un semantiskās klases. man patika dizains un negribēja dzēst failus, tāpēc atkal es cietu no refaktora, kas patērēja daudz žetonu, jo tas skāra tik daudz failus. 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: Kad viens LLM cīnās ar jūsu koda bāzi, pārslēdzieties atpakaļ uz vienu, kas iepriekš bija veiksmīgs. Dažādiem modeļiem ir atšķirīgs "izpratne" par jūsu projekta kontekstu. Un, ja jūs izmantojat Antigravity, kad beidzas žetoni, jūs varat pāriet uz MS Visual Code tajā pašā direktorijā un izmantot vieglu GitHub Copilot kontu ar Claude. Antigravity ir balstīts uz Visual Code, tāpēc tas darbojas ļoti līdzīgā veidā. Guidance: Iteratīvais dejas Nākamajās nedēļās es strādāju, lai izveidotu tīmekļa vietni un pārbaudītu / iterētu komponentus, es strādāju vairākos LLM kā token limitu nodošanu. excelled at architectural questions and generated clean website code with Lightview components Claude Gemini Pro pastāvīgi mēģināja izmantot vietējos rīkus un shell helper skriptus, lai atbalstītu savu darbu, kas ir vērtīgs ātruma un žetonu efektivitātes ziņā. Pārslēgšanās perspektīvas izrādījās spēcīgas: "Jūs esat atšķirīgs LLM. Kādas ir jūsu domas?" bieži vien radīja pārsteidzošas iezīmes vai ātrus labojumus kļūdām, par kurām viens LLM ir apgriezies. I found the real winner to be Gemini Flash. It did an amazing job of refactoring code without introducing syntax errors and needed minimal guidance on what code to put where. Sometimes I was skeptical of a change and would say so. Sometimes, Flash would agree and adjust and other times it would make a rational justification of its choice. And, talk about fast … wow! The Router Evolution The router also needed work. Claude initially implemented a hash-based router ( , , etc.). This is entirely appropriate for an SPA—it's simple, reliable, and doesn't require server configuration. #/about #/docs Bet man bija papildu prasības, kuras neesmu skaidri norādījis: es gribēju tradicionālos ceļus ( , Meklētājprogrammas tagad var apstrādāt hash maršrutus, bet maršruts, kas balstīts uz ceļa, joprojām ir tīrāks indeksēšanai un kopīgai izmantošanai. /about /docs Atklāšana: LLM dažreiz pēc noklusējuma būs vienkāršākais derīgais risinājums. Hash balstītu maršrutu ir vieglāk īstenot un darbojas bez servera konfigurācijas. Tā kā es neteicu, ka es gribētu maršrutu, kas balstīts uz ceļa, LLM izvēlas vienkāršāku pieeju. Atklāšana: LLM dažreiz pēc noklusējuma būs vienkāršākais derīgais risinājums. Hash balstītu maršrutu ir vieglāk īstenot un darbojas bez servera konfigurācijas. Tā kā es neteicu, ka es gribētu maršrutu, kas balstīts uz ceļa, LLM izvēlas vienkāršāku pieeju. 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. 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: Par arhitektūras modeļiem, jābūt skaidri par savām prasībām agri.Nedomājiet, ka LLM zina, jūs vēlaties sarežģītāku, bet SEO draudzīgu pieeju. Norādiet: "Man ir nepieciešams maršruts, kas balstīts uz ceļa ar vēstures API SEO" nevis tikai "Man ir nepieciešams maršruts." 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. Vadlīnijas: Es arī atklāju, ka LLM defenzīvi cenšas nodrošināt saderību ar iepriekšējām versijām, tas var novest pie pārāk sarežģīta koda. Confronting The Numbers The Final Tally Project Size: 60 JavaScript files, 78 HTML files, 5 CSS files 41,405 total lines of code (including comments and blanks) Vairāk nekā 40 Custom UI komponenti 70+ tīmekļa vietņu faili 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 lightview.js 603 7.75K Lightview-x.js tīmekļa vietne 1,251 20.2 K Iepazīšanās ar router.js 182 3K The website Labi nokrita for performance without having had super focused optimization. Galerijas sastāvdaļas Lighthouse Bet tad nāca sarežģītības metrikas. The Slop Revealed Es lūdzu Gemini Flash novērtēt kodu, izmantojot trīs formālas metrikas: A combined metric where 0 is unmaintainable and 100 is perfectly documented/clean code. The calculation considers: 1. Maintainability Index (MI): Halstead apjoms (koda lieluma un sarežģītības mērījums) Cyclomatic Complexity Koda līnijas Kāda ir densitāte Scores above 65 are considered healthy for library code. This metric gives you a single number to track code health over time. Vecāks, bet joprojām vērtīgs rādītājs, kas mēra lineāri neatkarīgu ceļu skaitu, izmantojot kodu. 2. Cyclomatic Complexity: More potential bugs Grūtāk rūpīgi pārbaudīt (metrāža faktiski var pateikt, cik daudz jums var būt nepieciešams rakstīt) More cognitive load to understand Mūsdienu rādītājs, kas mēra garīgo piepūli, kas cilvēkam ir nepieciešams, lai saprastu kodu. atšķirībā no ciklamātiskās sarežģītības (kas vienādi izturas pret visu kontroles plūsmu), kognitīvā sarežģītība sodīs: 3. Cognitive Complexity: Nested nosacījumi un loki (dziļāka nesting = augstāks sods) Boolean operator chains Recursion Breaks in linear flow Tās slieksnis: Clean Code - easy to understand and maintain 0-15: High Friction - refactoring suggested to reduce technical debt 16-25: Critical - immediate attention needed, maintenance nightmare 26+: Gemini Flash initially searched for an existing metrics library, couldn't find one, then ( ) 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 ( ) 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 spriedums Kopumā veselība izskatījās laba: 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 Mīlestība.js 58 65.5 3.3 ⚖️ Good lightview-x.js 93 66.5 3.6 ️ Labs Iepazīšanās ar router.js 27 68.6 2.1 ⚖️ Good But drilling into individual functions told a different story. Two functions hit "Critical" status: (Pāradresēts no LightView x.js) handleSrcAttribute Cognitive Complexity: 🛑 35 Ciklomatiskā sarežģītība: 22 Izturības indekss: 33,9 (lightview-x.js): Anonymous Template Processing Kognitīvā sarežģītība: 31 Ciklomatiskā sarežģītība: 13 Tehniskais parāds, kas gaida, lai kļūtu par uzturēšanas murgām. Vai viņš spēj izlabot savu slogu? Šeit tas kļūst interesanti. kods tika ģenerēts Claude Opus, Claude Sonnet un Gemini 3 Pro vairākas nedēļas agrāk. clean it up? Gemini 3 Flash I asked Flash to refactor lai risinātu tās sarežģītību. Šķita, ka tas aizņems nedaudz ilgāk, nekā nepieciešams. Tāpēc es pārtraucu un pavadīju laiku, pārskatot tās domāšanas procesu. Bija acīmredzamas vietas, kur tas kļuva sānu izsekots vai pat gāja apļos, bet es teicu, lai turpinātu. Pēc tam, kad tas bija pabeigts, es manuāli pārbaudīju kodu un rūpīgi pārbaudīju visas tīmekļa vietnes jomas, kas izmanto šo funkciju. handleSrcAttribute Critical Discovery #2: Gemini Flash "domā" plaši. Kamēr pārskatot visus tās domāšanas procesus būtu garlaicīgi, svarīgas ieskati mirgo caur IDE. Kad LLM šķiet iestrēdzis lokā, aborts un pārskatīt vēsturiskās domas par iespējamiem sidetracks un pastāstīt turpināt vai novirzīt pēc vajadzības. 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 , Es lūdzu pārskatīt statistiku, lai redzētu uzlabojumus. handleSrcAttribute Flash's Disappearing Act Unfortunately, Gemini Flash had deleted its file! It had to recreate the entire analyzer. metrics-analysis.js Finding: Gemini Flash agresīvi izdzēš pagaidu failus. Pēc tam, kad Flash izmanto skriptu vai analīzes rīku, ko tas rada, tas bieži izdzēš failu, pieņemot, ka tas ir pagaidu. 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. 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/ 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/ The Dev Dependencies Problem Kad es teicu Gemini, lai saglabātu metrikas skriptus pastāvīgi, parādījās vēl viena problēma: tā nespēja oficiāli instalēt dev atkarības, piemēram, (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 Atklājums: LLM ne vienmēr pareizi pārvalda atkarības. viņi izmantos visu, kas ir pieejams node_modules, nepārbaudot, vai tas ir oficiāli deklarēts package.json. Viņi izmantos visu, kas ir pieejams 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 Vadlīnijas: Pēc tam, kad LLM izveido lietojumprogrammas skriptu, kas izmanto ārējos paketes, skaidri jautājiet: "Vai esat pievienojis visas nepieciešamās atkarības package.json? lūdzu, pārbaudiet un instalējiet jebkuru, kas trūkst." 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: (cognitive: 5) fetchContent (cognitive: 5) parseElements (cognitive: 7) updateTargetContent (cognitive: 2) elementsFromSelector orchestrator (cognitive: 10) handleSrcAttribute The Results Metric Before After Improvement Cognitive Complexity 35 🛑 10 ✅ -71% Cyclomatic Complexity 22 7 -68% Status Critical Slop Clean Code — Kognitīvā sarežģītība 35 🛑 10 ✅ -71% Ciklomatiskā sarežģītība 22 7 -68% Status Kritiskais slānis 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 transformTextNode - teksta interpolācijas veidnes transformElementNode - atribūts interpolācija un recursion Results: Function Group Previous Max New Max Status MutationObserver Logic 31 🛑 6 ✅ Clean domToElements Logic 12 ⚠️ 6 ✅ Clean Mūziķu loģika 31 🛑 6 tīrs domToElements Logic 12 ⚠️ 6 ✅ Clean Galīgās bibliotēkas metrikas After refactoring, lightview-x.js improved significantly: 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 ⚖️ 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 ️ Labs 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 ️ Labs 1. LLMs Mirror Human Behavior—For Better and Worse LLM ir tādas pašas tendences kā vidējie izstrādātāji: Skrien uz kodu bez pilnīgas izpratnes Neatzīstiet sakāvi vai lūdziet palīdzību pietiekami ātri Generate defensive, over-engineered solutions when asked to improve reliability Ražot tīrāku kodu ar struktūru un sistēmām The difference? They do it . They can generate mountains of slop in hours that would take humans weeks. faster and at greater volume Domāšana palīdz 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. Vairākas perspektīvas ir spēcīgas Kad es teicu otram LLM, "Jūs esat cits LLM, kas pārskata šo kodu. 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? Cik daudz uzņēmumu ir pieredzējuši arhitekti, kas jebkurā laikā ir pieejami jebkuram izstrādātājam? Cik daudz kodu pārskatīšanas sarunu notiek bez ego iesaistīšanās? 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. 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. 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: Vadlīnijas: Sākot projektu, pamatojoties uz to, ko vēlaties sasniegt, lūdziet padomu par: The framework/library to use (React, Vue, Svelte, etc.) The architectural pattern (MVC, MVVM, component-based, etc.) Koda organizācijas preferences (funkciju mapi vs. slāņu mapi) 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." 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: The framework/library to use (React, Vue, Svelte, etc.) The architectural pattern (MVC, MVVM, component-based, etc.) Koda organizācijas preferences (funkciju mapi vs. slāņu mapi) Konvencijas nosaukums 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." The more structure you provide upfront, the less slop you'll get. This applies to all languages, not just JavaScript. Metrika nodrošina objektīvu patiesību Tie bieži tiek uzskatīti par pārāk garlaicīgiem, mehāniskiem, sarežģītiem vai dārgiem, lai iegūtu cilvēka attīstībai, bet LLM uzlabotajā IDE ar LLM, kas var rakstīt kodu, lai veiktu formālu avota analīzi (nav nepieciešama IDE spraudņa abonēšana), viņiem vajadzētu saņemt daudz vairāk uzmanības, nekā viņi dara. 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 Tie ir ideāli piemēroti: Finding: Formal software metrics can guide development objectively. Tehniskā parāda automātiska noteikšana Veselības pārbaude laika gaitā Atjaunošanas prioritātes Validating that "improvements" actually improve things Metrics don't lie. They identified the slop my intuition missed. 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: 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: Before marking code as done, try to have all functions with a cognitive complexity < 15 and maintainability index > 65. Set quality gates: Integrējiet metriku savā LLM darba procesā: Guidance: Run complexity metrics on all files. Identify functions with cognitive complexity > 15 or cyclomatic complexity > 10. After initial implementation: Prioritizējiet refaktorēšanu: Vispirms adreses kritiskās (kognitīvās > 26) funkcijas, pēc tam "Augstas vilkmes" funkcijas (16-25) Pieprasiet mērķtiecīgu refaktoringu: Neticiet tikai “uzlabojiet to”.Sakiet “Refaktora rīcībaSrcAttribute, lai samazinātu kognitīvo sarežģītību mērķa diapazonā”. After refactoring, re-run metrics. Ensure complexity actually decreased and maintainability increased. Sometimes ‘improvements’ just shuffle complexity around. Verify improvements: Iestatīt kvalitātes vārti: Pirms marķēšanas kodu, kā izdarīts, mēģiniet, lai visas funkcijas ar kognitīvo sarežģītību < 15 un uzturēšanas indekss > 65. spriedums After 40,000 lines of LLM-generated code, I'm cautiously optimistic. But like human developers, they need: Yes, LLMs can generate quality code. Clear, detailed specifications Structural constraints (frameworks, patterns) Regular refactoring guidance Objektīvi kvalitātes mērījumi 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 Atšķirība ir iterācijas ātrums. Kas varētu aizņemt cilvēka komandai mēnešus, lai izveidotu un refaktoru, LLM var sasniegt stundās. Skatoties uz priekšu Es esmu skeptisks, ka lielākā daļa cilvēku panāks laiku, kas nepieciešams, lai būtu skaidrs un konkrēts ar LLM - tāpat kā tie nav šodien, kad produktu vadītāji vai izstrādātāji pieprasa detalizētas prasības no biznesa darbiniekiem. Lūk, kas ir mainījies: Atsauksmes loks ir saspiests no nedēļām līdz stundām. We can now iterate and clean up faster when requirements evolve or prove insufficient. Tā kā kodēšanas vides attīstās, lai iesaiņotu LLM labākajā struktūrā - automatizētas metrikas, īstenoti modeļi, vairāku modeļu pārskati - kvalitāte uzlabosies. Īstais jautājums nav par to, vai LLM var radīt kvalitatīvu kodu. tas ir, vai mēs varam nodrošināt tos - un paši - ar disciplīnu, lai to izdarītu konsekventi. Un, man ir pēdējais jautājums ... ja LLM ir balstīti uz vēsturi un ir tendence palikt ar to, ko viņi zina, tad kā mēs attīstīsim tādu lietu definīciju un izmantošanu kā UI bibliotēkas? Vai mēs uz visiem laikiem paliksim ar React, ja vien mēs neprasīsim kaut ko citu? Ņemot vērā tā vēlu iekļūšanu spēlē un piederības LLM jau ir, man nav augstas cerības par Lightview pieņemšanu, bet tas bija interesants eksperiments. https://lightview.dev
