How to make LLM-assisted changes governable, reviewable, and reusable LLM programming assistants have demonstrated considerable value, but mostly with individual developers. The internal IT organization in Thoughtworks has been using them for their teams and have developed a method and workflow called Structured Prompt-Driven Development (SPDD). The article describes a simple example of this workf

Since Claude Sonnet 3.5 (new) in October 2024, I made a habit of testing every new model by asking Claude Code (an internal tool at the time) to add a table tool to Excalidraw. With each new model, Claude got a little further but still failed. Then, with the release of Opus 4 in June 2025, Claude started occasionally succeeding, enough that we turned the exercise into a pre-recorded demo for the C

はじめに 最近、AI エージェント（GitHub Copilot / Claude Code / Cursor / OpenCode / Codex …）に渡す「指示書」の種類が一気に増えました。 GitHub Copilot → .github/instructions/*.md, .github/prompts/*.md Claude Code → .claude/commands/*.md, .claude/agents/*.md Cursor → .cursor/rules/*.mdc これに加えて MCP サーバー / hooks / skills … チーム内でこれらを 「どこから集めて、どこに配っていますか？」 絵にすると、複数の取得元 × 複数のハーネス という多対多の配線を、各チーム／各リポが自前で組んでいるイメージです。 個々のツールが便利になっても、チーム全体としてこ

Decision Quality (DQ) は SDG が体系化した意思決定の質の枠組みで、良い意思決定の条件を6つに分解する。 Frame（解くべき問題の枠組み） Alternatives（選択肢） Information（情報） Values（評価基準） Sound Reasoning（論理的推論） Commitment to Action（実行へのコミット） 全体の質は一番弱い要素で決まる、というのがDQの中心的な主張である。意思決定そのものと、その結果は区別する。良い意思決定でも結果が悪いことはあるし、その逆もある。 設計判断の現場で繰り返し観測される失敗の多くは、6要素のうち Frame と Values の2つの取り違えで説明できる。Valuesを 評価軸 として8つに整理し、Frame の取り違えは 支配軸の取り違え として捉える。残りの4要素も副次的に絡む。早合点 は In

人材育成室 育成メンバーチームで 研修中の はす です。 この間の研修で、「DynamoDBのUpdate APIを、SQLのUPDATE感覚で使うと落とし穴にハマる」 ということを教わりました。 通常は、「対象のアイテムが存在する場合は、更新」 「対象のアイテムがない場合は、エラー」 が出るはずと考えると思います。しかし、実際には、SQL でいうところの Upsert の挙動をします。 つまりは、「対象のアイテムが存在しない場合は、新しく作成する」 のです。 SQL の経験が少ない私でも、これは直感とは違うなと思いました。そこで、他にも似たようにハマるポイントがあるのでは？ということで調べてみました。 DynamoDB を触り始めた方の参考になれば幸いです。 1.PutItem DynamoDB で 単一アイテムを書き込もうと思ったら、PutItem になります。 これが INSERT

30年以上にわたり、ジム・ハーター博士は、多くのビジネスリーダーが「やっているふり」をするだけのことを実際にやってきた。つまり、何が本当にパフォーマンスを動かしているのかを測定することだ。ギャラップの「ワークプレイス・マネジメントおよびウェルビーイング」主任研究員として、ハーターは世界中の数百の組織にわたる数百万人の従業員を対象とした研究を統括してきた。 彼は『Culture Shock: An Unstoppable Force is Changing How We Work and Live』の共著者でもある。現代の職場を作り替えつつある力学を、厳密にデータにもとづいて検証した書だ。彼の結論は、見通しを与える一方で居心地が悪い。というのも、証拠は実のところ何年も前から揃っていたからである。問題は知識ではない。意思だ。 数字は衝撃的だ。世界全体で、仕事にエンゲージしている従業員は約20％

ShopifyはなぜFalcon移行に苦戦したのか？FiberとC拡張ブロッキング #rubykaigi2026 RubyKaigi 2026の「Surviving Black Friday: 329 billion requests with Falcon!」がFalcon gemの生みの親とそのチームが語るShopifyのunicornからFalconへの全面移行の戦いの記録で面白かったので深掘りしたい。本記事では、その発表で語られた事実を整理した上で、Falcon移行の本質である「Fiber Schedulerのフック対象外となるC拡張ブロッキング」を最小再現コードを交えて確認する。 ShopifyはFalcon（Webアプリケーションサーバのgem）を本番導入し、CPUコアあたりおよそ7%の効率改善を狙った。Shopifyのブラックフライデーは、ピーク時に毎秒142万リクエストに達

はじめに こんにちは！Acsim 開発チームの笹沢です。 AI 駆動開発の浸透でコードの生産量は飛躍的に増えました。一方、人間がレビューに割ける時間は変わらないため、レビュー待ちで PR がスタックする場面が以前より増えていきました。 私たちのチームでは「人間のレビューを必須とするもの」と「AI レビューで OK とするもの」を線引きし、セルフマージ制度として日々の開発に組み込みました。直近では PR の 約 8 割が人間レビューを介さずにマージできています。マージまでのリードタイムも短縮されています。 この記事では、セルフマージ制度の設計と運用上の工夫、導入後の変化を紹介します。AI レビューが十分使えるレベルになった今、自チームのレビュー運用を見直したい方の参考になれば嬉しいです。 すべての PR に人間レビューは必要か 最近の AI レビューはコード品質の担保という意味では十分使える

皆さん、こんにちは。sotamakiと申します。 今日は、主にAIエージェント文脈で登場するサンドボックスについて学んだことをまとめていきたいと思います。 前提：AIエージェントは”行動”する 最近のAIエージェントは、単に文章を生成するだけでなく、コードを書いて実行し、ブラウザを操作し、外部APIを叩き、ファイルを読み書きします。指示を受け取り、自ら判断しながら一連の操作を完結させます。 ユーザー入力 ↓ ┌─► LLM（思考・計画） │ ↓ tool call │ 外部ツール / API / コマンド │ ↓ └── 結果フィードバック ↓ 最終応答 この「自律的にツールを呼び出せる」という特性が、従来のWebアプリとは異なるリスクを生む可能性があります。 通常のアプリは「受け取った入力をどう処理するか」をコードに書きますが、エージェントは「何を実行するか」をLLMが動的に決めます。攻

Selective Test Execution at Stripe: Fast CI for a 50M-line Ruby monorepo

Creative professionals look to technology to expand what's possible in their work. Claude can't replace taste or imagination, but it can open up new ways of working—faster and more ambitious ideation, a more expansive skill set, and the ability for creatives to take on larger-scale projects. AI can also help shoulder the parts of the creative process that eat up time by handling repetitive tasks a

ブラウザを開いて、AIエージェントに「最も静音なノイズキャンセリングイヤホンを探して、明日届くように手配しておいて」と頼む。エージェントは複数のECサイトを回り、レビューを比較し、カートに入れて配送指定をした上で、決済画面で「ここから先は確認をお願いします」と返してくる。 このとき、ブラウザの向こう側で何が起きているのか。エージェントはピクセルを目で見ているのか、HTMLを解釈しているのか、それともサイト側が用意した「エージェント向けの入口」を使っているのか。 AIエージェント時代のWebがどう変わっていくのかは、私自身ずっと気になっていたテーマだった。最近腰を据えて調べてみたところ、思っていた以上に議論と実装が進んでいた。今回の記事では、私が学んだ範囲で、いまWebのアーキテクチャへの変更を促しつつある二つの標準技術──WebMCPとNLWeb──を、コードスニペットを含めて紹介していく

アラン・ケイとは何者か 今のコンピュータ体験の多くはここから始まっている Dynabook — 「個人のためのメディア」という構想 GUI — コンピュータを「触れる」ものにした Smalltalk — コンピュータの見方そのものを変えた Appleのプロダクトとケイの思想 未来を当てたのではなく、前提を変えた 「メディアはメッセージである」 コンピュータは「思考のためのメディア」である 「使う」だけでなく「作れる」メディア AI時代の違和感 「何を作るか」から「何を変えるか」へ おわりに 参考 enechainプロダクトデザインデスクの近藤（@add_kk）です。電力や環境価値の取引、トレーディングに関するデザインを主に担当しています。 先日、社内のLT会でアラン・ケイについて紹介したとき、こんな反応がありました。 「未来人すぎる」 「タイムトラベラーでは？」 「その時代にタッチ操作を考

「Anthropic（Claudeを作っている会社）、開発が速すぎる」 最近、周りのエンジニアと話していると、この話題がよく出ます。僕も同じことを思っていて、いろいろ調べているうちに、単に「AIを使っているから速い」という一言では説明できない構造があることが見えてきました。 例えば、下記になります。 2026年Q1の3ヶ月で120以上の機能をリリース（18時間に1機能） エンジニア1人あたり1日約5PR（Pull Request、コードの変更を提出する単位） 社内では毎日60〜100回のリリース Claude Coworkは約10日で構築 Claude DesignはOpus 4.7のリリース翌日に公開 普通のソフトウェア開発企業の感覚からすると、明らかに異次元です。この記事では、公開されているインタビューや内部研究、関係者の発言をもとに、「なぜこんなことが可能なのか」というのを調べた限り