AIコーディングの原則
AIコーディングツールを使い始めて、しばらく経った。進歩は目覚ましく、便利だし役に立つ。一方で、OSS界隈ではAI Slop (AIが生成する低品質なコードやテキスト) が問題になっている。個人なら自分で気づいて直せるが、チームでは人数分だけ増幅される。誰かが流したSlopのレビューとリワークにチーム全体が巻き込まれ、AIコーディングのメリットを上回る生産性の低下を招く。この記事では、チームでその罠に落ちないための原則を定義する。 コードのオーナーは人間であり、責任を取るのも人間 LLMがコードを生成しても、そのコミットに名前が刻まれるのは人間で、深夜に障害対応で呼び出されるのも人間。「AIが書いたから」は通用しない。AIは7〜8割のコードを書けるが、プロダクション品質に仕上げるのはまだ人間の仕事だ。 コンテキストの共有とドキュメント 良いコードにはコンテキストの共有が要る。なぜその設計を
まだAIコードをレビューするか、しないかで言い争ってるの？
AIが生成したコードをレビューするべきかどうか、という議論は定期的に起こります。 3カ月以上その問題に悩んでいる人は、たぶんとっくに何らかの結論に達していると思います。 2026.03.08 改修メモ レビュー0に拘り過ぎているように読めたので、表現を全体的に柔らかくしました。 私の結論 品質を維持したままコードレビューを減らせるよう、開発プロセス全体を改善する必要がある これは、すでにレビューしなくて済むようになったとか、レビューを0にしなくてはならないという話ではありません。品質を保ったまま、大幅にコードレビューを削減し続けなければならないという話です。 これは、少なくとも次の3つの確定的な事実に基づいています。 今後コードレビュワーは育てられない AIはレビュワーを物量でひき殺す 今のままのレビューを人が続ける組織は、コードレビューを軽量化した組織に淘汰される そのために必要なことも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - ubugeeei/fwgsl: [WIP] A pure functional language that compiles to WGSL (WebGPU Shading Language).
海底撈火鍋 新宿店【公式】
