https://go.dev/blog/ai-assisted-engineering
Google（Go の PM Cameron Balahan と Google Cloud の Richard Seroter）による、Go が AI 支援開発に向いている理由の解説。
前提: ボトルネックが「書く」から「レビューする」へ
- AI が数秒で大量のコードを生成するようになり、言語の「書きやすさ」の価値が下がった
- 代わりに効くのは、生成されたコードを読む・検証する・保守するコスト
- アーキテクチャ、サービス境界、本番の安全性・信頼性の設計は引き続き人間の仕事
- AI は「新しいチームメート」。チーム開発のための言語設計だった Go の思想がそのまま効いてくる
Go はプラットフォーム
gofmt、テスト、依存管理、セキュリティツールが最初から標準ツールチェーンに入っている- AI が検証なしにリファクタを繰り返すと誤りが累積し、context window も汚れて精度が落ちる
- ツールチェーンを検証ループのガードレールとして使える
- エコシステム全体が同じツールを使う → 学習データも標準化され、LLM が idiomatic な Go を出しやすい
可読性: 書きやすさより読みやすさ
- 「同じロジックの書き方が 12 通りある」言語だと、AI の出力は寄せ集めのスタイルになりレビューが苦行になる
gofmtによる単一フォーマットと、抽象化を意図的に絞った言語設計で誰が書いても同じ見た目になる- 存在しない API の呼び出し（ハルシネーション）やロジックの穴に気づきやすい
信頼性
- 静的型付け: 存在しないメソッド、型の不一致、未初期化変数はコンパイルが通らない
- Python のような動的型付けだと本番の特定条件下まで顕在化しない
- コンパイルが速い（Java / C# / Rust より桁違い）ので、AI が自己修正ループを高速に回せる
- 標準ライブラリが厚いので、AI が古い・未メンテ・悪意ある third-party を引っ張ってくるリスクが減る
- 外部依存が要る場合も checksum database と module mirror で完全性を担保
govulncheckは実際に呼んでいる関数の脆弱性だけを出すのでノイズが少ない- 標準の test / fuzz でエージェント自身が境界値バグを潰せる
保守性
- 互換性の約束: Go 1.0 のコードが最新ツールチェーンでそのまま動く。Go 2.0 は出さない
- 上げてリビルドするだけでランタイムの改善を享受できる
- 単一バイナリ＋クロスコンパイル。エージェントが各ターゲット向けにビルドしやすい
goplsと新しくなったgo fixの modernizer が、古い書き方を決定論的に最新の idiom へ更新する- プロファイリング / 実行トレース / PGO（profile-guided optimization）が標準搭載
- 本番のプロファイルをコンパイラに食わせて最適化する閉ループが組める
所感
「AI にコードを書かせるほど、言語選択の重要性は上がる」という主張が面白い。 生成が速くなったぶん、検証がボトルネックになるので、決定論的なガードレールを標準で持っている言語が強い、という話。