"Learning Software Architecture" というタイトルの記事から。 ・ソフトウェア設計は、実際のプロジェクトを通じて実践で学ぶのが一番 ・プログラミングにおいてコード以上に重要なのはアーキテクチャ ・アーキテクチャ以上に重要なのは組織の社会的な問題 ・科学（研究に近い）向けのコードが産業界のコードと異なるのは、開発者の知識の差ではない ・これは、3ヶ月後に論文を出す、といったインセンティブ構造の違いによる ・プロジェクトのインセンティブ構造自体を設計できる機会は稀だが、できれば非常に効果的になる ・構造を変えられない場合は、諦めて制約の中で最善を尽くすしかない ・筆者は rust-analyzer の開発において、コントリビューターの層に合わせたアーキテクチャを採用した ・中核部分には優秀な開発者を惹きつけるため、依存関係を減らしてビルドを徹底的に高速化 ・周辺機能には週末だけプログラミングできる層を集めるため、各機能を完全に独立させた ・周辺機能の品質基準も正常系が動けばOKとして、クラッシュが全体に波及しない仕組みを作っておいた （つまり、コントリビューターが取り組みやすい構造を設計に取り入れて、社会構造に対応しようとした） ・ただ、適応を優先して実験的に作ったコードが、そのまま本番運用され続けるリスクもあるが ・なお、ソフトウェア設計の真理が1冊にまとまった本は存在しない ・それでも、おすすめの書籍や講演はいくつかある ・APoSDとか、Software Engineering at Googleとか

✍️ AIが秒間何百行もコードを書ける今、開発者の仕事は「書く」から「読んで検証する」へ変わりました。だとすれば、言語選択の基準も変わるはずです。 Why Go is an Ideal Language for AI-Assisted Software Engineering 🔍 概要 GoogleのGoチームが発表した「AI補助開発時代の言語選択論」。コード生成のボトルネックが「書くこと」から「レビュー・検証すること」に移った今、読みやすさと保守性を軸に設計されたGoがいかに理想的かを論じています。 ⚠️ 解決する課題 ・LLMは型の不一致や存在しないプロパティを頻繁に生成する ・動的型付け言語（Python等）では型エラーが実行時まで検出されない ・AI生成コードが古いパッケージや脆弱な依存関係を参照するリスクがある ・繰り返しリファクタリングで精度が劣化する（初回約95%→低下） 🛠 Goのアプローチ ・gofmtによる完全自動フォーマット：AI生成コードの構文が常に予測可能 ・静的型付け＋高速コンパイル：Java/C#/Rustより桁違いに速くエラーを弾く ・govulncheck：呼び出されるシンボルだけを対象とした低ノイズ脆弱性スキャン ・ネイティブファズテスト：境界条件バグを継続的に発見 ・15年間の完全後方互換：Go 1.0のコードが今も無修正で動作 📌 逆説的な結論 「開発者が書くコードが減るほど、言語選択はより重要になる。」AIの大量出力を安全に吸収するには、決定論的なガードレールを持つ言語基盤が必要。Goはそのために設計されていた。 #Go言語# #AIエンジニアリング#