行政概要 私は、40以上のコンポーネント、ルーター、およびLLM生成コードのみを使用してインタラクティブなウェブサイトをサポートする完全な反応型UIフレームワークを構築するために4週間のパートタイム(おそらく80時間合計)を費やしました。 . LLMs can produce quality code—but like human developers, they need the right guidance 主な発見 On Code Quality: よく指定されたタスクはクリーンファーストパスコードを生成します。 Poorly specified or unique requirements produce sloppy implementations Code degrades over time without deliberate refactoring. コードは故意のリファクタリングなしで時間とともに劣化する。 信頼性を向上させるために要求された場合に防衛的に超エンジニアリングのLLMs On The Development Process: タスクが大きいときに「よく指定される」のは難しい Extended reasoning ("thinking") produces better outcomes, though sometimes leads to circular or overly expansive logic Multiple LLM perspectives (switching models) provides valuable architectural review and debug assistance. 複数のLLMの視点(スイッチングモデル)は、貴重な建築レビューとデバッグの援助を提供します。 構造化されたフレームワークの使用、例えば Bau.js または Lightview は、制限のない開発よりも、傾斜を防ぐことができます。 Formal metrics objectively identify and guide removal of code complexity フォーマルメトリクスは客観的に識別し、コードの複雑さの除去を指示します。 The bottom line: In many ways LLMs behave like the average of the humans who trained them—they make similar mistakes, but much faster and at greater scale. Hence, you can get six months of maintenance and enhancement “slop” 6 minutes after you generate an initial clean code base and then ask for changes. 挑戦 4週間前、私は開発コミュニティで熱く議論されている質問に答えようとしました:LLMは実質的な生産品質のコードを生成できますか? 単純なCRUDアプリではなく、完全で近代的な反応型UIフレームワークで、多くの事前構築されたコンポーネント、ルーター、およびサポートするウェブサイトが含まれています。 数万行のJavaScript、CSS、HTML メモリ、パフォーマンス、セキュリティの考慮事項 プロのUXと開発者体験 作ることを選びました (※) )—Bau.js、HTMX、およびJuris.jsの最高の機能を組み合わせた反応型UIフレームワーク。制約:AnthropicのClaude(Opus 4.5, Sonnet 4.5)とGoogleのGemini 3 Proを使用して100%LLM生成されたコード(Flashは私が始めた時にはリリースされませんでした)。 Lightview ライトビュー.dev コードではなく質問から始める I began with Claude Opus: 「私はHTMX、Bau、およびJurisを組み合わせた反応型UIライブラリを作成したいです。 ハイパーメディアでは、特別な属性名を好むのではなく、改善された行動を好みます。 また、HTMLで文字列処理、SPAルーター、UIコンポーネントライブラリ、自動カスタマイズされた要素の作成、SEOを有効にするアプリケーション、追加の作業なし、ユーザーを促進し教育するウェブサイトも望みます。 「私はHTMX、Bau、およびJurisを組み合わせた反応型UIライブラリを作成したいです。 ハイパーメディアでは、特別な属性名を好むのではなく、改善された行動を好みます。 また、HTMLで文字列処理、SPAルーター、UIコンポーネントライブラリ、自動カスタマイズされた要素の作成、SEOを有効にするアプリケーション、追加の作業なし、ユーザーを促進し教育するウェブサイトも望みます。 Claude は最初にコードに潜り込んでいませんでした。 : dozens of clarifying questions TypeScript or vanilla JavaScript? スタイリングのためのUIコンポーネントライブラリは何ですか? (Pro / Cons のオプションが提供されました) HTMXは具体的にどのような機能を提供しているのでしょうか。 Hosting preferences? Routing strategy? 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. 発見: LLMs は、早期コード生成に対する強い偏見を持っています。 まだコードを覚えておらず、いくつかの相互作用の後でも忘れてしまいます。 これはすべてのモデル(Claude、Gemini、GPT)で起こります。 彼らは、実装要請ではなく質問とともに例が提供される場合でも、例のコードが与えられたときに、特に生成プロセスを開始するように引き起こされます。 まだコードをコードしないように思い出された場合でも、いくつかの相互作用の後には忘れてしまいます. 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. すべてのモデル(Claude, Gemini, GPT)で起こります。 Finding: LLMs have a strong bias toward premature code generation. 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. : if the user asks a question, the LLM should assume they want discussion, not code. Only generate/modify code when explicitly requested or after asking permission. Guidance: A better solution would be 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. : if the user asks a question, the LLM should assume they want discussion, not code. Only generate/modify code when explicitly requested or after asking permission. Guidance: A better solution would be 1時間後、クラウドはようやく「もう質問なし」と答え、「多くのステップがあるので、実施計画を作成したいですか?」 得られた計画は包括的なものであり、詳細な Markdown ファイルにはチェックボックス、設計決定、および以下についての考慮事項が含まれている。 Core reactive library 40+ コンポーネント Routing system A website … though the website got less attention - a gap I'd later address I did not make any substantive changes to this plan except for clarification on website items and the addition of one major feature, declarative event gating at the end of development. The Build Begins プランが適用されると、私はOpusでトークン制限を打ちました. 問題ありません - 私はジェミニ3(High)に切り替えました。 Within minutes, Gemini generated ――コア反応エンジン―と2つのサンプルファイル:「Hello, World!」デモは、バウのようなシンタクスとvDOMのようなシンタクスを両方表示する。 lightview.js その後、私はミスをしました。 「SPAとしてウェブサイトを構築してください」と私は言ったが、Lightview自体を使用することを明確にしなかった。 When I returned, there was a beautiful website running in my browser. I looked at the code and my heart sank: . React with Tailwind CSS 見つける: LLMs は、あなたが別に指定していない場合、最も一般的な/人気のあるソリューションを使用します。 React + Tailwind は、SPAs にとって極めて一般的なパターンです。Lightview を使用するための明示的なガイドラインなし - 私がちょうど作成したフレームワーク - LLM は、トレーニングデータで最も頻繁に見られたものにデフォルトされています。 見つける: LLMs は、あなたが別に指定していない場合、最も一般的な/人気のあるソリューションを使用します。 React + Tailwind は、SPAs にとって極めて一般的なパターンです。Lightview を使用するための明示的なガイドラインなし - 私がちょうど作成したフレームワーク - LLM は、トレーニングデータで最も頻繁に見られたものにデフォルトされています。 さらに悪いことに、Lightview で再構築するように頼んだとき、「まず既存のサイトを削除する」という言葉を忘れたので、50以上のファイルを1つずつ処理し、変更し、トークンを焦げた。 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 LLMを再作成するように依頼するとき、アプローチについて明確にしてください: Guidance: Delete the existing site and rebuild from scratch using Lightview 既存のサイトを Lightview を使用するように変更する 前者は大規模な変更のためのトークン効率を高めることが多いが、後者はターゲット修正に優れている。LLMは自動的に効率的な道を選択しない―あなたはそれを指示する必要がある。 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. 「いいね」クロードは効果的に説明し、「あなたはUIコンポーネントのためのDaisyUIを選び、DaisyUIはTailwindを依存性として必要とします。 Fair point—but I wasn't okay with it. I prefer semantic CSS classes and wanted the site to use classic CSS approaches. 見つける: LLMs 合理的ですが、時には望ましくない結論を作ります. あなたが依存性を有する1つのテクノロジーを指定すると、LLMs は、プロジェクトの関連する部分にその選択を拡張します. 彼らは論理的ですが、彼らは好みについてあなたの心を読み取ることができません. 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: 「DaisyUI コンポーネントは欲しいが、他の場所ではなく Tailwind のみを使用する」など、アーキテクチャ的なアプローチについて強い好みがある場合は、事前に明らかにしてください。 Guidance: 私はクラウドに古典的なCSSとセマンティッククラスを使用してサイトを書き直すように頼みました。私はデザインが好きでファイルを削除したくなかったので、再び多くのファイルに触れたため、たくさんのトークンを消費するリファクターに苦しみました。 ガイド: 1つのLLMがあなたのコードベースと戦っているとき、以前成功していたものに戻ります。異なるモデルはあなたのプロジェクトの文脈の異なる「理解」を持っています。そして、あなたがトークンがなくなったときにAntigravityを使用している場合は、同じディレクトリのMS Visual Codeに切り替え、Light GitHub Copilotアカウントを使用することができます。AntigravityはVisual Codeに基づいており、非常に類似した方法で動作します。 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: イテラティブダンス The Iterative Dance 次の数週間、私はウェブサイトを構築し、コンポーネントをテスト / イーテートし、トークン制限のリセットとして複数のLLMで働きました。 excelled at architectural questions and generated clean website code with Lightview components Claude Pro consistently tried to use local tools and shell helper scripts to support its own work—valuable for speed and token efficiency. However, it sometimes failed with catastrophic results, many files zeroed out or corrupt with no option but to roll-back. Gemini 見通しを変えることは強力であることを証明しました:「あなたは異なるLLMです。あなたの考えは何ですか?」しばしば、LLMが回転しているバグの突破的な洞察や迅速な修正を生み出しました。 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 初期のリハーサルは、ハッシュベースのルーター( で、 , etc.). This is entirely appropriate for an SPA—it's simple, reliable, and doesn't require server configuration. #/about #/docs しかし、私は明確に述べていなかった追加の要件がありました:私は従来のルートを望んでいました( で、 ) for deep linking and SEO. Search engines can handle hash routes now, but path-based routing is still cleaner for indexing and sharing. /about /docs 見つける: LLMs は時として最も単純な有効なソリューションにデフォルトされます。 ハッシュベースのルーティングは実装しやすく、サーバー側の構成なしで動作します。 見つける: LLMs は時として最も単純な有効なソリューションにデフォルトされます。 ハッシュベースのルーティングは実装しやすく、サーバー側の構成なしで動作します。 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. ガイドライン:アーキテクチャのパターンについては、早めにあなたの要件について明確にしてください。LLMはあなたがより複雑でSEOフレンドリーなアプローチを望むことを知っていると仮定しないでください。 指定: "I need path-based routing with History API for SEO" rather than just "I need 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: 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. ガイドライン:私はまた、LLMは防御的に以前のバージョンとの互換性を確保しようとしていることを発見し、これはあまりにも複雑なコードにつながる可能性があります。 Confronting The Numbers THE FINAL TALLY Project Size: 60 JavaScriptファイル、78 HTMLファイル、5 CSSファイル 41,405 total lines of code (including comments and empty) コードライン(コメントと空白を含む) Over 40 custom UI components 70+ サイトファイル 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 ライトビュー x.js 1,251 20.2K lightview-router.js 182 3K The website うまくスコアした スーパー・フォーカス・オプティミズムなしのパフォーマンスのために。 component gallery Lighthouse 次に複雑度メトリックが登場。 The Slop Revealed ジェミニ・フラッシュに3つの公式メトリクスを用いてコードを評価するように頼んだ。 A combined metric where 0 is unmaintainable and 100 is perfectly documented/clean code. この計算は、以下を考慮する。 1. Maintainability Index (MI): Halstead Volume(コードのサイズと複雑さの測定) サイクロマティック複雑性 コードライン どのようにDensity 65 を超えるスコアは、ライブラリ コードの健康であるとみなされます. This metric gives you a single number to track code health over time. An older but still valuable metric that measures the number of linearly independent paths through code. High cyclomatic complexity means: 2. Cyclomatic Complexity: より多くの潜在的なバグ 徹底的にテストするのが難しい(メトリックは実際にどれだけ書く必要があるかを教えてくれる) More cognitive load to understand 人間がコードを理解するために必要な精神的努力を測定する現代のメトリック サイクロマティック複雑性(すべてのコントロールフローを平等に扱う)とは異なり、認知複雑性は以下を罰する。 3. Cognitive Complexity: Nested conditionals and loops (deeper nesting = higher penalty) Boolean オペレーターチェーン 回帰 Breaks in linear flow 値: The Threshold: 0-15:クリーンコード - 理解し、維持しやすい 16-25:高摩擦 - 技術負債を減らすための再現推奨 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 ( ) Acorn JavaScript パッサーを使用 - 許可を求めることなく. これは印象的で、時には問題があります. 私はこのケースの問題を後で説明します。 Finding: LLMs excel at creating analysis tools. wrote its own complete analyzer metrics-analysis.js 判決 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 ️いいね。 lightview-x.js 93 66.5 3.6 ️いいね。 lightview-router.js 27 68.6 2.1 ️いいね。 But drilling into individual functions told a different story. Two functions hit "Critical" status: (lightview-x.js): handleSrcAttribute 知的複雑さ: 35 Cyclomatic Complexity: 🛑 22 Maintainability Index: 33.9 (lightview-x.js): Anonymous Template Processing Cognitive Complexity: 🛑 31 サイクロマティック複雑性:13 This was slop. Technical debt waiting to become maintenance nightmares. Can AI Fix Its Own Slop? コードは、クロード・オプス、クロード・ソネット、そして数週間前にジェミニ3プロによって生成されました。 掃除してんの? Gemini 3 Flash I asked Flash to refactor (フラッシュをリファクターに頼んだ) 複雑さに対処するために. これは必要以上に時間がかかるように見えた. だから私は中絶し、その思考プロセスをレビューするためにしばらく時間を費やしました. 明らかな場所がありました. それはサイドトラックを受けたか、あるいはサークルに入ったが、私はそれを続けるように言いました. 完了した後、私はコードを手動でチェックし、この機能を使用するすべてのウェブサイトの領域を徹底的にテストしました. バグが見つかりませんでした. 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: After the fixes to 改良を見るために統計を修正しました。 handleSrcAttribute Flash's Disappearing Act 残念ながら、Gemini Flash は削除しました。 ファイル! 全体のアナリストを再生する必要がありました。 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. Flash が作成したスクリプトや分析ツールを使用すると、しばしばファイルが一時的であると仮定して削除されます。 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/ Gemini に、ユーティリティ スクリプトを特定のディレクトリ(例えば 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 ジェミニーに永久にメトリックスクリプトを保持するように言ったとき、別の問題が浮上した:それは公式にデヴ依存をインストールできなかった。 (JavaScriptのパッサー) 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 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 利用可能なものは何でも使います。 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 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: LLM が外部パッケージを使用するユーティリティ スクリプトを作成した後、「あなたは package.json に必要なすべての依存性を追加しましたか? 欠けているものを確認してインストールしてください。 Guidance: The Refactoring Results 解析器が再現されると、Flash はモノリート機能を焦点を当てた助手に分解した方法を示した。 fetchContent(認知性:5) (cognitive: 5) parseElements Cognitive(認知性:7) (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 — 認知複雑性 35位 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 transformTextNode - テキストのテンプレートインターポレーション - 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 クリーン ホーム > 論理 12 ⚠️ 6 Clean 最終図書館メトリック After refactoring, lightview-x.js improved significantly: 93 → 103 (better decomposition) Functions: Avg メンテナンス: 66.5 → 66.8 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 ⚖️ 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 1. LLMs Mirror Human Behavior—For Better and Worse LLMs exhibit the same tendencies as average developers: 完全な理解なしにコードに急ぐ 敗北を認めないで、すぐに助けを求めないでください。 信頼性を向上させるために要求された場合に防衛的で過度に設計されたソリューションを生成する Produce cleaner code with structure and frameworks The difference? They do it 彼らは、人類に数週間かかる数時間で山の傾斜を生成することができます。 faster and at greater volume 2.思考が役立つ 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. 3. Multiple Perspectives Are Powerful 私が第2のLLMに言ったとき、「あなたはこのコードをレビューする別のLLMです。 発見: LLMs は驚くほど非防御的です。 あまりに抽象的で、不十分に抽象的で、または非効率であると批判されている実装に直面したとき、主要な LLMs (Claude, Gemini, GPT) は議論しません。 あまりにも抽象的で、不十分に抽象的で、または非効率的であると批判されている実装に直面した場合、主要なLLM(Claude, Gemini, GPT)は議論しません。 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 code review conversations happen without ego getting involved? ガイドライン:変更する前にまたは後に、 LLM を意図的に切り替える: 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: ガイドライン: プロジェクトを開始するとき、あなたが達成したいものに基づいて、以下についてアドバイスを求めます。 使用するフレームワーク/ライブラリ(React、Vue、Svelteなど) 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 他の図書館は...再発明を妨げない。 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." より多くの構造を事前に提供するほど、あなたが得る傾斜が少なくなります. This applies to all languages, not only JavaScript. プロジェクトを開始するとき、あなたが達成したいことに基づいて、以下についてアドバイスを求めます。 Guidance: 使用するフレームワーク/ライブラリ(React、Vue、Svelteなど) 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 他の図書館は...再発明を妨げない。 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. 5.メトリックは客観的な真実を提供する 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 彼らは完璧に: 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 Metrics don't lie. They identified the slop my intuition missed. ガイドライン:あなたの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: Before marking code as done, try to have all functions with a cognitive complexity < 15 and maintainability index > 65. Set quality gates: ガイドライン:あなたのLLMワークフローにメトリックを統合する: 最初の実装後: すべてのファイルで複雑度メトリクスを実行します. Identify functions with cognitive complexity > 15 or cyclomatic complexity > 10. リファクタリングを優先する:アドレス批判的(認知 > 26)機能を最初に、次に「高摩擦」(16-25)機能を設定する。 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: The Verdict LLMによって生成されたコードの4万行の後、私は慎重に楽観的です。 But like human developers, they need: Yes, LLMs can generate quality code. Clear, detailed specifications Structural constraints (frameworks, patterns) Regular refactoring guidance 客観的な品質測定 Multiple perspectives on architectural decisions LLMsが傾斜を生成するという批判は間違っていないが、それは不完全である。 . unclear requirements, insufficient structure, and lack of quality enforcement 違いはイテレーションスピードである。人間のチームが何ヶ月も建設し、リファクターを開発するのにかかるかもしれない、LLMsは数時間で達成することができます。 展望前 私は、ほとんどの人々がLLMで明確かつ具体的であるために必要な時間を許すだろうと懐疑的です - 製品マネージャーや開発者がビジネススタッフからの詳細な要件を押しつけたときのように、今日ではそうではありません。 しかし、ここは何が変わったのか: フィードバックループは数週間から数時間にわたって圧縮されています。 We can now iterate and clean up faster when requirements evolve or prove insufficient. コード環境がより良い構造にLLMを包み込むように進化するにつれて - 自動メトリクス、強制パターン、複数のモデルレビュー - 品質は向上します。 本当の問題は、LLMが質の高いコードを生成できるかどうかではなく、私たちがそれらと私たち自身を一貫してそれを行うための規律を提供できるかどうかです。 そして、私は最後の懸念を持っています ... LLMs が歴史に基づいており、彼らが知っているものに固執する傾向がある場合、私たちは、UI ライブラリのようなものの定義と使用をどのように進化させますか? 私たちは、何か異なることを要求しない限り、永遠に React に閉じ込められていますか? または、ライブラリはアナクロニズムですか? LLMs と画像やビデオモデルは、間もなく、基本的なコードなしで必要なユーザーインターフェイスのイメージを生成しますか? ゲームへの遅い入力と既に根付いているLLMを考慮して、私はLightviewの採用に高い希望を持っていないが、それは興味深い実験だった。 https://lightview.dev
