AIで8年間の構想を3ヶ月で実現
Lalit Maganti氏は、8年間構想していたSQLite開発ツール「syntaqlite」を、AI(Claude Code)の助けを借りて3ヶ月でプロトタイプ開発したが、最終的にはAI生成コードを破棄し、人間主導の設計で堅牢なライブラリを完成させた経験を共有している。
キーポイント
AIによる開発加速と限界
AI(Claude Code)は、400以上の文法ルールを扱うパーサー構築という退屈な作業を支援し、プロトタイプ開発を大幅に加速させたが、高レベルのアーキテクチャ設計には不向きであった。
プロトタイプ破棄と人間主導の再設計
AIで作成したプロトタイプは概念実証としては有効だったが、一貫した設計が欠如していたため、破棄され、人間による意思決定を重視したスクラッチからの再開発が行われた。
AI使用の非自明な課題
AIによるリファクタリングが容易なため、重要な設計決定を先延ばしにする傾向があり、コードベースの混乱を招き、思考の明晰さを損なうという課題が明らかになった。
実用的な開発ツールの完成
最終的に完成したsyntaqliteは、SQLiteクエリのパーサー、フォーマッター、検証ツールを提供する、言語サーバーなどで使用可能な高速で堅牢な開発ツールである。
影響分析・編集コメントを表示
影響分析
この記事は、AI支援開発の現実的な利点と課題を具体的な事例で示しており、AIが開発プロセスを加速する一方で、人間の設計判断の重要性を再認識させる内容となっている。特に、AIによるリファクタリングの容易さが設計決定の先延ばしを招くという指摘は、AIツール使用時の新たな注意点として開発コミュニティに影響を与える可能性がある。
編集コメント
AI開発ツールの現実的な使用感と限界を、具体的なプロジェクト経験から詳細に分析した貴重な記事。AI万能論ではなく、人間とAIの適切な協業モデルを考えるきっかけとなる内容。
Lalit Maganti氏は、長年にわたり目にした中で最もお気に入りの「エージェント型エンジニアリング」に関するロングフォーム記事の1つを提供しています。
彼らは8年間かけて構想を練き、その後3ヶ月をかけてsyntaqliteを構築しました。これは「SQLiteが deserving する高忠実度の開発ツール」と表現されています。
目標は、言語サーバーやその他の開発ツールでの使用に適した、高速で堅牢かつ包括的なリント(linting)および検証ツールをSQLiteに提供することでした。具体的には、SQLiteクエリ用のパーサー(構文解析器)、フォーマッター、および検証ツールです。私は過去に同種のものが欲しいと感じたことがあり、そのため数ヶ月前に作成した(まだ本番環境での使用にはほど遠い)sqlite-astプロジェクトにつながっています。
Lalit氏は、パーサーを構築するために400以上の文法規則を一つひとつ処理する必然的な退屈さから逃れるため、このプロジェクトを長年先送りにしてきました。まさに、コーディングエージェントが得意とするような退屈な作業です!
Claude Codeは、その最初のハードルを乗り越え、最初のプロトタイプを構築するのに役立ちました:
AI は基本的に、技術的な判断に関する私のあらゆる疑念、適切なものを作っているという確信の欠如、そして着手への抵抗感を、取り組むべき非常に具体的な問題を与えることで棚上げできるようにしてくれました。「SQLite のパーシングがどのように動作するかを理解する必要がある」というのではなく、「私にアプローチを提案させるために AI を使い、それを解体してより良いものを作り直す必要がある」ということになりました。頭の中で設計について endlessly に考えるよりも、触って遊べる具体的なプロトタイプや確認できるコードがある方が私の作業効率は格段に向上しますが、AI はそれ以前には想像もできなかったペースでその状態に至れるようにしてくれました。一度最初のステップを踏み出せば、その後のすべてのステップがはるかに容易になりました。
最初に vibe-coding されたプロトタイプは概念実証として素晴らしい結果を示しましたが、最終的に彼らはそれを捨ててゼロからやり直すことを決定しました。AI は低レベルの詳細には非常に優れていましたが、一貫性のある高レベルのアーキテクチャを生成することはできませんでした:
私は、AI が重要な設計決定における先送り(プロクラスチネーション)を助長することに気づきました。リファクタリングのコストが安かったため、「これは後で対応する」と常に言えました。そして AI がコードを生成したのと同じ工業規模でリファクタリングを行えたため、決定を先送りするコストは低いように感じられました。しかし実際にはそうではありませんでした:決定を先送りすることは、その間コードベースが混乱したままだったため、明確に思考する私の能力を蝕んでいきました。
2 回目の試行は大幅に時間がかかり、人間が関与する意思決定(human-in-the-loop decision making)を非常に多く含みましたが、その結果は時という試練に耐えうる堅牢なライブラリとなりました。
この全体を読むのに時間を割く価値があります。AIと密接に作業することの明らかなデメリットが満載であり、それらの障壁をどのように克服したかという詳細な説明も含まれているからです。
私がこの記事から得た重要な考えは、AIの設計およびアーキテクチャ(architecture)における弱さに関するものです。
私が何を求めているのかすら分かっていないものに取り組んでいたとき、AIは役に立たないどころか有害な存在でした。プロジェクトのアーキテクチャが最も顕著な例でした:初期の数週間は、AIの示す行き止まりをたどり、その場では生産的に感じられるが、精査すると崩れ去るような設計を探求することに費やしました。振り返ってみれば、AIをループから外して単に頭で考えただけの方が速かったのではないかと思わざるを得ません。
しかし、専門知識だけでは不十分です。問題を深く理解していたとしても、タスクに客観的に検証可能な答えがない場合、AIは依然として苦戦しました。実装には正解があります。少なくとも局所的なレベルでは、コードはコンパイルされ、テストは通り、出力は要求された内容と一致します。しかし、設計には正解がありません。オブジェクト指向プログラミング(OOP)が最初に普及してから数十年経った今も、私たちはまだ議論を続けています。
Via Hacker News
Tags: sqlite, ai, generative-ai, llms, ai-assisted-programming, vibe-coding, agentic-engineering
原文を表示
Eight years of wanting, three months of building with AI
Lalit Maganti provides one of my favorite pieces of long-form writing on agentic engineering I've seen in ages.
They spent eight years thinking about and then three months building syntaqlite, which they describe as "high-fidelity devtools that SQLite deserves".
The goal was to provide fast, robust and comprehensive linting and verifying tools for SQLite, suitable for use in language servers and other development tools - a parser, formatter, and verifier for SQLite queries. I've found myself wanting this kind of thing in the past myself, hence my (far less production-ready) sqlite-ast project from a few months ago.
Lalit had been procrastinating on this project for years, because of the inevitable tedium of needing to work through 400+ grammar rules to help build a parser. That's exactly the kind of tedious work that coding agents excel at!
Claude Code helped get over that initial hump and build the first prototype:
AI basically let me put aside all my doubts on technical calls, my uncertainty of building the right thing and my reluctance to get started by giving me very concrete problems to work on. Instead of “I need to understand how SQLite’s parsing works”, it was “I need to get AI to suggest an approach for me so I can tear it up and build something better". I work so much better with concrete prototypes to play with and code to look at than endlessly thinking about designs in my head, and AI lets me get to that point at a pace I could not have dreamed about before. Once I took the first step, every step after that was so much easier.
That first vibe-coded prototype worked great as a proof of concept, but they eventually made the decision to throw it away and start again from scratch. AI worked great for the low level details but did not produce a coherent high-level architecture:
I found that AI made me procrastinate on key design decisions. Because refactoring was cheap, I could always say “I’ll deal with this later.” And because AI could refactor at the same industrial scale it generated code, the cost of deferring felt low. But it wasn’t: deferring decisions corroded my ability to think clearly because the codebase stayed confusing in the meantime.
The second attempt took a lot longer and involved a great deal more human-in-the-loop decision making, but the result is a robust library that can stand the test of time.
It's worth setting aside some time to read this whole thing - it's full of non-obvious downsides to working heavily with AI, as well as a detailed explanation of how they overcame those hurdles.
The key idea I took away from this concerns AI's weakness in terms of design and architecture:
When I was working on something where I didn’t even know what I wanted, AI was somewhere between unhelpful and harmful. The architecture of the project was the clearest case: I spent weeks in the early days following AI down dead ends, exploring designs that felt productive in the moment but collapsed under scrutiny. In hindsight, I have to wonder if it would have been faster just thinking it through without AI in the loop at all.
But expertise alone isn’t enough. Even when I understood a problem deeply, AI still struggled if the task had no objectively checkable answer. Implementation has a right answer, at least at a local level: the code compiles, the tests pass, the output matches what you asked for. Design doesn’t. We’re still arguing about OOP decades after it first took off.
Via Hacker News
Tags: sqlite, ai, generative-ai, llms, ai-assisted-programming, vibe-coding, agentic-engineering
関連記事
ブログからニュースレターへのツールに新しいコンテンツタイプを追加
Simon Willison氏が、自身のブログからSubstackニュースレターへの自動転送ツールに新しいコンテンツタイプを追加し、エージェンティック・エンジニアリング・パターンの例として短いプロンプトで多くの作業を完了させた手法を紹介した。
Claude Opus 4.8:機能と反応について
Zvi は、新モデル「Claude Opus 4.8」の理解には多数のデータポイントが必要であり、限られたベンチマークからの評価は誤解を招くと指摘し、多様なソースからの数十件のテスト結果やモデルカード情報を統合して初めて一貫したパターンが形成できると述べています。
Anthropic、Claude Code および Claude Security のための「Mythos 1」を準備中(2 分読了)
Anthropic はモデル「Mythos 1」のより広範な利用に向けて動き出しており、同モデルはすでに Google Cloud や AWS の脆弱性発見プログラムを通じて組織保護に貢献している。また、Claude Opus 4.8 のリリースも噂されている。