ハクソク

世界を動かす技術を、日本語で。

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

2026年2月8日原文(haskellforall.com)

概要

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のミニマップのように実装できるけど、ここでの正しい動きは、エージェントの出力を修正できるフックとして実装することだと思う。そうすれば、特に名前を読まなくてもコードの構造を見られるようになるよ。

Hacker Newsで議論の続きを見る