はてなブックマーク

僕が本当に言いたかったのは、CursorのAI機能よりClaude CodeというCLIツールのほうが自分には合っている、という話のつもりでした。(個人の感想です。Cursorにもよくお世話になっていますm(_ _)m) でも頭の中でモデルとCLIツールとエディタが全部ごちゃ混ぜになっていて、あんなトンチンカンな発言になっちゃってマジ恥ずかしい。 SNSで燃えた最強ツール論争 SNSでこんな投稿が話題になりました。 「Claude Code使うならどれが最強か、VSCode、Cursor、Antigravityを比較する」 という企画です。 一見すると盛り上がりそうなテーマですが、AIコーディング界隈の人たちからかなり突っ込まれていました。比較しているもののカテゴリがバラバラだからです。VSCodeとCursorとAntigravityはコードエディタ(しかもCursorとAntigrav

仕様駆動開発なんて要らない、やめておけ。 仕様駆動開発不要論が界隈を飛び交っています。 しもしさんの「仕様駆動開発はやめた方がええ」という記事を読んで、共感しました。めちゃくちゃわかる。でも、うーん、ちょっと待てよ、と。 人の意見を鵜呑みにせずに、いったん自分の中で本当に不要なのか考えてみたいと思いました。 仕様駆動開発不要論について しもしさんの主張を整理すると、 実装に関するドキュメントは不要で、仕様はすべてコードにある。 ドキュメントとコードの両方をメンテナンスするコストが大きすぎる。 AIエージェント時代にはドキュメントの更新が確率的で、トークンの無駄も大きい。 コードは最新なのにドキュメントは半年前の設計のままってことありません？ 新しく入ったメンバーがドキュメントを信じてコードを読むと、現実のコードとの乖離に混乱する。これって、ドキュメントがないよりタチが悪いんですよねぇ。 さ

なぜ人間の介入無しに、AIが長時間ぶっ通しで作業が可能なのか？ 先日、以下のAnthropicの記事が公開されました。 16のClaude Codeエージェントを並列で2週間動かし続け、10万行規模のRust製Cコンパイラを構築したという内容です。 しかも 人間の介入は一切無し で自律ループによって動作していたとのことでした。 この記事を読んだとき、Agent Teamsの機能に興奮すると同時に 人間の介入は一切無し、の部分に強い興味 を持ちました。しかも2週間も！？えっ、ずっと！？ なぜ、人間の介入が一切無しに、AIが長時間ぶっ通しで作業が可能なのか？ このAnthropicの記事で興味深いのは 「実装はAIが中心だが、テストを含めた評価や環境設定はむしろ人間が入念に設計している」 と書かれていることです。 そして上記のAnthropicの記事と、実際に自分でClaude Codeを長時

先日、Claude Codeの開発者でありAnthropicのエンジニアでもあるBoris Cherny氏が、「初期のClaude CodeではRAG＋ローカルベクターDBを使っていたが、最終的にAgentic Searchの方が圧倒的に良いと分かった」 という発言がありました 私はBoris氏のこの投稿を見たとき「やっぱ、そうだよな」と思いました。なぜなら私もRAGで検索システムを作った際に似たようなことを考えていたからです。この記事ではこの騒動の背景を整理しつつ、なぜClaude CodeがRAGを捨ててAgentic Searchを選んだのかを説明します。 Boris Cherny氏について Boris Cherny氏はAnthropicのエンジニアであり、Claude Codeの創設者 でもあります。また『Programming TypeScript』の著者でもあり、複数の技術系ポ

この記事は、「AIを使えば楽になるはずなのに、なぜか前より疲れている」 と感じたことがあるエンジニアの人に向けて書いています。 AIに何度もプロンプトを投げ直し、出てきたコードを修正し続け、気づけば一日が終わっている。 「AIは便利なはずの道具なのに、なんで自分はこんなに消耗しているんだろう。。（泣）」 「AIを使っているのに、なぜか前より疲れている」という感覚はありませんか。 私は、あります。 むしろ、AIを本格的に使い始めてからのほうが、消耗感は強くなりました。 「AIで効率化できる時代なのに、なぜこんなにしんどいのか」と、疑問がわいてきました。 エンジニアの仕事は、本来、仕組みを作って楽になるためのものです。 それなのに、最新の技術を使えば使うほど疲れていくのは、どこかおかしいのではないか。。 私自身、設計相談、コード生成、レビュー補助、ドキュメント作成など、ほぼすべての業務でAIを

はじめに 「LLM（大規模言語モデル）」は文章の続きを予測するモデルとして広く知られています。 しかし、LLMは言葉だけでなく 画像を生成したり、画像の内容を理解して説明したりできるようになっています。 一体どうして、文章の予測だけしかできないはずのモデルがそんなことまでできるのでしょうか？ この記事ではその仕組みをできるだけやさしく解説します。 LLMってそもそも何をしているの？ LLMの基本は次の通りです。 大量のデータから「次に来る単語」を予測するように学習する 予測するために文脈（前後の言葉）を見る仕組みを身につける その結果、人間のように自然な文章を出せるようになる この仕組みの根底には Transformer というモデルがあり、 文章の中で重要な部分に注意を向ける「自己注意（Attention）」という仕組みがあります。 文章以外も扱えるようになった理由 文章に限らず、画像や

最近、Model Context Protocol（MCP）ではなく「ファイルベースで扱うSkills」の方が便利だという話をよく耳にするようになりました。 実際に過去数カ月、自分もClaude Codeや関連ツールを触りながら、MCPとSkillsを使ってきました。 その中で感じたことを雑多に言語化したいと思います 私が最初にMCPを触ったときの印象は、「とてもよくできた接続規格」でした。 USBのように、外部ツールやデータソースをきれいにつなぐための標準という感じです。 一方で、実際の業務で使おうとすると「で、結局このプロジェクトでは何をどうすればいいんだっけ」という部分は、別途プロンプトを書かなければならない場面が多くありました。 一方、Skillsは最初から「説明書そのもの」を主題にしています。Markdownやテキストファイルに、プロジェクト固有の知識や作業手順を書いておき、それ

はじめに こんにちは、最近SWRを使いこなすのが楽しくなってきた今日この頃の、からまげです。 SWRでページング(無限スクロール)する際、useSWRInfiniteを使うと驚くほどシンプルにコードが書けることがわかり、共有したくてこの記事を書いています。 この記事が、誰かのお役に立てれば幸いです。 わたしは、「Focus Cafe」を個人開発しています。 「みんなでポモドーロテクニックを使ってもくもく集中する」 Webサービスです。 Focus Cafeでは、SWRを使って、データフェッチや状態管理を行っています。 SWRは、React Hooks用のデータフェッチライブラリです。 ページング(無限スクロール)とは ページングとは、データの一覧をページ単位でオフセットとリミットを扱うAPIからデータ取得するような処理のことです。 ページング処理は、状態管理もあいまって複雑になりがちで、エ

伝え方を変えるだけで、これだけ変わる 先日、以下のツイートをしました。 上記のやりとりは、実際の開発の現場であったコミュニケーションを元に書いています。 Badコミュニケーション 現実の私たちは、下記のようなBadコミュニケーションを取ってしまうこともあるのではないでしょうか。 ×「Hogeがないから、このコードはダメだ。却下」 → ワイのモチベダウン わたしは、このようなコードレビューが苦手で、怖いです。 レビューのコメントってどうしても冷たくみえてしまうし、自分が傷つけられてる感じがするからです。 その結果、どうしても前向きに作業に取り組むことができなくなってしまいます。 気分が落ちたことで、さらにうっかりミスをしたりして、再度レビューで詰められたこともあります。 WinWinコミュニケーション 一方で、以下のやりとりが、WinWinコミュニケーションです。 〇「作業ありがとうございま