HNに聞く: AI支援コーディングはあなたの職業にどのように役立っていますか？

71日前

概要

AIツール を用いた プロフェッショナルなコーディング 体験談の共有
実際に役立った点 と 課題点 の両面を具体的に記載
プロジェクト内容 や チーム規模 などの文脈情報も明記
2026年3月時点 でのAI支援開発の実態把握が目的
誇張や悲観論を排除 し、現場視点での知見をまとめ

AIツールを使ったプロフェッショナル開発体験

使用AIツール： GitHub Copilot、 ChatGPT-4、 Amazon CodeWhisperer
プロジェクト内容： Webアプリケーション開発 （React/TypeScript + Node.js）、 API設計、 CI/CDパイプライン構築
チーム規模： 5名（シニア2名、ジュニア3名）、 リモートワーク主体
経験年数： 3～10年 の幅広いエンジニア構成

うまく機能した点

コード補完 や 定型処理の自動化 で 開発スピード向上
- 例：Reactコンポーネント雛形、バリデーションロジック、APIクライアント生成
既存コードのリファクタ提案 や バグの検出支援 で品質向上
- 例：ChatGPT-4で「このコードのバグを指摘して」と依頼→迅速な指摘
ドキュメント生成やユニットテスト作成 の効率化
- 例：Copilotでテストコード自動生成→手動修正で完成度アップ
新規技術スタック調査やエラー解決 の初動サポート
- 例：未知のnpmパッケージ利用時、ChatGPTで使い方や注意点を即座に確認

課題・限界とその対処

複雑なビジネスロジックや設計意図の理解不足
- CopilotやChatGPTは「文脈」を深く理解できず、 表面的なコード提案 に留まる傾向
- 対策： 要件や設計意図を明文化 し、AI利用は補助的に活用
セキュリティやパフォーマンスの考慮不足
- 例：SQLインジェクション対策漏れ、メモリ効率の悪いコード提案
- 対策： 人間によるレビューを必須化、AI生成コードは必ず検証
長文プロンプトや複雑な指示への対応力の限界
- 長い要件や複数条件が絡む場合、AI回答が曖昧になるケース
- 対策： 指示を細分化 し、段階的にAIへ質問
学習データの偏りによる非推奨パターンの生成
- 古いライブラリや非推奨APIの利用提案が稀に発生
- 対策： 公式ドキュメントとの突き合わせ を徹底

総合的な所感

AIツールは「作業効率化ツール」としては有用
- 単純作業や調査の初動、テスト作成の自動化などで 実用性が高い
設計・レビュー・意思決定は依然「人間主導」
- AIは万能ではなく、あくまで補助的存在
AI活用の成否は「使いどころ」と「人間の介在」に依存
- AIを過信せず、適切に使い分ける運用体制の重要性

まとめ：2026年3月時点のAI支援開発の実態

AIツールは現場で着実に定着 しつつある状況
単純・繰り返し作業の自動化 では大きな効果
複雑な設計や高度な判断は人間が担う必要性
AIと人間の協働がベストプラクティス
AI導入の成否は、現場のリテラシーと運用体制に左右

Hackerたちの意見

FAANGで働いてるんだけど、実際のところ、デザインドキュメントをまとめたり、コードの中で簡単な検索じゃ見つからないようなものを探す以外、ほとんど運がないんだ。チームのコードがXをやってるってのは分かるけど、まだうまくプロンプトを出して、動くコミットを得たことはない。あと、成功したICを個人的に知ってるわけでもないし。みんなが「今は10倍生産的だ！」とか「x, y, zをやるべき！」って言ってる投稿は無限にあるけど、正直、そういう人たちを知らないんだ。仕事以外では、小さなグリーンフィールドタスクに対してはすごくうまくいくし、10倍の改善を見たこともある。でも、仕事では今のところほぼゼロだね。職場で見た投稿は、大体新しいことをやってるチームかリファクタリングしてるチームだから、その結果には驚かないよ。

└

プロの環境で見つけた短所について、個人プロジェクトでは出てこないことを詳しく教えてもらえる？グリーンフィールドタスクを扱うっていうのは、たくさんのライブラリを使うときのボイラープレートコードやファイル構造の設定のことを指してるのかな？

└

わあ、私の経験とは全然違うね。どんなツールセットを使ってるのか聞いてもいい？自家製の「AcmeCode」に制限されてるの？それとも、Claude CodeやCursorの最新モデルにフルアクセスできるの？私は小さなタスクでも大きなタスクでも、生成されるPRの精度が50%から90%の間で変わるのを見てる。人間が調整できる50%の使えるコードから、90%のソリューション（たまに100%の「おお、実際にできた、コメントなし、マージしよう」ってのもある）まで。これもスキルセットだと思う。エンジニアによっては、自分の要望をうまく伝えられる人もいれば、コーディングしながら考えるのが得意な人もいる。

└

これには同意する。短いスクリプトやマスターしたもののグルーコードを書くのには問題がなかった。でも、実際に助けが必要なところでは、逆に遅くなってる気がする。

└

FAANGでもそう。会話から判断すると、同僚よりもツールを使ってると思う。最初の数回はAIツールを試したけど、かなりのヒットアンドミスだった。でも12月頃からツールがかなり改善されて、効果的になったよ。プロトタイプをすごく早く作れるようになった。チェックインの準備ができることは少ないけど、仮定やアイデアを検証できる。LLMがデザインしてたAPIの重要な欠陥を指摘してくれたこともあって、その後のプロセスに進む前に調整できた。計画が決まったら、エージェントコーダーを使って小さなCLを作るのが一番の方法だね。自分とレビュアーが理解できる以上の速さでコードを生成したくないから。遅く感じるかもしれないけど、チェックインは実際には早く進む。全てが魔法のようにうまくいくわけじゃないけど、AIに導かれて暗い道に入ったこともあった。あるデザインがうまくいくって言われたけど、実際には少し古かったり、作ってるシステムに合わなかったりする理由があったから。だから、10倍の効果があるとは言えないけど、自分一人でやるよりは確実に早く進んでる。ユーザーの専門知識はまだ重要だし、昔よくあった問題は、小さなリファクタリングをしてからテストを手動で直さなきゃいけないこと。LLMに「XをAからBに移動して、テストの失敗を直して」って頼む方がずっと簡単だよ。それから数分後に戻って、やったことを確認して問題を直す。もう一つは、私たちが依存しているインフラも含めて、広いコードベースの可視性があること。過去の四半期に外部チームによってビルドが壊れたことが数回あって、LLMにタイムフレームと問題の説明を与えたら、正確な外部の失敗を教えてくれた。もしそうじゃなかったら、問題を解決するのにどれくらい時間がかかったか分からない。テストで見逃された問題だったから。とはいえ、その壊れた部分がLLMの使用によって引き起こされたのかは疑問だ。最近、仕事がこんなに楽しいのは久しぶりで、これらのツールが自分の職業的安定にどう影響するのかちょっと不安だけど、今の時点でジーニーを瓶に戻す方法が分からない。

└

論理的にはその通りだね。FANGのコードベースはすごく大きくて、何年も前からのもので、オープンソースのフレームワークを使ってるわけじゃなくて、社内ライブラリやフレームワークを使ってるから、AnthropicやOpenAIには全く見えないんだよね。だから、これらは推論や思考をする機械じゃなくて、確率的な（画像/テキスト）生成器だから、見たことがないものは生成できないんだ。

└

こっちも同じ感じ。コードベースが大きすぎて複雑だから、正しいパターンを見つけるのが難しいんだよね。たまにはうまくいくけど、タスクが小さいほど良い感じ。

└

「まだうまくプロンプトできて、動くコミットを得たことがないんだけど、何を作ってるのか聞いてもいい？」

└

すごいことになってるね。こっちは逆の立場だよ。この2ヶ月で多分1万行の動くコードをプロンプトした。最初はテラフォームから始めたんだけど、これはもう完璧に理解してる。95%の確率でうまくいくし、どこで間違うかも分かってるから、その点に注意してる。（新しいプロジェクトや既存のリポジトリ、他のコラボレーターとも一緒に作業してる）次は大規模データ処理プロジェクトに移ったけど、これも順調で、小さなインデックスの問題を診断するためにシニアエンジニアが30秒で特定してくれた。（でも、何が分からないのか分からないこともあって、1週間も悩んでた）その間、同僚がデータのサンプルを欲しがってたから、それを作ったんだ。（解凍せずにzipから抽出）彼はランダム化されたものを一発で求めてきたから、すぐに完成。次は5つのカテゴリーでランダム化してほしいと言われて、さらにサンプルサイズを10倍にしてほしいって。データリクエストは変換が終わる前に完了したよ。以前ならそれに3時間かかってたし、技術的な限界にぶつかってたかも。モニタリングスタックも構築したし、サーバーを設定して、何十もの問題をトラブルシューティングするのに使った。できなかったことができるようになったし、難しかったことも簡単にできるようになった。簡単にできてたことは、今は速く簡単にできる。君の全然違う体験は本当に驚きだし、理解できないよ。（目を開かせてくれてありがとう）

└

実際にAIモデルにどうやってプロンプトを与えてるか、例を教えてくれない？みんなの体験の違いはプロンプトや期待に関係してる気がするんだよね。

└

FAANGのエンジニアではないけど、かなり大きな会社で働いていて、あなたの言ってることには1000%同意です。どれだけ多くの「コメントする人たち」が出てきて、あなたがxやyを間違ってるって言ってくるか、ほんとに狂ってる。彼らはそんな風に言わないかもしれないけど、「あなたのプロセスはどうなってるの？この製品を試したことある？」みたいな質問の形を使って、あなたの経験を完全に無視する微妙な方法をとってるんだよね。

仕事が本当に苦痛になってるし、個人プロジェクトの方が進むのが早い。職場では、上の開発者たちがAIを使って何でもやってる – コーディングだけじゃなくて – それで、私に整理させるんだ。コードベースがめちゃくちゃで、痛いし時間もかかる。一度、あるチームの機能をメインのコードベースに統合しなきゃいけなかったんだけど、その機能はAIでコーディングされてたから、メインプロジェクトのAPI設計に従ってなかった。しかも、最初の段階で必要ないエラーチェックや手作りのパース処理がたくさん含まれてて、それを整理するのに1週間以上かかった。元のチームがほぼ瞬時に作り出したのに対して、私がそれを直すのに時間がかかってしまったから、見栄えも悪くなった。AIツールはこういうデザインの整合性を取るのが苦手だから、初期のコンセプトをすぐに出すのは簡単だけど、生成した技術的負債を無視して大きなコードベースにうまくはめ込むのは無理なんだ。個人プロジェクトでは、他の人たちが楽しんでるのを少し体験できる。新しい機能をすぐに作ったり、新しいアイデアを探ったりできる。でも、コードベースがごちゃごちゃになるから、デザインには気を使わないといけない。よくAPIを設計して、Claudeに批評してもらって実装してもらう。私の立場の人たちにとって、将来は暗いと思う – ジュニアでもないけど、チームをリードしてるわけでもない。中間層は空洞化して、方向性を設定し、調整し、実行するプリンシパルに置き換わると思う。特権を持った少数がリーダーになるために雇われたり、自分のプロジェクトで成功したりするけど、その間にいる人たちは厳しい状況だね。

└

職場では、上の開発者たちがAIを使って何でもやってる – コーディングだけじゃなくて – それで、私に整理させるんだ。これは近い将来、最もやりがいのない仕事だと思う。大変だし、実際には構造的な欠陥を修正してるのに、請負業者が終わった後の現場を片付ける作業員と同じくらいの評価しかもらえない。しかも、ひどい冗長なスパゲッティコードを整理してるときに、リグレッションバグを持ち込んだら最悪だよね。

└

メインプロジェクトのAPI設計に従ってなかったもし壊れたコードを渡されたら、ちゃんと言ってやった方がいいよ。「これ、言ってることと違うじゃん。これをやり直すためのストーリーを作ってほしいの？」って。

└

そういう人間エンジニアの話は聞いたことある。「10倍」だけど、実際には必要な環境で機能しないんだ。でも、彼らは「機能が完成」するのを早く達成したよね。問題は、それが「実際に終わった」とは程遠いってこと。

└

自分が立場を取らず、彼らのゴミを片付けないなら、問題の一部じゃないの？ AIを使った開発を支持するなら、コードを生成するエンジニアがその品質に対して個人的に責任を持つべきだって言わないと。

└

ほんと大変だったし、元々すぐに仕上げたチームと比べると、時間がかかりすぎて自分が悪く見えちゃった。なんでヒーロー気取りなんだよ？マネージャーに選択を任せろ：コードベースを台無しにするか、2週間のクリーンアップにするか、彼らの選択だ。もし魔法のAIチームが統合を早くできるって言うなら、やらせればいい。

└

すべてのAIプログラミングタスクにはこれを返事として使え： https://simonwillison.net/2025/Dec/18/code-proven-to-work/ AIで適当にやって、実際の人間にコードを読ませるのはただのプロ意識の欠如だよ。しかも「著者」が読んでないのに。API設計とかもツールやCIビルドで自動的にチェックされるべきだし、チェックが通るまでPRのマージは拒否されるべきだよ。

└

各リポジトリにコーディングスタイルガイドのファイルが必要だと思う。好ましいパターンやコードの例を含めて。そうすれば、そういう問題は減っていくよ。

└

うちも同じようなことがあって、コードレビューのガイドラインを変更して、明らかにAIの雑なコードは拒否するって書いたんだ。これまでに4人の契約者を解雇したよ。早く仕事を終わらせるけど、いざ本番用に仕上げる段階になると全然ダメなんだよね。前回は予算を達成するためにそのままマージしたけど、みんなが後で苦労する羽目になって、今もそのツケを払ってる。

残念ながら、仕事が嫌になる。チームのダイナミクスも影響してるのは認めるけど。去年、大きな機能を実装するためにすごく集中してたんだけど、ビジネスロジックを正しくするのが大変で、同時にリソースをあまり使わずに実行可能にするためにすごくクリエイティブにならなきゃいけなかった。ほぼ完成してバグを修正してるときに、チームメンバーが待つのに疲れて、数週間前の自分のコードを持って行って、Claudeかなんかに渡して解決策を持ってきた。だから、自分のコードを仕上げる代わりに、彼らのバージョンを通過しなきゃいけなかった。提案の一つ一つにはビジネス要件が間違ってたり、巨大なバグがいくつかあったりした。どれも自分の解決策よりも近づいてなかった。自分のコードに対する貢献はありがたいけど、自分のコードを取ってClaudeに聞いて終わらせるのがそんなに簡単だと思われるのはちょっと失礼だよ。

└

AIだけじゃなくて、もっと色々あるよ…

└

誰かがそうしたら、単に「いや、最新のコードを使って」って言えばいいよ。

└

その気持ち、めっちゃわかる。今は創業者たちが生産性に夢中で、すべてがうまくいってるように見えるし、あまりミスもない。みんなできるだけ生産的になろうとしてるから、どこに向かってるのかもわからない時がある。正直、なぜ特定のタスクを自動化してるのかもわからないことがある。昔は、特に知りたくない分野では「知らない」って言える選択肢があったけど、今はその選択肢がなくなった。知識はすぐ手に入るから。だから、自分の役割が全然違ったはずなのに、バックエンドアプリのフロントエンド作業をやってることになる。

└

これはチームの問題じゃない？なんで同僚が君の責任を負ってるの？マネージャーは何してるの？

約1年前に、名前は言えないけど大きなテック企業で新しいポジションを始めた。そこで既存のウェブプロジェクトに取り組んでる。コードベースはひどくはないけど、全体的にはあまり良くもない。すごく巨大で、過剰設計されてて、かなり独特で、疑問のあるデザイン決定もある。1年以上働いても、まだ初心者のように感じることが多い。今年は仕方なくAIツールを使い始めたけど、驚くことに、これが自分にとってかなりの助けになってる。コード生成だけじゃなくて、モノリスを調べたり、どう動くかについての質問に答えてくれるのが本当に良い。以前は、何日もコードを見てから作業を始めて、何をどう作るかを考えて、インドや東欧の人に質問して、夜中に返事が来るのを待ってた。AIがそれを完全に置き換えて、驚くほどうまく機能してる。コード生成に頼るときは、主にボイラープレートを書く手間を減らすためだよ。生成されるコードは、スタイルや堅牢性の面であまり良くないことが多いから、ちゃんとしたものにするために少なくとも数回は見直さなきゃいけない。最終的には手書きで書くよりも速いと感じるけど、そんなに大差はない。自分のプロジェクトにはあまり役立たないけど、ChatGPTとおしゃべりするのは楽しい。

└

これらのツールを理解のために使うのが一番の使い道だと思う。メリットが多くて、デメリットは少ないし（最悪でも誤解を招く理解になるくらいだけど、主張を直接確認すればそれを最小限に抑えられる）。実際、これらのツールを使うときには、何が本当に起こっているのかを人間が理解することが大事だってテーマが出てきてる気がする。

使ってないよ。自分の考えは結構わかってるし、怠け癖がスキルを衰えさせるってのもわかってるから、リスクを冒さない方がいいかなって。6ヶ月くらい前に同僚が、AIを使わないようにしてるって言ってたけど、やっぱり簡単に手が伸びちゃうから難しいって。なんか薬物依存みたいだなって思ったよ。彼がそれを認めるのは、俺が使ってないってことを隠してないからだと思う。別の同僚は、コード生成にAIを使うのをやめたんだけど（確かそうだったと思う）、生成されたものが長期的なメンテナンスには messy だってわかってるから。Reactは初心者だけど、質問にはよく使ってるみたい。三人目の同僚（ジュニア）は、去年から頭が悪くなった気がする。問題を解決しないマージリクエストを開いてるし。マネージャーが言ってたけど、ペアプログラミング中にAIを使ってるのを見たことがあるらしくて、見た目は良かったから問題が見逃されてたみたい。マージリクエストにもAIがどうコードを名付けたり構造化したりしてるかのヒントがあったらしい。

└

アイデアやテストを話し合ったり生成したりするためにAIを使ってるけど、トリビアルなこと以外は全部理解して自分で入力するようにしてる。エンジニアの主な価値は理解することだから。AIは物事をより良く、早く理解するのを助けてくれる。AIに計画を任せてただ流してるだけだと、人間の資本が無視されて衰退しちゃうと思う。自分が何をやってるかわからないなら、未来はあまりないと思うけど、問題やシステムを深く理解してる人には常に未来があるよ。

└

俺も同じ感じだよ。でも一度使ってみたらハマっちゃった。嫌いなことに使い始めたら、どこでも使うようになった。5倍速で進むし、大体はついていけてる。でも週に2回くらい、話の流れを失ったことに気づく。月に1回は、1週間以上遅れちゃうこともある。

└

手動でコードを書くスキルが衰えていくのは確かに現実だね。紙の地図とコンパスでナビゲートするのと、Googleマップを使うのを比べる感じかな。スキルを失うのは特に気にしてないけど、プログラミングが好きで、それが10年以上の主な収入源だったから、ちょっと複雑な気持ちもある。Claude Codeを使うと、圧倒的に速くなるから逃れられないんだ。> 彼は、生成されたものが長期的なメンテナンスには不向きだってわかってるけど、ちゃんと動くし、Reactにはまだ慣れてない。短時間でコードを生成できるなら、論理的にはメンテナンスも難しくないはず。気に入らなければ再生成すればいいだけだし。このAIで生成するのは簡単だけど、その後メンテナンスできないっていう主張は信じられない。論理的に成立しないし、AIが生成したけどメンテナンスできないコードベースを見たことがない。今年見たのは、新しいツールを使ってAIが完全な機能を持つ言語やフレームワークを再構築したものばかり。私にとって、メンテナンスできないコードの主張は信じがたい。

俺はすごく有名なAI会社で働いてる。あらゆるツールにアクセスできるし、マネージャー、PM、エンジニアの各レベルで成功の度合いは様々だ。無限に近いOpus 4.6を使ったカーソルがあって、シニアエンジニアとしてのワークフローが根本的に変わった。ソフトウェアの設計やテストにもっと時間をかけるようになったし、開発時間のほとんどはAIの変更を促したりレビューしたりすることになってる。自分のコーディングスキルが衰えてるのはわかってるけど、実際に楽しんでた部分がコーディングだったかどうかはわからない。高いレベルで考えること、アーキテクチャやコンポーネントの接続、ユーザー体験に焦点を当てることが好きなんだ。でも、これらのAIツールを使うのは金の手錠みたいなもんだと思う。お金を払ってるモデルがないスタートアップで働くことになったら、キャリアの中で初めて、去年よりも機能をうまくコーディングできなくなる気がする。だから、プロとしてはメリットとデメリットがある。デザインやアーキテクチャのスキルは大幅に向上してるし、もっと時間をかけてるから。個人的にはすごく楽しい。自分では絶対にやらなかったサイドプロジェクトをいくつか作ったし、グリーンフィールドプロジェクトでClaudeのコードを使うのは最高だよ。

└

人々がコーディングスキルが衰えることにちょっと神経質になってる気がする。私は数年間プログラミングをやめてた時期があったけど、戻ったときには1ヶ月もあればすぐに感覚を取り戻せたよ。そのほとんどは、構文や標準ライブラリのクラスを思い出すだけだったしね（当時はC++だった）。

俺はAmazonのエンジニアで、Kiro（自社のハーネス）をOpus 4.6の下で使ってる。大体の不満はハーネスに関するもので、CCの方がずっと良い。生産性に関しては、仕事では2〜4倍、サイドビジネスでは10倍以上生産的になってる。以前は機能を届けるために残業してたけど、今は9時から5時まで働いて、サイドで仕事探ししながら、相対的にもっと多くの機能を届けてる。AIがコードを書くのに良いだけじゃないってことを多くの人が見落としてると思う。データ分析やデバッグ、デプロイなど、いろんなタスクに使えるんだ。デプロイのループを管理するのに定期的に使ってる（例えば、コードを変更して、変更をガンマにデプロイして、サンプルリクエストを作ってCloudWatchログから出力を確認する）。2週間で作った機能は、以前は1ヶ月かかってたのは、技術的な細かいことを学ばなきゃいけなかったから。データ分析には内部のグルーカタログがあって、データをクエリしてXを分析するスクリプトを書いてって言うだけで済む。特にAIやエージェントは俺にとって大きな助けになってる。自動化についてはすごく不安だけど、SWEが他の職業より先に自動化されるのはおかしいと思う。SWE自体が他を自動化するために必要だから。LLMには根本的な限界があると思うけど（詳細はあまり理解してないけど）、今のところ解放された知性のレベルは世界を根本的に変えるし、すでにSWEのあり方を変えてると思う。

└

どこかで、ジュニアがAIを使ったコードをプッシュするのを禁止するAll Handsがあったって見たんだけど、それってただの噂だったの？

└

2週間で、通常なら1ヶ月かかる機能を作ったことがある。なぜなら、もう二度と使わないような細かい技術的な詳細を学ばなきゃいけなかったから。AIの「本当に素晴らしいところ」の中で、これが一番上に来るだろう。ソフトウェアエンジニアとしてのキャリアの中で、新しい技術や言語、エソテリックなライブラリ、手作りのビルドハーネスなどを学ぶのにたくさんの時間を費やさなきゃいけなくて、特定のコードベース以外ではその技術を使う理由がないってわかると、いつもすごく落胆してた。大きな会社で働いていると、これがかなり頻繁に起こることだと気づいた。例えば、デザインドキュメントや機能リクエストを見て「お、これは簡単そうだな」って思ったのに、コードベースに入ると、元の開発者やチームがすごくニッチなトランザクション処理ライブラリを選んでたり（もっとひどいのは、テストもない手作りのものだったり…）、そのエソテリックな技術を理解するのが実際の作業の85%になってしまう。AIはそれをゼロにはしてくれないけど、新しい技術を理解するのにはすごく助けになってるし、特に開発環境やビルドのセットアップを手動よりもずっと早くできるようになった。もちろん、AIはより悪いアーキテクチャのゴミを生成するのを楽にしてくれるから、1年か2年後には、最初に生成されたAIのゴミの山を説明してもらうことにますます依存するようになるかもしれない。

└

「私はアマゾンのエンジニアです」これって制裁コメント？

└

仕事探しの理由を聞いてもいい？日常の仕事でやりたいことができてないって、何を思ってるの？

まだこれについて言及されてないけど、私にとって一番最悪なのは、管理職がクラウドを使って50ページのデザイン文書やPRDを生成して、私たちに「できるだけ早くレビューしてね」って送ってくることなんだ。誰も読まないし、作ってる人たちさえも読んでない。無限に意味のないスライドデッキを生成して、具体的な質問をされたらうろたえる社員を見てるよ。それが読まれるとしたら、他の人のクラウドによるものだし。それに、長い間（時には10年以上）コードを書いていなかった人たちが実装の詳細を計画したりコードを書いたりすることを可能にしてしまって、変な提案が来ることもある。とはいえ、本当にコードの種類によるね。私は本番用のコードを手書きしていて、AIができるのはそれをレビューしてバグを指摘することだけ。だけど、負荷テスト用にデータを生成するための使い捨てスクリプトみたいなものなら、もちろん、やってみてもいいよ。

└

一番いいのは、その人たちとミーティングを設定して、ドキュメントを一緒に確認することだね。そうすれば、彼らは自分たちのやったことを見直さざるを得なくなるし、出力が増えれば増えるほど、自分の時間を無駄にすることになる。

└

明らかにAI生成のコンテンツを押し付けられたら、私もAIを使って要約するよ。それか、あなたのデスクに行って説明してもらう。

└

私の（正直言って限られた）LLMの使用経験では、コードを自分でレビューする必要がないなら、書くのにはすごく役立つと思う。でも、後で自分でコードを編集するつもりなら、やっぱり自分で書かなきゃダメだね。それに、LLMはデザインが苦手だし。

ネガティブな結果だね。コードレビューや「より良い検索エンジン」やスニペットには本当に役立つと思うし、時にはラバーダッキングにも使えるけど、エージェントモードや実際の長いコーディングタスクでは、結局いつも生成されたコードをやり直す羽目になる。生成されるものは、常にちょっとした誤解をしていて、テストの小さな目標にしか興味がない学生みたいに見える。全体像を見ようとしないんだよね。毎回、これがうまくいけばもっと生産的になれるんじゃないかって期待して時間を無駄にしてる。もしかしたら、正しい方向に少し押してあげればいいのかも、って思ったり、持ち方やツール、プロセス、スキルが間違ってるのかもしれないって。まるでJavaScriptフレームワークの時みたいだ。

私は開発者から（いやいやながら）マネジメントに転身しました。今でもコードに触れながら、チームと一緒にいくつかのプロジェクトに取り組んでいます。毎日GitHub Copilotを使っていて、これが私たちのスピードと品質を向上させる素晴らしいツールになっています。20年以上の経験があるけど、これはただのツールの一つだと思っています。もしかしたら私は甘いのかもしれないけど、これに脅かされているとは感じていません。少なくとも私の会社では、ビジネスが追いついていないのが問題です。私たちはコードを書くのが早くなったけど、ステークホルダーは何を作ってほしいのか、決めるのが早くない。テストを早くしたり、LLMsが可能にする新しい手法を理解したりするのも同じです。次に目指したいのは、コードの品質を上げるだけじゃなくて、ビジネス分析を改善して、ビジネスの問題を理解して解決するために必要な会議の数を減らすことです。

ハクソク