Agentic Codingは罠だ
(larsfaye.com)- Agentic codingは、人が要件と計画を作り、複数のコーディングエージェントが実装する方式だが、生成・コミットされるコードと人との距離を広げ続ける構造になっている
- この方式は、熟練した開発者がアーキテクチャレベルで批判的にレビューしてこそ成功するが、AIの過剰使用は、そのために必要なスキルを弱める**認知的負債（cognitive debt）**を生みうる
- Anthropicの研究が扱った監督のパラドックスのように、Claudeを効果的に使うには監督するためのコーディング能力が必要だが、コーディングエージェントの使用はまさにその能力を弱めうる
- LLMは、深い理解や簡潔さよりも、一定時間内に生成されるコード量を増やす方向で使われがちであり、曖昧な要求を仮定やハルシネーションで埋めて、より多くのレビューや修正、トークン消費を生みうる
- Claudeの障害とトークンコストの変動は、ベンダーロックインとコストの不確実性を露呈しており、AIは実装を代替するオーケストレーターよりも、計画支援・ドキュメント・リサーチ・限定的な委任ツールとして使うほうが理解の負債を減らせる
構造的トレードオフ
- コーディングエージェントは有用で強力だが、すでに定量的・実務的に検討すべきトレードオフがある
- AIの非決定性に由来する曖昧さを緩和しようとすると、周辺システムの複雑さが増す
- 多くの開発者のスキルが衰える可能性がある
- Claude Codeの障害のように、特定ベンダーの障害がチーム全体を停止させうる
- 人件費は固定的だが、トークンコストは変動し続け、増加する可能性がある
- この方式が成功するには、熟練した開発者がアーキテクチャレベルで批判的に考え、数千行の生成コードの中から問題が大きくなる前に見つけられなければならない
- しかしAIツールは、そのために必要な批判的思考と認知的明瞭さに悪影響を及ぼす可能性があり、認知的負債（cognitive debt）が膨らみうる
単なる新しい抽象化ではない
- 「プログラマーがより高い抽象化レイヤーへ移行している」という解釈だけでは不十分だ
- 曖昧さが増すこと自体が、より高いレベルの抽象化を意味するわけではない
- FORTRAN、コンパイラ、高級言語が登場したときも、バグ、不安定さ、効率低下、「魔法」の増加を懸念する反応はあった
- 過去の懸念の多くは、新技術を受け入れると何を失うのかという規範的・理論的な心配だったが、AIツールは登場から数年で、すでに実質的な影響を示している
- その影響はジュニア開発者に限らず、10年以上の経験を持つ開発者にも及んでいる
- ジュニア開発者は、コードを直接扱う工程が減り、生成コードをレビューする役割へ押しやられることで、より急な学習曲線に直面する
- コードレビューは重要だが、学習プロセスの半分にすぎず、コードを自分で書いてデバッグする際の摩擦がなくなると、学習能力は大きく弱まる
- この現象は研究に時間がかかるため、リアルタイムの状況把握には逸話的証拠も重要だが、MIT Media LabのレポートやMicrosoft関連の報道のような裏付けもある
今回の変化が異なる理由
- C++開発者がJavaやPythonへ移ったからといって「ブレインフォグ」を訴えたわけではなく、システム管理者がAWSへ移ったからといってネットワーキング理解を失ったと感じたわけでもない
- シニアエンジニアが管理職へ移り、コーディングの機会が減って時間とともに腕が鈍る現象自体は新しくない
- 従来の経路では、何十年もコーディング、摩擦、問題解決を積み重ねたエンジニアが、文法よりアーキテクチャ上の意思決定を多く扱う役割へ移行していた
- 今は、そのような長期経験がないまま、開発者がAIエージェントを管理するより高次のワークフローへ移っている
- 問題は、そのワークフローが何十年もの経験で得られるのと同種のスキルを要求する点にある
- シニアエンジニアも例外ではない
- Simon Willisonは、約30年の経験を持つ開発者でありながら、アプリケーションが何をできて、どう動くのかについての「確固たるメンタルモデル」がなければ、機能が増えるほど推論が難しくなると述べている
熟練したオーケストレーターのパラドックス
- Anthropicの最近の研究は、コーディングエージェントを頻繁に使うことの危険として「監督のパラドックス」を扱っている
- 要点は、Claudeを効果的に使うには監督が必要であり、Claudeを監督するには、AIの過剰使用で弱まりうるまさにそのコーディングスキルが必要だということだ
- LinkedInで50人のエンジニアを管理するSandor Nyakoは、組織内でスキルの衰退が広がるのを見て、チームに「批判的思考や問題解決が必要な作業」にはAIを使わないよう求めている
- 彼は、スキルを育てるには困難に直面し、問題を深く考える筋肉を鍛える必要があり、批判的思考がなければAIが正しいかどうかを問うことすら難しいと考えている
- 「過剰使用」の基準も不明確だが、データに基づく研究と逸話的な資料は、数か月のうちにもスキルが急速に弱まる可能性を示している
- コーディングエージェントの使用は、エージェントをうまく管理するために必要なスキルそのものを弱めるという矛盾を生む
LLMは間違った部分を加速する
- 必ずしも、より速くコードを書く必要があったわけではない
- とくに、完全には理解していないコードや、妥当な時間内にレビューできない大量のコードを、より速く生み出す必要があったわけではない
- AI以前の優れた開発者の優先順位は、おおむね次のようなものだった
- コードとコードベースの関係を理解する
- 文書化された効率的な標準に適合しているか確認する
- 可読性を保ちながら、目標達成に必要なコード行数を最小化する
- 実行時間を考慮する
- Agentic codingとLLMは、この優先順位を事実上逆転させる
- 現在の能力と使われ方は、一定時間内に生成されるコード量を増やして速度を高めることに焦点を当てがちだ
- 速度は高い熟練度の自然な副産物だが、無理に押し進めれば精度低下につながる
- LLMを深い理解や簡潔さを高める方向で使うこともできるが、強制導入や組織全体のトークン使用量中心の過熱は、実際の利用がそうはなっていないことを示している
コーディングは計画でもある
- コードを書くことで、よりうまく計画し、よりよく考えられる開発者もいる
- コードを通じて考え、作業することは無意味な反復労働ではなく、セキュリティ・性能・ユーザー体験・保守性まで、技術的なレベルで考えさせるプロセスだ
- OpenCodeを作ったDaxは、Spec Driven Developmentに関するインタビューで、新しい作業や難しい作業に取り組むとき、実際にコードを打ち込む過程を通じて何をすべきかを見いだすと語っている
- 彼は巨大な仕様を先に書くよりも、型、関数間の相互作用、フォルダ構造を自分で触りながら概念をつかむやり方を好む
- 人が言語化したことが、実際の意図と常に一致するとは限らず、LLMはその曖昧さを仮定やハルシネーションで埋める
- その結果、レビューは増え、エージェントによる修正も増え、トークン消費も増え、生成物との断絶はさらに大きくなる
- 逆に、非常に明確で構造化されたプロンプトを書いても、LLMは存在しないメソッドを出力しうる
- LLMはコンパイラではなく次トークン予測エンジンなのだから、決定論的システムを確率的システムに置き換えておきながら、曖昧さがゼロになることを期待することはできない
- AIに積極的なシニア開発者たちでさえ、この断絶を深刻化する問題として見始めている
ベンダーロックインとコストの不確実性
- Claude障害の際、一部の開発者やエンジニアリングチームが停止したという投稿が出ていた
- いくつかのワークフローとコーディング能力は、すでに特定のAIベンダーに大きく依存する水準に達している
- 以前ならキーボードとテキストエディタさえあれば発揮できたスキルが、今ではAIモデル提供者へのサブスクリプションを必要とするようになっている
-
トークンコストは予測しにくい
- モデル提供者は大きな補助金を受けており、モデル自体も変化し続ける土台の上にある
- 新モデルの登場は、高いベンチマーク、過熱、実運用後の「弱体化された」という不満といったパターンを繰り返している
- 同じ仕事を処理するのに2〜3倍多くのトークンを燃やすという不満も続く
- 人件費は把握できても、トークンコストは日次・月次・年次で予測しにくい
- チーム全体がagentic codingをデフォルトにすると、コスト勘定は非常に柔軟なままである必要がある
- Primeagenは、完全なagentic workflowを使うと「モデル提供者が事実上あなたを所有する」と語っている
- トークン消費コストを支払わなければ、かつては批判的思考や問題解決能力で行っていたことが実行できないという産業構造が生まれうる
- これは単なる製品ベンダーへのロックインではなく、業界全体の技術能力に対するベンダーロックインに近い
- 財務的・知的な基盤はいつでも揺らぎうるが、ローカルLLMはその水準の利用量を吸収できるほど整っていない
- この問題は理論ではなく、すでに報じられており、モデル提供者自身も直接取り上げている
- Anthropicの別の研究は、デバッグスキルが47%急減したと述べている
- AIを職場、特にソフトウェアエンジニアリングへ攻撃的に導入すると、すばやい結果を得るためにAIに依存する一方で、問題が起きたときにデバッグする中核スキルを育てられない可能性がある
AIの役割を抑えるアプローチ
- LLMは、学習と能力向上のための強力なツールになりうる
- 概念や手法をより深く広く探究させ、以前より少ない手間で新しいアイデアを試せるようにしてくれる
- コード生成ツールそのものは新しいものではない
- Emmet、自動補完、スニペットは、コードを直接書く量を減らして生成するためのツールだった
- COBOLも
MOVE、WRITEのような英語風の単語で、少ない記述でより多くの命令を表そうとしていた - jQueryのモットーも「write less, do more」だった
- LLMは、こうしたコード生成ツールへのもう一つの追加と見なせる
- 重要な違いは、LLMとコーディングエージェントを補助プロセスとして活用する点にある
- 生産性のために個人のスキルを犠牲にせず、計画段階のブレインストーミングにはAIを使いつつ、実装には引き続き積極的に関与するやり方が可能だ
- 必要なときだけ委任すれば、生産性の利得を得ながら理解の負債を減らせる
日常的な使い方
- LLMを仕様と計画の生成に使い、実装は人が主導する
- これは「オーケストレーション」ワークフローを反転させるやり方であり、作業に応じて20%から100%まで自分でコーディングする
- モデルを使うときも、要求と生成コードの距離を縮めるために、頻繁に擬似コードを書いてから依頼する
- モデルは、一時的なコード生成、対話型ドキュメント、リサーチツールとして活用する
- 責任ある委任ツールのように使い、質問し、反復し、リファクタリングし、アプローチをより明確にする
- 一度にレビューできる量を超えるコードは生成しない
- レビューするには多すぎるなら、速度を落とし、作業を細かく分け、必要なら自分でリファクタリングして最終結果を包括的に理解する
- 自分でやったことがない、あるいは一人ではできない実装は、LLMやエージェントに任せない
- 例外は教育やチュートリアル目的の場合であり、その成果物は後で捨てることも多い
- 要するに、AIはStar TrekのDataではなくShip’s Computerのように使うべきだ
速さより良い仕事
- モデルによる生産性向上は実際に存在する
- 同時に、作業を自分の手で直接、頻繁に扱うことで生じる摩擦と理解も実際に重要だ
- コーディングを理解しないままコーディングを民主化しようとする試みは、繰り返し失敗してきた
- コードを理解するには、コードと直接かみ合う必要がある
- 継続してコードに関わり、自分で書かなければ、その理解とつながりを失いかねない
- 理解を失えば、エージェントをよりよく管理する能力も弱まり、AIコーディング段階は奇妙で不必要にストレスの大きい過渡期になる
より大きな実験になるかもしれない
- 現在の流れは、長期的影響を十分に理解しないまま、自分たち自身に対して実施しているもう一つの大規模実験のように見える
- ソーシャルメディア導入時にも、長期的含意を理解しておらず、その後、広範な注意力低下などさまざまな問題が現れた
- 今回は、さらに危険なものを賭けている
- fast.aiを作ったJeremy Howardは、AIエージェントにすべてを賭ける人は、自分が不要になることを保証しているようなものだと語る
- 思考のすべてをコンピュータに外注すれば、能力を高め、学び、より有能になっていくプロセスそのものが止まってしまう
1件のコメント
Hacker Newsの意見
ここ数年、エージェント型コーディングで仕事をしてきて、35年間手で直接プログラミングしていた頃よりも、自分が使う言語・システム・ツールについて多くを学んだ。
システム・手法・アプローチを決める能力は、いまでもツールより自分のほうがずっと上だが、こうしたツールは雑多な細部をたくさん知っている、とても博識なインターンのようなものだ。経験は浅く、熱心にミスもするが、少なくとも最初のうちはフィードバックを受け入れて行動に移す。ただし完全に理解して内面化しているわけではないので、よく忘れる。
自分が作業するすべてを全部知っていなければならないという主張は、とてもナイーブだ。2つ以上のチームで働けば、完全には理解していない部分が多いし、古いコードベースならほぼすべての部分が見慣れないこともある。数十年積み上がった巨大なモノレポでは、みんながあなたを専門家だと見ている部分ですら、きちんと理解できていれば運がいいほうだ。
こういう主張をする人たちは、たいていかなりジュニアか、ほぼ一人で働いているか、あるいは1つのプロジェクトを20年抱え続けてきたように感じる。チームや大きな組織で働く人なら、コードベース全体を知っているとは言えないし、エージェント型プログラミングをする人も同じだ。それでもエージェントに質問すれば答えは返ってくるし、一生他人のコードを読んできた身としては、LLMが書いたコードも読める。悪いコードが機械によって書かれたか人間によって書かれたかなどまったく気にならないし、少なくとも機械は私のフィードバックを受けて行動に移す。
些細な問題であっても、低水準言語、アセンブリ、あまり一般的でないアルゴリズム、ネットワークプロトコルのような追加の技術が必要になった瞬間に、解決できず止まってしまうソフトウェアチームをたくさん見てきた。
逆に、見たものを解釈する能力がないからではなく、プロプライエタリなライブラリやプロプライエタリなOSのようなブラックボックスを使っているために内部を掘れず、実際の動作を確認する方法がなくて詰まることもある。
だから、ごくまれにしか必要でなくても、自分が扱うすべてについて全部調べられる環境は、常に可能であるべきだと思う。
大事なのは、システムの残りを学ぶことを恐れず、索引を維持することだ。
何より、どんなことでも素早く把握できなければならない。そうすれば広く扱える。必要なときには深く掘り下げ、必要なときには高いレベルでざっと見る、というふうに問題に合った適切なレベルを取る必要がある。
昔、大学ではコンピュータサイエンス専攻に工学全般を教えていた。「化学工学やアナログ制御システムをいつ知る必要があるのですか」と尋ねたところ、「使うことはないだろう。ただ、コーディングできる程度の速さで把握して、あとで忘れればいい。我々は強固な基盤を与えているのだ」と答えられた。
これは大きなコードベースの中でもそのまま当てはまる。
git-ai [0] のようなツールは、LLMセッションをキャプチャし、各ファイル編集を特定のエージェント動作に結び付け、エージェントが特定のコード片について、その周辺の会話、つまりユーザーが何をプロンプトしたのか、そのコードを生んだLLMの推論が何だったのかなどを参照できるようにする。バランスを変えうるが、まだ広く使われてはいない。
[0] https://usegitai.com/
25年以上の経験があるシニア開発者として、最近「5分だけ入ってもらえますか」という感じで会議に放り込まれたのだが、こういう途中から何の文脈もなく引きずり込まれる会議が本当に嫌いだ。
自己紹介もなく質問が次々に飛んできて、数十あるうちの1つの外部連携についてだった。さらに悪いことに、向こうは私たちとは違う独自の用語を使っていた。
これらの連携を作るときにモデルに大きく依存していたので、質問を理解するのに非常に苦労した。きわめて退屈な作業で、外部の分厚い仕様書が提供されていた。
モデルを使っていなければ、10倍時間をかけてもこうした連携はおそらく完成しなかっただろう、という点についてはいまでも前向きに考えている。だが今は、こういう不快な瞬間が二度と起きないように、「なるほど」ポイントをもう一度文書化するかどうか真剣に考えている。
会議でここまで無知で恥ずかしいと感じたことはなく、言えたのは「それは確認して返答します、これも、あれもです」だけだった。
認知的負債は本当に現実で、個人的には技術的負債よりもつらい。技術的負債はチーム全体で共有されるが、認知的負債は個人的で、それを作ったのが自分自身ならなおさら、もっとよく知っているべきだ。
今後は、「これは何か」「あれは何か」という5分で読めるフラッシュカード型のMarkdown用語集を作らない限り、仕事は終わっていないと見なすつもりだ。
シニア開発者なら、気に入らない振る舞いにブレーキをかけるべき人だ。権限がある。「興味深い質問ですね。私の見解を述べるには、もう少し文脈が必要です。システムアーキテクチャを簡単に説明していただくか、このアプローチで実際にどんな問題を解こうとしているのか説明してもらえますか？」と言えばいい。
そういう扱いを受けたときに「この質問にきちんと答えるには、文書とコードを確認する必要があります」と言うのは、まったく問題なく、かなり外交的な返答だ。
専門性が積み上げる対象として見られるのではなく、単に創造的な確証バイアスを確認するために使われる会議は楽しくない。
生成されたコードの問題を見つけるには、開発者が気を配らなければならない。多くの開発者、特に大企業の開発者は、すでに仕事からかなり気持ちが離れていて、できるだけ最小の努力でチケットを閉じ、責任を押し流す方法だけを探している。
そういう開発者は、能力があっても、エージェントが見落とした問題を見つけられるほど生成コードを理解しようとはしないだろう。特に今のようなAI主導のスピード礼賛の中ではなおさらだ。
生成コードは言語的にはもっともらしいが、よくあるイディオムを無意識のうちに incoherent に真似ることが多く、その結果、実際のバグが、普通の人間、ひいては下手なプログラマですら思いつきにくい形で偶然隠れてしまうことがある。
LLMには内部評価がないので、レビュー担当者はそれを踏まえて行単位で評価し、LLMがそもそも持っていなかった隠れた根拠や暗黙知を最初から再構築しなければならない。そうして問題ではないものに引きずられ、高価な時間を消耗することもある。
この時点では、最初から書いたほうが投資が少なくて済むことが多い。
ひょっとすると今、企業はジャンクAIを買っていて、次の段階ではその「解決策」を約束されているのかもしれない。資本主義は予想どおりに機能している。
この記事は少し論点を外している気がする。
AIを多用すればスキルの喪失はある。
ただ、部屋の中の気まずい象を認めたい。AIは人をあまりにも速くしている。速いアウトプット自体が悪いという意味ではなく、コードを生み出した全体的な理解や経験よりも、速いアウトプットとコードのほうが先行しているという意味だ。深い知識にもとづいて安全な判断をしながら作る人よりも、ビジネス価値を語れる人に報酬が与えられている。
AIは良いし、良い解決策も作れるが、究極的には自分が何をしているのか分かっておらず、最善の場合でも強いオーケストレーターを必要とする。
私たちはビジネス主導開発の肥溜めの中にいて、悪い意思決定に対して十分に厳しい評判上の罰が返ってきていない。
つまり、スキルの喪失がそれほど大きな問題なのか確信が持てない。単に私たちの仕事の性質が変わりつつある兆候なのかもしれない。C++標準を暗記し、何百もの機能を正しく使う能力より、良いアーキテクチャを知っている能力のほうが高く評価される時代になるのかもしれない。
通常の開発では、「本当にこれを作りたいのか」「こうしたら何がまずいのか」をもっと行き来しながら吟味するし、理想的にはPR承認やマージ・デプロイ前にやる。その一部が「あとで誰が文句を言うか見よう」に移っている。言うとおり、予防1オンスは治療1ポンドに勝るということだ。
しかもそのコードは当該プロジェクトの慣用的なC++ではなく、LLMは既存のAPIを完全に無視していた。直せるし、メンテナが捕まえるべきだったが、生成されるコード量のせいで全員があまりに多くのエネルギーを使わされる。
こういうブログ記事は間違いなくAIの助けを借りて書かれているのだろうが、ここでもインターネットのあちこちでも、何年も前からコメントの話題になってきた。スキルの萎縮は深刻な懸念であり、2022年からAIに懐疑的な人たちが皆くり返し言ってきたことだが、ある人たちやある場所はまったく気にしていないようだ。
ある時点からコードへの洞察なしにゴミ製造機のレバーを引いているだけなら、上司が「なぜ年俸5万ドル以上を払う必要があるのか」と問うのも正当かもしれない。
もっと速く進むためにAIを使うのは、間違ったものを最適化している。私が働いてきたどの場所でも、機能を実装するのに必要なその他すべての作業に比べて、「コードを書くこと」自体が占める時間は最も少なかった。
1日でコーディングできる機能を考えてみよう。まず、会社で使っているAgileでもWaterfallでも、その計画プロセスを通じてすべてを計画し、作業を分割し、JIRAチケットを作り、誰がやるかを決めなければならない。これだけで数日から数週間かかることがある。その次に、提案設計をまとめた設計文書を書き、同僚やチームメンバーのレビューを受けなければならず、実質的な機能ならさらに1週間かかる。複数チームが関わるなら、それらのチームの同意と設計合意を得なければならないので、さらに1週間追加だ。場所によっては作業開始の承認が必要で、承認者の予定や空き状況によってさらに数日かかる。
そのあと、1日かけてコードを書き、テストを通す。
それからコードレビューがあり、チームと何度もやり取りして何度も繰り返し、追加レビューを受けることもある。さらに数日または数週間かかる。もっと大きな会社なら、法務、プライバシー、性能、アクセシビリティ、QAといった他部門のあらゆるレビューを通さなければならない。並列で進めるとしても、控えめに見積もってさらに2週間だ。最後にステージングに上げて、内部ドッグフーダーの間である程度熟成時間を取り、動作に自信が持てるようにする。さらに1週間。これでステージングから本番へ上げる準備は整うが、真面目な会社なら何であれいきなり100%本番には出さない。徐々に割合を上げ、ロールバックが必要な場合に備えてフィードバックや指標を確認しなければならない。全面リリースまでさらに2週間かかることもある。
つまり設計からリリースまで2か月ほどかかる機能で、私たちは1日かかる部分を5分に縮めようと大騒ぎしているわけだ。
ソフトウェアを作るときは、それが問題に対する理解のスナップショットであることを忘れてはならない。それは皆に、未来の自分にさえ、アプローチと明快さ、そして当面の問題への解法の妥当性を語る。だから何を語るかを賢く選ぶべきだ。
設計からリリースまで2か月かかる機能で、1日かかる部分を5分に縮めようとしているという表現は的を射ている。
こうした仕事は、安定した会社ではすべてのエンジニアの日常の中で小さくない部分を占めていた。「プラットフォームエンジニアリング」と呼ぼうが何だろうが、この領域は死んだ。
また、リスクと労力に対して見返りが釣り合わず試さなかった技術的にリスクの高いアイデアも、いまでは手が届く。単に「より速く進む」だけでなく、何かを試せる速度がエンジニアリングプロセスの性質そのものを変える。
ソフトウェアエンジニアが十分安くなれば、こうしたプロセスの多くは必要なくなる。すでにこうしたプロセスを持つ会社は、その官僚制を壊すのが極めて難しいので困るだろうが、そもそもそうしたプロセスがない、あるいは取り除ける会社はかなりの競争優位を持つことになる。
新しい話ではない。スタートアップは常に実行速度で既存企業と競ってきた。新しくなったのは、その速度をより長く維持できる能力だ。
法務、プライバシー、性能、アクセシビリティ、QAのようなレビューもすべて射程に入っている。会社がこれらのレビューに伴う法的責任を外部提供者に転嫁できるなら、そうするだろう。
[0] このプロセスのかなりの部分が、結局は時間を節約しようとしていたまさにその従業員たちに押し付けられる、という皮肉はいったん脇に置こう。
ビッグテックにはそうした見栄っ張りな手続きが多いが、小さな会社は速く荒っぽく動ける。
コード品質は結局のところあなた次第だ。
エージェントと反復しながら作業して、自分で直接書いたときとまったく同じ品質のコードになるまで磨き上げるのを妨げるものはない。
こういう記事はかなりもどかしい。ただし、筆者が言うトークンコストは現実であり危険だ。
AIツールは、アプローチのブレインストーミングや、ときどきコードを生成するのに使うが、実際のタイピングは自分でやる。そうすれば、時間が経つにつれてメカニズムやプログラミング言語を忘れてしまう可能性が減る。
正直、すべてがLLMにコードを書かせるプロンプトとそのレビューだけになるなら、オープンソースのメンテナをあえてやることはないと思う。まったく充実感がなさそうだ。
実際の有給の仕事なら、LLMの使い方がどう変わるのかは気になる。私がソフトウェア開発者でいるのは、この技術そのものを愛しているからだ。作る行為、頭を使ってアイデアをコードに変える行為が好きだ。単にLLMにプロンプトを与えるだけの仕事なら、その職を続けるか分からない。少なくとも転職を探し始めると思う。
保守しなければならないコードではこの方法を使う。それでもモデルは誤った情報をたくさん混ぜるので、ときどきやられる。だいたい、過去には正しかったが今は間違っている内容だ。
捨ててもよいスクリプトや検証しやすいスクリプトは生成させるが、過剰設計やすべての境界ケースを捕まえようとする試みは避けるよう頼む。スクリプトでは、失敗した段階がそのまま見えるようにエラーになってくれたほうが理解しやすいからだ。
PowerShellのように読みにくいと感じる言語は避け、画面内に収まるほど短く、全部読んで理解できるものを生成するほうを好む。Python、Bash、Batchが私の主なスクリプト言語だ。
AIの提案の50%以上はいまだに却下する。ありきたりすぎたり、理由もなくコードを移したり、ときには単に間違っていたりするからだ。
面白いのは、この技術が二者択一だということだ。
専門性なしに委任はできるが、それが間違っているのか、そもそも不可能なのか分からない管理職向け技術か、専門性はあるが、その専門性を徐々に失っていくコーダー向け技術かのどちらかだ。
だから次の四半期までのVCや株主以外の、誰のためのものなのかよく分からない。
少し話はずれるが、記事でSpec Driven Developmentが未来だと言っているのが面白い。
技術的には、私たちはWaterfallをやっていた頃にすでにそうしていた。良いドキュメントがあった時代が少し恋しい。ここ10年、いやそれ以上、1行だけのJIRAチケットを受け取ることが多く、ほとんど何も明記されていないので、人に電話しなければならないことがよくあった。
私はまだAIで仕事をするのを避けている。実験用にローカルモデルをいくつか試してみようとは思うが、他人のものを切り貼りして作ったものに金を払うのは拒否したい。そして今のところローカルモデルは期待外れだ。