これが最近のテーマになってる気がする。長くコーディングしてるシニア開発者は、こういうツールから価値を引き出せるけど、初心者はRustを知らなくてもコーディングの基礎を理解してるからこそなんだよね。どの言語でも、BSコードは同じ匂いがする。初心者は「匂い」って何かすら知らない。

同意するかも。個人的な経験から言うと、辛辣な批評を求めても、私をなだめて気分を良くしようとする必要が透けて見えることがある（4oと5の両方でそう感じた）。これをどう解釈すればいいのか分からない。元々の予測に戻るけど、このツールは助けを求めていて、LLMの独特な問題を痛感している人たちに役立つだろうね。

でも、媚びへつらいについての部分は特に啓発的だった。私はいつもこのことを避けるために、逆のバイアスで質問を二度促すようにしてる。でも、もちろん、私が持っている隠れたバイアスがLLMによって強化されているかどうかはわからない。

そうだね、微妙なところがあると思う。比較的経験のある開発者としては、新しい言語を使うときにはオートコンプリートを使うけど、コーディングの基礎をしっかり理解しているときは違うと思う。3つ目や4つ目の言語を学ぶときは、構文を理解しているから、赤ちゃんの初めてのforループとは全然違うよね。

100%。AIエージェントプログラミングが好きなんだ。新しいものを作ったり、アイデアを試したりするのが楽しいから。生産に向けてコードを書くつもりはないし、他の人が自分のコードをどう思うかなんて気にしてない。高度な技術を持った人たちと話すときに、自分が色々試してきたって言えるのが大事なんだ。10歳から「プログラマー」やってて、今35歳だけど、プログラマーとして働いたことはない。理由はわからないけど、AIが登場してから、コーディングやシステムレベルのものを作るのが好きになった。WASMみたいな、将来のウェブの可能性を感じるものを試すのも楽しい。自分の限界を知って、違うスキルセットを活かして成長した。自分のやり方で何かをするのがいいアイデアだと学んだし、実はすでにすごいプログラマーが基盤を作ってくれてることもある。私のCursor AIエージェントは、プロジェクト用にgitを設定してくれたから、SSHキーで簡単にプッシュできる。自分でできるって知ってるけど、やりたくないんだよね。> 例えば、ReSharperは古い方法で書くと新しい言語機能を活用するように提案してくれることがあって、これが新しい機能を知るきっかけになることが多かった。実際、これは私にとって新しい情報で、すごく面白い。若い頃にCの文法でコーディングを始めたから、その時に習慣が身についてる。今はバックエンドでPython、ちょっとしたウェブサーバー用にFlask、フロントエンドにはJavaScriptを楽しんでる。WASMのPythonはまだだけど、いじるのが大好きなんだ。バグを見つけるのも、物事の仕組みを探るのも大好き。概念を再発明することが多いけど、少なくともそれは自分のものだし、いじって学べる。中には趣味としてこの技術を楽しむ人もいるし、チーム内でも私より技術的に洗練されてる人がいる。彼らのレベルに追いつくためには、いじる必要がある。多くの場合、シンプルな解決策を見つけることができる。エンジニアの頭は物事を複雑にしがちだからね。

めっちゃ同意。AIのオートコンプリートは最高だよ。ドキュメントを読む必要がなくなるし、少ない行数だからレビューして意図した通りに動くか確認できる。大きな塊を作るわけじゃないから、学びを妨げることもない。

従来のオートコンプリートの利点は、通常、すべての適合するものをリストアップしてくれることだよね。すべてのメソッド、スコープ内のすべての変数や定数など... もしドキュメントがあれば、それも取得できる。学ぶにはすごくいいツールだと思う。選択肢をすべて教えてくれるけど、自分で決めることはないから。AIのオートコンプリートは、基本的にスタックオーバーフローを検索して、最初の回答を文脈なしで貼り付けて、あなたのコードに合わせて調整するだけ。学んでいるなら、自分でスタックオーバーフローを検索するか、AIを使いたいならお気に入りのチャットボットに聞いてみて。そうすれば、なぜそうするのかの説明が少しでも得られるから。

基本的に、あまり良心的じゃない人たちが他の人に仕事を押し付けつつ、マネージャーやPM、CEOに良い印象を与えるための仕組みだよね。彼らは私たちの仕事を自動化して、解雇したいと思ってるし。

「リーダーシップに技術的なプレゼンテーションをする」正直、これが唯一の方法かもしれないね。

問題は、HiGHSやCBCを使えばほぼ確実に最適解に導けると思う。オープンソースのPythonパッケージPuLPにはCBCが付属してるし。もし他の解決策がうまくいかない理由を言う現実主義者じゃなくて、問題を解決するヒーローとして見られたいなら、これを探求する価値があるかも。

ORの問題は難しい。コーディングしようとする人たちは、特定のアルゴリズムにハマっていることに気づいていないかもしれないし、LLMにそれをやらせることもできない。さらに悪いことに、そう言っても彼らはその背後にある数学を理解できず、ビデオコーディングの解決策を好むだろうね。

「LLMコードの整合性チェックにLLMを使えないとしたら、どうやって対処するんだ？」ユニットテストだよ。LLMはテストを書くのが得意だし、テスト可能なコードを書くのも上手い（ちゃんと頼めばね）。テストが実際にコードを呼び出して、明らかなエッジケースを含めて正しい結果を出しているか確認するだけなら、レビューはかなり早いよ。コードをレビューするよりも速いし、パフォーマンステストをテストに含めることもできる。私たちは、定義やテストを使って仕事をする世界に移行していて、関数内のコードの書き方の詳細にはあまりこだわらなくなってきてる。これは大きなマインドセットの変化だね。

「でも、レビューアの数は全く同じだよ。」LLMもレビューに役立つよ。LLMはコードのレビューもそこそこ得意だし、例えばGPT-5はオフバイワンや見落としのリターン、ローカライズされたさまざまな問題を見つけることができる。より高次のグローバルな理解が必要な問題には苦労すると思うけど。将来的には、大きなコードベースでLLMをファインチューニングして、すべての変更に対する第一レベルのレビューアとして使えるようになるかもしれないね。

エクセルプログラミングに対処したのと同じように、無視しておいて爆発するまで放っておいて、会社が倒産する前に何十万もかけて修正しようとするんだ。

もう少し投機的な時間が経てば、プログラミングはなくなるだろうね。

この気持ちには同意する。私はいつも、もしかしたらナイーブかもしれないけど、SF映画やショーで見るようなコンピュータ環境を夢見ていた。誰かが「すべての電力を前方のレーザーにルーティング！」とか「ライフサポートシステムをオンラインに保つためにライフルの電池を使え！」って言えるような世界。技術的なコンポーネントが簡単に交換可能で、互換性があって、再利用できるという想像上の世界。スマートフォンのハードウェアエンジニアに、壊れたiPhoneのカメラをAndroidの余ったカメラに交換してくれって頼んでも、せいぜい非常に難しい作業になるか、最悪の場合は不可能かもしれないって印象を持っている。

我々に押し付けられた多くのことは、ブルックのシルバーバレット的な偶発的な複雑さだと思う。LLMはそれを一気に切り抜けて、言語やフレームワークの周りに築かれた知識のサイロ（とエコシステム）を崩壊させる。

非常に難しい問題の一つは、ドキュメントを書くのが難しく、検索や読み取りも大変なことだ。それが学ぶのを難しくしている。一方で、AIは学ぶのを簡単にしてくれる。アンリアルエンジンをどれだけ理解しているかに、頻繁に感心しているよ。

やって考えることで学ぶんだよ。読むことや見ることじゃなくて。シンプルにそれだけ。

新しいプロジェクトをゼロから作るのは、経験豊富なプロの開発者でもつまずくことがあるよね。ほとんどの仕事では、既存のコードベースを使って作業して、そこから改良していくことが多いから。新しいサービスやアプリが必要になっても、コピー＆ペーストや共通のテンプレートから始めることが多いし。チームがもっと新しいものを必要とする場合、たいていは一人の人がそのセットアップを担当することが多い。プロジェクト全体をゼロから立ち上げて、すべての0から1の選択をするのはあまり一般的じゃない。弟子制度がこれを変えるわけじゃないよね。普通の電気技師は「新しい建物をゼロから配線する」仕事に呼ばれることが多いけど、普通の企業エンジニアは「既存のファイルやフォルダをコピーせずに新しいプロジェクトをゼロから立ち上げる」仕事にはあまり呼ばれない。

ちょっと宣伝になるけど、対面のミートアップを重視してるコーディングコミュニティに参加してみて！オンラインのやり取りよりも、ね。うちのコミュニティじゃなくても、クラフトマンシップに投資している開発者のグループならどこでもいいよ。これが直接的にあなたの不安を解決するわけじゃないけど、正しい方向への一歩だと思う。私の見解では、職場であなたが求めるものは見つからないと思うよ。理由はLLM以前からあって、転職が多いし、リモートやハイブリッド勤務だし、好奇心のないマネージャーもいるしね。

私が弟子制度に対して抱えている問題は、私のワークフローがパフォーマンスを示すために最適化されていないことなんだ。ごちゃごちゃしてるし、無計画だし、ジュニアは時々私が何もしていないのを見ているだけになることもある。教えたくはない、仕事を終わらせたいだけなんだ。ジュニアたちは、苦労して自分で学ぶことを受け入れるべきだよ。時々質問をしながら、チュートリアルを見て、何かを身につけるまで頑張るしかない。

実際、弟子制度の前には、まずは練習が必要だよ。繰り返して、繰り返して、また繰り返す。

+1 私は学校を比較的早く辞めた（すごく退屈だったし、教育のやり方は確実に石器時代に近いものだった）。ソフトウェアエンジニアとしての弟子制度を受けたけど、（すごく役に立たない）学校の要素もあったよ。90年代後半はほとんどが試行錯誤だった。私と師匠、そしてその師匠の師匠と一緒に。Linuxで遊んだり、ISDNルーターを作ったり、HTML、Perl、PHPでウェブサイトを作ったりしてた。これはdevops（流行る前の）で、ほとんどドキュメントなしで問題を解決することで、本当のエンジニアリングだった。すごくクリエイティブで、可能性の限界を押し広げていた。今のAIやバイブコーディングの世界に少し似ているけど、全く違うレベルで、かなりのプレッシャーがかかっている…楽しい時代だったな。

これが歴史を通じて、職人技を学ぶための確かな方法が弟子制度である理由だ。引用が必要だね - 少なくともソフトウェア開発に関しては。私が出会った同年代かそれ以上（40歳以上）の尊敬すべきソフトウェア開発者は、みんな独学だった。80年代や90年代にはあまり機会がなかったからね。でも、その頃はコンピュータにはプログラミングの手引きが付いていたんだ。

だから、歴史を通じて、職人技を学ぶための確かな方法は見習い制度なんだよね。現代の世界でも、大学はそんな見習いのための最適な場所だと思う。もちろん、マーク・トレバーの言葉にあるような大学じゃなくて、自尊心のある大学は、学生に徐々に難易度が上がる実践的な課題を与えてくれる。最初は簡単なデータ構造やアルゴリズムを実装して、簡単なパズルを解くところから始めて、最終的にはおもちゃのOSやデータベース、永続データ構造、コンパイラ、CPU、離散シミュレーション、機械学習モデルを実装するまで進んだ。関数や個々のコンポーネントを実装するところから始めて、すぐにゼロから物を作るようになった。大学で受けたトレーニングには本当に感謝してる。

LLMを使って、ああいうコードを教えてもらってるんだ。俺が見習いで、LLMは俺が言わない限り進まない。説明や教えをしてくれるのはLLMで、実際に書くのは俺。次のコースやチュートリアルを探すより、こっちの方がずっと好きだな。チュートリアル地獄は、教師になれると思ってる人たちの問題だと思う。買った無数の本やコースの中で、実際に何かを教えてくれるものはなかった。プログラミングを教えるモデル自体が完全に間違ってると思う。今はただのフラストレーションで、LLMに言語の最新ドキュメントを探させたり、自分でドキュメントやライブラリを見に行ったりして、そこから計画を立てる方がいい。唯一の不満は、LLMが本当に指摘したものを見ているのか、それとも事前に学習したことをそのまま吐き出しているのか、よくわからないこと。

テクノロジーの世界では、何かしらのゲートキーピングが悪いと見なされる問題がある。というのも、業界の人たちが自分たちは決して置き換えられないと思っているほどの傲慢さを持っているから。資本による協調的な努力で、業界に労働力を流し込んで給料を下げようとしているんだ。プロフェッショナルな基準がまったくないから、実際の仕事とは何の関係もないレetcodeの屈辱的な面接プロセスがゲートキーパーになってしまったと言えるかもしれない。