GitHub CEO、AIブームの中でも「手作業のコーディングは依然として中核」
(techinasia.com)- GitHub CEOのThomas Dohmkeは、AIツールの普及にもかかわらず、手作業のコーディング能力の重要性を強調
- AIがコードを生成しても、開発者が自ら修正・レビューしてこそ効率的だと主張
- 自動化だけに依存すると、実質的な非効率や生産性低下のリスクがあり、"Vibe coding"のようにAIコードを過剰利用すると品質とセキュリティのリスクが高まる
- AIと人間の開発者によるハイブリッドなアプローチが最も効果的であることを、業界トレンドや事例を通じて説明
- 開発者の役割はなくならず、AIと協働しながら戦略的な問題解決や設計能力が求められる方向へ進化している
GitHub CEO、AI時代でも手作業のコーディングの重要性を強調
GitHub CEOのThomas Dohmkeは、ソフトウェア開発の現場でAIツールの活用が広がっているにもかかわらず、手作業のコーディング能力を維持する重要性を強調した
- 「The MAD Podcast with Matt Turck」に出演し、開発者はAIが生成したコードを自分で修正する能力を持たなければ、生産性の低下を防げないと説明
- 効果的なワークフローとして、AIツールがコードを生成してPull Requestを提出し、開発者がスキルを活かしてすぐに修正するアプローチを挙げた
- 自動化エージェントのみに依存すると、ちょっとした修正を自然言語で説明するために不要な時間を費やし、非効率が生じるリスクがあると指摘
- Dohmkeは、「プログラミング言語で自分ですでにできる作業を、わざわざ自然言語で説明しようとするのは最も非効率な選択だ」と述べた
- OpenAI共同創業者のAndrej Karpathyが言及した「vibe coding」は、AI生成コードへの過度な依存を意味する用語であり、Dohmkeはこれについても注意を促した
インサイトと業界動向
1. AIコーディングの最適解はハイブリッド戦略
- Dohmkeの見解は、AI自動化と人間のプログラミングスキルの組み合わせが最適だとする業界のコンセンサスと一致する
- Deloitteの調査によると、開発者はAIツールを主にボイラープレートコードの作成に使っているが、人間による最終レビューを維持することで10〜20分の生産性向上を得ている
- AIが生成したコードの約半分には部分的な誤りがあり、「信頼するが検証する」戦略が業界標準として定着している
- Googleでは全コードの25%以上をAIが生成しているが、それでも人間の開発者による積極的なレビューと改善の工程が不可欠であることが確認されている
- このようなバランスの取れたアプローチは、AIの限界を認識しつつ、開発者の専門性が代替ではなく拡張される方向に業界が成熟していることを示している
2. 開発者の役割は変化しており、なくならない
- AIによってプログラミング職が消えるというより、開発者の役割は純粋なコーダーからAIベースの開発プロセス管理者へと変化している
- 専門家は、開発職がAI活用型プロダクトエンジニアと高度なシステム品質・セキュリティ保証アーキテクトに二極化すると見ている
- この変化は、効果的なAI活用法、戦略的な問題解決能力、高レベルの設計能力といった新たな能力の必要性を意味する
- ソフトウェアエンジニア不足が続く中、AIツールのジュニア開発者支援効果も実証されており、熟練開発者にとっても新たな成長機会をもたらしている
- これは過去に開発ツールや抽象化技術が登場した時と同様に、人間の創造性が依然として必要であることを示唆している
3. 「Vibe coding」の生産性と品質のジレンマ
- 「Vibe coding」という現象は、AI生成コードの生産性上の利点と品質・セキュリティ上の限界を示すトレンドである
- AIツールは迅速なプロトタイピングと反復開発を支援する一方で、コード品質の低下とセキュリティリスクへの懸念も高めている
- 実際の事例では、AIコードを未検証のまま使用したことによるセキュリティ脆弱性が発生している
- 非技術系の創業者が中心のスタートアップなどでは、AIコードの過剰利用が技術的負債を積み上げ、長期的な成長の阻害につながる可能性がある
- 大手IT企業の経験では、自動化と厳格な品質管理のバランスがAI導入の核心であり、スタートアップにとってもこの教訓は重要である
1件のコメント
Hacker Newsの意見
なぜ人々がシステムの本質的複雑性についてもう語らなくなったのか、とても不思議に思う
Fred BrooksのNo Silver Bulletでは、ソフトウェアエンジニアリングの本当の難しさは、中核となる問題空間を理解し、明確化し、モデル化することにあると指摘している。ツールの限界のような偶発的複雑性は二次的なものだ
最近は、AIエージェントがエンジニアの代わりに自然言語プロンプトでコードベース全体を作る、という話が多い。だがこの前提は、仕様(specification)の問題がすでに解決済みだと見なす錯覚でもある。実際には、曖昧なアイデアを詳細で堅牢なシステムへ変えることこそ、依然としてエンジニアの中核的な役割だ
誰かが詳細な仕様を与え、AIと反復的に作業してソフトウェアを作るなら、それは実質的にAIで偶発的複雑性を取り除いているだけだ。これは開発者がアセンブリから高級言語へ移行したのと似ている。エンジニアを置き換えるのではなく、生産性を高めるだけだ。反復作業のコストを下げ、より広く影響力を及ぼす機会も生まれる
もしエージェントがプロンプトだけで製品を作れるなら、それは誰かがすでにシステムを明確に定義してくれたおかげだ。そしてAIで既存製品を複製するだけなら、それは技術的問題の解決ではなく流通やコスト競争の話であり、エンジニアリングの革新ではなくビジネスの革新だ。
自分が何か見落としているのだろうか
仕様(specification)作業がAI登場よりはるか前から軽視されてきた理由こそが核心だ
利害関係者(顧客、管理職)は昔から、なんとなくの感覚でコーディングさせてきた。ざっくり説明すると、誰かが奇跡的にそれに合う解決策を出してくれる、という感じだ。ソリューションが完全に動くかどうかは誰にも分からない。ただ何となく動いているように見えるので通ってしまうことが多い
ほとんどの場合、プログラマがドメイン知識をもとに具体化している (たとえば、正しいフォーム送信ページがどうあるべきかを本能的に知っているから)
今は相手がAIに変わっただけで、このやり方がそのまま繰り返せるのかは見ものだ
本質的/偶発的複雑性の区別は、AIがソフトウェア開発のどこまで担えるかを考えるうえで非常に重要な洞察だ
多くの開発者は、なぜAIに置き換えられないのかを言葉で説明できなくても、本能的にはこの点を感じ取っている
実際、自分もClaudeのようなエージェントに、非常に複雑で外部のビジネスロジックが絡む大規模コードベースの問題を解かせようとしたことがある。だがAIはビジネス要件や文脈をきちんと直感できず、ビジネス寄りのコード変更はできない。文脈が狭い単純なコード変更を助けられる程度だ。つまり、偶発的複雑性しか処理できず、本当の開発者の役割である実際の要件をシステムに翻訳することには限界がある
付け加えると、実際には多くの開発者が解いているのは技術的問題ではなく、流通/市場の問題かもしれない。AIでジュニアを置き換えるのはまだ不安がある。最大の問題は、AIが自律的に自己修正できないことだ。それでもAIベースの事業者が既存ビジネスのコストを下げようとする試みは続くだろう。その変化が良いか悪いかは、仕事を追われる側にとっては大した意味がない
「自分は何か見落としているのか?」への答えがある
実際にはソフトウェアを使えない開発者がものすごく多い。こういう人たちはAIで簡単に置き換えられるだろう
以前のキャリアではJavaScriptで働いていたが、本当に驚くようなことをする人たちは、趣味で開発してきた人たちだけだった。会社では大半の人が画面にテキストを表示することすら苦労していた。冗談ではない
多くの人が巨大なフレームワークに挑戦したが、結局はコピペばかりで、何とか動かすのが精いっぱいだった。高度な複雑性を解決しているふりをしているが、ほとんどは不要な作業かコード自慢にすぎない
オリジナルのアプリを作る力や、文書作成、実際の使い勝手を測る能力がほとんどない
これをどう解決するのか? 法曹界の司法試験のような高い基準を導入し、基準を超えられない人は思い切って排除し、ジュニアや見習いとしてのみ採用すべきだ。そうして初めて開発者の世代がきちんと育つ
見落としている点への簡単な答えは、業界で"No Silver Bullet"を読んだ人がいないことだ
技術的負債やシステムアーキテクチャについて書く人たちは、実際にチームやビジネスを左右する意思決定者ではなく、そうした本もエンジニアにとっては任意の読み物にすぎない
AIでコーディング代替を語る人たちは、MVPを作ることと、10年かけてコードベースを拡張しレガシーを改善することの違いを分かっていない場合が多い
たとえば、あるマネージャーは1日に3つのプロジェクトへそれぞれ33%ずつ時間配分しようという、典型的に間違った提案をしたことがある。人員配置や時間の構造化は管理職の能力であるべきなのに、結局きちんと処理するのはエンジニアの役目になる
今やそういう管理職たちが「AIにすべての技術的負債やテストを解決させよう」と言い出し、うまくいかなかったときの説明までエンジニアがする羽目になる
複雑性の議論とは、実のところマネジメント不全の問題の繰り返しにすぎない。すでに大半の経験豊富なエンジニアは、自分の仕事が簡単なプロンプトで代替されるとは信じていない
本当に語るべきテーマは、「ソフトウェアエンジニアリングはマネジメントの問題が深刻で、AIはそれをさらに浮き彫りにしている」ということだ
多くの非開発者や学生は、ソフトウェア開発では複雑なツールの使い方を覚えなければならないと感じ、「仕様さえうまく作れれば誰でもソフトウェアを作れる」という約束に引きつけられる (仕様策定そのものが非常に難しく、支援技術が必要だという点は都合よく省かれている)
以前のノーコードもこの手の話で、実際にはノーコードツールは限定的で、機能が強力になるほど、より複雑で専門的な学習が必要になる
LLMによるSWE代替論も結局は、「システムを学ぶ代わりに自然言語でプロンプトすれば、モデルが勝手にツールを使ってくれる」というバージョンだ
こうして見ると、最近言われるvibe codingは事実上その目標の極致だ (ただし、保守性など実務上の弱点はある)
自分には、マネージャーがSWEをなくしたがる理由の一つは、SWEとうまくコミュニケーションできないことにあるように見える
LLMを使えば「ナード(開発者)」抜きで機械と対話できるので、その問題が解けると考える傾向がある
プログラミング言語は、望むプログラムの精密な仕様に適した媒体だ。自然言語は決してそのレベルの明確さを持てない
だからAIが生成した結果をレビューして編集するのは当然だ。場合によっては、変更内容を説明するより自分で直した方がむしろ簡単なこともある
Copilotがエラー率を増加させるという独立研究の結果が、自然と慎重な姿勢を広めた要因ではないかと思う
AIを売る人たちは、人間の著者はまもなく不要になると主張することが多い
Transformerは自動テスト、仕様の拡張、新規プロジェクトの加速、未知のAPIの探索、初期機能の構築、コードレビューなど、さまざまな仕事に適用できる
たとえコードが仕様の正しい媒体だとしても、Transformerは自然言語とそのメディア(コード)の間の自動化インターフェースとして機能する
最近のTransformerは膨大な知識のおかげで、コード生成自体には問題がない
人間がプログラミングで自動化を追求してきたように、Transformerは大きな飛躍だ
将来のある時点では、AIによるプログラマ代替が現実になる可能性はある (過去に自動織機、印刷術、電子計算機が人間の作業を代替したように)
ただ、今すぐ、あるいは10年以内に起きるとは限らず、今後も幻覚(hallucination)、精度、ツール化、インフラ構築など課題は残る
プログラミングの仕事があるかどうかは、ドメイン、実力、報酬期待値によって変わりうる
AIツールを真剣に受け止め、適応することが重要だ。そうしなければ、パーソナルコンピューティングやインターネット導入時のように変化に取り残されるおそれがある
AIの疑似創造性には限界があると思う
すべてのLLMの学習結果が再びLLMへの入力として循環するだけなら、新しいアイデアの範囲は決して広がらない
人間はその範囲の外へ出入りする創造性を示し続けている
将来LLMがその壁を越えるかもしれないが、今のところは『無限の猿定理』と大差ない
自分の経験では、LLMはスキャフォールディング(足場づくりツール)として使ったときに最も効果的だ
作りたい機能を頭の中のダンプのように伝え、するとそのモデルと、そのモデルに必要な基本コントローラを作ってほしいと頼む
あとはビューと実際のビジネスロジックだけに集中すればよいので、役割分担が明確になる
昔、高級言語が初めて登場したとき、超初期には今のLLMや自然言語コーディング批判に似た、「メモリを直接制御しにくいので精密さが足りない」といった批判があったと聞いている
問題は、自然言語では精密性が不可能だということではなく、たいていの人が精密でない形で要求を説明し、自分が望むことだけは明確でも、コンピュータに実際に何をさせるべきかをきちんと説明できないことだ
その結果、エンジニアがビジネス要件を翻訳するときに大量の推測をするか、LLMがその役割を担いながら、より少ない文脈しか理解できないという状況が繰り返される
AIの最善の使い方は、初めて触るAPIや面倒でやりたくない機能で詰まらず、フロー状態を維持することだ
AIはコード全体に共通パターンを素早く効率的に適用できるが、本質的には**『何をしているのか自分では分かっていない』**
最近の経験を共有すると、ポップアップサイズの計算と位置決めに関するコードをLLMにリファクタリングさせようとした
一方は"if"、もう一方は"switch"で書いてあったのだが、LLMはこの二つの違いにまったく柔軟に反応できず、明確に説明しても、両方をifかswitchのどちらかに統一してしまった
LLMは前のトークンのパターンを維持し続ける傾向がある
ここでは大きな問題ではないが、もう少し複雑な状況になると、細部を無視して表面上もっともらしいコードを出してくる
その代わり、小さな単位に分解して明確に指示すれば、LLMはかなり効率的だ。たとえば、「m_StateStorageにサイズを保存してからレンダリング段階で適用」といった指示は簡単にこなす
特にCerebrasのように、数キロバイトのコードでも高速に処理できるモデルと組み合わせれば、自分の考えをそのままコードとして入力するよりずっと速い
結局、今日評価しているのはトランスフォーマーモデルの現在の性能に限った批判だ
この業界は非常に変化が速いため、今日の限界が1か月後には意味を失っているかもしれない
「LLM」も厳密に言えば曖昧な表現だ。最新のトランスフォーマーモデルはマルチモーダルであり、テキストだけでなく複数の形式のデータを扱う
したがって、あえて批判するなら、どのモデル/ツール/パラダイムを指すのかを具体的に示さないと議論として実効性がない
「ソフトウェアエンジニア不足」および「AIがジュニア開発者に特に役立つ」という研究結果について
自分が生きている世界線(現実)では、テック就職市場は最悪で、AIはむしろジュニアが成長すべき場所から経験を奪い、不利に働いている
最近Claudeで面白い経験をした。Zedで「71行目のエラーを直して」と命じたら、91行目で無駄なフォーマット変更ばかりしてきた
まるでLLMと伝言ゲームをしているようだった
こんな簡単な修正ですら自分でやった方が速い。この別の体験からも、「LLMは本当に考えていない」という感覚を改めて確認した
LLMは行番号の認識がひどく苦手だ
こういう経験から、「LLMは行番号を数えられない」という教訓を得た
次は「関数XYZのエラーを直して」と言うか、その行自体を直接貼り付けて指示した方がよいだろう
そしてもちろん、LLMは考えているわけではない。単なる巨大な方程式にすぎない
このスレッドにはAIでコーディングするのが初めての人が多そうだ
オペレーターのミスかもしれない
LLMには適切なコンテキストを与える必要がある。行番号は不適切なコンテキストだ
自分の基準では、ソフトウェアエンジニアの役割は要件をソフトウェアに変えることだ
ソフトウェアは単にコードだけではなく、要件も単純な自然言語だけで与えられるわけではない
現時点では、AIと一緒に作業しても、自分の速度がAIより速くなるわけではない (単純作業や小規模ソフトウェアを除けば)
現在のAIは自分の基準ではジュニア/ミッドレベル開発者程度だ
ここ2年ほど、AIが体感的に飛躍的によくなったとは感じていない
ほとんどの要件は明確に文書化された形では出てこない
ビジネスロジックが何かを知っている人もほとんどいない
そのため、ソフトウェアエンジニアが自分で探し回って聞きにいかなければならない場面が多い
ソフトウェアの成長方向と、どう設計すればその拡張性を確保できるかを考える経験と直感も求められる
LLMがこうした役割を少しでも果たせるとは想像しにくい
明確な要求事項が与えられたソフトウェアプロジェクトなど、一度も見たことがない
プロジェクトの半分は「本当に欲しいものが何なのかを見極めること」だ
LLMはまだジュニアレベルにすら達していない
もし現存するAIが御社のミッドレベル開発者級に見えるのだとしたら、それは会社の採用の問題だ
コンピュータの最大の利点の一つは、信頼できて再現性の高い自動化だ
プログラミング言語のような形式言語は、望む自動化要件を曖昧さなく明確に伝えられる
自然言語はそこまで精密ではない
プログラムの本当の拠り所(ground truth)は結局コードだ
人間がプログラムの動作を正確に制御したいなら、コードを理解し修正できる能力こそが最も重要だ
「manual(手動)」という単語には否定的なニュアンスがある
該当記事で意図されていたのは「人間によるコーディングが依然として中核だ」ということだ
GitHub CEOが本当に"manual"という言葉を使ったのかは定かではない。もっと中立的または正確な語を選んだ元記事ソースがあればよいのだが
人間のコーディングを「manual」として貶めるのは望ましくない。人間の開発者もAI以外のさまざまな自動化ツールキットを使っている
「手動の思考」と同じくらい否定的かもしれない
"manual"の否定的な意味合いは初めて知った
最近は手作業にそこまで反感を持つものなのか気になる
"manual coding"と"human coding"の違いは何なのか気になる
「AIエージェントだけに依存すると非効率になりうる」
たとえば、単純な変更を自然言語で長々と説明するより、自分でコードを編集した方がはるかに速いことが多い
したがって、AIエージェントとの積極的な相互作用こそが最適なワークフローになるだろう
変更内容を自然言語で考えているうちに、入力する前から、必要な直接修正の方法が頭に浮かんでいることがよくある
コンテキストの多い変更ほど、自分の方がagentより速く直せる気がする
どの程度の積極的な相互作用がちょうどよいのか気になる
最近エージェントツールのスタートアップに加わったのだが、社内でこうした点をかなり議論している
「正直、これ全然うまくできてない!」とエージェントに継続的にフィードバックするのはよいと思うが、ある部分では疲れるかもしれない
どう思うか、ワークフローについての想像や追加のフィードバックも聞きたい
AIはまだ期待された地点まで達していない
たとえば、自分はしばしば誤った参照資料や仕様に悩まされる。これはAIが古いデータで学習されていて、リアルタイム更新能力が不足しているためだと思われる
現在のLLMとGIソリューションは、すべての段階(n-step)を一度に解こうとして、かえって有用性を落としている
1段階からi段階くらいまでをきちんと処理してくれるだけでも、人間にとってはずっと役立つはずだ
まだ自分の望む完全モジュール型AI(たとえば、自分のgithubスタイルを反映し、a、b、cのリソースだけを参照して問題xを解く)ソリューションは見ていない
そして、問題を順番に探索しながら、途中でより多くの質問を投げかけ、対話してくるコーディングAIが現れることを期待している
AIとコーディングについて、やや異なる方向の意見を述べるCEOなのが印象的だと感じた
一般にCEOや投資家は「全コードの30%以上をAIが書く」として開発者の役割縮小を予見しがちだが、実際には同じ開発者たちがより速くコードを書けるようにツールを使っているだけ、という診断だ
実際にコードを書くこと自体は、ソフトウェア開発業務の一部にすぎないことを強調している