どうもこんにちは、たくびーです。 弊社ではClaudeのチームプランに契約しており、開発者全員がClaude Codeを使うことができます。 希望者はChatGPTのチームプランも使えてCodexを併用することも可能です。 私はAI開発環境整備の一環でルールやスキルの作成やメンテナンスをすることが多いです。 そこで最近はエージェントスキルの設計方針について考えることが多く、現時点でどういう観点でスキルを作成しているかということをご紹介したいと思います。 TL;DR スキルを書くときは振る舞いとナレッジを分ける スキルの書き方にはソフトウェア設計が役に立つ AnthropicやOpenAIのスキルが勉強になるので詰まったら目を通す スキルの責務を小さくする Claude Codeが開発者全員使えるようになり、フロントエンドチームでは普段の開発業務でよく使われているであろう手順をスキルにしてい

はじめに こんにちは、Dress Code 株式会社でプロダクトエンジニアをやっている津田です。 AI が実装の大半を担ってからずいぶんと経ち、単体テストによってある程度の動作の保証をしてくれるようになった一方で、いつの間にか単体テストの実行時間が伸びていました。CI環境で50件計測し、p90 で 16分14秒 にもなっていました。これには GitHub Actions の setup 等も含め、ですが、単体テストの実行時間だけでも14分30秒かかっていました。 CIに時間がかかると、そのまま開発体験の悪さにも直結します。軽微な不具合修正であったとしてもリードタイムとしてその程度以上かかってしまう問題を引き起こします。 今回はそれを改善しました、というお話です。 あくまでも我々の置かれた状況での改善ですが、何か1つでも参考になるものがあれば幸いです。 背景 モジュラーモノリスを採用しており

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

組織には、必ずどこかにレビュアーがいる。 エンジニアが互いの PR をレビューする。TL が設計をレビューする。PdM が要件をレビューする。経営チームが議題をレビューする。組織のサイズが大きくなるほど、レビューの層は増える。層が重なるほど、一人のレビュアーに集まる案件数も増えていく。 そして、あるとき気付く。自分が、ボトルネックになっている。 レビューを待つ起案が、自分のところに積み上がる。一件あたりの議論は丁寧にやりたい。だが、待ち列は伸び続ける。レビュー枠を増やしても、追いつかない。 スケールしない。 待ち列は、なぜ伸びるのか表面的な原因は、案件数が多すぎることだ。レビュアーの時間が足りない。だから列が伸びる。 しかも、案件数は増え続ける。AI で書けるようになって、PR も設計文書も議題も、一人が出せる量が増えた。出す側で増えた分は、レビューする側に溜まっていく。 一方、レビューの

Unified toolchain for Flow Build the strongest React experience with Modern Flow.uf gives Flow-first React apps one native command for dev, builds, tests, formatting and linting. The official Flow parser, React Compiler and oxc stay in the same toolchain, with one config file for the whole path. Pre-release. uf is at 0.0.0-alpha. Interfaces move without warning, and every @uniflowed/* release on n

[SRE AI活用事例] 減らせ！TOIL削減大作戦！ https://mixi.connpass.com/event/403987/

はじめに 私はフロントエンドエンジニアで業務の中でクリーンアーキテクチャに触れる機会が多くあり、 その中で間違えて認識していたことがやっと理解できてきたので整理したいと思います。 この記事では、特に私が間違った認識を持っていた箇所と主にクリーンなアーキテクチャについて必須となる部分を記載していきます。 DDDの実践方法については特に触れませんのでご容赦くださいmm まずDDDとクリーンアーキテクチャは何が違うのか そもそも私は、設計という言葉を大枠で捉えすぎており、 段階に分けてみると、DDDとクリーンアーキテクチャは並ぶものではなく、 別の段階の話をしているだけだと分かります。 設計の段階 決めること 具体的な成果物 代表的なパターン・原則

誰かの作った膨大なAI駆動開発のワークフローやフレームワークではなく、私が個人的にAIにこう動いて欲しいと与えているものをまとめています。間違っていることがどんどん取り入れていきたいので教えてください。 コーディングに特化した内容、具体のHooksやツールに関する記述は除いています。 雑多なメモとして読んでください。当たり前のことばかりかもしれません。 考え方 設計方針 拡張性を標準とします。 API、インターフェース、型、データ構造など、すべての実装を将来の拡張を考慮して設計します。 これは、明示された作業範囲や、それが最終形とされているかどうかにかかわらず、すべての作業に適用されます。拡張に対応できないコードは、最初から書き直すことになります。 知識の鮮度 学習データは古くなります。古い案内は、案内しないことよりも有害です。 次の場合は WebSearch が必須です。 特定のバージョ

BPStudy#188〜要件定義を学ぼう。ChatGPTを添えて( https://bpstudy.connpass.com/event/281289/ ) の登壇資料です。 2023年4月28日(金)に開催。

内製・プロダクト組織のための実践ガイド。計画は外れる前提で立て、要件を軽く扱わず、言われていないことを扱う。立ち上げから要件定義、計画、チーム、実行、運用、そして終わらせ方までを全42章で扱う。

こんにちは！テラーノベルでiOS/Android/Webとフロントエンド周りを担当している @kazutoyo です！ Opus 4.5が出たあたりから、自分でコードを書くことがほとんどなくなりました。 最近はループエンジニアリングという言葉も出てきて、エージェントに任せる流れがさらに加速している感じがあります。 ただ、モバイルアプリで同じことをやろうとすると、Webアプリと比べて検証がしづらく、そこだけ人の手が残っていました。 そこで使っているのが、以前紹介した agent-device です。 エージェント自身がiOS Simulator / Android Emulatorを操作して、自分が書いたコードを確認できるようになりました。 とはいえ、入れれば勝手に回るわけでもなくて、任せられる状態にするための準備が実装側にけっこうあります。 今回は、計画から検証まで実際にどう回しているかと

道具の入れ替わりが激しい今だから、みんながどんな道具を使っているのか気になります。 自分の道具遍歴をまとめておきたくもなります。面倒な手入力はありません。 あなたのいつものエージェントに頼んで、あなたの道具をまとめてみませんか？ はじめる →

はじめに こんにちは、ZOZOTOWN開発2部Webバックエンドブロックのぐらです。普段はZOZOTOWNのバックエンド開発を担当しています。ZOZOTOWNのリプレイスでは、既存システムの仕様を正確に把握することが欠かせません。私たちはこの分析にAIを活用してきました。しかし、人間による追加調査がまだまだ必要という課題を抱えていました。本記事では、AIによる既存システムの分析ワークフローを作り直した過程と、そこで得られた知見を紹介します。 目次 はじめに 目次 背景・課題 ZOZOTOWNリプレイスにおける既存システムの分析 AI分析で直面した3つの課題 AI分析ワークフローを作り直す 改善1 ── 計算で確定できることは計算で出す 改善2 ── 調査を機能単位からシステム横断へ広げる 改善3 ── 出力をMarkdownからHTMLへ変える 改善の効果 精度はどう変わったか レビューの

はじめに こんにちは。商品基盤部の藤本です。 私たちのチームでは、生成AIコーディングエージェント（以下、AIエージェント。主にClaude Code）を使って開発に取り組んでいます。以前からAIエージェントに一貫した実装をしてもらうため、ルールを書いて指示する運用を続けてきました。しかし、ルール同士の矛盾やレビューだけでは遵守を保証できないといった課題がありました。本記事ではこの課題と、ArchUnitによる機械的な検証へ落とし込むまでの取り組みを紹介します。 目次 はじめに 目次 背景・課題 ルールの読者はAIであるという前提の転換 自然文のルールからArchUnitの実行可能な検証への変換 ルール文書・テスト・実コードの三者整合性を担保する方法 アドホックな知識からルールへの体系的な移行 複数リポジトリへのルール展開の検討と見送り 検証の必須ゲート化 まとめ 背景・課題 AIエージェ

Kotlinエバンジェリスト 長澤 太郎 Ubie株式会社のソフトウェアエンジニア。「テクノロジーで人々を適切な医療に案内する」をミッションに、日々開発に勤しむ。 本業のかたわら、自称Kotlinエバンジェリストとして、講演や執筆などを通じて啓蒙活動に尽力。国内最大のKotlin技術カンファレンス「Kotlin Fest」の代表を務める。 @ngsw_taro 『Kotlinイン・アクション』Dmitry Jemerov 著、Svetlana Isakova 著、長澤 太郎 監修・翻訳、 藤原 聖 監修・翻訳、山本 純平 監修・翻訳、 yy_yank 監修・翻訳 『Kotlinスタートブック』長澤 太郎 著 『Kotlin サーバーサイドプログラミング実践開発』竹端 尚人 著 こんにちは！Kotlin Festのオーガナイザーを務めている長澤太郎と申します。 今回は、普段Kotlinを使っ

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

TL;DR Claude Code の AskUserQuestion はターミナル UI なので、選択肢を読み比べる質問には向かない。図っぽいものも出てくるが罫線素片とASCIIアートでは限界がある。 今回作成した review-wizard は、AIエージェントからの人間への質問をブラウザのウィザード画面（1問ずつ表示、ステッパー付き）で出すプラグイン。質問の内容に応じて比較表やインライン SVG の図で説明され、質問が理解しやすくなる。 実装は一時的なローカル HTTP サーバ方式で、外部 npm 依存はゼロ。回答を受け取ったら閉じて終了し、常駐しない。 導入すると、質問が3問以上、あるいは選択肢の比較検討が要るときは Claude Code が自動でこちらを使い、1〜2問の即答は AskUserQuestion のままになる（SKILL.md の基準による）。 リポジトリ: htt