私たちは今や皆、AIエンジニアかもしれない

46日前原文(yasint.dev)

概要

AI活用による開発体験の変化と加速
設計力・直感力の重要性の増大
AIとエンジニアの役割分担の本質
基礎知識の価値と学習環境の進化
チーム選び・未来像におけるAIへの姿勢の重要性

コードを書く楽しさとAI時代の変化

コードを書く喜びは変わらないが、開発の周囲環境が劇的に変化
最近はAIエージェントやツールの開発、AIを監督するシステム構築、モデルのトレーニング、パイプラインの設計が主な仕事
AIが重労働を担い、自分は思考や設計に集中する開発体験
AIモデルの性能向上は周知の事実だが、ほとんどの人は本質を見落としている
AIによる自動生成コードは無指導では「スロップ（雑なもの）」だが、適切に導けば多くの開発者より優れたコード生成が可能

AI時代のソフトウェア開発術

何を作るか・どう動かすかを明確に設計できる人間が、AIを最大限活用できる
設計力・トレードオフの理解・アーキテクチャ選択が決定的なスキル
AIが複雑な処理（グラフ探索・ハッシュ戦略・AST解析・ファイル監視など）を実装し、自分は全体設計や状態変化時の挙動設計に注力
かつて数日かかっていた本格的なソフトウェアを数時間で出荷可能
デバッグもAIエージェントが分担し、複数の視点で同時調査が可能
直感や判断は自分が担い、AIはその加速装置

AI活用で変わる開発現場

ボイラープレートやCLIの手作業生成は不要になり、手間が大幅削減
AIが成果物を出すだけではなく、設計・分解・パターン選択・軌道修正は人間の役割
直感や基礎がないとAIは「スパゲッティコード」や拡張性のない設計を量産
モデルは悪い意思決定を防げない、むしろ加速させる危険も

エンジニアの新しいスキルセット

コーディング自体より、設計・要件分解・良し悪しの判断力が重要
**基礎知識（データ構造・計算量・デバッグ手法など）**がAI活用の前提条件
AIの出力が間違っている時に気づける力が不可欠
基礎がなければ、AIから何も引き出せない

学習環境と成長のチャンス

基礎知識や直感力は今や「門戸開放」、学習リソース・ツール・メンターが充実
学び直し・新規参入のハードルが史上最低、今からでも始められる
経験を積んだエンジニアは「置き換え」ではなく「増幅」される存在に

AIエンジニア時代のチーム選び

チームや職場選びで重視するのは「AIへの姿勢」
**ツール導入の有無より「好奇心・関心・学び続ける姿勢」**が重要
AIは一過性の流行ではなく、今後の方向性

AI活用の現実と限界（追記）

AI生成コードは全てレビュー、理解できないものは出荷しない
AIへの丸投げと適切な活用の違いは「スコープ管理」
- 小さく明確なタスクや検証可能な出力にはAIが最適
- システム全体の文脈や深い知識が必要な問題は自分でやる方が速い
道具を使うタイミング・使い分けが半分はスキル
自分の知識・直感は全て「人からの学び」や「失敗経験」の積み重ね
基礎を学んだ理由は、ツール進化後も変わらない

これからのエンジニア像

**AI時代のエンジニアは「AIエンジニア」**という新しい立ち位置
自分の成長やチーム選びの基準は「AIへの好奇心・関心」
今後も学び続ける姿勢が、エンジニアとしての価値を決める

Hackerたちの意見

毎日、同僚のエンジニアからAIがコードベースでやらかしたバカなことのスクリーンショットが送られてくるけど、AIが静かに書いたコードがほとんどのエンジニアよりも優れていることには誰も触れないんだよね。「ガイド付き」の部分のポイントは、すでに優れたエンジニアが必要だってこと。世界中のエンジニアと働いてるけど、スキルレベルはバラバラで、AIはそのギャップを埋められてない。一般化するけど、AIがカリフォルニアのスタートアップで働く典型的なエンジニアの仕事を10倍にするのは見える。君の好奇心に関するコメントもこれを強調してるよね。さらにK字型のエンジニアリング労働力が始まってる感じ。以前はあまり優れたエンジニアじゃなかった人でも、好奇心があって学ぶことが好きだったら、今は新しい構築方法を学ぶために超充電されてるし、試してみて、間違いから早いペースで学べるようになってる。残念ながら、この好奇心を持ったグループは、私の意見では少数派だね。

└

好奇心の部分には同意するよ。私はCSのバックグラウンドはないけど、好奇心からプログラミングを学んだんだ。それがきっかけで、実際に企業が使うプロダクションアプリケーションを作ったし、これがAI時代の前の話。今はAIがいるから、まるで自分のアシスタントエンジニアがいるみたいで、ワクワクするものを作る手助けをしてくれる感じ。

└

エンジニアは問題に気づいたら戻ってきて修正するか、誰か修正できる人を探すよ。でもAIは、君のコードベースをめちゃくちゃにしながら、ハッピーな絵文字を送って、完全にメンテナンス不可能な状態に持っていくんだ。

└

私はこの「好奇心」のキャンプにしっかり入ってるよ。ここ15年くらい（？）HNを読んできた。CSを中退してアートの学位を取った。キャリアは別のところにあるけど、その過程でシステムを理解することが趣味だった。いつかすべてを止めて「本当のエンジニアリング」を学びたいと思ってたけど、結局やらなかった。代わりに、自由な時間に企業ソフトウェアアーキテクチャ、プログラミング言語デザイン、コンパイラ最適化、オープンソースの政治についての難解な記事を何百（何千？）も読んできた。私には持ってない暗黙の知識がたくさんある。持ってないって分かってるのは、他の分野ではその知識を持ってるから。自分が「本当のエンジニア」であることについて知らないことがあるってことも分かってる。でも、味覚は知ってる。どんな質問をすればいいかも分かってる。魔法の言葉や答えを探す場所も知ってる。私みたいな人にとって、これは狂ったような黄金時代に感じる。アイデアには困ってないし、今は手や目、いい週にはトークンが足りないだけだ。

└

> でも、誰もが言わないのは、エンジニアのほとんどが書けないようなコードを静かに何百回も書いていることだ。こういうことが起こるのは、a) ランダムで、b) 滅多に起こらないから？

└

一つの問題は、開発者たちが過去数十年にわたって、Googleに関連するキーワードをいくつか入力するだけでオンラインで問題の解決策を探すように訓練されてきたことだよね。でも、AIを最大限に活用するためには、まるでイギリスの王室に正式な手紙を書いて背景を説明するかのように、しっかりとプロンプトを作るべきなんだ。基本的な英語のライティングスキルと、自分の考えを明確にまとめる能力が、エンジニアリングにとって必須のスキルになってるんだよね（でも、実際には多くの開発者がこれを欠いている）。

└

でも、それが問題なんだよね。時にはすごく信頼できるものが、他の時には全然ダメになることもある。自分自身や同僚を見ていて、LLMを使うことで早く燃え尽きたり、認知負荷が高くなったりするのを見てきた。もうただコードを書くんじゃなくて、何をする必要があるかを考えて、他の誰かが書いたコードのように見直すことになる。LLMは迅速なプロトタイピングやボイラープレートにはすごく役立つけど、私自身も毎日使ってるけど、Claudeが犯すミスの量は無視できないと思う。

└

K字型の労働力の話は鋭いね、あなたが正しいと思う。好奇心旺盛な人たちは少数派だけど、彼らが常に物事を前に進めてきたんだ。AIがそのギャップをもっと見えるようにしただけだね :) あなたのCodexのケーススタディ、コンテンツクリエイターとの話は面白い。生物学の博士号とライティングの修士号を持って内部ツールを作るなんて…まさに「今は何でも学べる」って言ったのはこういうことだよ。私の職場には博士号や教授がたくさんいて、物事が進んでいることに本当にポジティブな気持ちを持ってる。彼らは深い専門知識を持っていて、今は必要なツールを作れるようになったんだ。面白い時代だね。ぜひそれを書いてほしいな。

└

これも私の経験だよ。また、シンプルさを追求せず、アーキテクチャを考えない人たちは、非常に不安定で更新や強化が難しい巨大なモンスターを作り上げることになる。彼らは通常、自分たちの混乱を解決するために別のエンジニアを探すんだ。新しいエンジニアにとっては、簡単な方法はアーキテクチャを整えて、Claude Codeで一気に作ることなんだけど、彼らは自分たちの混乱に囚われていて、それを手放せない :(

└

ちょっと優しく言おうと思うんだけど、これはすごく軽薄で、人々はこれを不快に感じたり、嫌悪感を抱くかもしれない。すべての抵抗や懐疑心を無関心に丸め込もうとするのは、もしかしたらAI批判者をさらに遠ざけることが目的なのかもしれないね。そういうことなら、そのまま続けて。だけど、もし本当に仲間の態度に困惑しているなら、「自分には何が足りないのか？」（「好奇心」？）じゃなくて、「彼らは何を見ているのか？」とか「彼らは何に関心を持っているのか？」って聞いてみたらどうかな？もしかしたら、彼らは仕事の性質の変化に対して熱心じゃないのかもしれないし、「自動化の自己満足」が進むことを心配しているのかもしれない。特に「何百回も」まともなコードを書くのに対して「何かバカなこと」を一度書く割合があるから、たまにその「バカなこと」が彼らを通り過ぎて、AIの利点を全部消し去ることを恐れているのかも。もしかしたら、彼らは「典型的なコードがほとんどのエンジニアよりも優れている」とは感じていないのかもしれないし、「学び」がほとんど一時的なものだと感じているのかもしれない。去年の「プロンプトエンジニアリング」のアドバイスが今でも通用するのはどれくらいある？選択肢はあるし、彼ら（私たち？）を恐れや愚かさ、あるいは「無関心」から古い方法にしがみつくラダイトとしてレッテルを貼るのは簡単だけど、本当に理解したいなら、あるいは誰かの考えを変えたいなら、ぜひ彼らが本当に考えていることを聞いてみて、耳を傾けてみて。

└

> でも誰も、ほとんどのエンジニアが書けるよりも優れたコードを静かに何百回も書いていることには触れない。あなたの経験は、私の正反対だよ。私は、LLMが完璧に一発で成功するって言ってる人が常にいる。友人グループや同僚、さらにはここHNでもそうだ。大手テック企業も同じことを言ってることが多い。ごめん、でも誰も成功について話さず、失敗にだけ集中しているって言うのは全く誠実じゃないよ。あなたはそのグループが少数派だと言ってるけど、すべての証拠は逆を指し示している。もし人々がそれが役に立つと信じていなかったら、LLM企業はそんなに成功していないはずだ。

「今、何かを作ってるんだ。詳細には入らないよ。アイデアを教えるわけにはいかないから。」ってところで、もうダメだわ。

└

もしかしたら、今は実行が安くてアイデアが高いのかもね。個人的にはこの逆転に満足してるよ。

└

AIのハイプを語ってる連中が、自分の10個のOpenClawインスタンスが動いてるって言ってるのを見るのはちょっと面白いね。で、何をしてるのか聞くと、いつもはっきりした答えが返ってこない…でも、エージェントコーディングは好きだよ。ソフトウェアの蓄積されたゴミを処理してくれるから。

└

それは分かる。どう読まれるかも知ってる。でも、誰でもノートパソコンとサブスクリプションがあれば、週末にプロダクションソフトウェアを出せる時代だから、アーキテクチャやアイデアがもっと重要になってくるんだ。投稿の技術的な詳細は本物だよ。ただ、何を共有できるかはまだ言えない。受け入れるか、受け入れないかだね。

> でもガイド付き？モデルはほとんどの開発者よりも良いコードを書けるんだ。それが人々が直視したくない部分。ガイド付きの時に、どこで十分なガイダンスと過剰な手取り足取りの境界を引くの？ある時点で、自分でやった方がいいんじゃない？プロジェクトを終わらせるために（過去の多くの普通の開発者がやってきたように、筋肉記憶や経験、将来のプロジェクトのためのメンタルモデルを構築しながら）。

└

境界線はスコープだよ。エージェントにフルスタックアプリを作ってもらうつもりはない。そうなると、幼稚園児のように世話をしなきゃいけなくなって、正直、自分でやった方が早いから。エージェントの使い方は、集中して文脈に基づいて、一度に小さなタスクに焦点を当てることなんだ。例えば、依存関係グラフを受け取って、トポロジカルソートして、特定のノードが変わった時に影響を受けるノードを返す関数が必要だとする。それはスコープが明確だよ。エージェントがそれを書いて、私がレビューして、終わり。でも、Postgresで接続プールのリークをデバッグしている時、負荷の下で接続が解放されないのは、リトライループの中でトランザクションが開いたままになっているからだ。そんなのをエージェントに任せるつもりはない。私たちのシステムはもう分かってるし、どのサービスが問題を起こしているか、ORMレイヤーも、接続ライフサイクルが管理されている場所も知ってる。エージェントを適切にガイドするために必要な文脈を書くのにかかる時間は、コードを開いて自分でトレースするのにかかる時間よりも長くなるだろう。それが境界線だよ。提供する必要がある文脈がタスク自体よりも大きいなら、自分でやった方がいい。タスクが明確に定義されていて、出力が簡単に検証できるなら、エージェントに任せればいい。でも、筋肉の記憶の話は本当だよ。新しいことを学んだり、まだ理解していない領域を探る時は、まだ手書きでコードを書くことがある。AIは不慣れな領域で直感を育てるのにはひどくて、理解できない出力を評価できないからね。でも、日常的なスキャフォールディングやボイラープレート、繰り返すことに関しては、私は手書きしないよ。人生は短いから、50回目のRESTハンドラーを手書きするのは無駄だよね。

彼らは絶対に認めないけど、多くの人が仕事を失うことを恐れてるよね。この脅威は、まだ現実にはなってないけど、経済的な観点から見るとかなりリアルだよ。AIがどうこう関係なく、生産性を向上させるツールは、労働力の削減につながる可能性がある。ちょっと単純化した例を考えてみて。君はパン屋を経営してるとする。10人がいて、月に1,000斤のパンを作ってる。今、新しい半自動オーブンが導入されて、同じ量のパンを5人で作れるようになった。君には選択肢がある。5人を解雇するか、月に2,000斤のパンを生産するか。でも、街はそんなにたくさんのパンを本当に必要としてるのかな？さらに悪いことに、競合他社も同じ半自動オーブンを持ってるんだよね…

└

> ちょっと単純化した例を考えてみて。君はパン屋を経営してるとする。10人がいて、月に1,000斤のパンを作ってる。今、新しい半自動オーブンが導入されて、同じ量のパンを5人で作れるようになった。実際、最近の多くのパン屋でそういう状況があるんだ。でも大きな違いは、パン職人は形や材料がほぼ100%正確に再現されることを信頼できるってこと。何度オーブンを使っても、毎回同じようにね。オーブンの「最適な使い方」を考える必要もないし、「以前の10倍の量を焼く」なんて主張もしない。半自動オーブンは本当にちゃんと機能するんだ！これに近い体験を提供できるLLMを見せてほしい。

└

ちょっと単純すぎるかな。パン屋は製品の種類を増やしたり、他のことをして仕事を増やすことができるよ。実際、これはテック企業でも同じことが起こると思うんだ。

└

もしかしたら、パン屋はパンだけじゃなくて、ケーキやサンドイッチを作ったり、近くの町への配達を増やすかもしれないね。

└

もう一つの話だけど、もし100人のエンジニアがいて、そのほとんどを解雇して5人のスーパーAI加速エンジニアだけを残したら、競合が50人のエンジニアを残している場合、競合はまだ10倍の速さでイテレーションできる。だから、結局は人を解雇しても、遅れをとるリスクがあるんだよね。

└

ソフトウェアを作る行為を工場のライン作業に還元するのは無理があると思う。特にアムダールの法則を考えるとね。

└

ソフトウェアを書くのは、需要が固定された小さなパン屋みたいじゃない。常に作るべき機能や改善点が、キャパシティを超えてあるからね。良くも悪くも、ソフトウェア製品は決して完成しないんだ。

└

ソフトウェアに関しては、月に2,000個のパンを生産するって考え始めてる。今、ソフトウェアは供給に制約があったことに気づいて、組織はどのアプリやUIを作るかを非常に戦略的に考えなければならなかったんだ。今は、何でもアプリになり得るから、以前は見落とされていたビジネスユニット向けにもっとターゲットを絞ったフロントエンドを作れるようになった。

問題は、しばらくすると怠けて「デザインをリードする」ことをやめてしまうことだと思う。まあ、それはいいことだと思うけどね。ほとんどのコードは使い捨てのものだから。プロジェクトやアプリを何度も書き直すうちに、「適切な」アーキテクチャに注意を払う価値が出てくるんだ。10年前にこんなAIがあったら、フレームワーク開発者やエンジニアになる代わりに、作りたいものに集中できたのに。

└

同意するよ。俺も時間が経つにつれて怠けてきた。でも、コードを作るコストがすごく安くなったから、初めてプロダクションに出すときに完璧であることがそれほど重要じゃなくなった。すぐにゼロから書き直せるしね。「メンテナンス性」のハードルもかなり下がった。AIがひどいコードを維持する能力と持続力を持ってるから。多くの人が俺に反対するだろうけど、俺は手動でプログラミングするのが得意だし、もうそれをする必要を感じない。人のために何かを作りたくてこの世界に入ったんだし、AIのおかげでそれがもっと効率的にできるようになった。そう、コードの品質に対する純粋主義的なアプローチを手放さなきゃいけなかったけどね。

└

> 10年前にこれらのAIがあったら、フレームワーク開発者/エンジニアになる代わりに、作りたいものに集中できたのに。特にテストが組み込まれたフレームワークは、今やガードレールとしてさらに重要だと思う。

「今は何でも学べる。何でも。」これはLLMが登場する前から真実だった。変わったのは「答え」を得るのにどれだけの労力がかかるかってこと。LLMがその答えを渡してくれると、自分で（痛い思いをしながら）答えを導き出すことで得られたかもしれない学びを放棄することになる。トレードオフがあるんだよね：今答えを得ることと、未来のために学ぶこと。最近、LinuxプログラムをWindowsに翻訳するためにLLMを使ったのは、プログラムが今すぐ必要だったからで、WindowsのAPIを学ぶよりもそっちが重要だと思ったから。でも、その学びの機会を手放したのは確かだね。

└

本は、知識を暗記できない精神的に弱った人のためのものだ。 - ソクラテス

└

これにはちょっと異議を唱え始めてる。少なくとも、普遍的な真実かどうか疑問に思い始めた。例えば、「学び」というのは、間違ったアドバイスを何度も試して、やっと成功するための練習みたいなことが多い。AngularアプリがクライアントとSSRの両方で安全に動いている絶対パスを取得する方法には明確な答えがあるけど、そのタスクを達成するために間違った方法でやっている人がたくさんいる。こういう場合、LLMは最初から正しい答えを教えてくれることが多いし（それによって間違ったことを教えようとする過程での「ノイズ」が少なくなる）、その答えがどう適用されるかを説明してくれることも多い。私たちは過去30年間、「学ぶ」ということの意味を、検索エンジンが学びのインターフェースだった頃に多くの真実を持つバケツに精練してきた（その前は教科書を読むことだった）。この言い回しは、労働組合の仕事での「年功序列」や似たような形のゲートキーピングのように聞こえることもある。とはいえ、確かに「長い」方法で何かを学ぶことが、私たちの長期的な記憶や理解を価値ある形で広げることもある。だから、LLMを使うのはまだ私にとって難しい選択なんだ。経験が多い人にとっては、二つをより自信を持って区別できるから、選択はそれほど難しくないと思うけど、LLMを通じて学んだり達成したりすることが常に自己破壊的な道だとは思わなくなった。

└

結局、経済とその人自身、そして自分に対する態度に行き着く。深く学ぶ価値があるものもあれば、場合によっては簡単で早い解決策が求められることもある。最近、AIを使った「学び」のいくつかは、昔のCliffs Notesを使うこととあまり変わらないんじゃないかと思ってる。時にはCliffs Notesの要約を得ることで、論文を仕上げる方法や、退屈な/挑戦的な本（『緋色の手紙』、合ってる？）を素早く読み終える方法になることもあった。そして、場合によっては要約を読む方が本そのものよりも良いこともある。でも、みんなが同意できると思うけど、もしCliffs Notesだけを読んでいたら、自分の教育を台無しにしているだけだ。それは別の、もっと深い問題で、一部の人は自分に投資することに全く興味がない。彼らは最小限の労力で最大の報酬を得て、楽しむことを望んでいる。人が自分自身や成長、発展に興味を持つようにすること、好奇心を招くこと、それは時代を超えた問題だね。

└

私の解決策は優先順位をつけること。人生の中で全てを学ぶ時間は十分にないからね。深く学びたいことを選んで、苦労して取り組む。そして、あまり気にしないことについてはAIにお任せ。

└

これについては複雑な気持ちだ。片方では、LLMが少なくとも表面的には「ピンとくる」説明を見つけるのを楽にしてくれると思う。確かに、以前は利用できたけど、教科書にお金を払わなきゃいけなかったり（なんて素朴）、検索結果の5ページ目に出てくるウェブサイトにあったりした。短期的には、そういう外部的な要因が学習者にとってプラスになるかもしれない。一方で、学ぶことは行動することだ。少しでも難しくないと、それはおそらく学びではない。これは厳密にはLLMの問題じゃなくて、YouTubeの教育者に対しても同じ問題を抱えている。数学や物理の問題の素晴らしい視覚化を見ていると、学んでいるように感じるけど、実際には問題解決の筋肉を使っていないから、何も賢くなっていない。そういう体験を何度もしたことがある。誰かがLLMにELI5を頼んで、それを会話に活かそうとしたけど、返ってきた抽象的なものは彼らには深い意味があるように感じるけど、実際には役に立たないし間違っている。

└

作者が言いたいことはそうじゃないよ。毎日何回も、特定のコードや一般的な技術についてLLMと会話してる。これは同僚と同じ会話をするのにすごく似てる。確かに、LLMが間違えることもあるけど、そのために自分でコードを見たり、外部のドキュメントを探したりして、説明が正しいか確認してるんだ。重要なのは、LLMが僕のためにコードを書いてるわけじゃないってこと。説明をしてくれて、僕はそれを自分の仕事に応用できる検証可能な事実や概念的な枠組みを得てるんだ。

└

物事がこんなに変わっている中で、将来何が価値を持つかは不確かだね。

└

今はLLMのおかげで学ぶのがすごく早い。ウィンドウズのAPIを学びたいなら、もっと早く学べるよ。

└

大学の終わり頃に友達が言ってたことを思い出すな。「知ってることを全部学ぶのに年間1万2000ドルだけだよ」って。あんまり真に受けない方がいいけどね。

└

AIは、何も学ばずに実現するオプションを提供してくれるんだ。もし学ぶことが目標なら、学びを加速する手段もあるよ。

テクノロジーの世界にいなくて良かったと思ってる。もうこれをやりたくないから。これはAIを批判するつもりじゃないよ。この記事をそのまま受け取るなら、AIは人々をもっと生産的にする、彼らがエージェントを適切に操るためのセンスと知識を持っていると仮定してね。それは一時的に経済に悪影響があるかもしれないけど、良いことかもしれない。>でもAIがトラバーサルロジックやハッシングレイヤー、ウォッチループを書いているんだ。残念ながら、それが私がやりたいことなんだよね。それに、コンピュータとコミュニケーションを取るのが好きなんだ。エージェントにそれを委任したくない（もちろん、多くのエンジニアのように、アセンブリからC、Java、Scalaと、どんどんコンピュータとの間にレイヤーを増やしているけど、これはもっと大きな飛躍に感じる）。

└

もっと早くHCOLに引っ越していれば、もっと早くあなたのようになれたのに。終わりまでにもっと時間がかかると思ってた...

└

僕はリストラされた開発者で、今は全く新しい仕事を探してるんだ。正直、AIと関わるのには全然興味がない。つまらなそうだし、その考え方もなんか気持ち悪いんだよね。

└

テック業界で働いてるけど、最悪なのはAIが支配するために集まった悲惨な要素を目の当たりにすることだね。いくつかの要因があって、ほんとに落ち込む。1. 経済的生産性と、会社が成功するための意味が、良い高品質な製品を作ることから切り離されてしまった。今や株式市場が最終目標だ。2. AIは開発者が自分のコードを理解することが良いという考えを強く拒否しようとしている。これは客観的に間違ってるけど、開発者を代替しにくくする無形のスキルだから、経営陣が必死になってるんだ。3. 開発者が個々に力を持ちすぎて、AIは労働力の力を削ごうとする現代の試みのように感じる。4. 短期的な利益のために長期的な生産性を犠牲にすることは常に可能だった。シニア開発者であることは、このトレードオフを理解し、後で自分を困らせるようなものを「今すぐ」出すように経営陣からの圧力に抵抗することを意味する。5. AIが長期的に時間を節約する唯一の方法は、自分で書いたのと同じくらいその出力を理解しない場合だ。コードや大規模なアーキテクチャを理解することが重要だよ。長期的な生産性の高いコードを書くことを望むなら、余分なステップを導入してしまったから、逆に時間を浪費してる。6. 残念ながら、多くの開発者は良いコードを書くことに興味がない。適当なものを出しても、クビにならなければそれで十分。もう製品を作ることなんて誰も気にしない。AIは以前よりもずっと少ない労力で悪い仕事をさせることができる。7. これらのどれも機能していない。AIはプロジェクトを早く進める原因になっていない。良い高品質なAIプロジェクトは存在しない。コードの質は下がっている。オープンソースソフトウェアもひどいことになってる。パフォーマンスが重要でなくなる文化の延長だ。WindowsはすべてがReactコンポーネントでできていて、それぞれが個別のウェブブラウザだから、最終製品の質なんてもう関係ない。ソフトウェアはどんどんひどくなっていく。これらの企業は自分たちの製品に本当に関心を持っていないから。AAAゲームはその良い例で、WindowsやDiscord、Googleの製品、IBM、Intel、AMDのソフトウェアも同様だ。これらの問題の多くはアメリカの問題で、あちらの経済状況や狂ったベンチャーキャピタリズム、労働組合潰しが影響してる。EUがもっと独立してソフトウェア競争相手になり始めると、アメリカのテック市場は絶対に崩壊すると思う。

└

現在、どうやって生計を立ててるのか教えてもらってもいい？

└

> テクノロジーの世界から離れてよかったと思ってる。もうこれをやりたくないから。じいちゃんが、コンピュータを使い始める前にエンジニアリングから離れられてよかったって言ってたのを思い出す。俺が使ってた技術は楽しい技術だったけど、君たちが使ってるのは楽しくない技術だね。

> 数時間で出荷してるけど、以前は数日かかってた。プロトタイプじゃなくて、ちゃんとした構造化されたソフトウェアだ。 > もし何をしているのか理解できなければ、出荷しない。それは譲れない。ほんと、LinkedInだな。

└

AIの使い方についてブログを書いてる人たちは、みんなこんな感じだね。うーん、なんでだろう！

僕は昔ながらのREPLスタイルで、エージェント機能なしのローカルオフラインの小さなモデルを動かしてる。一度に一つのプロンプトだけ。答えを求めるんじゃなくて、特定のファイルを読んだり、特定のオプションを持つコマンドラインツールを尋ねたりしてる。結果をファイルにパイプして、それをCLIセッションに読み込むんだ。それから、そのコマンドを自分のスクリプトやドキュメント（Makefile）に変えてる。無関係なマークダウンテキストや生成されたスクリプトがたくさん出てこないように、モデルが勝手に動き回るのは禁止してる。ストレートな質問をして、ストレートな答えを探してる。一行ずつ、一つのファイルずつ。これで、自分が何を望んでいるのか、どうやってそれを手に入れるかを考える余裕がたくさんできる。自分たちが何を望んでいるのか、どうやってそれを達成するかを学ぶことは、機械に任せたくない貴重な学びの経験なんだ。

└

それな。俺も似たような感じでLLMを使ってて、知識のある同僚みたいにアドバイスを求めたり、何かを確認したりしてる。コードベースの変更は自分でやりたいし、テストも自分で実行したいんだ。エージェントが効率を上げるかもしれないけど、それは危険な道だよ。エージェントにコードベースをいじられたり、再度いじられたりするのを一日中見てるのは嫌だ。自分でやるのが楽しいから、AIが登場する前ほどではないけどね。

└

> 俺はストレートな質問をして、ストレートな答えを探す。1行ずつ、1ファイルずつ。LLMを問い詰めるときは、ソクラテス式の方法も使ってる。引っかけるような質問はなし、クリーンなセッション/コンテキストで、誤解されやすい言葉も使わない。これがうまくいってる。必要な情報はそこにあるから、引き出すだけなんだ。少し前にこの方法を使った演習があって、プロジェクトをコーディングしながらRustを学びたかったんだけど、AIは学びを加速するのにめちゃくちゃ役立った。全然関係ないこと、他の言語からのイディオムや慣習を翻訳することも知る必要があったし、特定の問題を解決するためのRustのイディオムについてももっと知りたかった。だから、解決策を書かせるんじゃなくて、一つずつ丁寧に質問したんだ。そのおかげで、何週間、いや、何ヶ月も節約できたし、今はRustも少しはできるようになったよ（まだ学んでるけど）。

今、2つのAIの仕事をしてる。企業向けのエージェントを作ってるし、大学でエージェント開発を教えてる。だから、ちょっと深く入りすぎてるかも。でも、プログラミングの未来は英語だと思う。エージェントフレームワークは、プロンプト、ツール、RAG、エージェント・アズ・ツール、エージェントハンドオフ、ステート/ランコンテキスト（ツールやサブエージェント、プロンプトテンプレート間で状態を共有するためのLLMから見えないKVストア）という小さなコアコンセプトに収束してる。これらのプリミティブだけで、ほとんどの低UXアプリケーションのビジネスユースケースをカバーできる。ツールがコーディングエージェントによって一発でできるようになったら、コードを書くのを完全にやめることになる。仕事は、名前を付けたり、説明したり、指示を出したりして、それらのパーツをフローチャートプログラミングに似た形で組み合わせることになる。だから、特定のビジネス問題を解決するようなアプリケーション開発では、コードはもはや関連する抽象概念ではなくなると思う。Claude Codeですら、普通の開発者には低レベルすぎると感じるだろう。次のIDEはGoogle Docsみたいになると思う。

└

プロンプトはこれからも残ると思う？SQLは長い間生き残ってるけど、サーブレットはそうじゃない。アセンブリから高級言語に移行したし、Flashはダメだった。だから、プロンプトがどれくらい続くかはわからない。今は素晴らしく見えるけど（当時のFlashやサーブレット、アセンブリのように）、別の技術が出てくると思う。おそらく、裏でプロンプトに基づいてるけど、今のプロンプトとは見た目が違うものになるだろう。プロンプトは残らないと思う。単なる一時的な「技術」だよ。

└

> 仕事は、名前を付けたり、説明したり、指示を出したりして、それらのパーツをフローチャートプログラミングに似た形で組み合わせることになる。それが人々が苦手なことだよ。人々が有限状態機械の概念や状態とロジックの違いを（直感的にでも）理解できないなら、LLMはコード生成ツールというよりも、むしろ願いの井戸（雰囲気）みたいなものだ。技術的な知識の問題もある。ソフトウェアは抽象の層でできていて、その下にもすでに抽象がある。それを知らないと、問題解決能力が制限されるよ。

└

あなたのエージェントクラスか、他にいいと思うもののリンクを教えてくれない？

└

最終的には、英語を超えた何かしらの言語を開発するかもしれないね。もっと正確で形式化されたもの。そうすれば、LLMは俺たちが言ってることを完璧に理解できるようになる。LLMはその形式化された言語に基づいてコードを生成できるし、Googleドキュメントもいいけど、俺たちが作るその形式化された言語に合わせたエディタを想像してみて。

ハクソク