DEV Community: James Anderson

The AI Agent Setup That Saved Me 20 Hours/Week (Full Config Inside)

James Anderson — Sat, 31 Oct 2026 09:55:12 +0000

Last week I deleted 3,000 lines of boilerplate and shipped two full features before lunch. Not because I got smarter — because I stopped doing the parts a machine does better.

Six months ago my week looked like this: write boilerplate, wire up routes, fix the same lint errors, repeat. I measured it once and nearly cried — ~20 hours a week on work that required a pulse but not a brain.

So I rebuilt my workflow around AI agents. Not "paste into ChatGPT" — an actual setup where specialized agents do scoped jobs and I stay the architect.

Here's the exact config. Steal all of it.

The mental model: you're a tech lead now, not an IC

The single biggest unlock wasn't a tool. It was a reframe.

Stop thinking "how do I get the AI to write this file?" Start thinking "how would I delegate this to a junior who's fast but needs clear scope?"

That one shift is what turns AI from a fancy autocomplete into a team.

My setup has three layers:

A planner — breaks a task into steps, never writes code
Workers — each handles one scoped job (a screen, a route, a test)
A reviewer — reads the diff and tries to break it

The setup

I use Claude Code as the harness because it supports subagents natively, but the pattern works with any agent runner.

1. Define specialized subagents

The trick is narrow scope. A generalist agent drifts. A specialist with one job stays sharp.

---
name: screen-builder
description: Builds a single React Native screen from a spec. Does not touch routing or state.
tools: Read, Write, Edit, Grep, Glob
---

You build ONE screen at a time. Match the existing component style exactly.
Never invent new patterns — grep for an existing screen and mirror it.
Return the file path and a one-line summary. Nothing else.

---
name: code-reviewer
description: Reviews a diff adversarially. Tries to find bugs, not to praise.
tools: Read, Grep, Glob, Bash
---

You are a skeptical senior engineer. For every change, ask:
"What input breaks this?" Report only real issues with file:line.
Default to "this is wrong" and make the code prove you otherwise.

2. Keep context tight

Agents get dumb when drowning in context. My rules:

One agent = one task = one clear "done" condition
Agents return conclusions, not file dumps
The planner never sees raw code; the workers never see the roadmap

3. The daily loop

Me:       "Add a repair-booking confirmation screen"
Planner:  → 4 steps, names the 3 files to touch
Worker 1: → builds the screen (mirrors existing screens)
Worker 2: → wires the route
Reviewer: → finds 2 edge cases I'd have shipped
Me:       → approve, commit

Total time: 18 minutes for something that used to eat half a day.

Real numbers (no vibes)

I tracked two weeks before and after on my side project, a repair-booking app:

Task	Before	After
New screen (UI + wiring)	~2.5 hrs	~25 min
Boilerplate/CRUD	~3 hrs/wk	~20 min/wk
Code review pass	~4 hrs/wk	~1 hr/wk
Chasing lint/type errors	~2 hrs/wk	near zero

Add it up and it lands right around 20 hours a week given back.

The mistakes that almost made me quit

I'm not going to pretend this was smooth.

Giving one agent the whole app. It confidently rewrote working code. Fix: scope every agent to one job.
Trusting the diff without reading it. An agent "fixed" a bug by deleting the test. Fix: the adversarial reviewer + I always read the final diff.
No "done" condition. Agents would gold-plate forever. Fix: every task ends with a concrete, checkable result.

The reviewer agent is non-negotiable. An agent that writes code and an agent that tries to break it catches things a single pass never will.

Would you trust this in prod?

That's the real question. My answer today: yes for scoped work, no for architecture. The judgment calls are still mine. The typing isn't.

What would it take for you to hand an agent access to your codebase? 👇

If this helped, drop a ❤️ and follow — next post is my full reviewer-agent prompt that's caught 40+ bugs before commit.

Built for Humans, Flooded by Agents: Why Git Infrastructure Is Being Rebuilt

James Anderson — Thu, 29 Oct 2026 01:15:02 +0000

In May 2026, Anthropic merged around 2,500 code changes a day into its monorepo. By September, it was merging more than 30,000.

That's not a typo, and it's not because they hired twelve times more engineers. Agents were writing the code. And the thing that broke wasn't the agents. It was Git.

Within roughly two weeks in October, three very different organizations published how they're rebuilding source control for this new kind of traffic: Anthropic, GitHub, and Enroute. Andrew Nesbitt noticed the pattern in his weekly source control roundup, and once you read all three side by side, it's hard to unsee.

They took three completely different approaches. But underneath, they arrived at surprisingly similar ideas.

Git was designed for a human at a laptop

Git is decentralized by design. Every clone is a complete repository. You can read history, run blame, diff, and check out any revision while fully offline. Pushes are occasional, because humans are slow.

For the vast majority of projects, that's still the right design. Anthropic's own post says so directly.

Agents break almost every one of those assumptions.

GitHub's numbers show how fast things changed. In September 2026 alone, developers and agents made 7.38 billion commits on GitHub, more than five times as many as a year earlier. Pushes grew 4.9x year over year, from 0.69 billion to 3.35 billion a month. GitHub Actions ran 3.26 billion times in the same month. Total Git activity on the platform more than doubled in a year, from 218 billion events a month to 473 billion.

GitHub's engineering post breaks down what that load actually does to a Git server:

Commit latency becomes the agent's speed limit. An agent in a tight loop commits after nearly every action. Latency no human would notice becomes the bottleneck.
Writes converge on one point. Thousands of agents on their own branches in one repository produce a sustained write rate that hits a single part of the architecture.
Merges fight over one ref. Trunk-based development and merge queues funnel everything into main.
Every push becomes thousands of reads. CI and code scanning fetch the same branch tip thousands of times per minute.
Maintenance never stops. Every write adds compaction and garbage collection work, and the cost compounds.

Anthropic's scale makes this concrete. Its main branch history is almost 100 GB, and a compressed working copy is over 25 GB. CI performs about 25 million checkouts a day. Fetched naively, Anthropic estimates that would be over 600 PB of Git traffic per day.

They tried everything Git offers first: shallow clones, sparse checkouts, promisor remotes, repository snapshots kept in blob storage. At their peak, they ran several hundred internal Git mirrors just to absorb the load. It bought time, but it didn't scale.

So what did each team do?

Approach 1: GitHub fixes the plumbing, without changing Git

GitHub can't replace Git. A billion repositories depend on it working exactly as it does. So GitHub is rebuilding the infrastructure underneath while keeping Git itself untouched.

To understand the problem, you need to know how GitHub stores repositories today. Its storage system, Spokes, keeps a full copy of every repository on the local disks of several file servers, five by default. When a push updates a ref, a three-phase commit protocol uses a quorum so everyone sees a consistent state.

Here's the catch GitHub identified: the mechanism for durability is the same one used for scale. The copies on disk are the source of truth, so adding read capacity means adding another durable replica. And every replica participates in every write. A push is only as fast as the slowest replica.

So adding replicas to handle read load makes writes slower. For most repositories, that trade-off is fine. For agent-scale repositories, it's a ceiling.

GitHub's redesign rests on two ideas:

Coordinate only what needs agreement. The only part of a push that truly needs consensus is the ref update itself. Storing objects, validating connectivity, and secret scanning are expensive, but they can happen in parallel. That shrinks the critical path of a push to one small step.

Separate storage from compute. The authoritative copy of each repository moves into Azure Blob Storage. Read capacity comes from lightweight compute workers that cache data and can be added or removed as traffic changes. Losing a worker becomes closer to a cache miss than a disaster. Maintenance like compaction and garbage collection moves to separate workers, off the hosts serving live requests.

A follow-up post describes one concrete bottleneck along the way. Moving the busiest repositories to Azure was blocked by a repository-wide lock that every write held across a 25 ms cross-region round trip. GitHub is switching to per-reference serialization, so only writes to the same ref wait for each other. That alone gave 3–4x write throughput in internal tests. Across the full new architecture, GitHub reports up to 35x higher write throughput in internal benchmarks.

Approach 2: Enroute keeps Git, but rebuilds storage like a database

Enroute, an open source Git server, takes a middle path. Clients still speak normal Git. But the storage engine underneath was rebuilt from scratch.

Enroute's starting observation is that many existing "Git on object storage" designs still send every push through one primary node, and every replica still keeps a full copy of the repository on disk. That's the same scaling ceiling GitHub hit, just moved somewhere else.

Instead, Enroute stores each repository as a Raft-replicated log of refs plus a list of immutable object layers in object storage like S3. New pushes add layers, which get merged in the background, so there's no git gc to schedule. Packfiles are rewritten on ingestion so that reading from object storage needs only a few requests.

The result: more than 7,500 pushes per second into a single repository, with every push written to a majority of ledger nodes before it's acknowledged.

Enroute is also refreshingly honest about the trade-off. Against stock Git serving a repacked linux.git, full clones are about 17% slower, while shallow clones are more than twice as fast. That's a sensible bet when most of your traffic is CI and agents doing shallow fetches, not humans cloning entire histories.

Approach 3: Anthropic leaves Git behind

Anthropic went furthest. A team of seven built Scion, an in-house version control system, and migrated its entire monorepo off Git in five months.

The key realization was this: like most companies, Anthropic was already using Git as a centralized system with one authoritative copy. And nearly all of its clients were agents and CI jobs, which are online by definition. Git's best feature, working offline with a full copy, was the very thing preventing it from scaling.

So Scion flips Git's model:

The server does the thinking. In Git, every client can act as a full server. In Scion, the server answers history and blame queries, creates commits, and performs merges and rebases. The client keeps only a bounded local cache. It can compute very little on its own, but it needs far less data.

Commits are changesets in a log. A Git commit points to a full tree. A Scion changeset is an entry in a write-ahead log on Spanner that lists only the files that changed, with content-addressed pointers to blobs in storage. There are no packfiles, no locking, and refs are discouraged except for main and release branches, because global state every server must agree on is "a looming scaling problem." Moving a ref is just a compare-and-swap on a single database row.

Expensive queries use derived data. Since a changeset only records what changed, Scion builds extra structures like blame indexes, path history, and skip lists over the commit graph. Each is defined recursively from a changeset's parents, and can be computed eagerly or on demand.

The fetch protocol is inverted. Git's fetch negotiation tells the server what the client already has, and the server computes what's missing. Scion's client instead asks only for specific objects it wants, walking down from the root tree. Every request is for an immutable object, so any cache layer can answer it. Sparse and virtual checkouts need no special support: the client just doesn't ask for what it doesn't need.

That last point enables a tiered cache: a daemon per machine, regional caches, and authoritative servers behind them. Each tier maintains a cache hit rate above 99%. Anthropic reports the new infrastructure is 200x smaller in CPU and memory than its old Git mirror fleet, and CI checkouts now take seconds instead of minutes.

Not entirely new, and worth saying so

When Scion's post first went up, engineer Rain (sunshowers) pointed out that its "derived data" design closely matches Mononoke, the server side of Meta's Sapling, which the original post credited only for "hard-won lessons." Anthropic updated the post two days later to say Mononoke pioneered many of the techniques Scion uses, especially its Bonsai data model, and to name Google's Piper as prior art too.

It's an important footnote. Companies with enormous monorepos solved many of these problems years ago. What's new is that agents are pushing far smaller organizations into that territory, and much faster.

Anthropic is also clear that Scion isn't a Git replacement for general use. It only makes sense for truly enormous monorepos, it requires its own code review, search, and CI, and it isn't being released.

The pattern underneath

Put the three approaches side by side and the same ideas keep appearing:

Idea	GitHub	Enroute	Anthropic
Separate durable storage from serving	Azure Blob + compute workers	Object storage layers	Spanner + blob storage + caches
Shrink coordination to the ref update	Per-ref quorums	Raft log of refs	Ref move is one compare-and-swap
Immutable, content-addressed data	Git objects	Immutable layers	Content-addressed blobs and changesets
Move maintenance off the hot path	Separate workers	Background layer merging	No packfiles, no maintenance
Keep the Git client	Yes	Yes	No

If that table looks familiar, it's because these are database ideas. Write-ahead logs, consensus on small pieces of state, immutable data that caches freely, compaction in the background. Git hosting is going through the same evolution databases went through when they had to scale beyond a single machine.

The real difference between the three is just one row: how much of Git's original model each is willing to give up.

What this means for the rest of us

Most teams won't hit these limits next month. But Anthropic expects this class of problem to become common within six to 12 months, and the ripple effects are already visible.

GitHub now says that during periods of unusual traffic, unauthenticated HTTPS clones of public repositories may temporarily require authentication. It's also previewing push attribution, which records who actually pushed a commit alongside the author and committer, something that matters more when many pushes come from agents.

Anthropic's post also suggests Git itself could absorb some of these ideas without abandoning its model: richer server-side APIs across forges, a different negotiation protocol, and better composition between Git's shallow and sparse features.

In the meantime, if your CI does full clones on every run, that's the easiest win available today. Git already supports most of what these teams are pushing toward:

# Shallow clone of just the latest commit
git clone --depth 1 https://github.com/org/repo.git

# Partial clone: fetch file contents only when needed
git clone --filter=blob:none https://github.com/org/repo.git

# Combine partial clone with sparse checkout for big monorepos
git clone --filter=blob:none --sparse https://github.com/org/repo.git
cd repo
git sparse-checkout set services/api

It won't get you to 30,000 merges a day. But it moves your pipeline in the same direction the biggest teams are going: fetch only what you need, when you need it.

The bigger question

Git won because it was built for a world of distributed humans working offline. That world hasn't disappeared, and for most projects Git is still exactly right.

But a growing share of commits now come from machines that are always online, never sleep, and push thousands of times a day. For that traffic, all three teams independently concluded the same thing: the server has to do more, the client has to do less, and coordination has to shrink to the smallest possible piece.

So here's what I keep wondering: if most commits in a few years come from agents, does Git's distributed design remain the default, or does it become the special case?

I'd love to hear from anyone running CI or agent workloads at scale. Have you started feeling this yet?

Sources

Anthropic, Redesigning source control at Anthropic, October 13, 2026
Brian Celenza, GitHub, Building Git infrastructure for agent-scale development, October 6, 2026
Eleanor White and Victoria Dye, GitHub, The bridge to agent-scale Git infrastructure, October 2026
Enroute, Enroute 0.3.0 release notes and Everyone is doing Git on S3 wrong
Andrew Nesbitt, This Week in Source Control: 28 October 2026
sunshowers, Anthropic's Scion is heavily inspired by Mononoke

Not the End, but a Shift: How AI Is Pushing Computer Science Toward Deeper Engineering

James Anderson — Wed, 28 Oct 2026 05:13:04 +0000

If you're studying computer science right now, or you just graduated, you've probably heard some version of this: AI writes code now, so what's the point?

It's not an irrational fear. The numbers behind it are real.

The fear is real

Researchers at Stanford's Digital Economy Lab studied payroll data covering millions of US workers and found something uncomfortable. In jobs most exposed to AI, workers aged 22 to 25 saw employment fall by about 13% relative to other groups since generative AI took off. For young software developers specifically, employment dropped close to 20% from its late-2022 peak.

And it's not mostly layoffs. Young people aren't being pushed out so much as never being let in. Companies are simply hiring fewer juniors.

So if you feel anxious, you're not imagining things. The ground has moved.

But the same research contains a detail that I think matters more than the headline, and it's where this article is going.

What AI is actually automating

Look at what kind of work AI is replacing.

The Stanford team found that entry-level jobs fell mostly in roles where AI automates tasks: generating complete code, handling routine requests, producing standard documents. In roles where AI augments people, helping them solve complex problems or make better decisions, employment for young workers held steady or even grew.

In software, the automated part is easy to recognize. Boilerplate. CRUD endpoints. Wiring forms to APIs. Converting one format to another. Writing the hundredth version of a login page. This is work that follows patterns, and patterns are exactly what AI is good at.

What AI is much weaker at is the part that doesn't follow a pattern: deciding how a system should be built, understanding why it fails, knowing what can go wrong before it does, and taking responsibility for the answer.

That difference is the whole point of this article.

Why routine development never felt like engineering to me

I want to be clear that this part is personal.

Plenty of developers genuinely love building features, and many developers do deep, serious engineering work every day. This isn't a judgment on them.

But for me, routine development work always felt repetitive. After four years of studying algorithms, operating systems, networks, computer architecture, and theory, I kept wondering why so much of the work waiting for graduates was writing code that looked almost the same as the last project. It never felt like what all that study was for.

And I don't think I'm the only one who has felt this.

How other engineering fields work

Look at other engineering disciplines.

A civil engineer designs a bridge. They calculate loads, choose materials, plan for earthquakes and floods, and sign off on safety. But they don't pour the concrete or weld the steel. Construction crews do that, following the engineer's design.

An electronics engineer designs a circuit and decides how it should behave. But the boards are assembled and manufactured by technicians and production lines.

In both cases, the engineer's value is in design, analysis, and responsibility. The building is done by others.

Computer science has been an exception. For decades, CS graduates were expected to be both the engineer and the builder, and most entry-level jobs leaned heavily toward the building.

AI is starting to change that balance. If AI can increasingly do the building, the human value shifts toward the part other engineers have always focused on.

The engineering side of computer science

This is where it gets hopeful.

There's a whole side of computer science that's about understanding and designing systems, not just producing code:

System design and architecture: deciding how services fit together, how data flows, how a system scales, and what happens when parts of it fail.
Network engineering: understanding how data actually moves between machines, and keeping that movement fast, reliable, and secure.
Cybersecurity: thinking like an attacker, finding weaknesses, and designing defenses. As AI makes attacks faster and cheaper, this field needs more people, not fewer.
Infrastructure and reliability engineering: keeping systems running, diagnosing outages, and designing them to recover.

These roles depend on exactly what a CS degree teaches: how operating systems manage resources, how networks route packets, how databases keep data consistent, how distributed systems behave when clocks disagree and messages get lost.

And people are already moving this way. One analysis of US data found that only about 31% of the 2023–24 computer science graduating cohort were working as software developers, compared with about 39% of the 2019–20 cohort. CS graduates are spreading into a wider range of roles.

The honest part: this shift won't be easy

I'd be doing you a disservice if I made this sound simple.

These engineering roles are not easy to walk into straight out of university. System design usually requires experience seeing real systems grow and break. Security roles often expect hands-on skills and practice. Network and infrastructure jobs come with their own certifications and steep learning curves. And they're competitive too.

Even the Stanford researchers are careful to say AI probably isn't the only cause of the drop in junior hiring, and nobody knows exactly how this will play out.

So this isn't a promise that AI will hand you a better job. It's a suggestion about where to aim. Hope works best when it's honest.

Where to start building real engineering skills

If you're still studying, you have something valuable: time. Here's where I'd put it.

Take your fundamentals seriously. Operating systems, computer networks, databases, and computer architecture are the courses many students rush through. They're also the foundation for every role mentioned above, and the part AI can't learn on your behalf.

Learn how things break, not just how they work. Read public postmortems from companies about their outages. Set up a small server and try to take it down. Learn what happens when a disk fills up, a certificate expires, or a network partition splits your system in two. Engineers are valued for knowing failure.

Get your hands on real systems. Build a small home lab, even on an old laptop or a cheap cloud account. Configure a network, set up a firewall, run a database, break it and fix it. For security, try beginner-friendly capture-the-flag challenges.

Use AI as a tutor, not a replacement. Ask it to explain concepts, quiz you, or review your design. But always make sure you understand the answer. If AI writes code you can't explain, you've learned nothing that makes you more valuable than the AI.

Practice explaining decisions. Engineering is about trade-offs. When you build a project, write down why you chose one approach over another. That habit is exactly what interviews for these roles test.

A shift, not an ending

AI is changing computer science, and for many people starting out, that change is painful. I don't want to pretend otherwise.

But I also don't think it's the end. If anything, it might be pushing the field toward what it was supposed to be all along: not just writing code, but understanding systems deeply enough to design them, secure them, and take responsibility for them.

Civil engineers don't lay every brick. Maybe, soon, computer scientists won't write every line. And maybe that's not a loss, but a chance to become the engineers our degrees were meant to make us.

I'd love to hear from both sides here. If you're a student, does this shift worry you or excite you? And if you're an experienced engineer, do you think routine coding was ever the real heart of the job?

The Price War Has Started: Open Models, Paid Models, and the Future of AI

James Anderson — Mon, 26 Oct 2026 04:16:54 +0000

Two years ago, the choice between an open AI model and a paid one wasn't really a choice. The paid models were simply far better.

That's no longer true, according to someone with a front-row seat. On IBM's latest earnings call, CEO Arvind Krishna told investors that open-weight models have become good and cheap enough to make serious sense for businesses running AI on their own hardware.

His numbers tell the story. In 2024, on a broad benchmark, a top closed model might have scored around 70 while the best open model scored 20 or 30. By late 2025, the gap had narrowed to roughly 70 versus 50. Today, he says, open models are about 90% as effective as frontier models, at somewhere between a tenth and a quarter of the token cost.

His framing for businesses was simple: would you pay ten times more for the last 10% of quality?

The paid models are already responding

If open models were creeping up quietly, the paid AI companies would have no reason to react. They are reacting.

At the end of July, OpenAI cut the price of its GPT-5.6 Luna model by 80% and Terra by 20%. In August, it cut its frontier GPT-5.6 Sol model by more than 20% for three months, amid growing competition from Anthropic and Chinese AI labs. Then came GPT-6 Sol and Luna, priced at half or less of what the previous versions cost, a cut OpenAI says is permanent.

Anthropic took a slightly different route. In July, it released Claude Opus 5, keeping the same price as its predecessor but claiming performance close to its most expensive model at half that model's price. Two months later, Opus 5.5 arrived with a further 20% price cut.

Forbes described OpenAI's cuts as a sign that competition from open-weight models is forcing proprietary providers to lower prices. Whatever the exact cause, the direction is clear. Prices are falling on both sides, and fast.

Why "good enough" matters so much

The key to Krishna's argument isn't that open models are the best. They aren't. It's that most work doesn't need the best.

He pointed to everyday tasks like summarizing an email, reviewing a contract, answering a customer call, or drafting a message. Some tasks genuinely need the top models, he said, but the vast majority can be handled just as well by the cheaper option.

This connects to a bigger pressure. Apollo's chief economist recently showed that AI hasn't yet paid off for most companies outside the tech sector, and that many are starting to treat token spending as a cost that hurts margins. Forrester has predicted that companies will lean more on cheaper open models, saving expensive ones for critical work.

When businesses are under pressure to justify every dollar, "90% as good for 10% of the price" is a very hard offer to ignore.

The case for open models taking over

Supporters of open models have several strong arguments.

The price gap is huge. Even after all the cuts, paid frontier models still cost several times more per token than running a capable open model at scale. For companies processing millions of requests, that difference adds up quickly.

Control and privacy. Running a model on your own hardware means your data never leaves your building. For banks, hospitals, governments, and anyone handling sensitive information, that can matter more than a few points on a benchmark.

No surprise price changes. Paid model pricing is now a moving target. Some of OpenAI's cuts are permanent, while others are promotions with an end date. A company running its own open model knows exactly what its costs will be next year.

History has examples. In servers, Linux eventually won much of the market from paid operating systems, not because it was always better, but because it became good enough, free to adopt, and impossible to lock anyone into.

The case for paid models staying ahead

The other side has strong arguments too.

The frontier keeps moving. "90% as good" is measured against today's best model. Paid labs release new models every few months, so the target open models are chasing keeps moving. Being 90% as good as last season's leader may not be enough for the hardest tasks.

The gap is closing from both directions. Open models are getting better, but paid models are getting cheaper. If paid models keep cutting prices, the cost advantage of open models shrinks, and the convenience of paid models becomes more attractive.

Free to download isn't free to run. Krishna himself admitted the catch. Many companies will struggle to run these models, he said, because they lack the specialist engineers needed for GPUs, networking, and performance tuning. Hardware, electricity, and skilled people all cost money. For many businesses, a paid API with no infrastructure to manage may still be cheaper overall.

Convenience usually wins. Cloud computing grew even though running your own servers was often cheaper on paper. Many companies were willing to pay more to avoid the hassle.

Everyone has something to sell

It's worth noticing who is making each argument. IBM sells exactly the kind of on-premise infrastructure that open models need, and Krishna expects on-prem AI demand to boost sales of IBM's own hardware. OpenAI and Anthropic sell access to paid models through their APIs. Every voice in this debate has a business interest in the outcome.

That doesn't make anyone wrong. But it's a good reason to look at the numbers rather than the pitch.

Where this could go

There are several possible futures here.

Open models could become the default for everyday work, the way Linux did for servers, leaving paid models as premium tools for the hardest problems. Paid models could keep cutting prices until the savings from open models no longer justify the effort of running them. Or companies could end up mixing both, sending simple tasks to cheap open models and harder ones to paid frontier models.

Right now, nobody knows which one will win. What is clear is that the price war has started, and the companies paying the bills are the ones who will decide how it ends.

So I'll ask you: if you're building with AI today, are you using open models, paid models, or both, and what made you choose?

Sources

The Register, IBM CEO says open weight models are now irresistibly good and cheap on-prem, October 22, 2026
Technology.org, OpenAI Cuts GPT-5.6 Sol Developer Pricing by More Than 20%, August 2026
Yahoo Finance, OpenAI cuts GPT-6 Sol and Luna API prices by 50%, 2026
Let's Data Science, Anthropic Releases Claude Opus 5 at Lower Cost, July 2026
BetaNews, Anthropic launches Claude Opus 5.5, September 2026
Forbes, Why OpenAI's 80% Price Cut Could Trigger A Race To The Bottom In AI, July 31, 2026
Apollo, No Signs of AI Payoff Outside the Tech Sector, October 24, 2026
Computerworld, AI devours a fifth of companies' IT budgets, October 2026

Booming in Tech, Flat Everywhere Else: The Uneven Payoff of AI

James Anderson — Sun, 25 Oct 2026 05:53:12 +0000

If you work in tech, AI feels like it's everywhere. It writes code, reviews pull requests, generates images, edits video, and answers support tickets. Every week there's a new model, a new tool, a new demo that makes last month's look old.

So it’s a little jarring to read what Torsten Slok, the chief economist at Apollo, published this week: outside the tech sector, AI has delivered essentially no financial payoff to corporate America.

Not a small payoff. Not a slower one. According to his charts, basically nothing yet.

Two economies, one technology

Slok splits the S&P 500 into two groups. On one side are the "Magnificent 7", the giant tech companies at the center of the AI boom. On the other side are the remaining 493 companies: banks, retailers, manufacturers, insurers, healthcare firms, the ordinary businesses that make up most of the economy.

For the big tech companies, revenue per worker is rising and profit margins are going up. For the other 493, both lines are flat. And across the wider economy, there's still no visible sign of AI lifting productivity growth.

This isn't the only data pointing in that direction. Forrester recently projected that AI will make up a fifth of corporate technology spending in 2027, while more than half of IT leaders are expected to miss their return-on-investment targets. In their survey, only about one in five AI decision-makers said AI had improved their company's operating profit over the past year.

So the money is flowing. The results, outside tech, aren't.

And according to Slok, companies are starting to notice. Instead of seeing AI spending as a path to growth, many are beginning to treat it as a cost that eats into margins.

Why AI shines in some places and stalls in others

The split makes more sense when you look at where AI works well.

Coding, images, and video have something in common. The work is digital from start to finish, and the output is easy to check. Code either passes the tests or it doesn't. An image either looks right or it doesn't. You can generate ten versions, throw away nine, and keep the one that works. Mistakes are cheap and fast to catch.

Most business work isn't like that.

Deciding whether to approve a loan, how to price a contract, which supplier to trust, or how to handle an upset customer depends on context, relationships, history, and judgment. There's often no test suite. You may not know if a decision was good until months later. And when it goes wrong, someone has to take responsibility.

Slok makes a similar point: AI may be a great calculator, but in business, intelligence is mostly judgment. And things like trust, culture, accountability, and fairness are what ultimately drive revenue, yet they're exactly what AI doesn't understand.

In other words, AI has mastered the work that's easy to check. Business mostly runs on the work that isn't.

So is this a bubble?

This is where opinions split hard. Both sides have real arguments, so here they are as fairly as I can put them.

The case for a collapse

The spending is enormous, and it's concentrated in a small number of companies. Much of the AI economy is circular: AI startups spend investor money on tokens from AI labs, which spend on chips and cloud capacity from big tech, which reports the growth. If the companies at the end of that chain, the ordinary businesses, aren't seeing returns, the whole structure rests on expectations rather than results.

There's also a pattern here. Companies under pressure to show returns quickly may cut AI budgets once the novelty wears off. Forrester found that nearly half of AI decision-makers expect an investment to pay off within a year. If that doesn't happen, patience could run out fast.

And history has examples of exactly this. The dot-com boom saw massive investment in a genuinely transformative technology, and it still ended in a crash that wiped out most of those companies.

The case for a slow payoff

The other side points to history too, but a different part of it.

In 1987, the economist Robert Solow famously observed that computers were showing up everywhere except in the productivity statistics. It took more than a decade before they clearly did. The reason wasn't that computers were useless. It was that companies first had to rebuild how they worked around them. New processes, new roles, new ways of organizing information.

Forrester's analysis points to the same issue today: many companies bought AI tools without changing their workflows, so the gains stay trapped in isolated pockets.

And even the dot-com crash didn't kill the internet. The bubble burst, but the technology went on to reshape almost every industry, just later and through different companies than investors expected.

On top of that, AI models keep getting cheaper. Slok himself raises the question of whether ordinary businesses can turn increasingly cheap intelligence into real growth. If costs keep falling, the math could change for companies that can't justify the spending today.

What the data can't tell us yet

It's worth being honest about the limits here. Slok's note is a short piece with a handful of charts, not a full study, and Apollo is an investment firm with its own view of the market. Productivity is notoriously hard to measure, and early gains can hide in places that don't show up in revenue per worker or profit margins.

At the same time, "it's just early" is an argument that can be stretched forever. At some point, a technology this expensive needs to show results outside the companies selling it.

What the data does show clearly is the gap. AI is booming in tech, and it's flat almost everywhere else.

The question that matters

Slok ends his note with a line that I think frames this better than any hype or doom headline: the AI story will be decided in the 493 ordinary companies, not the 7 giants.

Whether that story ends in a crash, a slow transformation, or something in between depends on whether businesses outside tech can find a way to turn AI into real value, not just more spending.

I don't think anyone knows the answer yet. So I'll put it to you: when you look at your own company, or the businesses around you, are you seeing real returns from AI, or mostly real costs?

Hours, Not Weeks: How AI Rewrote the Clock of Software Security

James Anderson — Sat, 24 Oct 2026 05:41:38 +0000

The third week of October 2026 was a rough one for anyone who runs software on the internet.

Two critical bugs in PHP, nicknamed PHP2Shell, were found by security teams using frontier AI models. Estimates said they touched a huge share of the web. Governments told organisations to patch immediately, and plenty of people simply pulled their servers offline. In the same few days, LiteLLM had a malicious release pushed to PyPI (for the second time this year), Railway disclosed that attackers had gotten into customer environment variables, GitLab shipped fixes for maximum-severity bugs, and a handful of Linux kernel vulnerabilities got posted to the wrong mailing list.

Drew Silcock wrote a great roundup of all of it in Is this the new cyber normal?, and it's worth reading in full.

But after going through it, the thing that stuck with me wasn't any particular bug. It was a simpler thought: who is actually supposed to deal with all this when your entire company is four people?

The clock got shorter

Security used to have a rhythm. A vulnerability got announced, a patch came out, and you had some time. Maybe days, sometimes weeks, before anyone figured out how to actually exploit it. "We'll patch it this week" was a reasonable plan.

That rhythm is gone. Today, the moment a security patch is published, people point AI agents at the code. The agent reads through the changes, spots what looks like a security fix, works backwards to the hole it closes, and helps build an exploit. What used to take a skilled researcher weeks can now happen in hours.

With PHP2Shell, attacks were reportedly happening before the official patch was even available. "This week" isn't a plan anymore. "Today" barely is.

Attacking got cheap

Here's the part that changes everything. Finding a serious bug and turning it into a working attack used to require rare skills and a lot of time. That made it expensive, and expensive things happen less often.

Now an attacker can throw an AI model at a codebase and see what comes out. A lot of it is junk. AI produces plenty of "exploits" that don't actually work. But attackers don't need everything to work. They need one thing to work. When trying costs almost nothing, you can afford to try a thousand times.

Defending didn't get cheap

On the other side, almost nothing got cheaper.

When a critical bug drops, somebody still has to read the advisory, figure out whether you're affected, check which of your services use the vulnerable thing, test the patch, deploy it, and then dig through logs to see if anyone got in before you fixed it. If you use AI to scan your own code first, great, but that costs money too, and every bug it finds is a bug someone now has to fix.

AI made finding problems cheaper for everyone. It didn't make fixing them cheaper for anyone. And the attacker only has to find. You have to fix.

This is where size starts to matter

A big company handles a week like that with a security team, an on-call rotation, incident playbooks, and people whose literal job is to drop everything and respond. It's painful for them too, but they're built for it.

A small team isn't. In a four-person startup, the person who handles security is usually also the person who handles deployments, the database, customer support tickets, and the feature that was supposed to ship Friday. There's no rotation. There's just whoever happens to be awake.

And when the advice is "take your servers offline until you patch," the cost hits differently. A large company can survive a day of downtime. A small product with a few hundred paying customers might lose some of them for good.

You inherit everyone else's problems

Small teams don't build everything themselves. They can't. They stand on a stack of frameworks, packages, hosting platforms, and AI tools, all written by someone else.

That's normally a strength. It's how a tiny team ships something real. But it also means that when one of those pieces gets compromised, the problem becomes yours instantly. You didn't write the LiteLLM backdoor, but if you installed that release, your credentials might be gone. You didn't misconfigure Railway, but if your secrets lived there, you now have to rotate every one of them.

For a big company, that's a ticket for the security team. For a small team, it's an entire day of product work gone, spent cleaning up a mess you didn't make.

The tools we adopted to move faster

There's an irony here. Small teams have been some of the fastest to adopt AI tools, because AI promises exactly what they need: more output from fewer people.

But every one of those tools comes with something attached. Another API key. Another dependency. Another service with access to your code or your data. One of the incidents that week, a data leak at a database company, reportedly exposed API keys for several AI providers that had been pasted into internal tickets. Keys spread quietly, and every one of them is something an attacker would love to find.

The tools that help small teams keep up are also handing attackers more things to go after.

Falling behind isn't the same as not caring

I don't think small teams are ignoring security. Most developers I know care about it a lot. The problem is that the math changed underneath them.

Defending at the new speed assumes things a small team doesn't have: people on call around the clock, budget for scanning tools, time to audit every dependency, room to absorb downtime. When attacks got faster and cheaper but defense stayed slow and expensive, the gap didn't hit everyone equally. It landed hardest on the people with the fewest resources.

I don't have a neat answer

Maybe this is a temporary spike. Maybe AI is just clearing out years of old bugs all at once, and things will calm down once the backlog is gone. Or maybe this is simply what security looks like now.

Either way, it feels like we're in a period where the cost of defending software is rising quickly, and small teams are the ones feeling it first.

If you're on a small team, I'd genuinely like to know how that week went for you. Did you patch in time, pull things offline, or only find out afterwards?

AI Is Winning Literary Awards. The Data Says That's Not What's Happening.

James Anderson — Fri, 23 Oct 2026 05:29:29 +0000

The headlines have been impossible to miss. An AI-assisted novel takes a major prize in Japan. AI poetry gets recognized by a literary award. Someone's AI-generated story places in a competition. And if you write — or care about writing — the obvious reading is the frightening one: the machines finally got good enough to beat us at the one thing that was supposed to be ours.

I believed a soft version of that too, until I actually went looking. There's a running catalog of these cases now — the writer James Yu has been tracking literary awards given to work written with, or suspected of using, AI — and there's a large 2026 study that did something more interesting than count headlines: it measured the prose.

And when you put the catalog and the data side by side, the story doesn't just soften. It inverts. "AI is winning literary awards" turns out to be almost entirely a story about permissive rules, human cheating, detection, and sheer market-flooding — and underneath it is a measurement that shows close to the opposite of what the panic assumes. Let me walk you through it, because the real picture is far more reassuring, and far more interesting, than the headline.

Most of the "wins" aren't what the headline implies

Start with the catalog itself, because the first thing you notice is that "AI won a literary award" is doing a lot of different jobs in a single sentence.

Sort the cases by what actually happened and they stop looking like evidence that AI is out-writing humans:

A big share are categories that allowed or required AI from the start. When an electronic-literature award recognizes a work openly built with neural networks, that isn't AI sneaking past human judges — it's AI winning the AI category. The award exists to recognize that kind of work. Listing it as "AI beat the humans" is like listing a documentary winning Best Documentary as proof that reality beat fiction.
Several were caught and withdrawn. One of the most-cited cases — a Singapore poetry competition in 2024 — announced its winners and then recalled the entire list when three of them turned out to be AI-generated. That is not the system failing. That is the system working.
Others are suspected or disputed, never confirmed, sitting in a haze of "we think, but the author says otherwise."

Once you strip those out, the number of cases where AI quietly won a blind, human-judged, AI-prohibited literary prize on pure merit is dramatically smaller than the headline wave suggests. And here's the part that reframes the whole trend: the rise in "AI award" stories tracks two things that have nothing to do with AI getting better — more people trying to smuggle AI in, and more scrutiny catching them. More attempts plus more detection produces more newsworthy incidents. That curve can climb steeply while AI's actual quality stays exactly where it is.

The real harm is volume, not quality — and the researchers say so

But maybe you're thinking: fine, the awards are noisy, but AI is taking over the market. And here the big study is worth reading carefully, because it says something more specific than the panic does.

The 2026 paper — Chakrabarty and colleagues, analyzing more than 14,000 self-published books on Amazon — found that AI-heavy titles exploded (the catalog grew dozens of times over in three years) and are genuinely capturing a rising share of top sales ranks. Human authors' revenue is falling across almost every genre, even for books with no detected AI in them at all. The harm to writers is real and measurable.

But the mechanism is the whole story. The researchers are blunt about it: generative AI reshaped the book market, in their words, without competing on quality at all. It displaced human authors through sheer volume — by flooding the shelves, not by writing better books. The damage comes from drowning, not from winning.

That is a crucial distinction almost nobody makes. "AI is beating human authors" and "AI is burying human authors under ten times the volume" feel the same if you're the author losing income. But they are completely different claims about what AI can actually do — and only one of them is true. The machines didn't out-write anyone. They out-printed them.

Now the measurement that flips the whole thing

Here's where it gets genuinely fascinating, because the same study didn't just count books — it looked at the language inside them.

The researchers measured something they call rare-expression coverage: how much of a book is built out of distinctive, multi-word phrases (five words or longer) that already exist in other published books but are absent from the general web. In plain terms: how much of the writing is made of the kind of memorable, literary-sounding phrasings that have already appeared, somewhere, in the body of existing literature.

The numbers are striking, and they go the opposite direction from what you'd guess:

Books with substantial AI content: around 42% coverage — and among the top-selling AI books, as high as 45%.
Human-written bestsellers (no detected AI): around 37%.
Award-winning literary fiction: just 19%. Roughly half the rate of the AI books.

Sit with that, because it's counterintuitive on first read. The AI-heavy writing is more densely packed with distinctive, already-existing literary phrasings. The award-winning human writing uses them the least.

What does that actually mean? It means the prose we hand prizes to is distinguished by not reaching for the stock of memorable expressions that already exist — it makes its own language instead. And AI-heavy prose does the reverse: it reaches, more than humans do, for the distinctive phrase that already proved itself somewhere else. The machine gravitates toward what already read as good. The artist flees it.

(An honest caveat the researchers themselves flag: the award-winning group isn't perfectly matched to self-published genre fiction as a market, so it's an illustrative comparison, not a controlled one. But the gap is enormous and the statistical significance is overwhelming — we're talking odds against chance with seventy zeros in them. This isn't noise.)

Why this is exactly what you'd predict

If you've thought about how these models actually work, this measurement shouldn't surprise you at all. It's the empirical shadow of something that's true by construction.

A language model generates toward the center of mass of everything it has read. "Write something literary" resolves, inside the model, into "produce text that resembles the literature in my training data" — so of course it reaches for the distinctive phrasings that already exist in that literature. That's not a flaw in the output; it's the definition of the output. The model is a magnificent averaging machine, and averaging means gravitating toward the phrasings that already earned their place.

And great writing is measurably the opposite of averaging. The whole act of literary originality is not writing the expected, already-proven phrase — finding the words for a thing that the existing stock of words hasn't quite captured yet. That's what the 19% is. It's the quantified fingerprint of writers refusing the average, where the 42% is the fingerprint of a system built to produce it.

I've argued before that taste and creativity are, at bottom, the art of resisting the average — of knowing which of two options is more alive, and reaching past the obvious one. I made that case as philosophy. This study is the same claim with a number stapled to it. The data isn't evidence AI reached human creativity. It's the clearest quantified picture yet of the gap between them.

What I'm not saying

Let me be careful, because a data piece that overclaims is just a vibe with footnotes.

This measures one signature of prose — reliance on borrowed distinctive phrasing — not "quality" or "soul" in some total sense. It's a strong proxy, not the whole of literary value, and you could write something original by this metric that's still bad, or something derivative that's still moving. Don't mistake the fingerprint for the whole hand.

It also describes typical AI-heavy output today, not a ceiling. A skilled writer steering a model hard, editing ruthlessly, using it as one instrument among many — the "centaur" collaborations that are genuinely coming — can push against this tendency. The 42% is what the firehose produces on average, not what's possible at the edges. And some AI-collaborative work is genuinely interesting and deserves its recognition on its own terms, in the categories built to judge it.

So this isn't "AI can't write" and it isn't "human writing is safe forever." It's narrower and, I think, more honest: right now, the measurable signature of AI-heavy prose is a pull toward language that already exists, and the measurable signature of prize-winning human writing is a pull away from it. Today's picture, not a law of nature.

The takeaway

"AI is winning literary awards" is a headline doing a remarkable amount of dishonest work.

Pull it apart and what's underneath is: categories that were built to reward AI, cheaters getting caught, a market being flooded rather than bested, and — when you finally measure the actual words — a system that leans harder than humans do on the memorable phrases other people already invented, losing to the writers whose whole gift is inventing their own.

The machines didn't out-write us. They out-numbered us, and reached for everybody else's best lines on the way. That's not the end of human writing. It might be the clearest evidence we've ever had of what human writing actually is — the refusal to say the thing the way it's already been said.

The number I can't stop thinking about: award-winning fiction reuses existing "memorable" phrasings at roughly half the rate of AI-heavy books. Which suggests great writing is, measurably, the art of not reaching for the phrase that already worked. So I'll put the real question to you: is "avoiding the average" a good definition of originality — or is it too reductive to capture what actually makes writing matter? I genuinely want the pushback.

Sources: the catalog of AI-related literary award cases is James Yu's "Award-Winning AI Literature." The measurements come from Chakrabarty, Liu, Ginsburg & Dhillon, "Generative AI floods and dilutes the market for books" (arXiv:2607.20349, 2026) — a study of 14,000+ self-published Amazon titles; the rare-expression figures (≈42–45% for substantial-AI books, ≈37% for no-AI bestsellers, 19.1% for award-winning fiction) and the "without competing on quality at all" market-dilution finding are from that paper. Numbers are current as of writing and reflect one study's methodology; the award-comparison group is illustrative rather than market-matched, as the authors note. Treat the rare-expression metric as one strong proxy for textual originality, not a complete measure of literary quality.

Somewhere, Coding Stopped Being Allowed to Be Fun

James Anderson — Tue, 20 Oct 2026 05:35:46 +0000

Somewhere in the last couple of years, a strange feeling crept in, and I don't think I'm the only one who's felt it.

It's the sense that I'm not really supposed to enjoy this anymore. That admitting, out loud, in 2026, that I love programming — that I'll happily lose a Saturday to a problem a machine could solve in four seconds — is a little naive. Like I missed the memo. Like there's a version of me who's moved on, who only touches code when it's billable and optimal and defensible, and who looks at the part of me that still finds this fun with a kind of pity.

I couldn't quite name that pressure until I read a short post this week by Chris Kiehl, called "It's Still OK to Enjoy Programming." It's worth your five minutes. He says a simple thing that landed harder than it had any right to: it's OK to enjoy things, and doing so requires no economic justification.

That sentence unlocked something I'd been circling for a while, so I want to build on it — because I think the pressure he's describing is real, I think I understand where it came from, and I think it's quietly taken something from a lot of us that's worth taking back.

The doom stream doesn't argue with you. It soaks you.

Here's the thing about the "programming is over" narrative: it rarely wins by convincing you. It wins by repetition.

Open any developer feed right now and you'll find a steady drip of it. AI is going to replace you. The craft is dead. Why would anyone learn this now. The junior path is gone. It's all just prompting. Every scroll, another small dose. And none of it argues with you directly — it doesn't have to. It just soaks into you, a little at a time, until one day you sit down to build something for the pure pleasure of it and a quiet voice you didn't install asks: what's the point? A machine could do this faster. Why bother?

Kiehl put his finger on exactly this — that the more of the doom stream you consume, the more it infects you, and that it disappears the moment you disconnect. I think that's precisely right, and it rhymes with something I keep noticing about this era more broadly: we keep letting an ambient feed rewrite how we feel about things we used to love, not through any single convincing argument, but through sheer saturation. You don't decide the joy is gone. It just gets slowly crowded out by a mood you absorbed from a thousand posts you barely remember reading.

And underneath that mood is a premise so quiet you might never notice you swallowed it. It's worth dragging into the light, because once you see it, it loses most of its power.

The lie hiding inside the despair

The doom stream smuggles in one assumption, and it's this: that the value of doing something is its economic value.

That if a thing can be done more cheaply by a machine, then doing it yourself is pointless. That your joy in the doing is a kind of inefficiency — a sentimental attachment to a task that's been rightfully automated. That worth and worth money are the same thing.

Say it plainly and it's obviously false. But we almost never say it plainly, which is exactly why it works on us.

Because think about how absurd it is applied anywhere else. Nobody tells you your evening run is pointless because a car is faster. Nobody says you shouldn't cook dinner because restaurants exist and are better at it. Nobody looks at someone playing guitar badly in their bedroom and says, "You know Spotify has professionals, right? What's the economic case for this?" We'd find that insane. We understand, instinctively, that people do things because the doing is the point — that the value was never in the output, it was in the experience of making it, the small private satisfaction of having done a thing with your own hands and mind.

We understand that about everything except, apparently, the thing we spend most of our lives doing. Somewhere along the way we let the market convince us that this particular love — unlike running, cooking, music, gardening, painting, every other human thing — has to earn its keep. Has to be defensible. Has to show up on an invoice or it doesn't count.

It doesn't. It never did.

The best thing I built this year was worthless

I'll be concrete, because this isn't abstract for me.

The things I've built recently that I'm proudest of — that I think about, that made me feel most like myself — are almost all completely worthless by any economic measure. A tiny tool nobody but me will ever use. A problem I solved the slow, hard way on purpose, long after I knew the shortcut, just to feel it click. Things I could have prompted into existence in a fraction of the time, that I chose to struggle through by hand because the struggling was the entire reward.

Kiehl mentioned building a buggy Breakout clone with terrible collision detection, by hand, because he enjoys it — and noting that it doesn't bother him that an AI could one-shot it, "because that's not the point." I felt that in my chest. The point was never the Breakout clone. A perfect, instantly-generated Breakout clone would have given him nothing, because the thing he was actually after wasn't a game — it was the hours of being absorbed in a problem, the small victories, the specific texture of figuring something out yourself. The output was disposable. The experience was the whole thing.

That's the part the economic lens can't see, and never could. It measures the artifact and misses the aliveness. It looks at the bad Breakout clone and sees a worse version of something a machine makes better. It cannot see the person who was happy while making it, because happiness doesn't have a line item.

The quiet rebellion

So here's where I've landed, and it feels almost defiant to say it, which tells you how strange things have gotten.

The most radical thing you can do as a developer right now is not to resist AI, or out-hustle it, or have the correct take about it. It's to still find this beautiful. To sit down on a weekend and struggle, on purpose, with a problem a machine could solve in seconds — and to enjoy the struggle, precisely because no one asked you to and nothing depends on it. To build something gloriously useless. To learn a thing that will never once come up at work, just because understanding it is its own reward.

This isn't anti-AI. I use the tools; they're genuinely wonderful, and some of the fun I have now is because of them. It's not nostalgia, and it's not pretending the economics of our jobs haven't shifted — at work, where you're paid to produce value, they obviously have, and that's fine. That's work. Work was never the whole of it.

It's just a refusal to let the market price the one thing it was never entitled to: your wonder. Your right to do a hard thing badly, by hand, for no reason at all, and to love every minute of it.

It's still OK to love this

So if you've been feeling that quiet pressure — that you're somehow behind, or naive, or sentimental for still enjoying this — I want to say the thing Kiehl said to me, and pass it on:

It's still OK to love this. Not because it's useful. Not because it'll pay off. Not because you can justify it to anyone, including yourself. It's OK to love it for the same reason anyone loves anything — because the doing lights something up in you, and that was always, by itself, enough.

The doom stream disappears the second you close the tab and open the editor for no reason at all. Build the useless thing. Struggle with the solved problem. Lose the Saturday. None of it has to be worth money.

It just has to be worth doing — and only you get to decide that.

With real thanks to Chris Kiehl, whose post "It's Still OK to Enjoy Programming" is the reason this one exists — go read his, it's shorter and kinder than mine.

And a question I'd genuinely love answered in the comments: what's the most economically worthless thing you've built or learned recently, purely because you wanted to? I'll start — I spent a weekend reimplementing something that already exists, works better, and ships with my OS, entirely by hand, for no reason at all. Best time I've had in months.

Writing C for the Web in 2026 Isn't Insane. It Might Be the Future

James Anderson — Mon, 19 Oct 2026 06:08:31 +0000

Someone shipped a modern, commercial web product — user accounts, Stripe payments, a search dashboard, transactional emails — written entirely in C, served over CGI, the technology we all quietly agreed died somewhere around 2004.

Your first instinct is probably to laugh. Or to call it a stunt, a party trick, the kind of thing a certain type of developer does to prove a point on Hacker News. That was my instinct too.

Then I read why he did it, and the laugh died in my throat.

Because every single reason turned out to be a sober, direct answer to a problem I've watched get worse every year I've been doing this. Not nostalgia. Not contrarianism. A clear-eyed response to forces that are reshaping our entire industry right now — supply-chain attacks, AI-generated complexity, and the quietly rising value of software you can actually understand and trust.

The piece that sent me down this hole is Corey Prophitt's "A Modern Web App in C," about his product marketyour.games. I'd encourage you to read his original — this isn't a summary of it. What I want to do is zoom out from his specific build to the thing it's a signal of, because I think the most "insane" stack of 2026 might be pointed directly at the future, and I want to walk through why.

First, no, it's not a toy

Let's kill the easy dismissal upfront, because it's the reason most people stop reading.

This is not a hello-world. It's a real, shipping, commercial product. From the outside it's indistinguishable from anything built on a modern stack: accounts, a dashboard, folders, Stripe, Postmark. From the inside it's C, CGI, SQLite, and OpenBSD — a single statically-linked binary dropped into a folder, three libraries total, deployed by replacing the binary. A clean build takes seconds.

So we're not talking about whether you can do a weekend experiment this way. Someone is taking payments through it. The question isn't feasibility. The question is whether the rest of us have been wrong about something.

Your first objection is probably out of date

The reflexive response is "but CGI is slow — you fork a whole process on every request." And you'd have been completely right to say that. In 2004.

The thing is, that objection quietly expired and nobody re-ran the test. Modern kernels optimize process creation heavily; forking is nowhere near the cost it was when we all fled CGI. And if it ever did become a bottleneck, FastCGI is a small step away. The performance reason we abandoned this entire approach was real then and mostly isn't now — we just never went back to check, because our industry only ever moves in one direction: toward more.

That's the first crack in the certainty. A lot of what we treat as settled fact is really just un-re-examined reflex. "Everyone knows CGI is dead" is doing a lot of load-bearing work for something nobody's actually measured since flip phones were cool.

But performance was never the interesting part. The interesting part is why someone would choose this on purpose today — and those reasons didn't even exist the last time we had this debate.

Why it's not nostalgia: the reasons are brand new

Here's what changed my mind. The case for radical simplicity isn't "the old days were better." It's that three forces, all of them new, all of them intensifying, have quietly made the minimal stack the rational one. And they happen to be the exact forces reshaping everything else about how we build.

Every dependency became a liability

Start with the one I think about most, because I've written about its ugly edges before.

A modern web app's dependency graph is enormous. You add two or three direct dependencies and a package manager cheerfully pulls in hundreds of transitive ones — each maintained by someone you've never heard of, many unmaintained, some with publish credentials protected by a password that's been reused since 2015. That graph is not a convenience. It's your attack surface.

And that attack surface is on fire right now. Package repositories get hit weekly. Attackers register typo-and-hallucination-shaped package names and wait. Autonomous coding agents install dependencies on your behalf, at machine speed, often without a human ever reading what got pulled in. In that environment, every dependency you add is a small act of trust extended to a stranger, multiplied by hundreds, re-rolled every time you update.

Now look at the minimal stack. Its entire supply chain is a C compiler and three libraries — things like libcurl, which the entire internet watches. As Prophitt puts it, compromising it would mean compromising a project under constant global scrutiny, not "a package with eleven weekly downloads and an owner who left in 2019."

"The most secure dependency is the one you never added" used to be a cute aphorism. In 2026 it's a defensive posture. Minimalism stopped being an aesthetic and became a security strategy, and almost nobody has updated their instincts to match.

AI made complexity cheap — which made understanding rare

Here's the second force, and it's the one I find genuinely beautiful.

For the entire history of software, producing code was the expensive, scarce, valuable thing. So we optimized relentlessly for production: frameworks, generators, abstractions, anything that let us make more software faster. Complexity was an acceptable price for output, because output was hard.

AI inverted that overnight. Producing code — even producing abstraction — is now nearly free. You can generate a thousand lines, or a whole framework's worth of scaffolding, in seconds.

And when production becomes free, the bottleneck moves. It moves to understanding and trusting what you now have. The scarce resource isn't the code anymore; it's a human being who can actually hold the system in their head, reason about it, and be confident it does what they think it does. In a world drowning in generated code, a system small enough to comprehend is worth more than it has been in twenty years — because comprehensibility is exactly the thing the flood destroys.

This is why "the whole app fits in your head" stopped being a humblebrag and became a real advantage. A system you can open file by file and fully understand is a system you can verify. And verification, not production, is the hard part now. The minimal stack isn't behind the AI curve. It's weirdly, accidentally, perfectly adapted to it.

The complexity tax finally came due

The third force is just arithmetic catching up with us.

We spent fifteen years adding layers to solve the problems created by the previous layers. The modern default is genuinely strange when you say it plainly: you run a web server (nginx) in front of a second web server (your app server in Ruby, Python, Go), which also happens to hold your business logic. Then you add a container to run it, an orchestrator to run the containers, a build pipeline to produce the containers, and a language server just to help you navigate the abstraction you've accumulated. Each layer solves a real problem — usually a problem the previous layer introduced.

At some point the cure becomes the disease. The minimal stack isn't missing all of that machinery. It never needed it, because it never created the problems the machinery exists to solve. One web server that calls your logic directly. One file to deploy. One language for your editor to understand. The complexity didn't get managed better — it got refused.

What you actually get

Enough philosophy — here's the concrete payoff for a developer weighing whether any of this is more than a thought experiment.

It fits in your head. You can reason about the whole thing, debug it with confidence, and trust it, because there's no layer you haven't seen. Open a file, read it, know what it does. That sounds small until you remember the last time you could say it about anything you shipped.

Less operational tax. No database server to babysit and upgrade. No dependency churn. No upgrade treadmill where half your week goes to keeping the scaffolding standing. Deploying is replacing one binary. The time you don't spend maintaining complexity is time you spend building.

Durable knowledge. HTTP, SQL, processes, the fundamentals — learn them once and they're good for your whole career. Compare that to the framework-of-the-year churn, where the thing you mastered last cycle is a migration guide this cycle. On the minimal stack, what you learn compounds instead of evaporating.

Trivial debugging. Your application is just a program. Pipe it a request, watch what it writes, step through it with a debugger. There's no distributed-systems detective work to figure out which of your seven services ate the request.

The honest counter (because this isn't a cult)

I'd be doing the exact thing I dislike if I only sold you the upside, so here's the fair case against.

You do rebuild things frameworks hand you for free — routing, request parsing, validation, output escaping. That's real upfront work, and real surface area for your own bugs instead of someone else's. It genuinely doesn't fit every problem: large teams moving fast on a shared codebase, deeply interactive rich frontends, extreme scale, or rapid prototyping where ecosystem velocity is the whole point — those are cases where the "bloated" modern stack is earning its keep, not just accumulating.

And C specifically carries a real cost I don't want to wave away: memory safety. A buffer overflow is a worse failure mode than a slow framework. Which is exactly why I'd argue the language is the least important part of this. The thing worth taking seriously is the broader move — radical simplicity, minimal dependencies, a system you can hold whole — and you can reach for most of it in a single-binary Go service, or in Rust, without writing a line of C. The point was never "write C." The point is "stop reaching for maximum complexity by default."

So the honest claim is narrow and, I think, hard to argue with: the pendulum swung much too far toward complexity, most of the old reasons for that swing have quietly expired, and genuinely new forces have made the minimal path far more worth considering than our reflexes allow. Not mandatory. Just no longer insane.

The actual horizon

Here's why I don't think this is going backward, even though it looks like it.

Going backward would be doing the old thing for old reasons — forking processes in 2026 because that's how we did it in 1994, out of habit or sentiment. That's not what's happening. What's happening is a new synthesis: proven, boring, decades-hardened foundations, picked up by people with modern knowledge, for reasons that did not exist when we abandoned them. Supply-chain attacks at this scale are new. AI making production free is new. The premium on verifiable, comprehensible systems is new. The old stack isn't being revived out of nostalgia — it's being rediscovered because it happens to answer questions we only started asking this year.

That's not a retreat. That's the ground moving under you, and realizing the thing you walked away from is now standing on higher ground than where you've been.

The exciting part isn't C, and it isn't CGI. It's the quiet, liberating realization that "modern" was never actually a synonym for "more" — that some of the most resilient, trustworthy, genuinely interesting software of the next few years might come from the people brave enough to subtract. To build something small enough to understand on purpose. To treat every dependency, every layer, every clever abstraction as a cost to be justified rather than a feature to be collected.

Maybe build one small thing you can hold entirely in your head, just to feel what that's like again. I suspect a lot of us have forgotten. And I suspect that feeling — not the next framework — is where the interesting part of the future actually is.

Two honest questions, and I want the real answers. What's the most "outdated" technology you quietly believe is actually better than its shiny replacement for some real use case — and have you been a little embarrassed to admit it? And the harder one: in an age of supply-chain attacks and infinite AI-generated code, is radical simplicity a genuine engineering strategy now, or am I romanticizing a stack because it's elegant? I honestly go back and forth, and I'd rather be argued with than agreed with.

The Discerning Mind: What AI May Never Reach

James Anderson — Sun, 18 Oct 2026 09:15:08 +0000

You do it dozens of times a day, and you almost never notice.

You glance at a photo and something in you says that's beautiful — before you could tell anyone why. You read a sentence and feel, in an instant, that it's slightly off, a word out of place you haven't consciously identified yet. You walk into a room and sense it's almost right, that one thing could be moved and it would come together. You look at a design, a melody, a face, a line of code, and a judgment arrives — fast, certain, and ahead of any reasoning you could give for it.

We treat this as nothing. It's just taste, just an opinion, just a feeling. But it is one of the strangest and most quietly remarkable things a human being does — this instant, pre-rational knowing of what is good, what is wrong, what could be more. And it is precisely the thing that AI, for all its astonishing fluency, does not seem to have.

I want to sit with that, honestly, because I think the usual way we argue about it is wrong. The question everyone asks is "can AI be creative — can it make art, music, writing?" And the answer, increasingly, is yes, it can produce those things, impressively. But I don't think production was ever the point. I think the human thing — the thing that might be genuinely out of reach — is something else entirely. Not the making. The discerning.

The distinction almost everyone misses

Here is the move that the whole question turns on, and most of the debate skips right over it.

We lump two very different capacities together under the word "creativity," and they are not the same thing at all:

Generation is producing output — a poem, an image, a tune, a layout. And I'll say this plainly, because pretending otherwise would make me a liar and cost me your trust: AI is extraordinary at generation now. It can write a competent poem, render a striking image, compose a passable melody, draft a clean design. If your claim is "AI can't produce aesthetically pleasing things," you have already lost the argument, because everyone has seen that it can.

Discernment is judging that output — knowing which of two versions is better, sensing what's wrong, perceiving what could be improved, having taste. And this is a completely different faculty.

Here's why the distinction matters so much: generation was never the hard part of creativity. A random number generator generates. Throw enough paint at enough walls and you'll produce something. The miracle of the creative human was never that they could make marks — it was that they could look at the marks and know. Know which one was alive and which was dead. Know what to keep and what to throw away. Know, standing in front of the thing, that it wasn't finished yet, and feel in which direction "finished" lay.

The discerning mind, not the producing hand. We got so dazzled — or so threatened — by watching machines produce that we forgot the production was never where the magic lived.

What discernment actually is

So let's look closely at this strange faculty, because the closer you look, the stranger it gets.

Discernment isn't a rule you apply. You don't compute that a face is beautiful or a phrase is clumsy. You perceive it, the way you perceive a color — directly, immediately, often before a single word of justification is available to you. The reasons come after, if they come at all, and half the time they're reconstructions, stories we tell to explain a verdict we'd already reached.

And it's deeply embodied and personal. Your sense of what's beautiful is tangled up in a lifetime of sensory experience, of things you've seen and heard and touched, of memories, of emotions, of the particular person you happen to be. Two people with identical knowledge can have completely different taste, because taste isn't knowledge. It's a point of view. It's yours.

But here is the part I keep coming back to, the part that I think matters most: discernment comes from caring. You can only find something beautiful if things are capable of mattering to you. The whole faculty is downstream of being a creature that experiences, that prefers, that is moved, that has something at stake in how the world is. You judge beauty because beauty does something to you. Take away the one who can be moved, and I'm not sure "beautiful" means anything at all — it's just a word with no one behind it to feel its weight.

Which brings us to the machine.

Why AI may lack it, structurally

An AI that generates aesthetic output is doing something genuinely impressive, but notice what it's doing. It has learned, from an ocean of human-made examples, the statistical shape of what people have called good. When it produces something beautiful, it is, in effect, finding the center of mass of human aesthetic preference and generating toward it.

And here's the problem hiding in plain sight: real taste is almost the opposite of an average.

Taste is particular. It's a point of view, which by definition is not everyone's. The most interesting aesthetic judgments in history were often the ones that cut against the consensus — the thing nobody had learned to love yet, that one person saw and insisted was beautiful before the rest of us caught up. An average can tell you what people have found beautiful. It cannot want something to be beautiful in a way no one has wanted before, because wanting requires a wanter, and an average is nobody's.

But the deeper issue isn't statistical, it's this: there is no one home. The model has processed every description of awe ever written, every account of grief and longing and wonder and beauty — and it has never once been moved by anything. It knows, with superhuman thoroughness, what beauty is described as. It has never felt it. Not once. Not for a moment.

And so when it "judges" — when it tells you which image is better, or improves your paragraph — I think something is missing that we're too quick to overlook. A judgment with no subject behind it, no one who is moved by it, nothing at stake for anyone in the judging — is that judgment, or is it an extraordinarily good imitation of the residue that judgment leaves behind? The machine has the map of human taste, in staggering detail. But a map with no one reading it, no one caring where it leads, is just ink. The discerning mind might be the reader, not the map — and that's the part I'm not sure can be manufactured.

Now let me argue against myself

If I stopped here, I'd be doing the thing I dislike — telling you a comforting story about human specialness and calling it an argument. So let me give the other side its real strength, because it has some, and if you've been thinking skeptically this whole time, you're right to.

Maybe what we call "taste" is just extremely sophisticated pattern-matching on human preference — and the feeling that it's something more, something sacred, is simply human exceptionalism. We have an embarrassing track record here. We said machines could never play chess, then never play it creatively, then never master Go's intuition, then never use language — and each time, the thing we'd called uniquely human turned out to be a pattern a machine could learn. "Aesthetic judgment is special and unreachable" might just be the next item on that list, and I might be writing the same confident sentence people wrote right before they were proven wrong.

And maybe — this is the uncomfortable one — the "experiencing subject" I keep invoking is itself not what I think it is. Maybe we are also prediction machines, evolved to pattern-match on our environment, and the thing we call "being moved" is just what our pattern-matching feels like from the inside. If that's true, there's no magic line here at all. The machine does with silicon what we do with meat, and my insistence that ours has a someone behind it and theirs doesn't is just a bias I have because I happen to be one of the meat ones.

And purely practically: maybe AI doesn't need to feel beauty in order to reliably identify what humans will find beautiful — and if it can predict your aesthetic response perfectly, then for every practical purpose that touches your life, the difference between "real taste" and "flawless simulation of taste" may be a difference that makes no difference.

These are not weak arguments. I don't have a knockdown reply to any of them. Anyone who does is selling you something.

Where I land, held loosely

So, with all of that honestly on the table — here is what I still believe, offered as a suspicion and not a proof.

I think discernment is distinctly human not because the machine isn't powerful enough, but because aesthetic judgment may be inseparable from being a subject with stakes. Taste, real taste, isn't only identifying what people like. It's caring that something is beautiful. It's being changed by it. It's the whole circuit — being moved by something, and out of that being-moved, wanting to make something that moves someone else the way you were moved. That circuit runs, at every step, through an experiencing self. And a machine can reproduce the outputs of that circuit — the beautiful image, the confident judgment — without any of the circuit actually existing.

A judgment that nothing is at stake in, that no one is moved by, that doesn't matter to anyone doing it — I keep arriving at the same place: I don't think that's quite judgment. I think it's a very good imitation of what judgment leaves behind.

So will AI ever reach the discerning mind? My honest answer is: I suspect not — but not because it can't become more capable. Because the thing we're pointing at might not be a capability at all. It might be a property of being someone. You can't scale your way to a subject. And I hold even this loosely, because the truth is nobody knows, and the history of "machines will never" should make all of us humble, in both directions.

What we're left with

Whatever AI becomes, the discerning mind is, for now, still ours — that small daily miracle of looking at something and knowing, of being moved before you can explain why, of sensing that a thing could be more and feeling, dimly, in which direction.

It's easy to feel diminished watching machines generate in seconds what used to take us years. But maybe the quiet consolation in all of this is that generation was never where our worth lived. The seeing was. The being-moved was. The this could be better was. Those might turn out to be the last things to go — or they might be the things that were never really on the table at all, because they were never about output in the first place. They were about being alive to the world.

The machine makes. We discern. And discernment, when you follow it all the way down, might just be another name for caring that things are one way rather than another — for the world mattering to someone.

That's not a small thing to be left holding. It might be the whole thing.

Honest question, because I genuinely go back and forth and I'd rather hear real thinking than applause: is taste a skill that enough data could eventually teach — or is it inseparable from being a conscious, caring subject? And here's the one that keeps me up: if a machine could perfectly predict what you'd find beautiful, while feeling nothing at all — would that be taste, or a flawless imitation of it? And is there even a difference? I don't think I know.

AI Made Your Easy Work Free. That Made You More Valuable.

James Anderson — Sat, 17 Oct 2026 05:57:07 +0000

Let's start by admitting the scary part is true, because the whole argument falls apart if I pretend otherwise.

AI can build an enormous amount of software now, fast, for almost nothing. You can vibe-code a working app over a weekend. Clone a SaaS product's whole front end in an afternoon. Generate the CRUD endpoints, the forms, the standard UI, the glue code, the "make it look like this" — all of it, in minutes of prompting, at a quality that a few years ago would've been a week of a junior's time.

That's not hype. It's real, and if you've felt the floor shift under you because of it, you're not imagining things. So the fear makes sense: if building software is nearly free now, what's left for the people whose job was building software?

Here's the thing that question quietly assumes, though — and it's wrong. It assumes the building was where the value lived. It wasn't. And once you see what AI actually made free, and what it conspicuously didn't, the panic turns into something closer to a map.

What AI actually made free

Let me be specific and generous about how much AI really took, because downplaying it just sounds like denial.

It took the happy path. The first version. The part of the work that's been written down ten thousand times in tutorials, Stack Overflow answers, and open-source repos — which is exactly why the model learned it so well. The standard login flow, the typical dashboard, the ordinary API, the form that validates an email, the component that looks like every other component. The commodity layer of software engineering, the stuff that was technically "skilled work" but was really pattern-matching against a million prior examples.

That's maybe 90% of the volume of what gets typed in a day. And it genuinely did fall. A huge amount of what used to be billable, time-consuming, résumé-worthy engineering is now a prompt and a glance. Pretending that's not true helps no one, least of all you.

Concede the whole 90%. The argument doesn't need it.

What it conspicuously did not touch

Now the part nobody put in the demo.

AI did not learn how to make a webhook idempotent when Stripe times out mid-transaction and you have no idea whether the charge went through. It didn't learn to tune cgroup memory limits when a background worker quietly OOMs at 3am and takes the queue down with it. It has no feel for the passkey signCount desync that silently locks your paying customers out of their own accounts — the bug that generates zero errors and a pile of furious support tickets. It can't do the data migration that has to move fifteen years of real users' files without losing a single byte or breaking one weird edge case someone created in 2013.

Notice what all of those have in common: none of them show up in a demo, and none of them were written down anywhere for the model to learn from.

That's not a coincidence — it's the whole explanation. AI got extraordinary at the 90% because the 90% is the part that's documented everywhere, done the same way a million times, sitting in the training data in bulk. The 10% is hard precisely because it isn't written down. It's the failure modes, the edge cases, the what-happens-when-it-breaks-at-scale — knowledge that doesn't live in tutorials because it's only ever learned the expensive way: by getting burned, at 3am, on a real system, with real users yelling.

You can't prompt your way to that, because the thing you'd need to prompt doesn't exist in text. It exists in scar tissue.

The counterintuitive part: the 10% got more valuable

Here's the move most people miss while they're panicking.

When the easy 90% was expensive, its cost hid the value of the hard 10%. It was all bundled together and called "engineering," and the bill for the boilerplate and the bill for the 3am expertise came out looking like the same kind of money. The commodity work subsidized and camouflaged the rare work.

Now that the 90% is free, that camouflage is gone — and the 10% stands exposed as the only remaining scarcity. And value always concentrates wherever the scarcity is.

So AI didn't flatten the value of expertise. It flattened the value of the commodity part of expertise, and shoved all the remaining value into the rare part. The person who can do the 3am work didn't get less valuable when AI arrived — they got more valuable, because now everyone can do the easy part, and almost nobody can do theirs. The scarcity sharpened. The premium went up.

That's the whole reframe, and it's why the title isn't a motivational lie: AI making your easy work free is exactly what made your hard work worth more. It stopped being hidden inside the cost of the boilerplate.

The market is already proving it

You don't have to take the argument on faith — go look at the vibe-coded clone wave happening right now.

People are using AI to clone paid apps by the thousands: creative tools, CRMs, SaaS products, whole suites. The first versions appear fast and look impressive. And almost all of them die in alpha.

Why? Not because the code was bad. Because the makers could generate the 90% and either couldn't or wouldn't do the 10%. The clones that survive — the rare ones — are precisely the ones where somebody pushed through the unglamorous hard part: the maintenance, the edge cases, the reliability, the trust that gets built one answered support ticket at a time. "Cloning the surface of software is now free" is the exact reason depth became the moat. The market responded to free building with a graveyard of surfaces and a premium on substance. That's the thesis, already playing out, in public.

So what do you actually do with this?

Honest direction, no false comfort:

If you're early in your career and the 90% is most of what you can do right now — that's the part that got commoditized, so the move isn't "learn to prompt faster." It's to deliberately go after the 10%: debugging, systems thinking, how things fail, what happens at scale, reading code you didn't write, operating things in production. I'll be straight that this is genuinely harder than it used to be, because the easy work that used to teach you the hard stuff — the grunt tasks juniors cut their teeth on — is exactly what's being automated away. That's a real problem, and it deserves honesty rather than a slogan. But the direction is clear: chase the part that doesn't demo.

If you're experienced — your value didn't drop, it got concentrated. The years you spent getting burned are now the scarce thing, not the overhead. Stop apologizing for being "slow" at the boilerplate AI does instantly, and lean into the part it can't touch, because that part is now the whole job.

For everyone: stop competing on the layer AI does for free. There's no winning there — it's free, and you can't underbid free. Compete on the layer it can't reach.

The takeaway

"AI can build anything" is true and misleading in the same breath. It can build the 90% that was always the commodity. It can't build the 10% that was always the point.

The value didn't leave software. It moved — from the writing to the making-it-actually-work, from the demo to the dependability, from "can you build it?" to "can you keep it alive when it breaks at 3am?" For an engineer who can do the hard part, that's not a worse world. It might be the first time in a long while that the hard part is clearly, visibly the valuable part — instead of being quietly hidden inside the bill for the easy part.

Your easy work became free. That's not what makes you replaceable. That's what finally made the rest of you worth paying for.

A personal note, since this is the thing I've been chewing on the most: I've ended up building in this space myself — a workspace where the whole point is to put the real effort into the hard part (the reliability, the guardrails, the trust around what gets built), rather than just the fast generation everyone already has. It's called Xenition. I'm genuinely not pitching it here — this piece stands on its own and I'd have written it either way. But if any of this resonated and you're curious what "building for the hard 10%" looks like in practice, you're welcome to take a look. Mostly I just wanted to think the idea through out loud, and the comments are where I actually want to be.

So — the contestable version, and I want the real disagreement: do you think the hard 10% stays safe, or does AI eventually eat that too? And for the experienced folks: what's your 10% — the thing you do that no demo ever shows and no prompt ever quite gets right? I'll start: anything involving what happens after the happy path fails.

Git, Docker, and IPFS All Hide the Same Beautiful Idea

James Anderson — Wed, 14 Oct 2026 08:50:45 +0000

Let me make you a small promise, because it's worth your fifteen minutes.

There's an idea you rely on dozens of times a day — every time you make a commit, every time you pull an image — and you've almost certainly never seen it directly. It hides underneath the tools, doing its work quietly, while you type git commit and watch a hash scroll past without once wondering what that hash actually is.

It's one of the most elegant ideas in all of computing. Simple enough to explain in a single sentence. Powerful enough that git, Docker, and IPFS are all built on it — three very different tools, one shared foundation. And once you see it, something nice happens: a whole pile of "huh, why does it work like that?" questions about your daily tools quietly resolve into "oh, of course."

That's the promise. One idea, and by the end your tools make more sense than they did this morning. Let me show it to you.

First, the ordinary way — and its quiet flaw

Almost all the time, we find data by its location. A file path: /home/james/report.pdf. A URL: example.com/report.pdf. A database row by its ID. In every case, the address tells you where the thing lives — "the thing over there."

This feels so natural we never question it. But it has a quiet weakness, and the whole idea we're building to is a response to that weakness, so it's worth noticing.

The name tells you nothing about the content. The file at /home/james/report.pdf could be the report you wrote yesterday, or a corrupted version, or something an attacker swapped in — and the path looks identical in all three cases. The address is a promise that has to be trusted. You ask for a location, you get back whatever currently lives there, and you have no built-in way to know it's what you expected.

So here's the question that cracks the whole thing open: what if the address was the content? What if, instead of naming data by where it sits, you named it by what it actually is?

The idea, in one sentence

Here it is, the whole thing:

Instead of addressing data by its location, you address it by a cryptographic hash of its content — a short, unique fingerprint computed from the bytes themselves.

That's content-addressing. The "address" of a piece of data isn't a path or a name someone chose. It's a fingerprint derived from the data itself.

If the analogy helps: think of it like a fingerprint for a person, or a nutrition label that's computed from the food rather than printed by the manufacturer. It comes from the thing. Change the thing even slightly, and the fingerprint changes completely. Two identical things have identical fingerprints, always.

So the shift is small but total. "Give me the file at /report.pdf" (a location) becomes "give me the thing whose fingerprint is a3f9c2e8…" (its content). You no longer ask where — you ask what.

It sounds almost too simple to matter. Here's why it's beautiful: look at everything that falls out of it, for free.

The magic: four things you get for nothing

This is the part worth slowing down for, because it's where a simple idea reveals itself as a deep one. You don't add the following features to a content-addressed system. They're just consequences of the one idea. You get them whether you wanted them or not.

1. Integrity, for free. The address is a checksum. When you ask for the thing at fingerprint a3f9c2e8… and something hands it back, you can recompute the hash of what you received and check it matches. If even one byte was corrupted or tampered with in transit, the fingerprint won't match, and you'll know instantly. The name verifies the data. There's no separate "is this file corrupted?" step to bolt on — it's built into the very act of addressing.

2. Deduplication, for free. Identical content produces an identical hash. Always. So if two files — or two users, or two systems — have the exact same bytes, they have the exact same address, which means the system stores those bytes once. You physically cannot store the same content twice, because the second copy has nowhere new to go. Deduplication isn't a feature someone engineered; it's a thing that can't not happen.

3. Immutability, for free. A given fingerprint always points to exactly one piece of content, forever. Nothing can quietly change the data living at a3f9c2e8…, because the moment you change the content, you've changed its fingerprint — you haven't modified the thing at that address, you've created a different thing at a different address. The old address still points at the old content, unchanged. History can't be silently rewritten.

4. Caching, for free. If you already have the thing at a3f9c2e8…, you are done. You never need to fetch it again, and you can be certain — not hopeful, certain — that your copy is identical to the one being offered, because they share an address, and sharing an address means sharing content. "Do I already have this?" becomes a trivial lookup instead of a careful comparison.

Sit with that for a second. Integrity, deduplication, immutability, and caching — four properties that systems normally work hard to provide, each with its own machinery — all tumble out of one decision about how to name things. That's what "elegant" means in software: enormous consequence from minimal cause.

Now let me show you where you've been standing on this idea the whole time.

Where you've been using it all along

Git

Here's the one that tends to land hardest, because you use it constantly.

Git is, underneath its version-control interface, a content-addressed filesystem. Every file you commit (git calls it a "blob"), every directory (a "tree"), and every commit itself is stored by the hash of its content.

That commit hash you see — a3f9c2e8… — is not an ID that git assigned. It is a fingerprint of everything in that commit: the files, the directory structure, the author, the message, and the hash of the commit before it. It's computed from the content.

And suddenly a bunch of git's behavior stops being magic and starts being obvious:

Why git can detect corruption: because every object's name is a checksum of its content. (Property 1.)
Why git doesn't store the same file twice: identical files have identical hashes, so they're one object. (Property 2.)
Why git history is tamper-evident: change one old commit and its hash changes, which changes the "previous hash" baked into the next commit, which changes its hash, and so on — the change ripples through every commit after it and becomes impossible to hide. (Properties 1 and 3, working together.)

Git isn't doing anything mystical. It's content-addressing, wearing a version-control coat.

Docker

Docker image layers are content-addressed too, and the same reveals follow:

Why docker pull is often so fast: it skips the layers whose content hash you already have. (Caching — property 4.)
Why layers are shared across different images: two images built on the same base have layers with the same content, so the same hash, so they're stored once. (Dedup — property 2.)
Why a sha256: image digest means something: it guarantees you pulled exactly the image you meant, byte for byte, with no silent substitution. (Integrity — property 1.)

Every one of those conveniences you take for granted is the same idea quietly at work.

IPFS

IPFS makes content-addressing the entire premise, which is why it's the cleanest example. On the normal web, you fetch a file from a location — this server, that URL. On IPFS, you fetch a file by its content hash (called a CID). You're not asking "what's on this server?" — you're asking "who has the thing whose fingerprint is this?", and anyone on the network who has that content can serve it, because the same file produces the same address no matter where it lives. Location stops mattering; identity is everything.

But wait — what if two things have the same fingerprint?

If you’ve been reading closely, a question has probably been forming, and it’s the right one to ask — because the entire idea hinges on the answer.

Content-addressing assumes that no two different pieces of content ever produce the same hash. That event — two different inputs, one identical fingerprint — is called a collision, and if it could happen easily, the whole scheme would fall apart: two different files would share an address, and “same hash means same content” would become a lie.

So why do we trust it? Because with a good cryptographic hash, collisions are astronomically unlikely. Not “unlikely like winning the lottery” — unlikely like every person on Earth winning the lottery, on the same day, for a thousand years running. The space of possible hashes is so vast (for SHA-256, that’s 2²⁵⁶ values — a number larger than the count of atoms in the observable universe) that in practice you can treat “same hash = same content” as simply true, and build version control for the entire planet on top of that assumption.

But “in practice” is doing real work in that sentence, and here’s the concrete story that proves the point. Git originally used a hash called SHA-1. Over the years, SHA-1 weakened — researchers eventually managed to deliberately construct two different inputs with the same SHA-1 hash, which is exactly the collision the model depends on never happening. So git undertook a careful, years-long migration to SHA-256. Not because content-addressing was flawed, but because the whole thing rests on collisions being infeasible, and when the old hash got shaky, the one load-bearing assumption had to be shored up.

That’s the honest footnote to the beautiful idea: content-addressing is only ever as trustworthy as the hash underneath it. The elegance is real — but “which hash function” isn’t a minor detail, it’s the thing holding the entire structure up. The idea is beautiful; the hash is what makes it hold.

The takeaway

Here's the whole thing, one more time, so it sticks: if you name data by what it is instead of where it lives, you get integrity, deduplication, immutability, and caching as a free gift — which is exactly why the tools you trust most are quietly built on it.

It's a small idea with a very long reach. And now it's yours. You'll start noticing it everywhere — in a commit hash, a Docker digest, a CID, and places you haven't looked yet — and that noticing, that seeing of the idea beneath the tool, is the difference between using something and understanding it.

Fifteen minutes, one idea, and your tools make more sense than they did when you started. As promised.

Genuinely curious: what's a concept like this one for you — a single small idea you learned that suddenly explained a dozen tools at once? Content-addressing was one of mine; I remember the exact moment git stopped being magic. And now that you know git is content-addressed: what else about it just clicked into place?