世界を動かす技術を、日本語で。

8年間の願望、3ヶ月のAIによる構築

2026年4月5日原文(lalitm.com)

概要

  • SQLite 向けの高品質な 開発ツール を長年求めていた背景
  • AIコーディングエージェント による開発体験の詳細な分析
  • syntAqlite という新ツールの開発と公開までの経緯
  • AIが 役立った点問題点 の両面からの評価
  • オープンソース活動と 個人モチベーション の変遷

SQLite開発ツールへの長年の渇望

  • SQLite は業界で非常に重要なデータベースエンジン
  • 高品質な 開発者向けツール が不足している現状への疑問
  • 他の OSSツール は信頼性・速度・柔軟性で不十分
  • PerfettoSQL のメンテナンス経験からツールの必要性を痛感
  • オープンソース活動への情熱と 個人の自由 を求める動機

開発の困難さと躊躇の理由

  • SQLite の言語仕様は複雑かつ公式仕様が存在しない
  • パーサーの正確性がツール全体の質を左右
  • SQLite本体の C言語による高密度な実装 の理解が困難
  • 400以上の 文法規則 の抽出・テスト・デバッグの煩雑さ
  • サイドプロジェクトとしては 難易度・作業量・リスク が高い

syntaqlite開発とAI活用の実態

  • 2025年以降、 AIコーディングエージェント の品質向上を実感
  • Claude Code を中心に設計・実装をAIに大幅委譲
  • 初期バージョンは スパゲッティコード 化し、全面的な書き直しを決断
  • Rust への全面移行と設計・品質管理の徹底
  • AIは「 標準的なコード生成」には強いが、独自設計部分は手動で補完

AIがもたらした変化と学び

  • 着手の心理的ハードル を大幅に低減
  • コード生成・リファクタリングの 圧倒的な効率化
  • リサーチアシスタント として新技術習得や知識の補完に有効
  • AI生成コードの 継続的なリファクタリング の重要性を痛感
  • 味のある設計」や大規模な抽象化は人間の役割

AI活用の課題と今後の展望

  • AIによる コードの標準化 がプロジェクト独自性に悪影響を及ぼす場合あり
  • リファクタリングの怠慢 が技術的負債を生むリスク
  • AIによる知識補完と 学習曲線の短縮 は大きなメリット
  • 今後も AIと人間の協調 による開発スタイルの進化が期待される

Hackerたちの意見

これには納得だな。250時間もかけたっていうのがすごい!自分がやった小さなプロジェクトを考えると、これはAIを使ったシステムプログラミングの大きなプロジェクトのいいモデルだと思う。

これ、めっちゃ自分の経験に近いわ。結論にも同意するし、もっとこういうのを見たいね。

AIコーディングについての正直でバランスの取れた意見を見るのは新鮮だね。これが本当のAI支援のコーディングだと思う。最初の「すごい!」っていう感覚を超えたら、実際にAIが書いたコードを見てどうなるかっていう経験は、AIコード生成を使って出力をレビューした真剣なソフトウェアエンジニアには共通してる。

「でも、1月末にコードベースを詳しく見たとき、欠点は明らかだった。コードベースは完全にスパゲッティ状態だった。Pythonのソース抽出パイプラインの大部分が理解できなかったし、関数はランダムなファイルに散らばっていて形がなかった。いくつかのファイルは数千行にもなっていた。非常に脆弱で、即時の問題は解決したけど、自分の大きなビジョンには対応できなかった。」 一部の人はコードをレビューするところまで行かずに、すぐにLinkedInやブログに行って、手動コーディングが死んだとか、もう手でコードを書くことはないって投稿する。コードをレビューして使えないゴミだと宣言する人もいて、その後ソーシャルメディアでAIコーディングが完全に無駄だって言って、何にも使わないって投稿する。このブログ記事は、そういう声の大きい少数派に入ってない人たちが今経験している旅を示している。AIコーディングツールが大きな加速剤になり得るけど、正しく使う方法を学ぶ必要があるし、コードに関与し続ける必要があるって気づくこと。いつも投稿される極端な意見ほどクリックベイトじゃない。ハードワークがまだ必要だって言ってる部分を読むのはちょっと残念だったけど、AIコーディングの現状については現実的でバランスの取れた見方だと思う。

そういう極端な意見は、ほとんどがクリックを狙ったものか、誇張された二次情報だから、「反対派」の意見が実際よりもバカに見えるようにしてる。ほとんどの人はすべてに対して「まあまあ」って感じで、極端な意見にはいないから、彼らに迎合するために極端な意見を嘲笑して、よりありそうに見せる。これはただのオンラインポピュリズムだよ。

同意する。これは本当にバランスの取れた良い記事だね。プロのソフトウェア開発にこの洞察を適用するのが難しい理由は、これがグリーンフィールドの作業で、ソロプロジェクトだったから。でも、それは著者のせいじゃない。もっと多くの人が関わるブラウンフィールドプロジェクトでAIツールをフル活用する方法についての記事が見られたら素晴らしいと思う。ひとつ付け加えたいのは、こういうプロジェクトで雰囲気でコーディングしたスパゲッティのようなものを作るのが間違っているとは思わない…それを学ぶためのプロトタイプとして見る限りはね。使い捨てのプロトタイプは非常に役立つ。最初に何を作りたいかを理解するのに役立つから、その後、実際にそれを作るためにエージェントをしっかりガイドする段階に進む前に。著者のミスは、ひどいプロトタイプが本物に進化すると思ったことだと思う。もちろん、そんなことは無理だったけど、著者が新たに始めてアーキテクチャにもっと注意を払って作り始めたときの最終結果は、最初の試みから何を作りたいかの要件について学んだ分、ずっと良かったんじゃないかな。

すごく的確で共感できる投稿だね。反AI派にとって重要な点は、このプロジェクトは、たとえちょっとスパゲッティ状態になっても、AIなしでゼロから全てを作るよりも、完璧にするのにかかる時間が桁違いに少ないってこと。AIを使ったプロジェクトに対する批判をよく見るけど、コードベースが時間の中で固定されていると思っている人が多いんだよね。でも実際には、人間はAIを使ってどんどん改善していける。AIなしのプロジェクトが0.1.0で完璧になるとは期待しないのに、なんでAIにはそれを期待するの?マーケティングやTwitter、LinkedInのゴタゴタがそういう主張をするのは分かるけど、ハイプを超えて、これらのツールをどう使うかを探る方が有意義だと思う。

最近、HNではこういう意見が増えてきて、過激なクリックベイト的なものが少し減ってきた気がする。もしかしたら成熟の兆しかもね。(それとも、最新モデルのハイプに疲れてきたのかも?)

+1 この3ヶ月、仕事でClaudeをメインのコーディングインターフェースとして使ってる。違うドメインを除けば、この投稿をそのまま書けたかもしれない。今やってるプロジェクトは、最初は雰囲気でコーディングしたプロトタイプから、すぐに販売用のプロダクションサービスに昇格した。後からメンタルモデルを構築しながら、無駄なコードや死んだコードをリファクタリングして大きく削除していった。でも、そのクイックで雑なプロトタイプがなければ、今の製品は存在しなかったし、Claudeを使ってチェンソーのように整理できた。金曜日には、やっと型チェッカーのプリコミットフックを追加して、90個の既存のエラーを約2時間で修正したよ(ちゃんと、型の無視はなしで)。最初はフルエージェンティックでやってみたけど、うまくいかなかった。それからClaudeと一緒にエラーを一つずつ見て、いくつかの型を厳密にし、クランキーな抽象を修正して、いい感じのクリーンな結果が得られた。AIを使ったコーディングは素晴らしいけど、個人的にはプロダクションコードには人間のレビューとガイダンスが欠かせないと思う。

ある人たちは、コードをレビューするところまで行かない。すぐにLinkedInやブログに行って、手動コーディングが死んだとか、もう手でコードを書くのは終わりだといった投稿を書き始める。別の人たちはコードをレビューして、使えないゴミだと宣言して、やっぱりSNSに行ってAIコーディングが完全に無駄だと投稿する。このブログ記事は、そういう声の大きい少数派に入っていない人たちが今経験している旅を示している。本当に起こっているのは、最初はみんなそういう人たちなんだ。そういう人たちは、経験を通じてあなた自身でもある。最初は不可能をやってのけるのを見てワクワクし、後にはその不完全さに批判的になる。これは悲しみの段階のようで、AIに対するクーブラー・ロスモデルみたいなものだ。

ありがとう。AIが何かに取り組む様子を読むのは学びがあって楽しい。自分がまだよく分からないことに取り組むのへのためらいも減るしね。雰囲気でコーディングして「無駄にした」時間は、頭を突っ込んで手動コーディングして「無駄にした」時間よりも痛みが少ない感じがする。

アーキテクチャとは、すべてのローカルな要素が相互作用することで起こるもので、ローカルに正しいコンポーネントをつなぎ合わせても良いグローバルな挙動は得られない。 この記事は素晴らしいね。レイヤードAIの使い方がこのギャップを埋める方法を探ってるんだけど、現在のモデルはあいまいなデザインフェーズが不足しているように思う。ローカル実行フェーズでは素晴らしいんだけど。ソフトウェアエンジニアリング全体の反映だと思う部分もある。ほとんどの人はデザインが苦手だし、繰り返しと経験でみんな上達する。でも、正解がなくてトレードオフのスペクトラムしかないから、現在のモデルがその人間のプロセスの部分を再現するのは難しいみたい。

長期的には、AIが私たちに提供する最も価値のあるものは、理解を深めるための強力なツールだと思う。LLMの出力目標が深い理解に変わるのを見られると思う。例えば、このプロジェクトのブロッカーは400のルールが詰まった密なCコードだった。LLMを使うことで構造と理解を解析してツールを作ることができたけど、もっと役立つ出力はルールとその相互作用の完全なドキュメントかもしれない。新しいコードからは今、もっと簡単に抽出できるだろうけど、APIドキュメントや論理ルールセットのマッピングにコメントを織り交ぜたものを想像してみて。その他の開発ツールも簡単に作れるし、コードとは独立してルールの構造に対するバグ分析もできるし、アーキテクチャレベルでの最適化も可能になる。LLMは何を作るかを知るために人間が必要だよ。コード生成が簡単になると、柔軟なコンテキストや理解を定義することが、努力なしで生成できるものを増幅する目標になる。

Hacker Newsで議論の続きを見る