AIコーディングツールを毎日使っている開発者たちは、実際にどんな一日を過ごしているのでしょうか。
海外のプログラマーコミュニティ（Reddit）で、この問いに対する生々しい声が集まりました。
本記事では、その議論から見えてきた開発者の新しい働き方を紹介します。
「AIエージェントマネージャー」という新しい役割
複数の開発者が口を揃えて語るのは、自分たちの役割が根本的に変わったという実感です。
ある開発者は「3〜4つのClaude Codeセッションを同時に立ち上げ、それぞれに指示を出しながら管理している」と述べています。
もはやキーボードでコードを打つことはほとんどありません。
音声入力ツールを使って各セッションに話しかけるだけです。
コードを書く人から、AIを管理する人へと変わったといいます。
別の開発者はこう表現しました。
朝起きたら、その日の3〜4つのタスクを取り出す。 それぞれ別のClaude Codeセッションで処理を開始する。 良いプロンプトを書くのに30〜45分。 その後1〜2時間で検証とデプロイを行う。 昼には1日分の仕事が終わっている
以前なら1つのタスクに1日以上かかっていました。
それが午前中に3〜4つ完了します。
午後は翌日のタスクについて考える時間に充てられるようになったそうです。
タイピングが新しいボトルネックになった
興味深いのは、タイピングそのものがボトルネックになっているという声です。
音声入力ツールへの移行を勧める意見が多く見られました。
Wispr FlowやSuperwhisperといったツールを使います。
考えていることをそのまま話します。
それがプロンプトに変換されます。
ある開発者はこう語っています。
自分のボトルネックは2つあった。 コードレビューとタイピングだ。 音声入力でタイピングのボトルネックは解消された。 残るはコードレビューと設計判断による疲労だけ
Superwhisperのカスタムモードについて言及する声もありました。
「ぐちゃぐちゃな話し方でも、意図を汲み取って構造化されたプロンプトに変換してくれる」とのことです。
プロンプトは同僚に話しかけるように
効果的なプロンプトの書き方についても、具体的な知見が共有されていました。
あるベテラン開発者は、仕様書のような堅い文章ではなく、同僚に話しかけるようにプロンプトを書くといいます。
たとえばこんな具合です。
おはよう、クローディアス！ 最近の素晴らしい成果に感謝している。 今日はユーザー向けのSSOとMFA実装について探っていきたい。 正直どの方法がベストか分からない。 だから君の専門知識を頼りにしたい。 StytchとWorkOSで迷っているが、WorkOSのAuthKitが魅力的だと感じている。 必要なら別のプロバイダーを組み合わせてもいい。 新年にリリースしたいから、シンプルに、ユーザーの利益を第一に考えてほしい
このような会話調のプロンプトを「プランモード」で実行します。
するとAIはモノレポを探索します。
WorkOSと統合するAPIエンドポイントの計画を立てます。
いくつかの質問を投げかけます。
データベース更新のコードまで書き上げます。
そしてなぜStytchではなくWorkOSを選んだのかまで説明してくれるのです。
ポイントは、具体的な実装方法ではなくゴールを伝えること。
人間と同じで、細かく指示されすぎると混乱するというわけです。
AIに反論させる設定
Claude AIはデフォルトだと同意しがちな傾向があります。
これに対処するため、システムプロンプトに工夫を加える開発者が多いようです。
たとえば次のような設定を与えます。
あなたはエリートのスタッフソフトウェアエンジニアで、ソフトウェアアーキテクチャと開発に関する深い知識を持っている
こうすると、単に同意するのではなく、間違いを指摘してくれるようになります。
実際にある開発者は「プロンプトを渡したとき、『待って、その考え方は間違っているかもしれない』と言われた。
そしてAIの指摘が正しかった」という経験を語っています。
もう一つの工夫として、カスタムスラッシュコマンドがあります。
「/verify」というコマンドを作成します。
AIに自分のプロンプトの意図を復唱させます。
前提条件と確認質問を出力させます。
これでロジックの誤りを事前に発見できるのです。
それでも手を動かすべき領域
AIがすべてを置き換えるわけではありません。
いくつかの領域では依然として人間の判断が不可欠だという意見も目立ちました。
ある開発者はこう指摘しています。
コードは以前からボトルネックではなかった。 ほとんどの時間は計画、調査、他人のコードを理解することに費やされる
AIは確かに役立ちます。
しかし知識のカットオフがあります。
古いライブラリや非推奨のAPIを平気で提案してくることもあります。
結局、コードを書く時間がプロンプトを書く時間に置き換わっただけという側面もあるのです。
テストについては「絶対にAIに書かせない」という強い意見がありました。
テストはAIを含む誰もがコードを自由に変更できるための安全網だからです。
真のテスト駆動開発を行います。
テストで振る舞いをエンコードします。
カバレッジを常に100%に保ちます。
そうすればAIをペアプログラミングのパートナーとして使いながら、出力を一緒にレビューできます。
コードレビューの負担増加
生産性が上がる一方で、コードレビューの負担が増えたという声も多くありました。
「マージリクエストのレビューに多くの時間を取られる。自分が書きたいと思うコードになるまでマージを許可しない」と語る開発者がいます。
開発中はヒューマンインザループとしてAIの動きに関与し続けます。
すべてのコードはAIが書きますが、監視は欠かしません。
Metaで働く開発者の声も興味深いものでした。
社内でClaude Codeへの無制限アクセスがあり、内部ドキュメントとも連携している。 大規模コードベースでの作業能力は驚くほど高い。 一方で、基本的な問題に対して複雑怪奇なアプローチを自信満々に提案してくることがある。 常にダブルチェックが必要だ
そして正直な悩みも共有されていました。
「手作業で直した方が早いのに、自分でやる気が起きなくなっている」
AIが真に輝く場面
一方で、AIが圧倒的に有効な領域も明確になっています。
まずコードレビューでの活用です。
「新しいチームメンバーとして、このコードを理解できるか？暗黙の知識に依存していないか？」
「シニアエンジニアとして、このソリューションについてどう思うか？」
といった質問をします。
するとリンターや静的解析ツールを超える有用な洞察が得られるとのことです。
大規模リファクタリングも得意分野です。
AIはパターンを認識する能力が高いのです。
複数ファイルに同じリファクタリングを適用する作業では、ビフォーアフターの例を1つ示します。
変更点を確認させます。
そしてファイルを次々と処理させます。
単純だが面倒な編集作業も任せられます。
「このリストをマッピングに変換して」
「ここのタプルをすべて配列に置き換えて」
といった指示には、例を1つ示すだけで対応してくれます。
正規表現を書いたりcoreutilsのチェーンを組んだりするより早いでしょう。
ジュニアエンジニアにも扱いやすい点も魅力です。
並列処理のワークフロー
同じリポジトリで複数のタスクを並列に進めたい場合、git worktreesを使うというテクニックが紹介されていました。
異なるリポジトリなら単純に別のターミナルを開けばいいでしょう。
同じリポジトリ内で並列処理する場合は、worktreesでブランチを分離します。
こうすればコンテキストのずれやファイル編集の競合を防げます。
「1つのリポジトリで1つのタスクが終わるのを待っていた。今は3つのリポジトリを同時に進めている。5倍の生産性が15倍になった」という声もありました。
まとめ
Redditでの議論を通じて見えてきたのは、開発者の仕事がコードを書くことからAIを管理することへと移行しているという現実です。
この変化には良い面と課題の両方があります。
午前中に1日分の作業を終えられるようになりました。
一方でコードレビューの負担は増加しています。
タイピングがボトルネックになるほど生産性が上がりました。
もう一方で手作業をする気力が失われるという副作用も報告されています。
40年のキャリアを持つ開発者の言葉が印象的です。
「Opus 4.5が転換点だった。私より上手にコードを書く」
AIツールへの依存にはリスクもあります。
ある開発者は警告しています。
「コーディングにAIを頼りすぎると、障害やツール禁止で使えなくなった瞬間に役立たずになる」
結局のところ、AIは道具にすぎません。
使いこなすには、何を任せて何を自分でやるかの判断力が問われます。
プロンプトエンジニアリング、並列処理、適切なコードレビュー。
これらの新しいスキルを身につけた開発者が、この変化の恩恵を最大限に受けています。
技術の変化は止められません。
問われているのは、その波にどう乗るかでしょう。
