タグ

kiririmodeのブックマーク (9,578)

  • 人間レビューはもう不要? AI と人間のレビューの線引きを決めた話

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

    人間レビューはもう不要? AI と人間のレビューの線引きを決めた話
    kiririmode
    kiririmode 2026/05/04
    AI 時代のレビューは、人間がすべてを承認する仕組みから、不可逆な判断だけを人間が担い、戻せる変更は AI レビューとセルフマージで高速に流す仕組みへ変えるべきと言う話
  • AIによってプロダクトマネジメントとMVPの重心が変わった話|numashi/LayerX バクラクVPoP

    はじめにLayerXで執行役員/VP of Product をしているnumashiといいます。 これまでキャリアの多くを、新規プロダクトの立ち上げにプレーヤーとして費やしてきました。ゼロからプロダクトを作り、顧客に届け、失敗し、作り直す——その繰り返しの中で、Minimum Viable Product(以下、MVP)という概念は自分にとって単なるフレームワーク以上のものでした。 「何を作るべきか」を問い続けるための、思考の型でした。 今、新規事業をやる中で、改めて生成AIの登場によってMVPの意味が根から変わりつつあると感じたため、言語化しようと思います。 MVPとは何か新規プロダクトを作る際、MVPは開発の羅針盤でした。 Minimum Viable Product——その質を説明するとき、Henrik Knibergのイラストがよく引用されます。 「車を作るなら、まずタイヤだけ

    AIによってプロダクトマネジメントとMVPの重心が変わった話|numashi/LayerX バクラクVPoP
    kiririmode
    kiririmode 2026/05/04
    仕様負債は、顧客課題への解像度の低さが、時間差でプロダクトに請求してくる借金。生成AI時代のMVPで本当に重要になるのは、実装スコープを削る能力ではなく、顧客課題と仕様を深く定義する能力
  • 品質の言語化のススメー早期テストの原則をClaude Code Agent Skillsで実現する試み - LayerX エンジニアブログ

    LayerX QAエンジニアの小山です。 昨今、AIコーディングアシスタント(特にClaude Code等)の進化により、コードの実装やテスト追加のスピードが飛躍的に向上しています。しかし、AIにコードを書かせる際に「どこまで厳密なエラーハンドリングが必要か」「テストはどの程度書くべきか」といったことに迷われた経験はないでしょうか? 今回は、バクラク事業部の品質の定義やテスト戦略などを言語化し、Claude Codeが動く際にリスクの高い箇所を守るように動いてもらい、テストも同時に生成してもらう、早期テストで時間とコストを節約する試みについてご紹介します。 ソフトウェアテストの原則「早期テストで時間とコストを節約する」 筆者はJSTQB FLの公認コースのトレーナーを15年ほどしているのですが、JSTQB FLシラバスの中に「テストの原則」として7つの原則があります。その中の1つとして「早

    品質の言語化のススメー早期テストの原則をClaude Code Agent Skillsで実現する試み - LayerX エンジニアブログ
    kiririmode
    kiririmode 2026/05/04
    AIが速くコードを書く時代に品質を守るために必要なのは、AIに丸投げすることではなく、人間が品質・リスク・テスト責務を言語化し、AIが開発初期からそれを適用できる仕組みにすること
  • https://x.com/suthio_/status/2050033020535820420?s=12&t=8snO90Ee0V5u8yV3LK7zwA

    kiririmode
    kiririmode 2026/05/04
    Anthropicの開発速度は「AIを使っているから速い」のではなくAIを前提にプロダクト開発の構造そのものを作り替えているから速い。AI時代の競争力は組織全体が「作る・使う・評価する・直す」を高速に回せる構造の保持
  • サプライチェーン攻撃の対策 - kawasima

    背景: 何が起きているか 2025年9月、Shai-Hulud攻撃がnpmエコシステムを直撃した。ngx-bootstrap、ng2-file-upload、@ctrl/tinycolor等の正規パッケージが改ざんされ、postinstallフックで難読化済みのbundle.jsを実行、npm/GitHub/クラウドの認証情報を窃取しwebhook経由で外部へ送信した。最終的に数百パッケージが汚染された。[1] 2025年11月のSHA1-Hulud(第2波)では、被害者をGitHub Actions self-hosted runnerに変換し、リポジトリにワークフローを注入してAWS/Azure/GCP認証情報を吸い出す手口に進化。600以上のパッケージ(Zapier、PostHog、Postman等)が影響を受けた。[2] 2026年3月にはAxiosが直接侵害された。攻撃者はメンテ

    サプライチェーン攻撃の対策 - kawasima
  • AI駆動開発で、なぜミドルエンジニアは不安になるのか ── AIによる分業の終わりと始まり - arclamp

    AI駆動開発が「使える」となってきたことで、20代後半から30代中盤のミドルエンジニアが疲弊しているという話を聞きました。たしかに、エンジニアの中でも「AIは楽しい・これでもっと良くなる」という意見と「不安だ・これからどうなるのだろう」という意見に分かれているようです。 私の周りでは、特にベテランが楽しんで、ミドルが不安になっているような構図を感じています。 この記事では、システム開発における30年間の分業と統合の歴史を振り返りつつ、それぞれの世代が何を経験してきたのかを整理します。そのうえで、AI駆動開発が既存の分業をどのように統合しようとしているのかを見ていきます。そして、これがベテランとミドルの違いに、どのように影響しているのかを考えます。 最後には、AI駆動開発が「分業の終わり」ではなく、AIを前提にした「新たな分業の始まり」でもある、という見方を提示します。 この30年の歴史を振

    AI駆動開発で、なぜミドルエンジニアは不安になるのか ── AIによる分業の終わりと始まり - arclamp
    kiririmode
    kiririmode 2026/05/04
    AI駆動開発は専門分業の終焉でなく、AIを前提に「何をAIに任せ何を人間が担い境界をどう設計するか」という新しい分業を始める変化。ミドルの不安は、自分の存在価値を支えてきた専門領域がAIに直接触れられるから生じ
  • Compound Engineering

    kiririmode
    kiririmode 2026/05/04
    開発のたびに得た知見をエージェント・ドキュメント・レビュー観点・ワークフローへ還元し次の開発を高速/安全/高品質にする開発思想。AI時代のエンジニアは良いコードが継続的に生まれる仕組みを設計改善し続ける人
  • A Guide to Agent-native Product Management

    kiririmode
    kiririmode 2026/05/04
    AIエージェントによってPMの作業実務は対話化・自動化されるが、PMの本質である「プロダクトへのオーナーシップと説明責任」はむしろ戦略、出荷、学習、見直しのループを設計する役割として強まる。
  • Most Companies Aren't Anywhere Near Ready for AI

    Most of the frustration people have with AI not being able to do what they want is actually them not being able to describe what they want. I have consulted for the world's largest companies, hundreds of startups, and tons of mid-size companies in the Global 1000. The number one issue I see is unclear and constantly-changing vision and goals. AI is about execution, and it's quite powerless when it

    Most Companies Aren't Anywhere Near Ready for AI
    kiririmode
    kiririmode 2026/05/04
    AIで成果を出せるかどうかは、AIの性能よりも、企業が自分たちの目的・戦略・業務・課題を明確に理解し、実行可能な指示として言語化できる状態にあるかで決まる。混沌とした組織を自動的に賢くする道具ではない。
  • Graphify — Knowledge Graph Skill for AI Coding Assistants

    kiririmode
    kiririmode 2026/05/03
    AIコーディングアシスタントにリポジトリを雑に読ませるのではなく、AST含め事前に構造地図を作って、必要な依存関係・設計意図・関連ファイルだけを辿らせるための前処理ツール
  • GitHub Copilot is moving to usage-based billing

    TL;DR: Today, we are announcing that all GitHub Copilot plans will transition to usage-based billing on June 1, 2026. Instead of counting premium requests, every Copilot plan will include a monthly allotment of GitHub AI Credits, with the option for paid plans to purchase additional usage. Usage will be calculated based on token consumption, including input, output, and cached tokens, using the li

    GitHub Copilot is moving to usage-based billing
    kiririmode
    kiririmode 2026/04/28
    Copilot の価格を契約席数やリクエスト回数中心の管理からAI 利用量に基づくコスト管理へ移行。AI Credits という含有利用枠を消費する方式になり、企業ではその含有利用分を組織全体でプールし予算制御と組み合わせて管理
  • 個人開発アプリを作ったあと、どう売るかを仮説検証して整理してみた

    はじめに 「アプリは作れた。でも、どう売ればいいか分からない」── そう思ったことはないでしょうか。 個人開発で意外と難しいのは、実装そのものよりも「誰に、どういう文脈で届けるか」です。 最近、集中用の環境音ミキサーアプリ Focusnest をリリースしました。 機能にはそれなりに自信がありました。複数音のミックス、プリセット保存、タイマー統合、1/fゆらぎ、オフライン対応。機能だけ見れば、十分戦えそうに見えます。 でも、いざ「どう売るか」を考えたときに手が止まりました。 環境音アプリとして見ると競合が多い。機能は説明できる。でも、それが「欲しい理由」として伝わる気がしない。 そこで、仮説検証ツール kaizen-lab を使ってマーケティングの仮説を整理してみたところ、Focusnest は「環境音アプリ」ではなく、集中に入るためのスイッチ として売るべきなのではないか、という仮説が見

    個人開発アプリを作ったあと、どう売るかを仮説検証して整理してみた
    kiririmode
    kiririmode 2026/04/26
    機能でなくユーザの課題文脈から価値を再定義する。既存カテゴリで競合比較されるならカテゴリをリフレーミングし、嗜好ベースではなく課題ベースでターゲットを絞る。機能訴求は状態変化・ユースケース訴求に変換
  • GitHub - tobymao/sqlglot: Python SQL Parser and Transpiler

    SQLGlot is a no-dependency SQL parser, transpiler, optimizer, and engine. It can be used to format SQL or translate between 31 different dialects like DuckDB, Presto / Trino, Spark / Databricks, Snowflake, and BigQuery. It aims to read a wide variety of SQL inputs and output syntactically and semantically correct SQL in the targeted dialects. It is a very comprehensive generic SQL parser with a ro

    GitHub - tobymao/sqlglot: Python SQL Parser and Transpiler
    kiririmode
    kiririmode 2026/04/26
    dialectを含むSQLをASTとして解析し、BigQueryやSnowflake、Posrgresqlなど異なるSQL方言間で変換・整形・検証できるPython製OSSライブラリ。データ基盤移行、SQL静的解析、リネージ抽出、AI生成SQLの検証などに使うSQL処理基盤
  • Agent Harness Engineering

    April 19, 2026 A coding agent is the model plus everything you build around it. Harness engineering treats that scaffolding as a real artifact, and it tightens every time the agent slips. Roughly: anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again. We’ve spent the last two years arguing about models. Which one is s

    Agent Harness Engineering
    kiririmode
    kiririmode 2026/04/26
    エージェントが失敗したときにモデルの限界として諦めるのではなく、失敗をハーネス上の制約・ツール・フィードバック・運用ルールへ変換し同じ失敗を二度と起こさないようにすることが、エージェント開発の中核
  • GitHub Copilot制限へ、2026年1月以降の週次運用コストがほぼ倍増したことを受けて課金方式をトークンベースへと段階的に移行か

    GitHubGitHub Copilotの個人向けプランについて、新規申し込みの停止、利用制限の厳格化、利用可能モデルの見直しを2026年4月20日に発表しました。GitHubは「今回の措置は既存ユーザー向けの安定した提供体制を守るため」としていますが、別の報道では「GitHub Copilotの週次運用コストが2026年1月以降ほぼ倍増しており、Microsoftが将来的にトークンベース課金への移行を検討しているため」と伝えられています。 Changes to GitHub Copilot plans for individuals - GitHub Changelog https://github.blog/changelog/2026-04-20-changes-to-github-copilot-plans-for-individuals/ Changes to GitHub C

    GitHub Copilot制限へ、2026年1月以降の週次運用コストがほぼ倍増したことを受けて課金方式をトークンベースへと段階的に移行か
    kiririmode
    kiririmode 2026/04/26
    GitHub Copilotも、エージェント型利用による計算コスト急増を受け個人向けプランを制限し始めている。固定月額中心の価格モデルから将来的にはトークン消費量に応じた課金へ移行していく可能性あり。まぁそうなるよね…
  • 「あの人さえいなければ」──この誤診が、チームの生産性を下げる | サイボウズ式

    話題の人気ブログ「おい、」シリーズの著者で、ソフトウェアエンジニアのnwiizoさんによる新連載「生産性を取り戻せ」が始まります。この連載では「仕事の生産性」をあらゆる角度から捉え、チームで生産性を高めていくためのヒントを探っていきます。 第1回のテーマは「なぜ私たちは“意味のない忙しさ”に陥るのか?」です。そもそも「生産性が下がる構図」とは何なのか、その質に迫ります。 はじめに 金曜日の午後4時だった。 「来週のアラインメント会議の事前資料」を作っていた。正確に言えば、事前資料を作るための事前打ち合わせで「次回までにまとめておいてほしい」と言われた内容を、資料に起こしていた。その中身は、先週の会議で話したことの要約だ。 先週の会議も、その前の週の会議も、同じことの繰り返しだった。誰のための資料かわからない。何を決めるための会議かもわからない。ただ、カレンダーに入っている。入っているから

    「あの人さえいなければ」──この誤診が、チームの生産性を下げる | サイボウズ式
    kiririmode
    kiririmode 2026/04/26
    知識労働では価値よりも可視性が評価されやすい。そのため組織は善意のまま「見える忙しさ」を増幅する。価値を生まない忙しさを再生産する構造を見えるようにする語彙を持つことが生産性を取り戻す第一歩
  • Gemma 4をローカルで動かす ── PLE・量子化・TCO計算まで踏み込む実践ガイド - Qiita

    2026年4月2日、Google DeepMindがGemma 4をApache 2.0ライセンスで公開しました。E2B、E4B、26B MoE、31B Denseの4サイズ展開で、スマートフォンからワークステーションまでカバーします。 Reddit r/LocalLLaMAでは公開直後から大きな反響があり、Arena(旧LMSYS Chatbot Arena)のテキストリーダーボードでは31Bがオープンモデル3位(ELO 1,452)、26B MoEが6位にランクインしています。 この記事では、Gemma 4の技術的な特徴を掘り下げたうえで、手元のデバイスで動かすための具体的な手順を整理します。 Gemma 4の技術的な強み Apache 2.0ライセンス 商用利用・改変・再配布が自由なApache 2.0を採用しています。LlamaやMistralのカスタムライセンスと異なり、企業での

    Gemma 4をローカルで動かす ── PLE・量子化・TCO計算まで踏み込む実践ガイド - Qiita
    kiririmode
    kiririmode 2026/04/26
    Gemma 4はPLEによる軽量化、量子化、AL2ライセンスによってローカルLLMを実務で使える選択肢に近づけた。ただしAPIの全面代替ではなく、機密データ処理・オフライン利用・反復タスクのTCOに向いた補完手段として捉えるべき
  • GitHub Copilot は自ら学ぶ: Copilot Memory 入門

    この記事は「GitHub Copilot のメモリ機能」についての連載記事の第1回です。2026年4月時点の情報に基づいています。 GitHub Copilot は自ら学ぶ: Copilot Memory 入門(この記事) VS Code で GitHub Copilot のメモリ機能を使ってみた Copilot CLI で GitHub Copilot のメモリ機能を使ってみた Copilot Cloud Agent で GitHub Copilot のメモリ機能を使ってみた GitHub Copilot のメモリ機能のベストプラクティス GitHub Copilot のメモリ機能 カスタム インストラクション、Agent Skills、AGENTS.md、…。GitHub Copilot をカスタマイズする方法はここ1年で急激に増えました[1]。これらは基的に人間が書いて、ファイルと

    GitHub Copilot は自ら学ぶ: Copilot Memory 入門
    kiririmode
    kiririmode 2026/04/26
    GitHub Copilotのメモリ機能は開発者が毎回コンテキストを説明しなくてもリポジトリ固有の知識をエージェント間・環境間で再利用可能にする仕組み。Copilot Memoryはクラウド上に保存。
  • https://x.com/genkaidokusho/status/2047437540035293379?s=12&t=8snO90Ee0V5u8yV3LK7zwA

    kiririmode
    kiririmode 2026/04/25
    シゴデキを、カオスに秩序を与えるための「言語=ルール」を持ち込むことと定義すると、その言語が周囲の認識や行動を規定する以上、そこには不可避的に権力性が生まれる。だからメタ認知と第三者的牽制が必要
  • https://x.com/akshay_pachaar/status/2041146899319971922?s=12&t=8snO90Ee0V5u8yV3LK7zwA

    kiririmode
    kiririmode 2026/04/25
    エージェントの性能差はモデル差だけでなくハーネス設計の差から生まれる。AIエージェント開発の本丸は、プロンプトではなくハーネスエンジニアリングにあるという話