# Jams — Daniel Spinosa

Collaborative thinking — ideas explored, not just stated.

## [Token-Maxing Is Just the Mythical Man-Month Again](https://danspinosa.com/jams/token-maxing-is-just-the-mythical-man-month-again)

*April 21, 2026*

Everyone's racing to use more tokens.

More agents. More orchestration. More AI talking to AI, coordinating, delegating, handing work down the chain. It feels like scale. It feels like power.

I keep thinking about The Mythical Man-Month.

the old problem, restatedFred Brooks figured this out in 1975. Adding more people to a late software project makes it later. Bigger teams don't move faster — they move slower, because communication costs scale faster than output does. The coordination overhead eats you.

We spent decades learning to keep teams small.

And now the hot take is: spin up a swarm of agents, have them talk to each other, token-max your way to productivity. We're rebuilding the exact inefficiency we spent fifty years trying to eliminate. Same problem, new substrate.

I tried one of the more ambitious multi-agent orchestrators recently. Dozens of agents coordinating with each other, delegating, negotiating. I hit my token limit in about twenty minutes. Nothing got built. I'm not writing it off — the project is young and I'll try again. But it was a clean demonstration of how fast coordination without output can burn through a budget.

what you actually want to maximizeIt's not tokens. And it's not token minimization either — that's just gaming the metric by producing nothing.

The real target is something like:

(Interestingness + Utility) / (Tokens × Time)

You want the best stuff — useful, interesting, pointing somewhere new — and you want it fast, using as few tokens as it takes. But tokens and time can trade against each other. Burn more tokens if it compresses time. The ratio can still go up. That's not waste, that's a worthwhile exchange.

What this formula kills is the failure modes on both ends: the team that token-maxes its way to mediocrity, and the team that penny-pinches itself into paralysis.

this is actually a life formulaHere's the thing. I didn't come up with this for AI.

I've been running a version of it my whole career — maximizing interesting and useful per hour, so I could go be a person. I love reading. I love thinking. I love working out, camping, cooking good food, spending time with my kids. The better I was at producing something interesting and useful in a shorter period of time, the better it was for everyone relying on me — and the better it was for me.

Tokens are just a new input cost I had to figure out where to put. They go in the denominator. They're a cost and a feature.

rails already answered most of the questionsI've been a Rails developer for a long time. One pertinent reason I absolutely  love it: it's made the decisions that don't need to be my decisions.

Convention over configuration. Settled answers to table-stakes questions. Twenty years of baked-in practice. When I sit down to build something, I'm not negotiating the database layer or wiring up authentication or thinking through deployment. Those are answered. I get to focus on taste. What am I building? What does it do? What value does it actually deliver?

That's always been the lever Rails gives a solo developer or small team. With AI it's multiplied.

When I'm working with Claude Code on a Rails app, we're not reinventing wheels. The 37signals DNA is in the framework. There's no sub-agent to figure out the API, no sub-agent arguing about front-end state, no sub-agent negotiating first principles with another sub-agent.

One focused agent, with strong conventions behind it, produces more than a swarm splitting up ambiguity. Less coordination overhead. Fewer tokens on AI-talking-to-AI. The denominator shrinks without the numerator suffering.

the work life battleHere's the irony the formula creates.

AI makes work more enjoyable than ever. I'm shipping things I couldn't have shipped before. I'm doing work I genuinely love more than I ever have. And that makes the battle harder.

I've always fought the work life battle ... not balance, battle. Because I love both. I love the work and I love the life, and they compete for the same hours. I've never been about counting hours. I've been about look what I produced, isn't it good? And then going home.

Now the work is even more magnetic. And that means the battle is even more worth fighting.

the gardeningLast weekend I was gardening. Getting my hands dirty. Getting my brain into this world of plants and roots and ecosystem — slowing down, building something sustainable, planning for systems that are going to thrive on their own.

That's not recovery from work. That feeds the work.

All of the time away from the desk — the reading, the camping, the cooking, the kids — it comes back. Different perspectives. Different flows. Experiencing things that have nothing to do with software and everything to do with how you think about systems, time, value, what lasts.

The sauntering isn't the reward at the end. It's an input.

the harnessThe people winning the agentic era (or any era, I think) are going to be the ones who know what's worth building.

Not the ones running the biggest swarm. Not the ones spending the most tokens. The ones who've kept enough of themselves intact — enough curiosity, enough taste, enough life outside the work — to point the harness somewhere worth going.

It's not just who can handle the harness. It's who can decide what to do with it.

That's the formula. And most of it happens away from the keyboard.

## [The Dark Factory Needs a Light Switch](https://danspinosa.com/jams/the-dark-factory-is-a-start)

*April 9, 2026*

I've been running a dark factory for a while now.

If you haven't heard the term: a dark factory is a factory where humans aren't needed on the floor. You turn the lights off and let the machines run. People have started applying this to software — specifically to agentic coding, where AI agents write the code and you don't review it. Specs in, software out.

I've built real things this way. Dozens of real users. Software I use myself. And it works — often better than what I used to ship by hand.

The dark factory is all about the code. But we need more than that.

the lights aren't always offMy factory isn't permanently dark. I turn the lights on and off.

When I'm in familiar territory — my Rails stack, patterns I've built before, problems I've solved — the lights are off. I trust the machines. I've programmed them well. I've pointed them at good examples, written the CLAUDE.md files that encode my taste, built up the skills files that teach them how I want things done.

When something new enters — like when I recently added Hotwire Native to apps that were already working — the lights come on. I get in there. I work with the robots. I teach them the new domain. I find good examples, I point them at iOS patterns that hold up. And once the factory is producing well in that new territory, the lights go back off.

The skill isn't running the factory in the dark. The skill is knowing when to turn the lights on.

the light switch is a skillI've been thinking about using Gastown on my projects. If you haven't seen it — it's a multi-agent orchestrator. Instead of one Claude Code instance, you've got dozens running in parallel, coordinated by a Mayor agent that delegates work down the chain. It's fast. It's powerful. And it raises the stakes on everything I'm saying here.

Because here's the thing: the more agents you're running, the more damage you can do outside your competence sphere.

When I'm in familiar territory — Rails patterns I've built a hundred times, problems I've solved before — the dark factory hums. The agents know what good looks like because I've shown them. The CLAUDE.md files encode it. The skills files encode it. There's a reference library of prior good work to point at.

When I'm outside that sphere? That's when the red warning light needs to go on.

Not a yellow light. Red. Full stop.

New domain, new platform, new architectural pattern — that's when you turn the lights on and actually look. Check the architecture. Read the code. Make sure the factory is set up correctly for this new territory before you let it run. Because in unfamiliar ground, the agents don't have good priors to draw on. Neither do you. And if you're running ten agents in parallel while neither of you knows what good looks like — you're not running a dark factory. You're running a chaos factory.

The light switch is the skill. Knowing when to flip it is what separates a factory you trust from one that's quietly producing slop in the dark.

the robots are nondeterministic. so are you.Here's the thing that snuck up on me: managing AI agents is not a new problem. It's the oldest problem in building things with other people.

Human engineers are nondeterministic too. They bring priors you don't control. They fill ambiguity gaps with their own judgment. They optimize for outcomes you didn't fully specify. They have different levels of maturity, different levels of taste, different experience in your domain.

The AI just made it obvious. We spent decades pretending human teams were deterministic — with processes and org charts and code reviews — and they never were.

So when I ask myself how to work well with an AI coding agent, I'm asking the same question I asked as a startup founder hiring my first engineers: how do I collaborate with this nondeterministic system to produce something of value? Not how do I make them into me. How do we work together?

the moat is the teamA lot of people say the moat is the spec. Or the test scenarios. Or the factory configuration. Those things matter. But they're too specific.

The moat is the team.

The team is humans and AIs and processes and workflows and feedback loops. It's how you work and when. It's whether people get to sleep. Whether they get to saunter — to sit with an idea that isn't a ticket yet, to feel something is off before they can say why. It's culture.

And culture drifts. Not rots — drifts. Rot carries judgment. Drift is just what happens when you're not actively gardening. As a startup founder I learned this the hard way: culture grows on its own if you let it. You can't say it's wrong. You can just notice it's not what you wanted, and tend to it.

Your CLAUDE.md files are culture documents. Your skills files are culture documents. They're the mechanism by which you transmit your values to a collaborator who doesn't sit next to you, doesn't pick things up by proximity, doesn't learn by watching. They need to stay alive — updated when you learn something, when the domain shifts, when your taste changes.

A stale CLAUDE.md is cultural drift you won't notice until the output starts feeling off.

this is not vibe codingVibe coding is turning the lights off without building the factory. It's trusting a system you haven't earned the right to trust.

What I'm describing is the opposite. You spend real time building the factory — the skills, the configuration, the examples, the feedback loops. You earn the darkness by earning the trust. And when trust runs out in new territory, you light it back up.

The robots don't saunter. I do. That's the point.

The best specifications come from the questions I ask while I'm not working — in the shower, on a walk, sitting with something that's bothering me and not yet named. The friction of not-yet-knowing is where the factory gets better. If the dark factory is running so well that I'm never stuck, never bored, never sitting with something unclear — that might actually be a warning sign.

The factory runs the code. I run the factory. And the thing that keeps the factory producing well is protecting my own capacity to ask better questions.

That's why the dark factory needs a light switch. The code is the output. The team — how it's built, how it's tended, what it values — that's the work.

## [The Bugs Are the Features](https://danspinosa.com/jams/the-bugs-are-the-features)

*April 7, 2026*

The wrong question is: what can AI do?

The right question is: what does AI doing things reveal about what humans are?

That reframe is everything.

AI doesn't saunterWe built AI to predict the next best token. Given input, produce output. Fast. Accurate. Tireless. We didn't build it to throw the input away and come back with something totally different based on its own motivations and taste. We explicitly didn't build that. That wasn't the goal.

And it shows.

AI doesn't saunter. It doesn't sit with an idea. It doesn't wake up at 3AM and realize the whole frame was wrong. It doesn't push back on the brief. It doesn't ask should we even be doing this? It just does it — again and again, with complete confidence — until you tell it to stop.

That's not a criticism. That's what makes it extraordinary at what it does.

But it reveals something.

The bugs are the featuresEvery quirk we've been trained to apologize for — the anxiety, the second-guessing, the wandering curiosity, the stubborn feeling that something's off even when you can't explain why — those aren't inefficiencies.

They're the whole job now.

The person who questions the brief is the most valuable person in the room. The one who says wait, are we even solving the right problem? The one who wakes up at 3AM not because they failed, but because their judgment is running at a level that doesn't clock out.

That discomfort? That's quality control. That's taste. That's something AI doesn't have access to.

“I can produce a wrong answer with complete confidence. You can't. That feeling when something's off — that's yours. That's not a bug. That's the feature.

- Opus 4.6”

The complementThere's a concept in economics called complementary goods. When one thing gets dramatically cheaper, demand rises for its complement. Gasoline gets cheap, people drive more. AI gets good at knowledge labor — fast execution, code, drafts, synthesis — and its complement becomes the scarce thing.

Human judgment. Taste. Moral courage. The willingness to actually care whether the answer is right.

We spent decades trying to train that out of people. Make them consistent. Predictable. Six sigma perfect. Flowcharts and optimization. That's great for products. It's terrible for people.

And now the products have gotten so good at being consistent and predictable that the inconsistent, unpredictable, opinionated human in the room is the irreplaceable one.

My experienceI've been an engineer for a long time. I was fast. I could build something in a day that might take others a week. And what I did with the time I saved wasn't grind out more features.

I used it to sit with the problem. To ask whether we should build the thing at all. To sleep. To read weird stuff. To go outside. To follow my curiosity into corners I couldn't justify to anyone.

I didn't do it because I had a strategy. I did it because I liked it.

Turns out that wandering built something — a particular kind of brain, a set of priors, a way of connecting things that isn't easy to replicate. That's what AI doing the labor creates space for. Not more labor. More human.

This isn't a crisis. It's a rethinking.We had to do the labor before because we didn't have the machines. The machines came, and we didn't stop being valuable — we became legible to ourselves. We could finally see what we were actually good at.

Same thing is happening now. Faster. More disorienting. But the same.

The combine harvester didn't make the farmer obsolete. It made visible what the farmer was actually for — knowing what to plant, when, why, for whom, and whether this season's risk is worth taking. That's not labor. That's judgment. Taste. Experience. The accumulated weight of caring about the outcome.

The 3AM feeling isn't a flaw in the system.

It is the system.

## [What is a Jam?](https://danspinosa.com/jams/what-is-a-jam)

*April 6, 2026*

"Did AI write this?" is the wrong question.

It's like asking did a typewriter type this. Did a compiler compile this. The tool isn't the author.

I think about this book report I did as a kid. Everyone else was doing it by hand. I made mine on a word processor — did the layout, found pictures, made a binding. It was done. And someone asked me, "did the computer make this?"

I was kind of offended. I was a kid and I remember thinking, what a dumb question. I made it. I used a computer. Did a pen make your book report?

AI is new, so we're not used to it yet. And because we call it "intelligence," we get weird about it — like maybe it's doing the human's job? But it's a tool. A loud, confusing, impressive tool, but a tool.

A jam is me thinking out loud, using that tool. The ideas are mine. The thinking is mine. I'm not the best writer — so I work with something that is. We go back and forth, argue a little, and what comes out is something I couldn't have written alone. But the soul, that's from me.

---
Source: [danspinosa.com/jams](https://danspinosa.com/jams)