AIで作りたくなってから8年、実際にAIで作るまで3か月（via）Lalit Magantiによる、エージェント的エンジニアリングに関する長文の記事の中で、私が久しく見てきた中でも特にお気に入りの一つです。

彼らはsyntaqliteについて、考えるのに8年、そして作るのに3か月を費やしました。彼らはこれを「SQLiteにふさわしい高精度な開発者向けツール」と説明しています。

目的は、言語サーバーやその他の開発ツールで使えるように、SQLite向けの高速・堅牢・包括的なリントおよび検証ツールを提供することでした。つまり、SQLiteクエリのためのパーサー、フォーマッタ、そして検証者です。私は以前からこういうものが欲しいと思っていました。だからこそ、数か月前の（はるかに本番投入には程遠い）sqlite-astプロジェクトがあるのです。

Lalitは、このプロジェクトに数年間ブレーキをかけていました。なぜなら、パーサーを作るために400以上の文法ルールを通していく必要があるという、避けられない退屈さがあったからです。まさに、コーディングエージェントが得意とする種類の退屈な作業ですよね！

Claude Codeが、その最初の壁を越えて最初のプロトタイプを作るのを助けました：

AIは基本的に、技術的な打ち合わせで私が抱くすべての疑念、正しいものを作る不確実性、そして始めることへの消極さを脇に置かせてくれました。というのも、取り組むべきとても具体的な問題を与えてくれたからです。「SQLiteのパースがどう動くのかを理解する必要がある」ではなく、「AIに提案させて、それを壊してより良いものを作る必要がある」だったんです。私は、頭の中で延々と設計を考えるよりも、いじれる具体的なプロトタイプと眺めるためのコードがあるほうがずっと良く進められます。そしてAIは、以前は思いつきもしなかったスピードでその地点に到達させてくれました。最初の一歩を踏み出したあとは、以降のどのステップもずっと楽になりました。

最初の「雰囲気でコードを書いた（vibe-coded）」プロトタイプは、概念実証としてうまく機能しました。しかし、最終的にはそれを捨ててゼロからやり直すという判断に至ります。AIは低レベルの詳細にはとても効果的だったものの、首尾一貫した高レベルのアーキテクチャは生み出せなかったからです：

AIによって、重要な設計上の意思決定を先延ばしにしてしまうことが分かりました。リファクタリングが安価だったので、「これについては後で扱えばいい」といつでも言えてしまう。さらにAIは、コードを生成するのと同じ規模の工業的なやり方でリファクタリングもできるので、意思決定を先延ばしにするコスト感が低く感じられました。でも実際は違いました。意思決定を先延ばしにすると、コードベースがその間ずっと混乱したままなので、はっきり考える能力が腐食していきました。

2回目の試みは、かなり時間がかかり、また人間が関与する意思決定がずっと多く含まれていました。しかしその結果、時の試練に耐えうる堅牢なライブラリが得られました。

これを最初から最後まで読むために、少し時間を取る価値はあります。AIを大いに使うことには、あまり自明ではない欠点がたくさん詰まっているだけでなく、そのハードルをどう乗り越えたのかも詳しく説明されています。

私が持ち帰った重要な考えは、AIの「設計とアーキテクチャに関する弱さ」についてです：

自分が何を欲しいのかすら分かっていないような何かに取り組んでいたとき、AIは役に立たないというより有害なほうに近いところにありました。プロジェクトのアーキテクチャがそのいちばん明確な例で、私はAIに導かれるまま初期の数週間、行き止まりに何度も入り込み、いま考えると「その時点では生産的に感じる」ような設計を探っていましたが、精査すると崩れ落ちていました。振り返ってみると、AIをループに入れずにただ考え抜いただけのほうが速かったのではないか、と疑問に思わざるを得ません。

しかし、専門知識だけでは不十分です。問題を深く理解できていたとしても、タスクに客観的に検証できる答えがない場合、AIは依然として苦戦しました。実装には「正解」があります。少なくともローカルなレベルでは。コードはコンパイルでき、テストは通り、出力はあなたが求めたものと一致します。設計には「正解」がありません。OOPが最初に勢いを得てから何十年も経った今でも、まだ議論が続いています。