あなたがやるべきタスクを見つけたと思うよ。コードを書くこと自体があなたにとって助けになるなら、AIにその助けを奪われないようにしよう。「生産性」の漠然とした必要性のためにね。私たちは皆、自分の技術を向上させるために時間をかける必要があるし、AIにはその部分を代わりにやってもらえないから。だけど、例えば、行き詰まったり初稿が終わった後に、より良いパターンや言語、ライブラリの機能を示してくれることで助けてくれることはあると思う。それは cheating じゃなくて、友達に頼むことだよ。

これは本当に面白いポイントだと思う。ちょっと年配の視点からいくつか考えがある。今は物事が急速に進んでいるけど、過去10年間の遅さのせいで、さらに速く感じるのかもしれない。俺は90年代中頃から後半にかけてウェブ開発に入ったけど、その頃も似たような感じだった。接続されている人たちはウェブが大きくなることをなんとなく知っていたけど、同時に物事が急速に変わることもわかっていた。学んだことはすぐに役に立たなくなって、次の新しいことを学ぶための肥料になってしまう。ここ10〜15年は本当にずっと安定しているように感じる（人によって感じ方は違うかも）。だから、俺が言いたいのは、そう、実際にこれは普通に戻りつつあるってこと。少なくとも、俺が楽観的な気分のときはそう見える。何かを選んでやってみるといいよ。それが脳の肥料になるかもしれないけど、良い深い肥料があれば、あなたはシニアデベロッパーになれると思う。あまりメタファーが伸びすぎてないといいけど！

数年前、「ライブラリを使う代わりに自分でxを書く」というブログ記事のトレンドがあった。自分のバージョンを作ることで、ソフトウェアについて多くを学べる。クライアントサイドのルーティングがどう機能するかを学びたい？クライアントサイドのルーターを書いてみなよ。LLMのおかげで、何でも「ライブラリ」コードになったと思う。だから、結局はプロジェクトから何を得たいかにかかっている。C#を上達させたいなら、自分でポートするべきだと思う。ポートされたコードを手に入れて他の側面に集中したいなら、クロードにやらせればいい。もし学ぶことが目的なら、何をしても何らかの苦労が必要だと思う。何かが簡単に感じるときは、あまり学んでいないことが多いと気づいた。

35年以上の開発者キャリアの終わりに近づいているけど、LLMに関することではいつもこうしている: 自分が解決できることを一般的に解決するように頼むんだ。ただ、やる気が出ないだけ。例えば、昨日はOpen API 3.0のスキーマに取り組んでいた。サンプル入力に合わせてスキーマを「修正」できることはわかっているけど、つまらないからやる気が出なかった。以前やったことがあるし、何も学べないから。だから、クロードにやらせたら、うまくいった。それから「例」セクションがスキーマと合わなくなったので、クロードが適切な例を書いてくれた。でも、ここでのポイントは、これをやっても何も学べなかったってこと。だけど、何かを学べるときもある。だから、LLMが新しいことを教えてくれたときは、その知識を「知識バンク」に入れている。AnkiのSRSフラッシュカードアプリを使っているけど、他にも「TILブログ」に追加する方法（これもやってる）や、新しいことを解決策を見ずに何度か書き出してコンパイル/実行する方法がある。その後、その知識を別の方法で使う方法を考えたり、要件を変えてそれを書くことを試みたりする。基本的に、脳がこの新しいことと少なくとも2つの方法で関わるようにして、他のことと統合できるようにする。これが重要なんだ。新しい（話し言葉の）言語を学ぶときも、こういうことが多い。新しい単語を学んだら？3つの異なる文に入れてみる。新しいフレーズを学んだら？それに基づいて少なくとも2〜3の新しいフレーズを作る。これで、俺の脳が運動し続けられることを願っている。

プロとして16年コーディングしてきたけど、Claude Codeのおかげで、頭を打ちつけて学ばなきゃいけなかったことがかなり上達したよ。新しいことを学ぶ時は、効率のために、他の学習体験と同じように「簡単に来て、簡単に去る」って感じだね。私の意見としては、完全に学ぶことが目標なら、ゆっくりと忍耐強い方法を優先すべきだと思う（どんなに「物事」が早く進んでいても）。早く学ぶことが目標なら、Claude Codeや他のAIツールが役立つよ。「エージェント」モードより「アスク」モードを使う方が効果的だと感じてる。新しい概念を理解するために、アナロジーやシナリオ、記憶術を作るのが好きだよ。もしただ物事を終わらせたいだけなら、仕様書を書くのが上手くなって、エージェントに任せるのがいいと思う。その際、もちろんたくさんのテストを追加することを忘れずにね。何かを作っている限り、どのアプローチにも少なからず価値があると思うよ。

私の経験では、生成されたコードをレビューしないと、C#に十分精通することができず、コードベースがすぐにゴミになっちゃう。LLMでのコーディングではエラーが重なっていくし、修正しない限り、実際に価値のあるコードベースにはならないよ。友達はその問題がないみたいで、LLMに十分なテストを書かせて、早い段階で脆弱性をキャッチしてるって言ってたけど、私はそのアプローチを試したことがない。残念ながら、私のコードはあまりアルゴリズミックじゃないから、テストが難しいんだよね。

AIの前はコピー＆ペーストがあったよね。Stackoverflowからコードをコピーして理解せずに使ってた人は何も学ばなかったし、それを何度も目の当たりにしてきた。アドバイスや概念を求めるのは全然問題ないと思う。でも、すべてを自動で書かせるのは、確実に学べなくなるよ。とはいえ、開発者として自分の時間を守る必要がある。学ぶべきことは山ほどあるし、ジュニアとしてゲームを作るのが目標なら、GDscriptのコードを移植するのはあまり時間の使い方として素晴らしくはないと思う。もちろん、そこから学ぶことは確実にあるけどね。

コードを生成させて、その後別のインスタンスにそのコードを批評させて、どう改善できるか、なぜそうなるのかを言わせるんだ。そしたら、そのインスタンスに分からないことや理解できないことについて質問してみて。リンクも聞いて、リンクを読んでメモを取る。内面化していく。ある日、ClaudeとRubyのコアメソッドについて議論してたんだけど、全然合意できなかったから、実際のドキュメントを確認しに行ったら、そいつが正しかった。2009年からRubyを使ってるのにね。

こんな感じの時は、Claude Codeにプロジェクトをレビューさせて、設計とアーキテクチャの文書を作成させるかな。次に、C#で再作成するための計画を作らせる。そして、計画文書で定義した小さなステップに従って、C#で新しいプロジェクトを生成させる。最後に、アプリを作る際の経験をレビューさせて、そのインサイトで元の計画文書を更新させる。最初のC#プロジェクトは捨てて、もう一度挑戦する。計画にはテストから始めることを含めるのを忘れずに。

2. 良い仕様から始める。仕様に十分な時間をかける。良いアウトラインを提供すれば、AIにほとんどの仕様を書かせることができる。具体的にどうやって仕様をアウトラインするのか気になる。姉妹のマークダウン文書？どれくらい詳細なの？など。 > 3. 最初からテストを確保する。これが最も重要な部分。テスト（良い仕様とともに）は、AIエージェントが良い解決策に再帰する方法だ。TDDが戻ってきた。皮肉なことに、俺はこれに苦労している。ベストな結果を得るためには、テストフックを使うとクロードがうまくいくけど、そうするとクロードはコードが動く前にテストを書く能力を失って、バグや仮定を検証するために自動修正を始めてしまって、ちょっと変になってしまう。何も忘れたり放棄したりしないようにするのには非常に助けになるけど、特定の設計やプロトタイプの段階では逆に害になることもある。テストの挙動を有効/無効にできるフラグを持つようにしてるよ（笑）。

同意だね。CCがうまく機能するには、かなりの構造が必要だと思う。最近、テストや型、ドキュメントがしっかりしたDjangoプロジェクトに取り組んでるんだけど、CCは大体うまくいってるよ。時々ガイダンスが必要だけどね。最近は、ローカルモデルでCCをオフラインで動かすサイドプロジェクトも始めたんだ。ChatGPTの助けを借りて、まずはそこそこ動くバージョンができたけど、結局CCに切り替えた。CCは重要な問題を解決するのを避けようとしてる感じがするし、エラーを回避したり、ほとんどのことに対して新しいファイルやスクリプトを作るだけで、今のコードを修正したりリファクタリングすることはしないね。

1. モノレポは時間を節約できる そうだね、時間を節約できるけど、Claudeの時間やたくさんのトークンを使って必要なものを見つけようとするコストがかかる。Aiderは、必要なファイルを追加してそれをやらせることができるから、ずっと使いやすいよ。どうしてClaudeがAiderより人気なのか、私には理解できない。Aiderはほぼすべての面で優れたツールだし、タスクに適したLLMを使えるからね。

Claude Codeは素晴らしいけど、そうじゃなくなる瞬間が来るよ。何かを修正したり、追加したりする必要が出てくると…自分で全部書いていれば簡単だった小さな機能が、今はアーキテクチャが理解できないごちゃごちゃになってて不可能になっちゃう。

最近のClaudeモデルはSQLの書き方や編集に信頼性がないと感じてるのが興味深い。例えば、条件は正しく書くけど、ANDやORの周りに括弧を追加しない（それをGemini Proがバグとして正しく指摘した）。

Cursorって、ターミナルにいなくても同じ体験ができる気がするんだよね。Claude Codeがそんなに優れてるとは思えないな。

コーディング懐疑派として、驚いたよ。このコーディング懐疑や皮肉、反発の面白いところは、多くの人が期待をすごく低く設定していることだ。彼らは、ツールが生み出すものは全てゴミだと思っていて、最悪の例が平均を代表していると信じている。そして実際にツールを使ってみると、その期待（すごく低い）を超えていて、驚くんだよね。まあ、Claude Codeが10人のチームで100億ドルのSaaSを生成することはないってみんな知ってるけど、ツールは多くの人が思っている以上に強力なんだ。

もしかしたら、Claude Codeの限界に達したらopencodeやGemini/Google認証のcrushを試してみるといいかも。

数ヶ月前までは、どんなサブスクリプションでも月20ドル以上払うなんて考えられなかったけど、今はMax 20プランで月200ドル払ってる！経験豊富な開発者として20年の経験があるけど（アメリカにいるスロバキア人仲間でもある）、他のツールは役に立つけど、なんか「そこに」至ってなかった。無駄なゴミをたくさん生み出すことが多かったし。Claude Codeは明らかに別のレベルにいる。確かに、すごく手取り足取りが必要だけど、私のやり方はプランモードで、要件を100%理解していると確信できるまで続けて、計画されたコード変更が妥当だと思ったら、あとは任せて、最後に自動修正されたもの（コンパイラエラーやユニットテストの失敗、リンティングの問題など）をコードレビューする感じ。ちょっとおっちょこちょいだけど、知識は豊富で、すごく速く働くジュニアエンジニアみたいなもんだね。これが未来だって言えるよ。ソフトウェア開発が向かっている明確な方向性だね。

シニア開発者で、ジュニアにアドバイスして、彼らが修正するのを導いてあげられるなら、これが向いてるよ。シニア開発者たちから聞くけど、ジュニア開発者は本当にダメだって。彼らは遅く、不安定、あるいはひどいコードを生産して、理解もしていないコードをPRしてくる。私にとっての理想は、ボイラープレート（説明に基づいてクラスの青写真をくれ）、JSONをクラスや他のフォーマットに翻訳してくれること。あと、「このコードの何が悪いの？スタッフレベルのエンジニアならどう書く？」って質問も役立つよ。手動でキーボードを叩いているときに、コードの何が悪いかを聞くことでバグを見つけたこともある。

完全に同意する。使い方をしっかり学ばないとね。例えば、大規模なリファクタリングが問題を引き起こすって言ってる人が多いけど、SwiftUIプロジェクトでうまくいく方法を見つけたよ。ファイルを移動させたり、大きなファイルを小さなコンポーネントに再構成したり、異なるビューのコンポーネント設定を標準化したりするリファクタリングをした。私に合ったパターンは、1) アーキテクチャとコーディング基準を文書化させる、2) リファクタリングの計画を作成させる、3) まずは低リスクのリファクタリングをやらせる、4) リファクタリング計画を更新させる、5) 残りのリファクタリングを進める、って感じ。リファクタリング計画には日数の見積もりがついてくるけど、Claude Codeではそれが全く役に立たない。代わりに、1) チャットメッセージの数、2) トークンの数、3) トークン数に基づくコスト、4) 影響を受けるファイルの数で見積もりをお願いした。もう一つのうまくいくアプローチは、まずは使い捨てのアプリケーションを生成すること。その後、正しいやり方を文書化させて、学びを取り入れて、どこでつまずいたかを記録させる。最後に、そのガイドラインとルールに従ってアプリケーションを再構築する。もう一つのヒントは、時々つまずいたときに、Windsurfでプロジェクトを開いて、別のLLM（例えば、Gemini 2.5 proやqwen coder）にプロジェクトと問題をレビューさせて、その後WindsurfにClaude Codeを修正するためのプロンプトを提供させること。これは場合によってはうまくいく。あと、今までの最大の洞察は、最初から完璧を期待しないこと。フィードバックループが必要だよ：コードを生成して、テストして、結果を確認して、コードを改善する。SQLには特に効果的で、リアルデータにアクセスできるときは特にそう。データベースを調べて、いくつかのクエリを試して、データからスキーマを理解しようとして、動作するSQLクエリを作る。最後のステップとして、動作するクエリを簡素化することが多い。私はテストデータベースにフルアクセスできるMCPツールを使っているから、実行計画を実行させて統計を確認させる（pg_stat_statements）。クエリのマーメイドダイアグラムを描いて、パフォーマンスの数値（取得したレコード数、キャッシュヒットなど）を含めて、最適化されたクエリとインデックスの提案を返してくれる。CSVやParquetファイルでもDuckDBを使って試したけど、実行計画を実行して、両方のクエリを比較して、Parquetがなぜ良いのかを説明して、クエリがプッシュダウンを行っているのを見ることができた。間違ったことがあったときは、コードを調べる代わりに、マーメイドダイアグラムで構築したものを説明する設計文書を作成させる。これで、よくある設計ミスがすぐに見つかって、修正をお願いすることができる。複数のツールを同じプロジェクトで使うと、それぞれが計画を追跡する独自の方法を持っている問題がある。Claude Codeに自分自身のルールを考えさせて、Windsurfとプロジェクトで協力するように頼んだら、どのファイルを持つべきか、どう使うべきかのルールを含むCLAUDE.mdと.windsurfrulesのセットが返ってきた（PLAN.md、TODO.md、ARCHITECTURE.md、DECISION.md、COLLABORATION.md）。

Claude Codeの時代にプログラマーとして持っておくべき最も貴重なスキルは、仕様書を注意深く読むことと、コードレビューの際に鋭い批判的思考を持つことだと思う。

zen mcpをopenrouterに接続して、kimi k2とqwen3 480bを使って2k tok/secでcerabras推論を行う。

4. 「もう一歩踏み込む」のがすごく楽になる（コードに「TODO」を追加することはなくなったし、新しいClaudeを立ち上げるだけで済む） 特にこれ。リソースが限られているせいで、テストや技術的負債を削減しない職場で働いたことがない。今は、欲しいと言うだけでまともなテストスイートが手に入る。純粋主義者を満足させるかは別だけど、長い間放置されていた中程度の果実が自動で収穫できるようになった。

始めるのが辛いってのは大きいよね。これがあれば、今まで「時間があればやりたいな」って思ってたことができるようになる。実際、プロンプトの合間に、ターミナルでNYT Connectionsゲームを作るっていうバカなアイデアが浮かんで、3つのプロンプト後には完成したよ: https://github.com/jleclanche/connections-tui

ClaudeにDockerを管理させるのは本当に良かった。6ヶ月後に忘れないように、既存の製品をパッケージ化するためのガイドを作成中なんだ。同時に、フロンティアモデルが改善したり、悪化したり、変わらなかったりするかもしれないけど、求めているのは一貫性なんだ。

5. Dockerオーケストレーションでモノリシック：ClaudeにDockerコンテナを管理させるようにしたら、10倍の効率になった。ゼロから運用可能な新しいサービスをDockerコンテナで立ち上げられるようになった。これはすごく興味深いね。君のセットアップはどうなってるの？ClaudeがDockerと上手く連携するためにどんなプロンプトを使ってるの？Claudeのインスタンスを他のマシンから隔離するために何かしてる？（例えば、これらのDockerインスタンスをVM内で実行するなど）それとも、ただYOLOでやってるの？

すごく詳細なplan.mdファイルを作ることに成功したよ。すべてのシステムがどうつながっているかまで書いて、claude-loop[1]を寝ている間に動かして、朝に手動でパッチを当てる感じでね。[1]: https://github.com/DeprecatedLuke/claude-loop

#5にすごく興味があるよ。Dockerを避けるために努力しているけど、その重要性も理解しているから、君のプロンプトの一般的なフォーマットを知りたいな。

5. Dockerだけじゃなくて、Playwright MCPサーバーも使って、UIやリクエストの実装を見せてあげて。6. プランモードで始めて、満足するまでプランを繰り返そう。7. スラッシュコマンドを使うといいよ。これはミニプロンプトで、時間をかけて洗練できるし、最初のコンテキストを提供したり、GitHubとやり取りするためにghみたいなツールを使えることを思い出させたりできる。1.についてはちょっと同意できないな。2.は、いいところでコンパクトにするのが大事で、0%になったからって無理にする必要はないよ。

これは自動化好きには夢がかなったようなものだね。何でも自動化できるし、スクリプト化できるし、ドキュメント化もできる。将来的に他の（おそらくローカルの）モデルを使うことになっても、これが私の選ぶインターフェースになるよ。ほんとにパワフルだね。

すごく良いんだけど、>> 6週間でプルリクエスト、コミット、マージされたコード行数にかなりの変化があると思ってたんだけど、実際はそうでもないみたい。チャートを見る限り、Claudeを使っても前と同じような出力だし。これがLLMを使っているときに感じたことを表してる気がする。もっと生産的に感じるし、実際「良くなった」って感じるけど、実際は自分が作業してないから、モデルを見守ってるだけで生産的に感じるんだよね。でも結局、出力は同じで、LLMの利点は全て、レビューや修正、再プロンプトにかかる時間で台無しになる。しかも「難しい」部分を他に任せて、自分の思考力を使わないから、スキルがすぐに衰えていく。Claudeや他のLLMを1ヶ月使ってみて、その後に小さなアプリを自分で作ってみて。コード部分だけじゃなく、全体のアーキテクチャや構造も難しく感じるはずだよ。結局、コードベース全体が徐々に（でもそんなにゆっくりじゃなく）劣化して、長期的にはマイナスになると思う。少なくとも今のLLMではね。

昔ながらのやり方でimagemagick/mogrifyコマンドの作り方を学んだよ。AIツールの助けがあれば、めちゃくちゃ時間を節約できるね。

CLIツールがあれば、Claudeがそれを実行するし、もしCLIツールがなかったとしても… Claudeに聞いてみて、驚くかもしれないよ。そんなのにClaude Codeは必要ないよ！r/unixpornにいるだけで、メインストリームのOSがコンピュータを便利なツールから消費主義のおもちゃに変えたことを実感するくらい、十分なスクリプトやヒントが集まるよ。

ちゃんとしたバックアップシステムはある？それともサンドボックスを使ってる？

完全に同意だね。もう一つの使い道は静的サイトジェネレーターだよ。好きな構文で投稿を書いて、Claude Codeに同じフォーマットでブログ記事にしてもらうだけ。例えば、「ここに画像 image.jpeg を追加」と書けば、ちゃんと追加してくれるんだ。MarkdownやHugoをいじるよりずっと簡単だよ。