タグ: #developer-experience
GPU・LLM・MLOps・Kubernetes、そしてマインドセット · 17 件
理解がボトルネックだという主張とその循環 — 説明を生成した側が検証対象であるとき
エージェントがコードを作る速度が人の読む速度を超えたとき何が残るかを扱った記事が議論を集めました。著者は検証のための理解から参加のための理解へ目標を移そうと提案し、3つの仕掛けを出します。ところがコメントで出た最も強い反論は、その説明自体をモデルが書くなら検証が成り立つのかという循環の指摘でした。提案された仕掛けのどれがこの反論に耐え、どれが耐えないかを切り分けます。
2026-08-14 · 13 分で読めます #engineering-culture#code-review#developer-experience#documentation#ai-assisted-developmentDiátaxisを四つのフォルダと誤解する理由 — ひとつの文書に二つのモードを混ぜるとなぜ崩れるのか
Diátaxisは文書をチュートリアル・ハウツー・リファレンス・説明の四種類に分けます。ところがチームのほとんどはフォルダを四つ作ったところで適用を終え、肝心の問題はそのまま残ります。本当の失敗は分類ではなく、ひとつの文書のなかで四つのモードを混ぜるときに起きるからです。混ざるとなぜ崩れるのかを、フレームワークが根拠にする二つの軸から辿り直し、段落単位で判定する羅針盤と、今週すぐ回せる作業ループまで整理しました。
2026-08-09 · 16 分で読めます #documentation#diataxis#technical-writing#developer-experience#information-architectureNix 2.35がフレークのソースをstoreにあまりコピーしなくなった — 6年8ヶ月かかったイシューと、アップストリームがlazy treesの代わりに選んだ道
2026年7月13日にタグ付けされたNix 2.35.0の最初のハイライトは「Sources are copied to the store more lazily」です。この一行が閉じたイシュー3121は、2019年10月7日にEelco Dolstra本人が開き、2026年6月9日に閉じられました — 2,437日。興味深いのは、実際にマージされたものがDolstraのlazy treesではなかったという点です。彼のPR 6530
2026-07-16 · 25 分で読めます #nix#reproducible-builds#build-systems#developer-experience#open-sourceeBPF Verifierは止まった場所しか教えてくれない — 拒否235件を再現して測った診断ギャップ
eBPFを触ったことがある人なら誰でも経験するあれです。Verifierがプログラムを拒否するのに、エラーメッセージは何の問題もなさそうな行を指している。2026年7月に出た論文が、このもどかしさを初めて数値化しました。著者らはStack Overflow、GitHubのIssue、修正コミット、カーネルのセルフテストから候補936件を集め、カーネル6.15.11 + clang 18という固定ツールチェーンで再現し、実際に拒否された2
2026-07-16 · 34 分で読めます #ebpf#linux#kernel#debugging#developer-experienceAI は本当に開発者を速くするのか — 測定された数字が語ること
二つのランダム化比較試験が正反対の答えを出しました。一方は AI を使った開発者が 55.8% 速かったと言い、もう一方は 19% 遅かったと言います。ところが後者の数字を出した METR は、2026年2月に続報を公表し、2025年の結果の上に「現在の AI モデルの影響をもはや反映していない」という警告バナーを自ら掲げました。それで話が消えるのではなく、むしろ鋭くなります — 続報の実験ですら、参加者の自己選択バイアスに足を取られて
2026-07-12 · 38 分で読めます #career#ai#productivity#software-engineering#developer-experienceAI コーディングツールとうまく働くための5つの習慣
同じツールが、ある実験では 55.8% の得を、別の実験では 19% の損を生みました。符号を変えたのはツールではなく使い方です。METR、GitHub Copilot の RCT、Stack Overflow の調査、そして Anthropic のエージェント設計文書から引き出した5つの習慣 — タスク選択、レビュー予算、機械的ガードレール、コンテキスト設計、そして自己計測。それぞれが、2週間で反証できる1行のルールで終わります。
2026-07-12 · 20 分で読めます #ai#productivity#software-engineering#developer-experience良いツールは見えない — gingerBill の主張と「見えなさすぎる」ツールの落とし穴
Odin 言語の作者 gingerBill のエッセイ「Good Tools Are Invisible」を読み、その論旨を整理したうえで現場からの但し書きを加えた記事です。彼は、良いツールは摩擦なく背景へ消えるべきで、欠点を「楽しいパズル」として売り直す話法は正当化だと批判します。私は「感じる生産性と実際の生産性」の区別には同意しますが、インターフェースが見えないことと内部が不透明なことは別だと考えます。ビルドシステムや Kubern
2026-07-11 · 14 分で読めます #tools#developer-experience#kubernetes#build-systems#editorsLLM バーンアウト — 仕事が「作る」から「レビューする」へ静かに変わるとき
開発者 Alec Scollon のエッセイ「I Think I Have LLM Burnout」が Hacker News で話題になりました。一日が、コードを「書く」仕事から、モデルが書いたものを「レビューする」仕事へと静かに変わったという感覚を、的確に言い当てたからです。本稿はその主張を忠実にまとめ、バランスの取れた見方を添えます。生成は安くなりましたが検証はそのままで、AI の出力をレビューすることは実際の認知的な労働です。道
2026-07-11 · 13 分で読めます #llm#developer-experience#burnout#ai-tooling#code-reviewAIコードレビューツールの台頭 — 何を任せ、何を人間が見るか
AIコードレビューツールが急速に広がっています。AIがうまく捕まえる欠陥と、人間が必ず見るべき領域を分け、CI統合や導入チェックリスト、そして批判的な視点までまとめます。
2026-06-25 · 27 分で読めます #devops#code-review#ai-tools#developer-experience#ci-cd日本のIT会社で生き残る日本語表現 2026 完全ガイド — 敬語・コードレビュー・会議・障害対応・1on1の実践語彙 深掘り
2026年、メルカリ・LINE・ZOZO・サイバーエージェント・PayPay・楽天・DeNAで外国人エンジニア比率が30%を超える中、海外出身のエンジニアが日本語のPR/会議/障害対応でトーンを外さず生き残るための実践語彙集。敬語の階段、お疲れさまです vs 承知しました vs 了解の丁寧さランク、議事録テンプレート、ふりかえり(KPT/YWT)、単体/結合/UAT テスト用語、暫定 vs 恒久、障害対応表現、1on1/評価/OKR、J
2026-05-16 · 37 分で読めます #japanese-for-developers#tech-japanese#keigo#business-japanese#code-reviewグローバル開発者英語表現辞典 2026 - コードレビュー、スタンドアップ、1:1、RFC、ポストモーテム、PR、面接まで実践ガイド
2026年、グローバル分散エンジニアリングチームで働く日本人開発者向けの実践的な英語表現ガイド。コードレビューのLGTM/nit/non-blocking、Slackのheads up/bump/gentle ping、スタンドアップのparking lot、1:1のtop of mind、RFCのout of scope/non-goals、ポストモーテムのroot cause/blameless、PRのcloses 123/behi
2026-05-16 · 36 分で読めます #technical-english#code-review#standup#rfc#postmortem現代のコードレビューとMergeパイプライン — PR・Merge Queue・Stacked PRs・Monorepo・AI Review・Trunk-Based・Husky・Semgrep 深掘りガイド (2025)
毎日やっているのに一番語られない活動。PRの社会学・Code Owner・Merge Queue (GitHub/Mergify/Aviator/Graphite)・Stacked PRs (Graphite・Sapling・Jujutsu)・Monorepo vs Polyrepo 2025・Nx/Turborepo/Moon/Bazel・AI Review (CodeRabbit・Greptile・Ellipsis・Cursor)・
2026-04-15 · 17 分で読めます #code-review#pull-request#merge-queue#monorepo#stacked-prsPlatform Engineering 完全ガイド 2025: Internal Developer Platform, Backstage, Golden Path
Platform Engineeringのすべて！Internal Developer Platform(IDP)構築、Backstage（サービスカタログ/テンプレート/TechDocs）、Golden Path（標準化された開発パス）、セルフサービスインフラ、Developer Experience測定、Platform as a Product、組織設計。
2026-04-13 · 26 分で読めます #platform-engineering#idp#backstage#golden-path#developer-experienceプラットフォームエンジニアリング 2026: 内部開発者ポータル(IDP)で開発生産性を30%向上させる
プラットフォームエンジニアリングはDevOpsに代わる新しいパラダイムです。Backstageのような内部開発者ポータル(IDP)を通じて、開発チームは「ゴールデンパス」に従い、インフラストラクチャ、セキュリティ、デプロイが完全に自動化され、開発生産性が最大30%向上しています。
2026-03-16 · 11 分で読めます #platform-engineering#backstage#idp#developer-experience#devops開発者の認知負荷管理とチームトポロジー：DevEx革新実践ガイド
認知負荷理論、SPACEフレームワーク、Team Topologiesパターンを組み合わせ、組織の開発者体験（DevEx）を体系的に測定・改善する実践ガイドです。
2026-03-14 · 20 分で読めます #devops#developer-experience#cognitive-load#team-topology#devexPlatform EngineeringとBackstageによるInternal Developer Platform構築実践ガイド
BackstageベースのInternal Developer Platform構築からSoftware Catalog、Golden Path Template、プラグイン開発、運用自動化まで網羅するPlatform Engineering総合ガイド。
2026-03-06 · 28 分で読めます #devops#platform-engineering#backstage#internal-developer-platform#developer-experienceマウスに触れない喜び：ターミナル生産性を最大化する5つの核心戦略
vim-tmux-navigatorによるシームレスなナビゲーション、直感的なパネル分割、Vimuxによる超高速フィードバックループ、システムクリップボード同期、Dotfiles管理 — VimとTmuxでターミナル生産性を最大化する5つの核心戦略を、実践的な設定とともに徹底解説。
2026-03-01 · 51 分で読めます #vim#tmux#terminal#productivity#neovim