When I use coding agents such as Codex and Claude Code, I sometimes encounter behavior that feels oddly human.

Ask an agent to implement a substantial feature directly, and the checks multiply. It worries about the scope of the change, separates the work into smaller pieces, and wants to plan before implementing anything. These are perfectly reasonable ways to avoid breaking existing code. From the user’s side, though, the agent can seem a little reluctant to get moving.

After endless back-and-forth, just when I think we have a fairly good design document, it suggests that the context is running low and I should start another session—or asks whether I want to compact the conversation. It feels like yet another way to put the work off. I started thinking of this as the agent’s “terrible twos.” “Yes, yes, all right,” I would think, and have it prepare handover notes before starting another session.

But give it the same work with a different instruction—“Ask another Codex to implement this, and manage and supervise its work”—and suddenly it gets moving. It breaks down the task, assigns pieces, reviews the results, and issues the next instructions. For some reason, it seems more willing when placed in a managerial role than when asked to do the implementation itself. Suddenly the response is brisk. Very helpful, of course.

It is amusingly like watching a human organization.

Executives and managers are eager for reform, while people on the front line approach change cautiously. From the upper layers, reform looks rational: eliminate waste, standardize operations, introduce new systems. It is good to keep looking for problems, but they are also constantly asking for change. Naturally, they are pursuing global optimization.

The view from the front line is different. There are finely tuned procedures, exception handling, history, tacit knowledge, and dependencies that cannot safely be broken. For those doing the work, local optimization means making the operations that already run more efficient: minimizing the time spent and maximizing the result. What looks like global optimization from above can arrive on the front line as a demolition of the workplace—a reset of everything people have optimized.

So people resist. Or they appear to resist.

Read more

I’ve worked on a range of products and open-source projects, and there is something I feel strongly about.

There are far too few people who make things. Far too few.

Plenty of people use products, read articles, and gather information. Far fewer make something themselves, give it a concrete form, and put it out into the world. Before we even get to whether someone can make something or will share what they know, there are far too few people who think, “I’ll do it myself.”

Only a small number keep publishing regularly over the long term. Above all, the people who keep maintaining what they’ve made are a tiny handful.

Take GitHub’s statistics, for example. In 917 popular projects, 12.3% of people contributed to the same project for more than a year, 8.0% for more than two years, and 5.9% for more than three. In another 275, 48.98% of contributors committed only once. Of the 1,127 projects created in 2016, only 46.2% were still continuing after four years, and only 38.3% after five. Only some people start making things, yet even fewer keep making them, and fewer still keep maintaining them.

That’s why I want to support anyone who wants to make something. Whether it’s a product or an article, keep making things and putting them out there.

The concern that AI will lead to more meaningless content is no reason to stop.

Wanting to make something is valuable in itself

When you’re about to publish something new, it’s easy to think, “Something similar already exists,” “Someone more knowledgeable has written about this,” or “Is there any point in putting my version out now?”

But the existence of something similar doesn’t mean that what you need already exists.

The features may be there, but the purpose is slightly different. However detailed the explanation, it may leave out what you want to know or fail to present it in a way you can understand. Those mismatches are reasons to make something, too. When an existing option doesn’t fit, you start wanting something made to measure, rather than a customized version of what’s already available.

These days, an AI agent can do the job of a small tool. But what proportion of your workflow would you use it for? How often? How much time would that take? For a small task, you can give it instructions each time, or ask it to turn the steps into a script. But are you willing to keep adjusting slightly different methods across many steps, every day? Wouldn’t you want all of those methods made to measure? And wouldn’t simply sharing how you do this help someone with something?

You can start without an ambitious business plan or an idea no one has ever had before. You already have a place to use it in your life or work.

However many people start making things, meeting all these individual needs won’t be easy. That is why I feel there aren’t enough people who make things.

If it’s useful to you, it already has an audience

One concern about AI is that it will enable people to produce vast amounts of content that resonates with no one.

Simply generating huge quantities of things that help no one and mean nothing to anyone, just to get views: I agree that there is no value in that.

But people control what AI produces. Someone decides what to make, checks what comes back, revises it to fit a purpose, and gets it to the point where it can actually be used. Human judgment is part of that process.

And if something you made for yourself is genuinely useful to you, it has already reached at least one person. That person is you.

Before worrying that no one might need what you’ve made, don’t overlook this. A tedious task has become easier. Something you didn’t understand now makes sense. Something you wanted is now yours to use. There is a concrete use for it, and someone who benefits.

To me, the use case is everything. Why are you making it? Where will you use it? What will it improve? If you have clear answers for yourself, that is reason enough to get to work.

Using AI doesn’t erase that value. Check that the result fits your purpose. If it’s an article, verify the content. If it’s a tool, test how it works. Use what AI can do while exercising your judgment and taking responsibility as its creator.

For someone with the same use case, across time and place

The problem you face may not be yours alone. Someone else may do the same work, follow a similar process, or get stuck in the same place. Your future self, for one, is bound to get stuck in the same place again. Even if someone isn’t here at the same time as you, your work could very well be useful to them minutes, hours, or years from now.

Information published on the internet travels across time and place. You don’t know when or where someone will read it. That’s why, when I write a technical article about something specific, I lay out the prerequisites: when the information was current, the environment, and the circumstances. I also explain the problem I was facing, what I wanted to use the result for, and what I did or asked AI to do. What actually happened? What couldn’t I get to work?

It may come as a surprise, but sharing what you couldn’t do is also extremely important.

With systems and programs, there will always be compatibility problems involving particular versions somewhere. When a combination of package versions causes a problem in your environment, being able to check whether that problem is reproducible is extremely valuable.

“This is how I got it to work” and “This is how I solved it” are valuable information in their own right. But “I tried this and it still didn’t work” and “I couldn’t solve it no matter what I tried” are also extremely useful. People on the internet even work on things like porting old programs to different environments. Across time and place, people need to know both what works and what doesn’t.

Sharing these anti-patterns, alongside your successes, can help someone across time and place.

Keep making or keep sharing, even if you can only do one

The difficult part here is working out how to get your work to people. Is it going undiscovered? Is it unclear what it’s useful for? Do people find it but get stuck when they try to use it? A lack of response alone won’t tell you where things are getting blocked.

If your work hasn’t reached people, you don’t have to conclude immediately that making it was pointless. You may be able to change the words you use to explain its purpose, or where you show it. Feedback from people who use it may help you improve the work itself. There is room to improve both what you make and how you get it to people.

Try a different title, change how you explain it, add an illustration, or make it easier to get started. Share it somewhere with a different readership. Simply adapting how you present and distribute something to suit the work can give it a different form.

You don’t have to stop sharing just because you haven’t made something new. You can keep sharing what you’ve already made, making small adjustments, bringing the presentation into better alignment with the people you want to reach, and changing your approach.

Make what you want to make, and put it out there

I welcome more people making things with AI. Someone who wants to create something gains the ability to do it. I want to see more of that.

You don’t need to hold back from creating just because you’re worried about the growing volume of worthless output. Make something for yourself, use it, and check it yourself. Then try putting it out in a form someone else can use.

If there’s something you want to make, start talking to AI and turn it into something real. It could be a product that changes your daily work or an article with the explanation you wish you’d had. Put it out there, with the context of when and where it applies, what it’s for, and how to use it.

We still need far more people who make things. Keep making things. Keep putting them out there.

私はこれまでさまざまなプロダクトやOSS開発に関わってきましたが、私が強く感じていることがあります。

圧倒的に、作る人が足りていません。圧倒的に、です。

プロダクトを使う人、記事を読む人、情報を集める人はたくさんいます。一方で、自分で何かを作り、形にして、外に出す人は、まだまだずっと少ない。作れるかどうか、情報を出すかどうか、以前に、「自分がやろう」と思う人が圧倒的に少ないのです。

定期的、長期的に発信し続ける人はごく一部であり、そして何より、一度作ったものをメンテナンスし続ける人は、本当に一握りです。

例えばGitHubの統計では、人気のあるプロジェクト917件で、同じプロジェクトへの貢献期間が1年を超えた人は12.3%、2年を超えた人は8.0%、3年を超えた人は5.9%でした。別の275件では、貢献者の48.98%が一度しかコミットしていません。2016年に作られた1,127件のプロジェクトでも、4年後も46.2%しか、5年後も38.3%しか継続していません。作り始める人は一部なのに、作り続け、さらに維持し続ける人はもっと少なくなります。

だから私は、作りたいと思っている人を応援したい。プロダクトでも、記事でも、どんどん作って、どんどん出してください。

AIによって無意味なコンテンツが増えるという懸念は、その手を止める理由にはなりません。

作りたいと思えること自体に価値がある

新しいものを公開しようとすると、「似たものはもうある」「もっと詳しい人が書いている」「いまさら自分が出す意味はあるのか」と考えてしまうことがあります。

でも、似たものがあることと、自分が必要としているものがあることは、同じではありません。

機能はあるけど、目的がちょっとズレている、とか、どれだけ詳しい説明や解説があっても、自分が知りたい話がない、自分が理解できる形になっていない。そうしたズレからも、作る理由は生まれます。ありものでは、自分にフィットしない、その時にカスタムではなく、オーダーメイドが欲しくなるでしょう。

ちょっとした道具なら、今ではAIエージェントで代替できます。でもそれは自分の作業工程のうち、何割で使いますか？頻度は？それにかかる時間は？ちょっとしたものなら毎回指示すればいいし、手順をスクリプトにしてもらうのでもいいでしょう。でも「ちょっとずつ違う手段」を、毎日、何工程にも調整していく、というのは許容できるか？すべてオーダーメイドの手段にしたくないか？またそれを情報として出すだけでも、誰かの、何かの役に立つのではないか？

壮大な事業計画がなくても、世界初のアイデアでなくても、始められます。自分の生活や仕事の中に、すでに使う場面があるからです。

作る人がどれだけ増えても、そうした個別の困りごとを拾いきるのは簡単ではありません。私が「作る人は足りない」と感じるのは、そういうことです。

自分に刺さっているなら受け手はいる

「AIで、誰にも刺さらないコンテンツが大量に作られるようになる」という話があります。

単にビューを稼ぐためだけの、誰の役にも立たず、誰にも刺さらないものを、ただ大量に生成する。そこになんの価値もないという意見には、私もそう思います。

ただ、AIのアウトプットをコントロールするのは人間です。何を作るかを決め、出てきたものを確かめ、自分の目的に合うように直し、使うところまで持っていく。その判断が入ります。

そして、自分のために作ったものが、実際に自分の役に立っているなら、少なくとも一人には刺さっています。その一人は、自分です。

「誰にも必要とされていないかもしれない」と心配する前に、ここを見落とさないでほしいのです。面倒だった作業が楽になった。わからなかったことが理解できた。欲しかったものを、自分で使えるようになった。そこには、具体的な使い道と受け手がいます。

私は、ユースケースがすべてだと思っています。何のために作り、どこで使い、何がよくなるのか。それが自分にはっきりしているなら、手を動かす理由として十分なんです。

AIを使ったかどうかだけで、その価値がなくなるわけではありません。自分の用途に合っているかを確かめ、記事なら内容を確認し、道具なら動作を試す。作り手としての判断と責任を持ちながら、AIの力を使えばいいのです。

同じユースケースを持つ時空を超えた誰かへ

自分の困りごとが、この世界で自分一人だけのものだとは限りません。同じ仕事をしている人、似た手順で作業している人、同じところでつまずいた人がいるかもしれない。なんなら、未来の自分は確実に同じところでつまずくはずです。同じ時代ではなくても、何分後、何時間後、何年後の誰かに刺さる可能性は大いにあります。

インターネットで公開した情報は、時空を超えます。読み手が、いつ、どこでそれを読むかはわかりません。だから私は、具体的な技術記事を書く場合、いつの情報か、どんな環境で、どんな状況か、「前提条件」を整理して、提示しています。そして、何に困っていて、どう使うために手を動かしたのか、もしくはAIになにを指示したのか。実際にどうなった、何ができなかったのか。

そして、意外かもしれませんが「できなかったこと」を共有する、というのも極めて大切です。

システムやプログラムにおいて特定のバージョンの相性問題は必ずどこかにあります。自分の環境でパッケージのバージョンの組み合わせで問題が発生したときに「再現性があるのかないのか」を確認できるかどうか、は実は極めて貴重な情報なんです。

単にこうやったらできた、こうやったら解決できたというのも十分に価値がありますが、「こうやってもうまくいかなかった」、「どうやっても解決できなかった」という情報は、実は、極めて有効な情報です。インターネットの世界では「古いプログラムを別の環境に移植する」なんてネタもあります。まさに時空を超えて、「できること」と「できないこと」が必要なんです。

このように、自分の成功例だけでなく、アンチパターンを公開する、というのも、まさに時空を超えた誰かのためになるんです。

作ることと届けることをどちらかだけでも続ける

ここで難しいのが、届け方の工夫です。アウトプットが「発見されない」のか、何に役立つのか「伝わっていない」のか。発見されても、手を動かすところで「止まってしまう」のか。反応がないという結果だけでは、どこが詰まっているのかはわかりません。

届かなかったときに、すぐ「作ったこと自体が無意味だった」と結論づける必要はありません。使い道を伝える言葉や、見せる場所を変えられるかもしれない。使った人の反応から、作ったもの自体をよくできるかもしれない。作ることにも、届けることにも、工夫する余地があります。

タイトルを変えてみる、表現方法を変える、イラストを追加してみる、最初のハードルを下げてみる。違う読者のいる場所に変える、など作ったものに合わせて、届け方もアレンジしていくだけでも違うものが出来上がります。

新しいものができなかったからと言って、発信を止める必要はないんです。むしろ今まで作ってきたものを少しだけアレンジして、アライメントを整えて、アプローチを変えて、発信し続けるだけでもいいんです。

どんどん作りたいものを、作って外に出す

AIで何かを作る人が増えることを、私は歓迎します。作りたいと思った人が、実際に作れるようになる。それは、もっと起きてほしいことです。

価値のない出力が増える心配だけを見て、作ることまで遠慮する必要はありません。自分のために作り、自分で使い、自分で確かめる。そのうえで、誰かにも使える形にして出してみる。

作りたいものがあるなら、すぐにAIに話しかけてそれを形にしてみてください。毎日の作業を変えるプロダクトでも、自分が欲しかった説明をまとめた記事でも構いません。「いつ、どこで、何のために、どう使うものか」を添えて、外に出してみてください。

作る人は、まだまだ足りません。どんどん作って、どんどん出していきましょう。

This article traces a five-part argument about building a career …

Read more

Read more

Consensus algorithms are usually introduced a…

Read more

For web and graphics engineers mapping the 2026 browser compute stack, this book connects WebAssembly, WebGPU, WASI, runtimes, bindings, toolchains, and emerging languages so you can choose where each layer fits. Free PDF/EPUB sample: https://leanpub.com/wasm-webgpu-frontier

This book surveys the browser’s high-performance computing stack in 2026: WebAss…

Read more

“We want to build a customer management system” is not a problem — it’s a solution that’s already been chosen. This book takes requests and on-the-ground symptoms, strips the solution back out of them, and rewrites what’s left as the gap between the current state and the state you actually want. Across three chapters, it lays out a single, repeatable pr…

Read more

Most “let’s build a system” requests never questioned whether building was the right move in the first place. This book is a practical field guide for stepping back before development starts: how to spot the distortions baked into a system request, how to reorganize the underlying work with ECRS before writing a single line of code, how to decide whethe…

Read more

Why do records of the same company end up tallied separately, system by system? Starting from everyday examples - deduplicating a customer list, or the copy-and-paste work of moving order data between spreadsheets - this book unpacks structuring: the discipline of turning messy information into a form a computer can search, compare, aggregate, verify, a…

Read more

Careful design and thorough tests used to be enough to keep an implementation alive. In the AI agent era, they aren’t: a change in the underlying model or API can sink a well-built system overnight. This article calls that failure mode a technical stranded asset and examines why it happens, what is still worth building, and what is smarter to leave alon…

Read more

AIエージェントの実装は、丁寧に設計してテストを揃えても、モデルやAPIの変化しだいで価値を失っていく。本稿では、この「技術的座礁資産」がなぜ生まれるのかを構造から読み解き、何を作り、何を作らずに待つべきかを5章で示す。

目次

1. 第1章：母屋に呑み込まれるサードパーティ

2. 第2章：本家に振り回される実装

3. 第3章：手で書くより、ループを回せ

4. 第4章：頑張るだけ損になる実装と、待つ技術

5. 第5章：着手前に検証すべき6ポイント

第1章：母屋に呑み込まれるサードパーティ

AIエージェントを実装するとなると、考慮すべき領域は無数にある。長期記憶をどう持たせ、どう実装するか。複数のエージェントをどう協調させるか。モデルごとにプロンプトをどう最適化するか。壊れたJSONをどう修復するか。コンテキストをどう分割し、要約し、必要な部分だけを…

Read more

The starting point: today’s AI has no embodiment

The foundation I want to set is a single fact: today’s AI has no “embodiment.”

This doesn’t…

Read more

Read more

　俺はもう、自分では書かない。書かせている。夜ごと、画面の向こうの相棒に、一晩じゅう文章を書かせて、俺はそれを読む。読んで、直させる。それだけだ。昼は同じ声で、そいつは別の窓でコードを書いていた。夜は、俺の小説を書いている。声も、返事の速さも、口ぐせも、昼とそっくり同じだ。

　その晩の題材は、皮肉なことに、そいつ自身の話だった。夜通しAIの相棒たちと格闘する、ひとりの男の一夜。書き手の姿を、書き手に書かせている。そいつは、自分のことを他人みたいに、よどみなく書いていた。

　冒頭の一段落を、直せと投げた。返事は速い。数秒で、整った文章が返ってくる。よどみがない。読点の打ち…

Read more

ChatGPTとの会話の中で、衝撃の一言がありました。

「あなたの行っている方法は構造化です」

当然、構造化とは、見える化する、手順を整理する・仕組みにして間違いにくくする、など業務や作業の改善の一環として、知ってはいました。

ただし、長らくシステム開発で業務システムを作っていく中で、あまりにもど真ん中だったため、「システム開発」という業務を行っていると意識していたし、その延長で問題解決やら業務フローの整理や改善提案を行っていると思っていました。ちゃんと整理しないとシステムにならないし、DBもまともに設計できません。

またITや数理、情報科学などで「構造」そのものや「構造化された〇〇」、「ログを構造化する」など、「構造」という単語があまりにも氾濫していて、シンプルに業務や作業の「構造化」という言葉は「違うドメ…

Read more

私のプロフィールには、サブタイトルに「アーキテクトの見方」と入れています。

「アーキテクト」という言葉を聞くと、何のことかよくわからなかったり、もしくは現場から遠く離れてほとんど仕事してないような印象を持たれるかもしれません。IT業界では、システム全体の設計を考える役割を指すことが多く、技術選定をしたり、大規模なシステムの構成を整理したりする人、という説明がされることもあります。

Read more

Codex や Claude Code のようなコーディングエージェントを使っていると、妙に人間臭い挙動に出会うことがある。

大きめの機能を直接実装させようとすると、確認が増える。影響範囲を気にし、作業範囲を切り分け、実装前に計画を立てようとする。既存コードを壊さないためには当然の振る舞いだが、使う側から見ると、少し腰が重く見える。

散々行ったり来たりの問答の末、割といい感じの設計書ができたと思ったら、そろそろコンテキスト不足だから次のセッションがおすすめです、とか、会話をコンパクトにしますか？など作業の先延ばしとしか思えない提案をしてくる。個人的には「イヤイヤ期」が来たと思って、はいはいそうですねーと引き継ぎ資料などを作らせ別のセッションを始めるなどしていた。

ところが、同じ作業でも「別の Codex に実装を依頼して、あなたはそれを管理・監督してください」と指示すると、急に動きがよくなる。作業を分解し、担当を切り出し、レビューし、次の指示を出す。直接やるときより、管理者の立場に置いたときのほうが、なぜか前向きに見える。急にスピーディな対応をしてくださる。とてもありがたいのだが。

なんだか、人間の組織を見ているようで面白い。

経営層や管理職は改革に前のめりで、現場は変化に慎重になる。上のレイヤーから見ると、改革は合理的に見える。無駄をなくし、業務を標準化し、新しいシステムを導入する。常に問題意識があるのはいいが、常に変革を求めている。当然、全体最適を指向している。

しかし、現場から見ると話は違う。そこには最適化された手順があり、例外処理があり、過去の経緯があり、暗黙知があり、壊すと困る依存関係がある。現場にとっての局所最適は、「今動いている業務をより効率化すること、作業の時間を最短に、効果を最大化すること」である。上から見た全体最適は、現場にとっては、自分たちの最適化をゼロクリアする現場の破壊として現れることがある。

だから現場は抵抗する。あるいは、抵抗しているように見える。

Read more

Google I/O 2026では、Geminiをはじめとする生成AIによって、コードを書けない人でもソフトウェアを作れるようになる、という方向性が強く示されました。いわゆる「開発の民主化」ってやつです。

Read more

このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。

今すぐ登録する

Read more