2026/01/15 1:26
クローズはブロックを組み立てるのが得意ですが、作成する際にはまだ苦手な部分があります。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
記事は、Claude がルーチンで明確に定義されたプログラミングタスク（Sentry ログのデバッグや AWS サービスの移行）を自動化する点では優れているが、エレガントな抽象化や真に創造的なコード生成には苦手だと示しています。Sentry のデバッグループでは、Claude が Playwright スクリプトを書き、サイトにログインし、チャットメッセージを送信し、MCP 経由で Sentry に接続して反復的にデバッグを行い、約 90 分で成功させました。通常は 1〜2 日かかり、FastAPI エンドポイントの手動セットアップ（
StreamingResponsekeyIdPairs本文
Opus 4.5がリリースされ、人々はそのことを止められずに絶賛しています。AGI（汎用人工知能）は間近だ！ これは能力の飛躍的な進歩です！ 私も間違いなく非常に印象的だと感じます。しかし、数週間にわたり実際のコードベースで試してみた結果、その見方は過度に単純化されていると思います。Claude は今やよく設計されたブロックを組み立てることができるようになりましたが、それらを作り出す必要があるときには崩れます。
それを示すため、3つの実際の例を挙げます：
- Claude が90分間単独で実行し問題を解決した Sentry デバッグループ；
- 3時間で完了した AWS マイグレーション一発手術；
- 私たちのコードベースを悪化させる恐れがあるハックを提案した React リファクタリング。
同じパターンがすべてに当てはまり、さらにそれによって実際のシニアエンジニアが行うことと、なぜ私たちが長い間 AGI から安全であるかを示しています。 🎯— Ryan Nystrom (@ryannystrom) 2026年1月10日
TL;DR
良い点
Playwright と Sentry を使ったデバッグループ
Claude Code が私にとって最も印象的だったのは、単独でデバッグを行えたことです。
Sentry をシステムに組み込もうとしていました。Sentry はコードの実行箇所を素敵なトレースで示し、予想より遅く動作している原因を特定しやすくします。あるトレース例ではデータベース検索を最適化する必要があると示されました。
通常は設定に数分かかりますが、その日はうまく動作せず、良いデバッグログもありませんでした。唯一の進路は推測と検証：フロントエンドでテストメッセージを送信し、Sentry ログを確認し、ドキュメントに基づいて別のアプローチを試すという方法です。それは苛立たしくて退屈でした。
Claude に Playwright を使った小さなテストスクリプトを書かせました。そこでは私たちのウェブサイトにログインし、チャットを送信します。その後 Sentry のドキュメントを渡し、デバッグしたい正確なコードパスが分かるまで作業を続けるよう指示しました。約1時間半で Claude はやっと解決しました。性能エンジニアリングの基本ループはシンプルです：コード変更 → テスト → トレースログ確認 → 繰り返し。このツールセットで Claude はその作業を私たちに代わって行えるようになりました。
(興味があるなら問題点は、Sentry が FastAPI エンドポイントのトランザクションを自動設定する一方で
を返すものには設定しないということでした。解決策は手動でそれを書き込むことでした。)StreamingResponse
Modal から AWS ECS への移行を夕方に完了
私は Modal を1年間快適に使っていました。オンデマンドでコンテナを起動する UI が最高ですが、先週その限界に達したため AWS に移行しなければなりませんでした。Amazon の Elastic Container Service (ECS) でオートスケーリングのコンテナ化ワークフローを構築したかったのです。私は Linux サーバを手作業でセットアップしてきましたが、Kubernetes や ECS は触ったことがありませんでした。
Claude にそれをやらせました。Terraform と AWS CLI へのアクセス権を渡しました。最初の試行で Dockerfile を生成し、それを AWS のコンテナレジストリにプッシュし、CLI を使って正しいパーミッションを設定し、必要な ECS 設定を Terraform で構成しました――全て一発です！ 驚異的でした。
これは数日かかるはずだった単純作業で、数多くのミスと AWS ドキュメントのページに追われるものでした。Claude はそれを圧倒的に速く完了させ、深夜までにすべてを動かしました。
結論
両方のユースケースは本当に印象的です――詳細と注意が必要で、1日半分の低付加価値作業を節約し、Claude が自らの状態を追跡して継続できる能力を示しています。Opus 4.5 について人々が絶賛する理由がわかります。
悪い点
良いエンジニアとは何か？ 私は「sweeks」という名で知られる優れたエンジニアを知っていました。彼はクリーンなコードで有名で、OCaml での私の雇用主の多くのパラダイムを一人で発明したと囁かれていました。sweeks は神ではありませんでした――彼はあなたや私と同じようにバグが起きる普通のコードを書いていたのです。彼がコードを書く上手い理由は、ガーデナーだったからです：彼がコードベースに足を踏み入れるたびに、剪定ばさみを取り出し、散らかったコードを何度も書き直して、完璧に抽象化された本質だけが残るまで整えました。
sweeks はインスピレーションです。私がコードベースで変更を加えるたびに、それが最もエレガントな解決策かどうか尋ねます。そうでない場合は、コードを書き直し続けます。ハッキーな修正には5分、周囲のコード全体を修復するには30分かかります。急いでいない限り、私は必ず後者を選びます。
これはシニアエンジニアが行うことの縮図です：明らかな改善点を見つけて迅速に実行し、大きなステップチェンジ（コストは高いですが将来的に複数倍の効果があります）を特定してそれを推進します。Opus はシニアエンジニアではありません。
Claude が React を書こうとして失敗
最近、クリスマス前にきちんとクリーンアップされずにプッシュされたぎっしり詰まった React コードを扱っていました。2つのコンポーネントが同じデータにアクセスする必要がありました：Component A は ‘key’ を持ち、Component B は ‘id’ を持っていました。構造は次の通りです。
const keyIdPairs = [(key, id)]; // タプルのリスト const idToData = new Map<id, data>();
Component A もオンデマンドでデータを検索する必要がありました。Claude は線形検索を提案しました：
// リストをスキャンして一致する id を見つける const id = keyIdPairs.find(pair => pair.key === key).id; const data = idToData.get(id);
これは文脈上明らかに馬鹿げており、正しい解決策は upstream ソースが
idkeyClaude は良いレゴブロックが必要
私は Claude をとても賢い子供として考えています。彼はレゴを組み立てるのが大好きです。良いインフラや抽象化は、あなたが渡すレゴブロックです―それらが大きくて優れているほど、できることも増えます。
Sentry や Terraform を渡したとき、Claude は成功しました。なぜなら、それらのツールは複雑なシステムを素晴らしく設計された抽象化で包んでいるからです。良い抽象化がない場合――私たちのぎっしり詰まった React コードのように―Claude は迷子になり、自分自身を救うことができません。
Grant Slatton はこれをよくまとめています：
“LLMs は概念グラフでクリーンな切断を下すのが苦手です。”
Claude の力は、あなたが与えるブロックの質に制限されます。彼は Sentry や Terraform、Playwright を自ら再現できません。それらは極めて複雑で設計されたコード片です。Claude が単独で良い抽象化を作れないため、人々がそれを使って何かを達成する限界があります。
私の Claude 批判を一文にまとめるとすれば：Claude には魂がありません。 彼は何かを望んだり、美しいものを創ろうとしたりしません。そのため、そこにない場所でエレガントな抽象化を生み出さず、コードの庭を手入れすることもできません。それでも Claude は素晴らしいツールですが、魂がない限り、私たちは少し落ち着くべきです。彼はすべてのエンジニアを置き換えるほどには近づいておらず、むしろ私たち全員をより重要にしています。
Edited Jan 12: I rewrote the React section to explain more clearly what Claude did wrong. Thanks to Konsti for pointing this out!