エージェンティックコーディングを超えて

概要

Agentic coding は生産性向上に寄与せず、コードベースへの親しみや快適さを損なうという批判がある。 Calm technology の原則を活かしたAI支援ツールが、開発者のフロー状態維持に効果的。既存の例（インレイヒントやファイルツリープレビュー）は「穏やかな」デザインの好例。 GitHub Copilot などのAIツールでも一部はcalm designに近づいているが、課題も残る。今後は、 流れを妨げないAI支援機能 の設計が重要課題。

エージェンティックコーディングの課題

Agentic coding ツールは、開発者の生産性やコード理解を向上させない現状
個人経験 ：実際に使っても結果に満足できず、品質が低い印象
面接時の観察 ：Agentic coding利用者は課題未達や誤答が多く、期待に反してパフォーマンスが低下
研究結果 ：BeckerやShenの研究でも、成果物ベースの生産性は向上せず、時に悪化
現状のAgentic coding がソフトウェア開発に悪影響を及ぼす可能性
今後の課題 ：開発者の力を引き出し、コード品質向上に繋がるAI支援の模索が必要

Calm Technologyの観点と開発ツール

Calm technology ：ユーザーのフロー状態を保つための設計思想
主な原則 ：
- ユーザーの注意を最小限しか奪わない設計
- 「パススルー」性：ツール自体よりも本来の作業対象に意識が向く
- 穏やかさを生み出し、維持する機能
開発現場の例 ：
- インレイヒント （例：VSCodeの型注釈）は周辺的・非侵襲的な情報提供
- ファイルツリープレビュー （例：VSCode、GitHub PRビューア）は、必要な時だけ意識に上るパッシブな情報提示

チャット型Agentic codingツールの問題点

注意力の要求が大きい ：ユーザーはエージェントの返答を待つか、断続的に作業を中断
「パススルー」性の欠如 ：ツールとコードの間に一層の媒介が生まれ、操作が間接的・不明瞭になる
穏やかさの欠如 ：情報更新や理解のために常に能動的な操作が必要

Calm designに近いAIツールの事例

GitHub Copilotのインラインサジェスト ：
- コードへの直接的な提案で「パススルー」性は高い
- しかしデフォルトでは頻繁な提案で注意を奪い、フローを妨げることも
- 自動提案をオフにし、明示的なトリガー（Alt+\）でのみ表示すれば改善可能
Next edit suggestions（Copilotの次編集提案） ：
- 編集候補がファイル全体に点在し、ユーザーは必要に応じて選択可能
- 認知負荷が低く、注意の周辺で穏やかに存在
- コードとの直接的なやりとりを維持し、フロー状態を妨げにくい

AI支援Calm Technologyの新しい可能性

ファセットベースのプロジェクトナビゲーション ：
- 意図や目的別にプロジェクトを俯瞰できるツリー表示
- 使うほどにプロジェクト理解が深まる設計
自動コミットリファクタ ：
- 編集やPRを意味ごとに細かく分割し、レビュー負担を軽減
- 人的レビュー労力の削減
ファイルレンズ機能 ：
- 「Focus on…」で関心領域のみ表示、「Edit as…」で他言語・他フォーマットとして編集
- 関連ファイルや行だけを見せる「Zen mode」の機能拡張

まとめ

Agentic coding の現状には課題が多く、開発者体験や生産性向上には直結しない
Calm technology の設計原則を取り入れたAI支援ツールが、開発現場の本質的な課題解決に寄与
今後は、 フロー状態維持・注意の負担軽減・穏やかな支援 を重視したAIツール設計が重要
積極的な課題提起と新しい発想によるツール開発の必要性

Hackerたちの意見

この投稿はHaskellとは関係ないから、タイトルがちょっと誤解を招くね。でも、記事の内容は良かったし、実際にエージェント的なAIコーディングはこう進化するんじゃないかなと思ってる。今のツールはAI支援コーディングの始まりみたいなもので、MS-DOS時代みたいな感じ。時間が経つにつれて、「自分の得意な言語」から「ターゲット言語」へのバックプロパゲーションが一般的になるかもしれないね。

└

プログラミング言語は、今後10年間のコンピュータサイエンスで最も面白い分野だと思う。AIは、偽造できない正確性の基準が必要だから、証明検証とプログラムの境界がどんどん曖昧になっていくんじゃないかな。ランタイムも、人間には全く必要ない方法で、大規模な並列開発をサポートする必要がある。

└

この投稿はHaskellとは関係ないから、タイトルがちょっと誤解を招くね。公平に言うと、それは記事のタイトルじゃなくて、記事が投稿されたウェブサイトのタイトルなんだけどね。

└

たまにはAIに関係ない記事がこのサイトにあるのが嬉しかったな。まあ、良い記事だったけどね。

└

同意。この記事は各ページのdocument.titleにブログ名を付け加えてるみたい。モデレーターの誰かがそれを取り除くべきだと思う。

└

記事は良いの？意外と質が低いと感じたんだけど、私の評価は間違ってるのかな？要するに、今のAIの重要性を人々に納得させようとする記事なんだけど、私は全然そうは思わないし、説得力のある「主張」は一つも見つからなかった。

└

同意。FAの要点は「落ち着いた技術」についてだね。タイトルはそれをもっと反映すべきだと思う。著者が言ってることには全部同意するよ。すべての例に証明はできないけど、UIが何かは分かる。著者は注意の焦点の中心について言及してるけど、私たちは注意の周辺についてもっと聞くべきだと思う。その帯域幅は中心に比べてかなり低いけど、まだ存在していて、流れに対する決定をかなり控えめに導くことができる。（大きな）目の動きは注意を妨げるもので、注意自体は商品として扱われるべきだと思う（何千人も使うUIの場合は、むしろ借り物のように）。

最近、AIを使って私たちをサポートし、重要なことをやる力を与えることにもっと焦点を当てるべきだと感じてる。奪うんじゃなくて、退屈なクリアボイラープレートは強化するけど、デザインの決定はしない。レビューを簡単にするのは、私たちのワークフローを強化する完璧な例だよ。レビューをしてもらうんじゃなくて、私たちをサポートしてくれる感じ。最近、この小さなスキルを使ってPRのレビュー方法を生成してるんだけど、すごく役立ってるよ。 https://www.dev-log.me/pr_review_navigator_for_claude/

待機時間や流れを壊す問題は、遅さの影響なんじゃないかなと思う。これをテストするのは簡単で、今は超高速の1000トークン/秒のプロバイダーがあるからね。（Cerebrasのコーディングプランが売り切れないのを待ってる ;) 小さなタスク（ちょっとした編集）には使ったことがあって、「リアルタイム」な部分は質的な違いをもたらすよ。非同期からインタラクティブに変わるんだ。量の十分な変化が質の位相変化を生む。とはいえ、エージェント的なものの主な問題は、私のメンタルモデルが同期しなくなることだね。モデルがどんなに速くなっても、私が追いついて理解するのには固定の時間がかかる。同期を保つために一番楽しめる方法は、自分が運転席にいて、たくさんの小さな迅速な編集を手動でコマンドすることだよ。（つまり、自分専用の「エージェント」を作って、プロンプトを出して、提案された編集を受け入れるか編集して、繰り返すって感じ。）だから、メンタル状態の「同期」は常に行われていて、非同期になる機会がないんだ。自分が運転してるからね。このアプローチをセミオート、またはパワーコーディングって呼んでるよ（手動で扱うけど、速度と力を大幅に向上させるパワーアーマーに似てる）。

└

コードレビューやチームメイトとの同期も必要だから、チームでの協力がうまくいくかどうかが、ある時点で制限要因になるんじゃないかな。

└

とはいえ、エージェントを使うときの主な問題は、俺のメンタルモデルがずれてしまうことなんだ。モデルがどんなに速くなっても、俺が追いついて理解するのには固定の時間がかかる。だから、同時に6つ以上のClaudeセッションを運用している人には懐疑的なんだ。俺は5つまで行ったけど、それは3つのセッションで、2つはただのバックアップだったから。3つのセッションでも、常にどこにいるかわからなくなって、再調整に時間を無駄にしてしまったり、間違ったセッションで作業したりしてた。 > 同期を保つのに一番楽しい方法は、運転席にいることだと思う。手動で小さな素早い編集を命令するのがいい。そうそう、一つのセッションで機能をどんどん片付けていくと、素晴らしいフロー状態や勢いが得られるんだ。この状態で2つのセッションを行き来するのは気にならないけど、同じプロジェクトの異なる機能よりも、異なるプロジェクトの方が体験は良いよ。完全なコンテキストスイッチがあれば、再調整もしやすいしね。

各関数名に特定の色を付けて、各変数の型にも色を付け、その後にシンボル名やキーワードのハッシュから派生した色を付けることを考えてるんだ。それぞれの型に特有の色を持たせて、コードを印刷可能なマトリックス「ローLOD」や「ミップマップ」形式に変換する感じ。これをVSCodeのミニマップのように実装できるけど、ここでの正しい動きは、エージェントの出力を修正できるフックとして実装することだと思う。そうすれば、特に名前を読まなくてもコードの構造を見られるようになるよ。

└

いいアイデアだね。「視覚タイプ」としては、これがもっと直感的に理解できると思う。GUIよりTUIの方がシンプルで、本質に集中できるから好きなんだ。TUIを強化するための簡単な手段だよ。

私が見つけたのは、チャットインターフェースを嫌う人のほとんどが、その強みを活かせていない使い方をしているってこと。最近まで、LLMは本当に使えなかった。タスクを設定しても、ほぼ正しいものを出すまで何時間も手取り足取り教えなきゃいけなかったんだ。今はチャットボットと会話して、デザインを練ったり、アイデアを出し合ったりして、作りたいものの具体的なイメージを固められるようになった。エージェントが理解できる形で計画をまとめられるから、そこからはエージェントを動かして、時々チェックして、何かが不十分で詰まってないか確認するだけ。とはいえ、このワークフローは、ジェミニよりもクロードの方がずっと良く機能すると思う。

私もチャットインターフェースの方が好き！インラインのAI提案は本当にイライラする。見ているテキストが動いちゃうからさ。

└

同感！まるで、60%の確率で間違ってる熱心な先生のペットにずっと叫ばれてる気分。IDE内でコードベースを検索できる機能はありがたいけど、必要なときにボタンを押したいんだよね。

「ファイルレンズ」の例が本当に好きだな。> 「Focus on…」は、ユーザーが変更したいことを指定できて、その関心に関連するファイルやコードの行だけを表示することができる。> 「Edit as…」は、ユーザーがファイルや選択したコードを別のプログラミング言語やファイル形式のように編集できるようにする。

エディターセッション、diff、またはプルリクエストを取って、自動的に人がレビューしやすいようにより焦点を絞ったコミットのシリーズに分割できる。これはAIが人間のレビュー作業を減らせる一例だと思う。もっと注目されるべきだと思う。AIコードレビューのスタートアップはほとんどが「ハンズオフ」のコードレビューをやってるだけ。エージェントがすべてをレビューするだけなんだ。人間が使いやすい「レビュー計画」をエージェントに作らせればいいじゃん。レビューを個別に（または独立して）レビューできる部分に分けて、コーディングエージェントが修正できるようにする。ファイルの適切な順序を持たせて（GitHubはコミット内のファイルをアルファベット順に表示するから最適じゃない）、簡単にユニットテストできる関数の実装みたいな退屈な詳細は隠しちゃえばいい。

└

ぜひそうしてほしい。AIを使わないのと似たような失敗パターンがあるケースがたくさんあって、それが役立つんだ。リスクが低いAIのアプリケーションは、リスクが高くなくても大きな成果を上げることができるよ。

└

残念ながら、GitHubではPRのコミットを簡単にレビューできないんだ。ファイルを選択的にレビューするのは簡単だけど、コメントはPRブランチの最新のHEADに適用されると考えられているんだ。これが、レビューエージェントがそのワークフローを使わない理由かもしれないね。ただ、リリースされたOpusやCodexにこれを指示するのはそんなに難しくないと思う。特に、人間かモデルを通じてPRプランを生成できるならね。

└

俺もこれやってるよ。例えば、先日構造体のフィールドをいくつか名前変更して、他を削除するコミットを作ったんだけど、それを2つの別々のコミットにした方がレビューしやすいことに気づいたんだ。でも、機械的に分けるのは難しかったから、Claudeに頼んで、最終的に古いものと一致し、両方ともテストに合格する2つの新しいコミットを作ってもらった。うまくいったよ。

└

なんでエージェントに人間が使える完璧な「レビュー計画」を作らせないの？レビューを個別に（または独立して）レビューできる部分に分けて、コーディングエージェントが修正できるようにするんだ。ファイルの順序を適切にして（GitHubはコミット内のファイルをアルファベット順に表示するから最適じゃない）、簡単にユニットテストできる関数の実装などの退屈な詳細は隠す。そうそう！これを使ってPRにコメントを作成して、提案されたレビュー順序や変更の関係を示す図を作ってるんだ。この超シンプルな追加が、今のところコードレビューにとても役立ってるよ！(詳しくはここ: https://www.dev-log.me/pr_review_navigator_for_claude/)

└

「メインにPRがあるから、これをいくつかのチャンクに分けて、各チャンクをレビューするためにバックグラウンドエージェントを派遣して、俺と一緒にチャンクを一つずつ進めて、各チャンクの間にフィードバックをもらうようにしてくれ」

└

この考え、いいね。レビューのスケーリングは確実にボトルネックだし（まだコードを読んでいる私たちにとって）、それを楽にするためにトークンを使うのは価値があると思う。

└

まさにその通り。既存のコードレビューツールは、コードの量が増えるにつれて不十分になってきたよね。もっと革新が必要だと思う。レビューを楽にするためのアイデアとして、ケント・ベックのSB Changesの概念に従ってコミットを再構築するのが思いつく。構造の変更（整理やリファクタリング）と振る舞いの変更（機能）を分ける感じで。構造の変更はすぐにざっと見れるようになるし（特にカバレッジが良ければ）、振る舞いの変更のレビューに集中できるはず。難しいのは、単にハンクを違う順番でコミットするのとは違うってこと。でも、基本的なエージェントループのスキルがあれば、今のモデルの能力と組み合わせてうまくいくかも。

└

昨年の5月から、AIにPRにコメントを追加させて、特に注意が必要な点に目を向けさせることについて話してるんだ。ほとんどのコードレビューツールがこれをやらないのは、A/Bテストでノイズの多いレビュー出力だと人が関与しにくくなることがわかってるからだと思う。

一般的には「穏やかなテクノロジー」の考えには賛成だけど、インレイヒントは悪い例だと思う。あれは逆に不安を感じさせるんだよね。コードが読みづらくなるし、注意がそれちゃうし、仮想キャラクターが邪魔してテキストを編集するのも awkward になる。タイプするたびに再レンダリングされてカーソルの位置がずれるし、全然リラックスできないよ、笑。

レビューの順序の問題は、AI生成よりもグラフのトラバーサルに関することだよね。すでにすべてのdiffは依存関係グラフ（インポート、関数呼び出し、型参照）をエンコードしているし、最適なレビュー順序は認知負荷で重み付けされたトポロジカルソートに過ぎない。GitHubのアルファベット順は、フルコールグラフがあるときには情報ゼロだよ。難しいのは、順序を生成することじゃなくて、コードが変わるにつれて依存関係グラフを効率的に抽出・維持することなんだ。

└

これを可視化するための拡張機能やサードパーティツールってある？

ハクソク