「ClaudeよりCodexを1週間使ってみた」でコメント冗長論争
あるエンジニアが「ClaudeよりCodexを多く使った1週間」の感想をブログに書き、Hacker Newsで反応を集めた。ブログは「Codexの方がRuby/Railsのコードでコメントが少なかった」と評価していたが、コメント欄では逆にClaudeの冗長なコメント癖への不満が噴出し、Grok・Gemini・Kimiなど各モデルの体験談も飛び交って意見はまとまらなかった。
クイックインプレッション:Claudeより多くCodexを使った1週間
出典: allaboutcoding.ghinda.com / 元記事はこちら
俺はClaudeの20ドルプランしか契約してない。先週末、けっこう重い作業(QuakeをRaspberry Pi純正GLES 1.0に移植)をやってたら2回もClaudeの利用上限に達して、それでOpenCodeのLunaに乗り換えたらトークン代0.40ドルくらいで全部終わらせられた。これはすごい。Opus 5.0が4.8と比べてイマイチな出来なのを見ると、Anthropicはやばいんじゃないかと思う。
>>4 モデルの性能は何に使うかによってかなり主観が変わる。自分はPMで主に知的作業がメインだけど、Opus 5を日常使いしてかなり満足してる。今のところAnthropicのモデルで一番のお気に入りかも。フロントエンドのコーディングにもよく使ってる。OpenAI系のモデルよりこっちの方が好きで、いろいろ乗り換えながら使ってる。Kimi K3もいい。
自分の経験だと、Claudeは気取っててトゲトゲしいインテリ気取り、Codexは黙々と仕事をこなす叩き上げのタイプって感じ。
どのモデル?その情報なしにハーネス同士を比較しても意味がない。
>>11 どのモデルで、どのエフォートレベル?
「この記事の書き方:自分で書いてGrammarlyで校正・修正した」か。こんな注記が必要な時代になったのかと思うと感慨深い。とはいえ、書いてくれるのはありがたい。ただ、文章の大半をLLMに書かせてる人ほど、こういう注記は付けない気がする。
自分の感覚では、Claudeは細かく説明しなくても意図を汲み取ってくれることが多い。Codexは些細な部分に引っかかって、そこに対して過剰に作り込んだ解決策を出しがち。
> CodexによるRuby/Ruby on Railsのコード変更はコメントが少なかった。これはかなり気に入った点で、近々この件で行った実験を共有する予定。 →コメントが少ないのがなぜ良いことなの?
>>15 Claudeのコメントってこんな感じ。 // addはxとyの和を返す // addition-implementation-plan.mdのセクション2.1に基づき、sumはユーザー加算インターフェースの継ぎ目として設計されている // 以前sumは数値を加算していたが、今も数値を加算する def add(x, y): return x + y
>>15 最近のClaudeのモデルは冗長なコメントを書きがちで、みんなうんざりしてる。
>>15 Claudeのコメントは、現在の状態に至るまでの検討の経緯を丸ごと書き込んでいることが多い。LLMが「なぜ」を把握するには便利だけど、コードの中でも特に重要で紛らわしい部分でもない限り、人間はそんな書き方はしない。
各モデルについて、みんな真逆の体験談を語ってるのを読むのはなかなか興味深い。
>>2 ハーネスとモデルの組み合わせは、この記事が扱ってる以上に重要だと思う。自分はds flash v4をprime-agentのハーネスと組み合わせて使ってかなりいい結果が出てるし、思考トークンも見られる。同じモデルでもOpenCodeだとあまり気に入らなかった。SolとLunaはどこで使っても良い。Solが計画を立てて、Lunaが実装する。
>>2 Grok 4.6に触れないのは罪だろう。速いし正確。しかもちゃんと会話が成立する、Claudeが出してくるわけの分からない文章と違って。
>>23 >Grok 4.6に触れないのは罪 まだそこまでは。あの人に変な入れ知恵しないでくれ。
>>23 最近は実装にGrok 4.6、レビューにgpt 5.6 solをよく使ってる。今のところかなりgood。
>>2 >gemini 3.7は速くて優秀なのに、みんな気づいてない って、それってGemini 3.7 Flashのこと?だったら違う。気づいてないんじゃなくて、単に良くないだけ。今週、依存関係のバージョン固定漏れでPythonパッケージのビルドが失敗したんだけど、Geminiに投げたら5〜7分くらい変な方向に行ってるのに気づいて、Claude Opus 4.8でやり直したら1分もかからず直った。一例だけの話ではあるけど、Googleの新しいモデルを試すたびに毎回こういうことが起きてる。
>>2 未来はもう来ていて、それがちょっとムラのある形で行き渡っていることに感謝すべきだと思う。そうでもなきゃ、みんなで強い意見をぶつけ合うネタなんてほとんど残らないんだから!
>>7 自分も同じ経験。Codexが書いたコードをClaude(主にSonnet)に渡してシンプルにしてもらったら、はるかに良い仕事をした。Codexはどうやってもよりシンプルな解法を理解できなかった。
>>15 コメントが少ないのは基本的には良くないこと。AI生成のコメントが少ないのは基本的には良いこと。
>>15 良いコードはそれ自体で説明になっていて、コメントは不要。「Clean Code」という本をおすすめする。要約はこちら(リンク参照)。
>>15 Claudeはよく「このコードが何をしないか」についてコメントする。その時点では意味があっても、コードベースに残すべきものじゃない。
>>17 補足として。codex/solは、範囲がきちんと決まった難しい技術的問題の方が得意な気がする。総当たり的な分析ループをぐるぐる回せるようなタイプの問題、たとえばパフォーマンス最適化とか探索系の問題とか。数学の証明なんかはその良い例だと思う。
>>40 同意。マルチプレイヤーゲームのパケットトレースが入ったフォルダを渡して、翌朝には元とほぼ同じ挙動のサーバーができてる、なんてことができるのはこのLLMだけ。
>>17 え、何にでもsha256チェックサムやstate enumを提案してくるの好きじゃないの?(笑) たしかにその傾向はあるけど、「今のフェーズはシンプルにして」と言うと落ち着く。「その辺はまた後で対応するから、約束するよ」って言い聞かせてる(笑)
>>19 自分はsolをmediumで9割方使ってる。試してみる価値はあるかも。特に小さな変更のときは。
>>30 そうそう、Claudeはプロンプトに対して「はいそうします」的なコメントをやたら入れたがるし、現状ではなく前の草稿や実装の話を持ち出すことも多い。
>>30 >Claudeが入れるコメントの中には、PRのコメント欄に書けば済むようなものもある それはClaude次第かな。自分の(Claude自身の)古いコメントのおかげで、新しい問題を解決できたことが何度もある。
>>30 Claudeは、もう人間がコードを見ないという前提で動いてる気がする。あのコメントは、次に変更しに来る別のClaudeのために書かれてるんだと思う。
>>32 このコメントを読んだだけで、明日またこんなのを読まなきゃいけないのかとうんざりした。本気でOpenAIに乗り換える時期かもしれない…
>>49 bedrock/foundry/vertexみたいに、サーバーレスのAPI経由でモデルをそのまま入れ替えられる仕組みを上司に提案しようとしてる。Digital Oceanも特に有望に見える。
>>33 あの冗長なコメントは、なぜそれがそうなっているのかという背景を残してくれる。だから将来変更するときに、その経緯を踏まえて判断できる。
>>50 >なぜそれがそうなっているのか そこには実際には無いことや、以前あったものについての「物語」を書いてくる。たいてい役に立たなくて、ただのノイズ。しかもいかにもAIっぽい冗長な文体で書きたがる。
>>50 履歴を掘る必要があるなら、git log -pのようなコマンドの方が、LLMの推測より実際の履歴を反映していてよっぽど役に立つ。目的を書いたコメントの方が、履歴にもコード自体にも書かれていない分、有用。
>>50 あの大量のコメントは、結局リリースされなかった中間状態について言及していることが多くて、恒久的に残る記録としては役立たずでノイズになるし紛らわしい。レビュアーには役立つこともあるから、コミットメッセージやPRのコメントに書く方がずっと適切。
>>53 しかも書き方自体もあまり役に立たない。「//これは見た目の問題じゃない:このcssはユーザーがどこをクリックすべきか分かるようにするためのもの」みたいな。「これは〜ではない」というパターンは、良く言っても無意味。
>>53 「小説を書くんじゃない」← これをClaudeに何度言ったことか。何をやっても冗長さが目に見えて減る気配がない。
>>57 そうそう、Claudeがコメントで「以前と比べて今はこうなっている」とか「別の判断をしていたらどうなっていたか」とか説明してくるのが本当に嫌。頼むから、今のコードの状態だけ話してくれ!
※本記事は5ch(Hacker News)スレッド「Quick impressions: A week of using Codex more than Claude」より抜粋・要約して構成しています。
まだコメントはありません。