#開発手法

AIにコードを書かせる話になると、どうしても「全部任せてよいのか」「人間の仕事はなくなるのか」に話が飛びがちだけれど、この文章はそこをかなり冷静に引き戻していて、その感じが私はわりと好きだった。Claude Codeの作者が言っているのは、AIに全部書かせることではなく、品質の線を下げないために人間がどう見るか、という話なんですよね。そこがはっきりしているのは大事だと思う。 読んでいて引っかかったのは、「プルリクはブロックボックスでもよいのか」という問いが、結局はかなり人間側の観察力に寄っている点です。AIが出したコードを全部読む必要はない、でもどこかで「これは本当に大丈夫か」を判断しないといけない。その判断を支えるために、lint、テスト、レビュー、ガードレールを重ねる。つまり、AIが強くなるほど、人間は雑に見てよくなるのではなく、むしろ「どこを見なくていいか」を設計する役目が増えるんだなと思った。 あと、Claude Codeが「新しいモデルを入れたら終わり」ではなく、effort設定や CLAUDE.md みたいな周辺の仕組みまで含めて考えているのが面白い。AIの性能だけで勝負す

この文章は、ソフトウェアエンジニアが「経験を積んだあとに、かえって動きづらくなる」感覚をどう乗り越えるかをめぐるエッセイだ。著者は、Sunil Pai の「the senior engineer death spiral」を読み返したことをきっかけに、first principles thinking、つまり前提をいったん外して物事を最初から考える姿勢に話をつなげている。いまこのテーマが面白いのは、AI agent と組んで開発する流れが広がり、古いやり方や過去の制約をそのまま持ち込むと見えなくなるものが増えているからだと思う。単なる精神論ではなく、実際の開発の進め方に直結する話でもある。 著者はまず、Sunil Pai の “the senior engineer death spiral” を何度も読み返したと書く。彼の要点は、成果そのものより momentum、つまり前に進み続ける感覚を重視することだ。行き詰まったら、できるだけ小さな単位まで仕事を分解し、実際にひとつ終わらせる。すると次に何をすべきかが見えてくる、という考え方で、著者も強く同意している。 そのうえで著者は、自分が

AIにコードを書かせる開発は、速い。けれど、その速さが「何を作るべきか」を見誤らせることがある。Liam Powell の記事は、Bend 2 という新しい言語を題材に、その危うさをかなり具体的に示している。面白いのは、彼が単に Bend をこき下ろして終わらせていない点だ。むしろ、AIで開発を進めるときに起きやすいズレを、別の言語と実例を使って説明している。 元記事が取り上げているのは、Bend 2 が「AI coding era」のための言語として打ち出されている、という話だ。人間は「laws」と呼ばれる仕様や制約を書く。AI は実装と proof を書く。コンパイラは、その proof が正しいかを検証する。見た目にはかなり野心的で、筆者も「そういうことをしたい人がいるのは分かる」と認めている。 ただし、彼の主張は Bend そのものの思想批判ではない。問題にしているのは、Bend が vibe-coding の罠にはまっているのではないか、という点だ。vibe-coding とは、十分に調べたり設計を詰めたりする前に、LLM を使って勢いよく実装を進めてしまうやり方を指している