正直、自分に合ったニッチを見つけてる気がする。個人的には、ソフトウェアエンジニアリングは、作り出す仕事に基づいて異なる職業に分かれていく感じだと思う。この「プロンプトして祈る」流れは、製品やお金を作るのに本当に効果的だけど、成功してる人たちは5年前にノーコードツールに手を伸ばして、似たような成功を収めてたはずだと思う。今はもっと速くて包括的になってるけど、製品の一般的なテーマは変わらないと思う。重要じゃないわけじゃないけど、ソフトウェアの領域内で効果を持つソフトウェアが多い気がする。そういう市場はずっとあったと思うし、重要だからこそ、そういうツールを「エンジニアリング」するために時間とお金をかける価値がある人には合わないんだよね。多くのSaaS製品がそのニッチを埋めてきたし。自分がやりたい働き方ではないけど、特定のブランドの価値のあるソフトウェアを生み出すための異なる職業として尊重することに慣れてきてる。そこにチャンスがあるのに、自分はそれを逃してる。取る人に責任はないけどね！ 飛行機の空中衝突回避システムを書くソフトウェアエンジニアは、自分の仕事を真剣に受け止めて、変更点を理解し、ソフトウェアを無限に維持できるようにしないとね。売上追跡ソフトウェアのエンジニアリングにあまり関心がない人も多いけど、飛行機のソフトウェアのエンジニアリングには本当に気を使ってると思う。

いつから貨物カルトじゃなくなったの？

そうなんだけど、他の開発者とプロジェクトを共有したりアクセスをチェックインしたりすると、これらのことは共有されるようになるんだよね。エージェント的なサポートを使って自分だけでコードを作業するのは一つのことだけど、各開発者がエージェントツールを使ってチームで作業するのは全然違う話だよ。

そのスタートの仕方が間違ってるっていうのには完全に同意するよ。でも、自分の経験では、ツールを使えば使うほど「感覚」がつかめるし、いろんなパーツがどう機能して連携するかを知るのは結構役立つよ（必須ではないけどね）。ネット上には低品質な情報が多すぎて、必要な情報を見つけるのが本当にイライラする。

誰が人工の壁を作ってるの？もしかしたら投稿を読み飛ばしちゃったかもしれないけど、この情報は「エージェント工学を始める前に知っておくべきこと」って感じじゃなくて、「知っておくべきことがいくつかあるよ」っていう印象だね。

この記事は、始める前に大きな.claudeフォルダを設定しなきゃいけないって言ってるわけじゃないよ。小さく始めて短く保つことが大事だって何度も繰り返してる。初めてAIコーディングを体験する人向けでもないし、これらのツールを使ってAIコーディングで避けられないフラストレーションに対処するためのガイドなんだ。実際、HNでのAIコーディングに関する不満の多くは、初心者が書いてるもので、彼らも自分の好みやガイドラインを含むシンプルな.claude設定から恩恵を受けるはず。AIコーディングツールを試してみて諦める人たちがよく言う不満は、ツールが自分の考えを読み取ってくれないとか、ユーザーが望まないことをし続けるってこと。AGENTS.mdや.claudeフォルダに数行書くだけで、そういう問題がすぐに解決できるよ。

これは、大きなエンジニアリングチームがClaudeの周りに何らかのガードレールを設けたい場合に重要だよ。例えば、私はClaudeにいくつかの前提条件が満たされるまで作業を始めないように指示するルールがあるんだ。[0] これがうまく機能していて、何かをする前に必ずこれらの条件をチェックしてるみたい。セキュリティチームは、開発者がエージェントツールを使って何かをすることに対して、あまり心配せずに安心感を持ちたいと思っているだろうね。それに、エージェント開発を本当に始めたばかりの私にとって、どうやって作業しているかをルールに落とし込む時間が、Claudeが私が嫌がること、例えばGPGキーでコミットにサインしないことをしないように助けてくれた。ただし、これらのルールは決して固定されることはないし、少なくとも最初はね。[0]: https://github.com/carlosonunez/bash-dotfiles/blob/main/ai/c...

さらに言うと、自分で作ったスキル以外は絶対にインストールしない方がいいと思う。自分で作ったスキルをガイドしてもらうのもアリだけど、既存のものをフォークして必要な部分だけ持ってくるのがベスト。みんなのワークフローは違うし、どれが正解かなんて誰にもわからないからね。ランダムなスキルを詰め込んだハーネスにすると、また新たな非決定性が加わって、コンテキストウィンドウも大きくなっちゃう。自分でメンテナンスする代わりにインストールすべきスキルはplaywright-cliだけだと思うけど、それくらいかな。

組織を巻き込むのは、こんなにのんびりしたもんじゃないよ。今はClaudeを使うことにかなりオープンだけど、未知のことはやっぱり未知だから、.claudeフォルダが提供するガードレールがあると、ツールに慣れるときに安心できるんだ。

ピーター・スタインバーガー本人が、クレイジーなコーディングワークフローを考える代わりにAIとチャットしてるって言ってるよ。

ほんと、まずはプランモードを使えば90%は解決するよ。CCがサブエージェントを起動して、だいたい正しいことをしてくれるしね。個人的には、この「生産性を上げるために設定をカスタマイズする」系の話は、1年以内に改善されたモデルやハーネスによって廃れると思う。1〜2年前のLLMをコードで使うためのレッスンなんて、もうすっかり忘れ去られてるしね。

それは本当だけど、最初は何かプロジェクトを始めるのが一番だと思う。ユーザーが物事をどう整理して考えるかのアイデアを得るためにね。私にとっては、これがガスタウンで、今ではおそらく最もカスタマイズされたガスタウンのインストールを持ってる。自分で作ったものこそが、AI体験の本質だってことに完全に同意するよ。製品化されたものが魔法のように生活を変えてくれるなんて思わない方がいい。これがガスタウンの本当の天才だと思う—どう動くかじゃなくて、実際に動くってこと、そしてイェッゲが自分の頭からそれを作り出したってこと。だから、私は同じ教訓を受け取って、すごく遠くまで進んだし、いろんな意味で全く違う方向にも行った。でも、これは天才の作品で、彼がそれを世に出したことを本当に尊敬してる。

問題は、ハーネスと特定のモデルがどのタイプの指示が最適かに大きく影響するってことだよ。AnthropicのモデルをCodexやGPTモデルの最適なプロンプト方法と組み合わせて使うと、結果がすごく悪くなるんだ。GPTモデルをCodexと一緒に使って、GPTが反応しやすいプロンプトで促すと、全然違う結果が出る。具体的なプロンプトがどれだけ重要か、みんな気づいてないと思う。同じプロンプトでも、モデルによって結果が大きく異なるし、プロンプトを繰り返し改善する時（例えば処理のために）、使うモデルによって変更内容が変わるんだよね。

なんで彼らがスイッチを許すと思うの？

同意！今はSentryのdotagentsを使って、いろいろやってるよ。

その通り。これらの.mdファイルは、LLMが照合するテキストの塊に過ぎない。何かが起こる可能性を高めたり、逆に起こらない可能性を下げたりするかもしれない。実際、人々は決定論的なワークフローを構築したいみたいだけど、テキストの塊はそのための正しいアプローチじゃない。正しいツールは、特定の状態を通じてエージェントを制御し、ツールの呼び出しを一歩ずつ検証するコードだよ。

うん、これを見た瞬間、この記事はあまり役に立たないだろうなって思った。クロードにガイドファイルに従わせるのはちょっとイライラするね。

スキルはコマンドを上回るんじゃないの？カスタムスラッシュコマンドは手動で呼び出されるだけで、スキルはコンテキストにいるんじゃないの？その違いがよくわからない。今ググってみたら、スラッシュでスキルも呼び出せるみたいだし。

Emacsの初期設定ファイルの無駄話を思い出すな…

こういう罠に人を引き込むことでお金がたくさん稼がれてるね。実際に自分が何を望んでいるかを知っていて、それをうまく伝えられれば（生産性アプリが役立つところ）、AIを使ってたくさんのことができる。私の経験では、ほとんどの人は自分が何を望んでいるかを実際には知らない。あるいは、自分が望んでいるものに何が含まれているのかを理解していない。計画を求めることは、その理解を得るための近道なんだ。