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

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

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

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

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

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

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

すごく共感する。頭の中に何年もあったプロジェクトを、最近やっと約6週間で作り上げたんだ。正直、AIの部分はそんなに難しくなかった。結局、アーキテクチャを考えすぎずに実際に形にすることが大事だった。ツールのおかげで、スピード感を持って進められたから、いつもみたいに途中で放り出すこともなかった。

これが一番難しい時期だと思う。ここ1年はそんな感じだった。先月やったことの多くは、6ヶ月前には完全にSFだった。可能性の範囲と質が数週間ごとに飛躍的に進化している。今は、使ったことのない言語でいくつかのプロジェクトを進めている。Rustでサイドプロジェクトをやっていて、Goのプロジェクトが2つある。JavaやKotlin（ここ10年）でのバックエンド開発の経験は数十年あるし、時々Pythonも使ってる。他の言語でも限られた経験がある。バックエンドプロジェクトの構造や、何を見て、何をテストする必要があるかは分かっている。多くの人は、AIが生成するものはすべてレビューする必要があると言うけど、それは非常に理にかなっている。ただ、今はAIが生成するコードの方が、私がレビューするよりも早い。私たちのレビュー能力がボトルネックになっている。で、何かがうまく動いているとき（手動と自動テストで証明されている）、どのタイミングで「十分だ」と言えばいいのか？簡単な答えはないけど、適切なレベルのデューデリジェンスについて考える必要がある。バイブコーディングは、基本的に何かを壁に投げてみて、くっつくかどうかを見るのと同じ。エージェンティックエンジニアリングはその逆側にある。私は実際に、プロンプトで多くの品質属性を強調している。良いデザイン、高い凝集性、低い結合、SOLID原則などの重要性をね。そういう視点でリファクタリングを求めると、良い機会がいくつか得られる。あとは「いい感じ、やろう」と言えばいいだけ。こういうふざけたプロンプトのバリエーションをやるのがちょっと楽しい。「そうなるように」ってのが一番好き。良い計画があれば、何をタイプしてもあまり関係ない。エッジケースや、ハッピーパス以外のテスト、堅牢性、同時実行性、レイテンシ、スループットなどについても重要な質問をする。そうしないと、AIはショートカットを取ったり、ハッピーパスだけに焦点を当てたり、すべてが大丈夫だと妄想したりすることがある。でも、これを見つけるために詳細なレビューが必要なわけではない。AIにコードをレビューさせて、何が間違っているか、改善できることの詳細なリストを作らせることができる。何か見つかるものがあれば、正しくプロンプトすれば見つけてくれる。これにはアートがあると思う。でも、これもあまり労力を要しなくなると思う。多くのことは、うまくいかないことを正しく行うための進化したガードレールに集約される。もしAIがデフォルトでこれらのことを正しくやり始めたらどうなるんだろう？どんどん良くなっていくと思う。

テストは似たような偽の安心感を生み出した。500以上のテストがあると安心感があったし、AIのおかげでさらに生成するのも簡単だった。でも、人間もAIも未来に遭遇するすべてのエッジケースを予見するほどクリエイティブではない。バイブコーディングのフェーズでは、テストケースを考えたときに、あるコンポーネントの設計が完全に間違っていて、完全に再設計する必要があることに気づいたことが何度もあった。これが、私の信頼の欠如と全てを捨ててゼロからやり直す決断の大きな要因だった。これが私の経験だ。テストはAIと作業する上で最も難しい部分かもしれない。特にひどいのは、最初からテストがない既存のクソコードをリファクタリングすることで、その機能が混乱していたり、他の場所で不適切に使われていたりすることだ。AIは、論理が動作することを確認するテストケースは書くけど（それはいい）、統合テストでカバーされるべき動作は全くカバーされていない。これについてはまだ良い答えがない、特にReactアプリでの経験が最も痛かったから、テストのベストプラクティスが分からない。でも、行動駆動開発と仕様駆動開発（AI）を組み合わせることがここでの潜在的な答えだと考えている。良いテストを生成するためのアプローチやフレームワークを持っている人がいれば、興味がある。

彼がRustを選んだとき、SQLiteのポートを調べることもできたし、libsqliteはかなり良い仕事をしているよ。