Why Senior Engineers Choose Boring Go Over Exciting Rust
How a $3.2M production disaster taught us that technical excellence doesn’t always align with business success — and why boring… How a $3.2M production disaster taught us that technical excellence doesn’t always align with business success — and why boring technologies often deliver better outcomes Senior engineers learn that the most technically impressive solution isn’t always the best business
AIバグ発見システム「Sashiko」がGoogle社員によって開発される、日本の「刺し子」に由来する名前でLinuxカーネルの未発見バグを次々に検出
Google社員のRoman Gushchin氏がAIを用いたバグ発見システム「Sashiko」を開発して公開しました。Sashikoは主にLinuxカーネルのパッチに含まれるバグを発見するために設計されていますが、Linuxカーネル以外のプロジェクトでも使用することができます。 Sashiko https://sashiko.dev/ Sashikoは日本伝統の刺しゅう技法である「刺し子」にちなんだ名前です。刺し子は「ただの補強(パッチ)ではなく装飾的な意味も持つ技術」であり、「自動化されたパッチレビューでLinuxカーネルを強化する」というシステムの使命を表すのにピッタリだそうです。 SashikoはLinuxカーネルプロジェクトのメーリングリストに送信されたパッチ提出メールをすべてスキャンし、Gemini 3.1 Proを用いてバグの有無を分析するシステムです。Sashikoのウェブ
Code Review for Claude Code | Claude
Today we're introducing Code Review, which dispatches a team of agents on every PR to catch the bugs that skims miss, built for depth, not speed. It's the system we run on nearly every PR at Anthropic. Now in research preview for Team and Enterprise. Managing the review bottleneckCode output per Anthropic engineer has grown 200% in the last year. Code review has become a bottleneck, and we hear th
OSSにおけるAI Slop問題の何が問題なのか？
Honoは2021年の12月に開発が始まって4年と少し経つ。たぶん、あなたが想像する以上に大きくなっている。GitHubのスターは現時点で29.2K。これは日本人発OSSで観測する限り第3位の数字だ。最近ではMCP公式SDKの依存に入り、ダウンロード数はうなぎのぼり。月間1億ダウンロードが近い。Cloudflareは多くのプロダクトでHonoを使っている。 これだけ大きな規模のOSSに、クリエーター、もしくはメンテナとして関わることは非常に貴重な経験である。そこにはみなさんが見ていない景色が広がっている。 Honoの開発において「憂鬱な」こともたくさんある。ただ、それを上回る楽しいことがある。そうやって相殺してきた。ところが最近、4年間で一番憂鬱なタイミングきている。俗に言うAI Slop問題である。 今回は、OSSにおけるAI Slop問題について、実体験を元に何が問題なのかを語ってみた
How to Kill the Code Review
Second wave speakers for AIE Europe and CFP for AIE World’s Fair are announced today, and OpenCode is confirmed for Miami! We’ll also be in Melbourne & Singapore. Editor: This is the latest in our guest post program, where we will publish AI Engineering essays worth considering, even if we don’t personally agree with them — having just shipped an AI review tool, this is one of those cases where I
生成 AI による仕様書作成とレビューの考え方 | CyberAgent Developers Blog
ジャンプTOON ソフトウェアエンジニアの國師 (@ronnnnn_jp) です。 この記事では、仕様書の作成・レビューに生成 AI を活用するための実践的なアプローチを紹介します。 目次 生成 AI による開発効率の変化 LLM の特徴と制約 コンテキスト情報の整備 手順や制約の明確化 評価と効果 なぜ Notion AI か おわりに 生成 AI による開発効率の変化 2024 年 5 月にサービスを開始したジャンプTOON は、モバイルアプリケーションと Web ブラウザアプリケーションを提供しています。バックエンドも含め、ジャンプTOONの開発は大きく次の流れで進みます。PM が企画と仕様策定を行い、開発メンバー (エンジニア、デザイナ、QA など) を巻き込んで仕様をブラッシュアップします。その後、デザイナが UI デザイン、エンジニアが実装を進めます。 昨今ではコーディング A
人間のコードレビュー力を鍛えるために。AIコーディング時代の「ペアプロ・モブプロの心得」 | レバテックラボ（レバテックLAB）
人間のコードレビュー力を鍛えるために。AIコーディング時代の「ペアプロ・モブプロの心得」 2026年1月22日 IDEO PLUS合同会社代表 加藤 潤一 30年以上のソフトウェア開発経験を持つエンジニア。東芝グループで製造技術・品質保証を経験後、株式会社ドワンゴ、グリー株式会社、Chatwork株式会社(現 株式会社kubell)でテックリードを歴任。自ら設立したIDEO PLUS合同会社にてSaaS企業を中心に、ZOZO、Leveragesなどでも技術顧問・技術支援を行う。ドメイン駆動設計とリアクティブシステム設計が専門。Scala、Rustに精通し、持続可能で耐障害性の高いソフトウェア設計を得意とする。 X：@j5ik2o keyboard_arrow_down はじめに keyboard_arrow_down AIとの協働の難しさと課題 keyboard_arrow_down ペア
若手が生成AI任せで仕事して、レビュー地獄で逆に生産性が落ちた話｜片山良平＠paiza会長
自分でやって100点取れるその領域のシニア（経験者）がこれやるのは良いのだけど、20点しか取れないジュニアが生成AI任せで16点のものを100個作られるとシニアがチェックで死に、全体としての生産性が落ちる。 …という問題が生成AI駆動開発では既に起きている。 https://t.co/npcE57PTVL — 片山 良平@paiza代表 (@rk611) August 25, 2025 ジュニアエンジニアが生成AIで大量の低クオリティなものを作ってしまうがために、シニアエンジニア（年齢ではなくハイスキルな先輩エンジニア）が、チェックで工数を取られてしまうという問題について何社でも聞いたので、その話をポストしたものです。 これは生成AI駆動開発やってる人、つまりITのエンジニアだけの話だと思っていたのですが、想定以上に色々な領域の方から共感をいただきました。 このブログが良いなと思ったら、n
どのくらい生成AIに任せているかをあらわす指標 - Mitsuyuki.Shiiba
fukabori.fmのtwadaさん回、面白いなー分かるなーって思いながら聞いて、今の自分の頭の中を書きだしてみようと思ったので書いておく。 どのくらい生成AIに任せているかをあらわす指標 どのくらい生成AIに任せているかをあらわす指標は、こうかなぁと僕は思っている。 「生成されたコードを自分が読んでいない割合」 どれだけたくさん生成AIにコードを書いてもらっていたとしても、生成されたコードを自分が全部読んで理解している場合は、主導権は自分にある。逆に、生成されたコードを全く読んでいなければ生成AIに主導権がある。 右のほうが生産性は上げやすい AIにどれだけたくさんコードを生成してもらったとしても、全部読んで理解しないといけないなら人間がボトルネックになる。右側にいけばいくほど、生成AIに任せられるので生産性は上げやすい。 ただ、右側にいけばいくほど自分がコードを理解していないし、構造
そのAI生成コード、全部レビューしますか？全部信じますか？
初めまして、kagayaです。 AIネイティブなプロダクト開発を頑張っています。 共訳した「AIエンジニアリング（オライリー・ジャパン）」が11/28に発売です。よろしくお願いいたします。 世はAIコーディングエージェント時代。 圧倒的に手数は多くなり、自動でPRを生成する取り組みも見かけるようになりました。 かくいう私も、Claude Code Actionを夜間に動かしてGitHub Issueを自動解決する実験をし、朝に作成されているPRを眺めて、「これが不労コード生活か」と思うなどしていました。 そんな中で、新しく生まれた悩みの一つは、このコード、どこまでレビューすればいいんだ？ です。 全部読んでたら、自分で書いた方が早くない？でも全部信じるのも怖い。 バイブに身を任せた結果として生まれた数千行のPRを前に、途方に暮れた経験がある人もいるのではないでしょうか。 Thoughtwo
最近の人類のレビュー疲れ | Democritizing Data
今年に入ってやたらレビューの時間が増えた。これはコードもそうだしドキュメントもそうだ。 そして、これによる疲れも急激に増加している。 もちろんこれは、LLMによる支援によってアウトプットの速度と量が増加したからだ。 そして、必ずしも質が向上しているわけではなく、むしろ下がっているように感じる。 当然、自分の生産性も下がっている。 自分の頭をダンプし、どういう課題があるか、そして、どう向き合っているかを書いていこうと思う。 他人を経由したプロンプティング私は、機械学習のプロジェクトのテックリードとしてしばらく働いている。 その仕事として、Engineering Requirement Documentsなどの技術文章を書くことも多いが、レビューする機会も多い。 機械学習で難しいのが、プロジェクトが変わり解く課題がちょっと変わると、がらりと全然違う知識が必要になり、新規に論文を読む必要が出てく
コードレビューの本質は“思考の共有”。GitHub CopilotとDevinの活用で見えた、生成AIの長所と限界 ｜SHIFT Group 技術ブログ
コードレビューの本質は“思考の共有”。GitHub CopilotとDevinの活用で見えた、生成AIの長所と限界 生成AIのアウトプットを、ひとがレビューをする。その反対にひとがつくったものをAIがレビューする。質のよいプロダクトにつながるよう、 DAAE統括部の倉見は、こうしたコードレビューに「GitHub Copilot」と「Devin」をとりいれ比較してみたと語ります。 そのメリットやデメリットを深ぼるなかで見えてきたのは、レビューの本質が‟対話”にあるということ。そしてレビュースキルが求められ、エンジニアの役割が変わりゆくなかで、どう自己を成長させていくのかという新たな問いでした―――。 DAAE統括部 倉見 大学で情報工学を専攻後、メーカー企業に入社し、医療IT分野で複数の新規システム開発に従事。開発ではフロントエンドからバックエンドまで幅広く担当し、テックリードも経験してきた
Nx の攻撃から学べること #s1ngularity | blog.jxck.io
Intro Nx リポジトリが攻撃を受け、広範囲にわたるインシデントが発生した。 今回の事例は、GitHub Actions を中心に複数のステップが組み合わさった攻撃であり、過去に何度も発生してきた攻撃と本質的には変わらない。 しかし、途中で AI が何度か登場するため「AI が書いたコードをマージしたから」などといった表面的な反応もあるが、実態はそこまで単純な話でもない。 また、「自分のプロジェクトは Nx を使っていないから関係ない」とも言えない攻撃であるため、特にフロントエンドエンジニアは全員注意と確認が必要となる。 この攻撃が何だったのか、そこから学べることは何なのか、解説する。 Nx Incident 今回のインシデントについては、既に公式の Advisory が出ている。ニュース系の記事も多々あるが、一次情報は以下となる。 Malicious versions of Nx a
生成AIの成果物に責任を持ってくれ｜qsona
プログラマーの世界では昔から「お前がコピペしたコードはお前のコード」というならわしがある(多分)。つまり、たとえばコードレビューで他の人から指摘が入ったときに、「隣にある別のコードをコピペして作ったからそうなっている」というのは言い訳にならないということだ。ペーストした瞬間からそれは自分が責任をもつべきで、そのためにはそのコードを自分で理解して説明できる必要がある。ジュニアプログラマーはこういった意識が薄いことが多いが、レビューする側のプログラマーとしては、ジュニアプログラマーが責任を持った振る舞いをしてくれないと非常に疲弊するので、こういう哲学は早めに教え込むことが多い。 これに似た話として、最近、プログラミング以外の事例も含めて、生成AIに作らせたものを隅々まで自分で理解しない・説明できない (つまり責任を持てていない) ままそれを成果物として他人に見せるケースがあまりに多すぎるように
コードレビューが激変している - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは、フロントエンド推進課の水野です。 普段はWebフロントエンド領域を中心に、商材開発や技術支援、開発改善に携わっています。 自動化・標準化、開発プロセスの変遷に関心があり、作るものだけではなくその過程や運用設計を意識して取り組んでいます。 note.com 最近、自分の中でコードレビューのやり方が変わったなと感じています。 GitHub CopilotやClaude Codeのようなツールが当たり前になり、構文エラーやコーディング規約のチェック、命名規則の統一のような作業はほぼ自動化できてしまいます。 成果物の出てくるスピードと規模感も桁違いで、レビューだけで1日が溶ける日もたまにあります。 その中で、改めて「自分は何をレビューすればいいんだろう」「コード以外に見るべきものはなんだろう」と考えることが増えました。 個人的にコードレビューや開発現場に関する話が好きで、ブームが再燃し
20年選手のエンジニアが「良いコード」を改めて学ぶために、最近の本を4冊買って読んでみた - give IT a try
はじめに：僕の知識はもう時代遅れかもしれない？ プログラマとして、毎日コードを読み書きし続けて約20年。 自分の中には何が良いコードで、何が悪いコードなのか、明確な基準があるし、どうして良いのか、どうして悪いのかを人に説明できる自信もあります。 が、ここ最近は「自分のこれまでの知識や経験」がその判断基準になっており、あまり積極的に新しい情報を外部からインプットしていませんでした。 ネットを見ていると「良いコードとは or 悪いコードとは」を論じてそうな新しい技術書がちょこちょこ発売されています。 もしかすると僕の知識は古くなってるかもしれない、最近の技術書を読むと僕の知らない新しい観点を学べるかもしれない、そう思って以下の4冊を購入してみました。 Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考（2023年2月発売） Tidy First? ―個
読みやすいコードを書く
読みやすいコードとは何か 読みやすいコードとは、脳に負荷がかからないコードである。脳に負荷がかからないコードとは、人間の脳の特性に配慮して書かれたコードである。したがって読みやすいコードを書くには、まず人間の脳の特性を把握する必要がある。読みやすいコードの特徴は、この人間の脳の特性から論理的に導かれる。 また、「コードを読む」とは過去から未来への情報伝達、または自分から他者への情報伝達であり、情報理論における以下の２つの数学的原理にも支配される。 頻出する情報には共通の符号を割り当てることで情報を圧縮することができる。 失われた情報を復元することはできない。 この記事に書かれた内容はプログラムに止まらず、ドキュメント、記事の執筆など、プレインテキストによって情報を伝達する際には一般に適用可能である。 もしもこの記事を読むのが面倒であれば、以下の５つだけを覚えておけばよい。 ひとつの処理の単
きれいなコードを書けという話について - Software Transactional Memo
前回のブログから90日以上経ってしまったので広告が載ってしまったから短文でもアウトプットしておく。 プログラマとして仕事をしているとコードと向き合っている時間の9割以上は既存のコードを読んでいる、だから読みやすさは重要である、という言説は耳にタコができるほど誰もが言っている。 仕事で書かれるコードが誰のレビューも通ること無くマージされている現場は凄惨だが、自分より明らかに経験を積んだ人たちが何度もレビューを重ねたコードが読みやすいかというとそうとは限らない。良いコードが守るべきルールをすべて守っていても不可解なコードはあるし、どんなに読みやすいコードでも数千行の規模になってくるとやはり脳内からこぼれて一度に覚えておける範囲からはみ出る。 変数名や関数名をわかりやすくするとか不必要な技巧を凝らさないとかわかりやすい設計にするとか主観的な事を偉そうに語る本は山ほどあり、それらの本を崇める事は悪
Go初学者へのコードレビューでよくあったコメント20選
はじめに こんにちは、ソーシャルベッティング事業本部 海外ベッティング事業部の山崎です。 本記事では、Effective GoやGoogle のスタイルガイド、Code Review Commentsといった公式資料、Future Architectの記事などを参考に、Go を初めて触る開発者を対象にした汎用的なレビューコメントの 20 選を紹介します。 大きく以下の４つのセクションに分けました 言語仕様に関わる内容 標準パッケージの使い方 エラーの扱い方 単体テスト Linter の活用について 可能な限り lint で自動化して人の手が加わる前に静的解析でできればベターです。 特にこの記事で紹介するような汎用的なコメントについてはいくつか反映できる lint もあると認知しております。 そのような設定の lint config サンプルをまとめようとも思いましたが、実際に運用まで至って
質問は恥ではないし役に立つ - Qiita
一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
