AIで8年間の構想を3ヶ月で実現
本文の状態
日本語全文を表示中
詳細モードで約5分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Simon Willison Blog
Lalit Maganti氏が、8年間構想していたSQLite開発ツール「syntaqlite」を、AIを活用してわずか3ヶ月で構築した事例を紹介している。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るSource Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
8年間望み、AIで3ヶ月かけて構築
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
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み