Laws of Software EngineeringA collection of principles and patterns that shape software systems, teams, and decisions.
AIで一気に実装する レイヤー座標データとSVG画像が揃ったところで、Claude Codeに実装を依頼しました。Webアプリ用のプロジェクトを初期化し、Canvas APIでSVGを重ねて描画する処理を実装。初稿の時点でパーツの選択・ポーズの切り替え・PNG出力まで一通り動作しています。 13:39 「理想だ!これが作りたかった半年前」 — ホンディ 初稿 デザインとコードを往復する ある程度コードが形になったところで、デザインとロジックの調整両方を並行して進めるために、generate_figma_designツールを使ってブラウザの表示をFigmaキャンバスに書き出しました。デザイナーが使い慣れたFigma上でUIをブラッシュアップできる状態を作れました。 14:02 「すでに割とデザインいいかんじなんですよねw」 — ホンディ Figma上で調整を進める中で、面白い気づきがありまし
ある朝、俺はなにか気がかりな夢から目をさまして、自分が寝床の中で一本のチューブに変わっているのを発見した。 俺はチューブだ。AIに投げて、返ってきたものを受け取って、また投げる。ロジックの本質は俺をすり抜けて、構築中のシステムとチャットウィンドウの間を往復している。それは確かに俺の中を通ってはいるが、俺には触れていない。どこにも積み重ならない。 時にはもう少し高度な役回りをすることもある。顧客からの苦情が届く、AであるべきところがBになっている。という具合だ。俺はチューブ以外の役回りが出来たことに内心はしゃいで、意気揚々とコンディショナル・ブレークポイントを仕込む。ここがBであるときにデバッガが止まるようにする。そして顧客と同じ操作をして、デバッガが止まるのを待つ。 デバッガは止まった。変数を覗き見しても、何が起こっているかはおぼろげにしかわからない。ただ、チューブ+αとしては上等だ。俺は
HOME > JAXA共通技術文書 JAXAの開発経験を役立ててください 安全・信頼性推進部では衛星・ロケット・探査機等、様々な宇宙機を開発する際の道しるべとなるよう多くの標準(共通技術文書)を整備しています。これらは、より効率的に開発を進めるため、より成功確率を高めるため、長い年月をかけて出来上がった、言わば「虎の巻」です。JAXAプロジェクトでの利用を想定してきたために「~すること」「~しなげればらない」という表現が多用されていますが、民間主体のプロジェクトにも役立つ情報があると信じています。 プログラム管理要求文書 JMR-000 共通技術文書の定義及び管理 JMR-001 システム安全標準English JMR-002 ロケットペイロード安全標準English ・JMR-002様式 ・CZA-2018029 ロケットペイロード システム安全プログラム計画書/安全データパッケージテン
(不定期出世できなかった中年愚痴です。) 二十年以上前に書いた自分の日記 に以下のような一節があった。 コーディング・コンベンションに相当するお仕事コンベンションのようなものが欲しい. 私が求めているのは, 金持ちになる方法でも頭がよくなる方法でもリーダーシップを発揮する方法でも出世する方法でも画家になる方法でもなく, 日々の業務のボトムラインを こういうものだ とまとめたもの. いってみれば お仕事版 “コードコンプリート” … ほど網羅的でなくていいや. “ライティングソリッドコード” のような本だ. ゼロ年代前半に大学を卒業した頃、自分はプログラマのキャリアパスをわかっていなかった。どうも管理職というのにならないといけないらしい。それとは別にアーキテクトとかいうのがあり、それはかっこいいらしい、くらいの認識。それぞれがなんなのかはわかっていなかった。 最初に働いた会社にはたしかに管理
On the foolishness of "natural language programming". Since the early days of automatic computing we have had people that have felt it as a shortcoming that programming required the care and accuracy that is characteristic for the use of any formal symbolism. They blamed the mechanical slave for its strict obedience with which it carried out its given instructions, even if a moment's thought would
This post is essentially this comic strip expanded into a full-length post: For a long time I didn't need a post like the one I'm about to write. If someone brought up the idea of generating code from specifications I'd share the above image with them and that would usually do the trick. However, agentic coding advocates claim to have found a way to defy gravity and generate code purely from speci
はじめに 2026年3月、GoogleのLinuxカーネルチームに所属するRoman Gushchin氏が、AIを活用したパッチレビューシステム「Sashiko」を公開しました。Linuxカーネルのメーリングリストに送られるパッチをリアルタイムで解析し、人間のレビュアーが見落としたバグを自動検出するシステムです。 名前の由来は日本の伝統的な刺繍技法「刺し子」です。布を補強しながら美しい模様を描く刺し子のように、単なるパッチ当てではなくコードの品質そのものを強化するという意図が込められています。 直近1,000件のFixed:タグ付きupstreamコミットを対象にGemini 3.1 Proで検証したところ、約45.2%のバグを検出できたという結果が出ています。注目すべきは、これらのバグがすべて人間のレビュアーによる承認プロセスを通過していた点です。 本記事では、Sashikoの技術的な仕
カスタムリンター戦略: エージェント向けルールの設計 Factory.aiの4カテゴリ Factory.aiがオープンソースで公開したeslint-pluginは、エージェント向けリントルールを4カテゴリに分類しています。 Grep-ability(検索容易性): デフォルトエクスポートよりnamed exportを強制。一貫したエラー型と明示的なDTO。エージェントがコードベースをgrepで走査する際の命中精度を高める Glob-ability(配置予測可能性): ファイル構造を予測可能に保つ。エージェントがファイルを確実に配置・発見・リファクタリングできるようにする アーキテクチャ境界: クロスレイヤーのインポートをブロック。ドメイン固有のallowlist/denylistで依存方向を強制 セキュリティ/プライバシー: 平文シークレットのブロック、入力スキーマのバリデーション強制、e
ChatGPTなどの大規模言語モデル(LLM)の進化により、AI技術は私たちの生活やビジネスに不可欠な存在となりつつあります。なかでも、人間のように自律的にタスクを遂行し、ビジネス課題の解決を可能にする「AIエージェント」が近年、大きな注目を集めています。本連載では、AIエージェントの基本概念から開発実践知、そして将来性までを全4回で徹底解説します。第3回は「AIエージェントの内部構造」をテーマに、コーディングエージェントを例に挙げ、長時間にわたる複雑なタスクを完遂させるための基盤技術「エージェントハーネス」について深掘りします。LangChainが公開する「DeepAgents」の構造と筆者の開発経験に基づいた実践的なカスタマイズ手法を詳しく解説します。 はじめに 第1回では、AIエージェントの基本的な概念と活用が期待される領域について解説しました。続く第2回では、PoC(概念実証)から
開発というともっぱら個人開発をしており、そこで生成AIを使っていますが、最近の自分自身の使い方やツール選び、ワークフローと言うと大袈裟な感じがしますがそういう進め方について、メモしておこうと思います。2025年11月~2026年2月くらい時点のはなしです。 メモなのでたいへんに長くなりました。こちらは Gemini どんによる簡単なまとめです。生成AIを「~どん」と呼ぶのも最近のようすです (読みにくくなるので文中では呼び捨て)。 この記事は、個人開発における生成AI(主にClaude CodeやGemini)の活用手法について、2025年11月から2026年2月時点の状況を記録したものです。コーディング、テスト、設計、レビューなど多岐にわたるタスクをAIに依頼する際の「コンテキストの構築方法」や、作業内容に応じた「委託と伴走の使い分け」について、実際のプロジェクトの事例を交えて解説してい
はじめに 最近は、ずっと GitHub Copilot CLI をメインで使っているのですが、恥ずかしながら LSP サーバーを追加出来ることを知らずに使っていました。LSP サーバーを追加することで GitHub Copilot CLI が、プログラムのコードから特定のクラスやメソッドを探す際に文字列検索ではなく LSP サーバーを使ってコード構造を理解して検索するようになるため、より正確な検索結果が得られるようになります。 これによってテキスト検索のせいで発生する無駄な検索結果が減って AI にとってもコンテキストの汚染を少なくすることが出来るようになります。 追加方法 GitHub Copilot CLI の個人的に素晴らしいと思っている点の 1 つとして、自分自身のドキュメントを検索して自分自身の使い方を教えてくれる点があります。LSP サーバーの追加方法も GitHub Copi
私も、最近まで、GitHub Copilot や、Claude Code を使ってそのヤバさに気づき、様々な葛藤を体験した。そのあたりは次のブログにも書いた通りだ。しかし、最近考えが変わってきた。これ、クッソおもろいやんw いや、マジ最高ですわ。みんなやらんと損やでと思ったのでブログを書いてみることにしました。 ここに書いた通り、私は、コーディングエージェントを自分なりに極めようと決めた。それは、自分が 10x なりなんなりの爆発的な生産性を手に入れないと、ライバルに対抗できなくなるのは自明なのと、プラットフォーマーとして、AI後のユーザ(開発者)が欲しいものが何かを知るためにも、重要と思ったからだ。自分がやらないのは自分の趣味ではなく、プロンプトうつだけで、なんかエージェントのマネージャみたいだし、自分が興味を持てるだろうか?ある同僚は、こういっていた。 私は、休日に AI 抜きでプログ
English Article 最近はClaude Codeでコーディングすることが増えてきました!しかしこいつもそうだけどVSCodeもメモリをもりもり食います。大食いが5プロジェクトもあるとまあメモリもカツカツです。 そうして流行りのGhosttyに乗り換えたのが半年前なんですが、最近はGhosttyでVSCode環境をそのまま再現したい!という今の自分のGhostty環境をお見せします! 私の環境Ghostty環境そして私の元々のVSCode環境です。 詳しく見ていきましょう。まずVSCodeのほうですが、簡単にはこれです。一般的な部類だと思いますが、左のサイドバーにファイル一覧とGitのTree表示。右にはClaude Code or Code Editorとその下にターミナルという基本構成です。 これをそのまんまGhosttyで再現したい!ということで実際に使っているのはこれです
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く