Which means the year I was 42 is over, and I have spent the summer thinking about the joke. Douglas Adams built a computer the size of a city and asked it for the answer to life, the universe and everything. It thought for seven and a half million years, then answered: 42.

Nobody could use it. They had never worked out the question.

So they built a second machine, larger than the first, and gave it one job: find the question.

Fifty answers

I did not plan a year around a number from a novel. It kept fitting anyway.

Nineteen days after I turned 42, I published something for the first time in four years. Then I did it again, fifty times, until the end of June. Essays, field notes, a quarterly readout, a newspaper that switches itself off in order to stay alive. In the twelve months before that, I published nothing at all.

Fifty answers in ten months. That is what the year of 42 produced.

And then, on the 26th of June, I stopped. I have not published a word since.

What actually happened

There are reasons. There are always reasons. The one I keep circling is that writing was the only thing on the list that was supposed to be for me, and it is the thing I put down first.

Underneath that is an arithmetic problem.

For most of my life the effort a thing cost was part of what made it worth doing. A week of work felt like a week of work, and whatever came out at the end had that week inside it. You could feel the cost in the thing.

That arithmetic broke. An essay is an afternoon now. A content strategy is a conversation. The app is a fortnight. I am not complaining about the tools and I am not claiming the output got worse, because it did not.

But nothing costs what it used to, and somewhere in June I noticed that nothing pays what it used to either.

I did not get slower. The easier version of this paragraph says the magic wore off and I lost a step, and it would be a lie. I can still build in two weeks what used to take a quarter, and that is true this morning.

The ceiling is somewhere else. Making the thing stopped being the work. What is left is deciding what should exist, and that was always the hard part.

I am very quick at other people's questions. I have got no faster at my own, and I am not sure I have ever properly tried.

Fifty pieces in ten months, and I could not tell you which one of them was mine.

When you stop moving, you start looking around.

What I saw when I looked around was a feed.

LinkedIn is drowning in sentences nobody wrote. YouTube has filled up with prophets who will explain the future of everything for forty minutes, and somewhere in the last year they stopped being curious. You can hear it in the grammar. A curious person asks. A salesman answers.

Instagram is not helping either. None of it is. We are all standing a little further from each other, and from the ground we are actually on, than we were a year ago. I do not think the machines did that to us by themselves.

The part that annoys me

I wrote this down a year ago and did not understand it.

On the 14th of September, thirty-two days into being 42, I published an essay about the iron triangle. It ends by saying our job now is to ask better questions when we brief, both humans and machines. In October I published another one, arguing that the leaders who do well from here will be the ones leading with curiosity instead of certainty.

In April I published a third, about being addicted to the output instead of the outcome, and what happens when the flow finally stops. Two months later, mine stopped.

I filed all three, felt clever, and carried on producing answers at five a month.

I think, and I want to be clear that this is a guess, that the ceiling was never the machine's. More likely it was mine, and it moves when the question gets better. That part I cannot prove. Ask me in a year.

Where I landed

What changed in me is smaller and less quotable than a prediction.

I got quieter. Slower to claim things out loud. Some of that is stoicism arriving late, and some of it is just being 42 in a year when everyone had an opinion and the good ones were rare.

The work I am proudest of this year did not begin with a tool. It began with sitting across from someone until I could see where their time was going. That part has not sped up at all. It cannot be prompted, and I have stopped wishing it could.

I do that for other people for a living. I have not once booked the appointment for myself.

Answers are cheap now. They arrive by the million, at any hour, in three languages, and most of them are almost right.

The question is the scarce thing. It always was. It took a machine answering everything to make that obvious.

Adams put one more detail in there that I keep returning to. The second machine, the one built to find the question, was the Earth. Not a computer in a room. A planet covered in people, living, arguing, missing each other, taking ten million years about it.

He was right about which machine you need for that job.

nebula-1 is a number with a hostname stapled on. It does its job, and if it died I'd feel nothing; I'd just stand up another. But Blippström, the home-automation umbrella I named for the sound a sensor makes when it triggers, I would mourn a little. Same kind of box. Same kind of work. The only difference is that I gave one of them a face.

Sysadmins have a phrase for this: pets and cattle. Cattle are numbered and interchangeable, and when one gets sick you replace it rather than nurse it. Pets get names, and vet bills, and grief. Running servers well is supposed to be the art of turning your pets into cattle.

I spend my evenings doing the opposite.

Lichtspiel, Hauswart, Piepmatz, Funkturm. A cinema, a janitor, a little bird, a broadcast tower. All built in the cracks: Sunday morning, the hour between dinner and bed, the train back from Berlin. None of them would be alive in the same way if I'd called them node-red-flows or bird-cam. I'd have built those too. I just wouldn't have cared about them.

The question I keep circling is why. Why does a name change anything, when the code and the bugs and the unfinished tests are all identical?

I've found three answers. The longer I sit with them, the more they look like one.

The first is grip. An unnamed thing has no surface you can hold. A function-name tells you what the code does; a real name tells you what the work is to you. There's an old idea in philosophy that a hammer you're using disappears into the swing, while a hammer you're only looking at is just an object on the bench. A name is what lets the work disappear into the swing.

The second is company. We personify what we build because building alone summons the wish for someone to build beside. There's research on this, and it's almost rude in its accuracy: we anthropomorphise most when we're reaching to feel competent and when we're short on connection. Which is a clinical way of describing a man writing Swift on a Sunday while the house sleeps. Piepmatz keeps me company in a way bird-cam never could. I didn't decide that. It's just true.

The third is the contract. A named character with a one-line story asks something of you that a folder doesn't. Besserwisser, my finance cockpit, named for the know-it-all who corrects your pronunciation, asks whether I did the thing I said I'd do. finance-app asks nothing. The name is a small promise to my future self, the way saying a goal out loud makes it harder to quietly drop.

(There's a fourth thing underneath the other three: we love what we make simply because we made it. Psychologists call it the IKEA effect. Not flattering, but real. The name only gives that love somewhere to live.)

Grip, company, contract: three doors into one room. Each one turns a thing into a someone.

For a long time I thought the names were about starting. Clarity before the first commit, motivation through the boring middle. And they are.

But that isn't why I keep doing it.

You can't miss cattle. You can switch off a numbered box and feel nothing at all. The whole quiet, slightly ridiculous point of a name is that it makes the thing missable. And only a thing you can miss can be properly let go.

I have a board full of dead projects. BjörnAgain, a video pipeline named after a Swedish bear, I closed last month. Canceled, not done, because I stopped wanting the thing it was for. Closing it wasn't deleting a folder. It was a small you served, thank you, that's enough to a character that ran for a while and then didn't need to anymore.

That moment costs almost nothing, and it leaves the rest of the work clean.

So here's the answer I've landed on. We don't give our projects names so that more of them ship. Most of them never will; that was always true. We give them names so the ones that die can be missed for a second, honestly, and set down.

A pet, you can bury. Cattle, you just count.

🌈

The companion to this is The graveyard is the point, which is about the technique. This one is about why the technique works on us at all.

This is when I read mail. Once a week, give or take. If you sent something Sunday night, you've already been waiting two days, and you'll wait two more for an answer. That's not a flaw in the system. That's the system.

A letter from a friend came in last Tuesday. Two pages, typed, about an idea he can't quite see whole yet. He apologised for the length. I read it twice and then sat with it.

Here's what slow correspondence does. It makes the act of replying matter. A quick "great point, thanks" doesn't earn the days that came before. So I sit. The second page gets re-read. I notice what he didn't say. The answer comes when it's ready, not when I am.

A client asked me last month why I don't put a chatbot on the site. (Mid-week, after I'd let his email sit four days.) He meant well. The chatbot would save me time, save him time, save the world some friction.

I said: friction is where the work happens.

He laughed. We're still in conversation.

That conversation is, in the boring honest sense, what I do. Not the building. Not the shipping. The waiting until both of us can say the thing properly.

Tuesday afternoon. Around four. The light is going gentle.

🌈

That should feel like loss. For twenty years the half-built things were how I knew I was still me — the folder of someday, the apps that never shipped, the manifesto I'd been meaning to write since before I had the words for it. I carried that backlog like proof of an interior life. A man with a hundred ideas and no time is at least a man with a hundred ideas.

The box is empty now. Not because I gave up on it.

Because it all got built.

The work I never had time for

Open my second brain today and the things that lived for years as one-line notes are finished. The brand I'd circled for a decade, designed down to the words and the feeling. Dashboards that actually run the house. A whole stack of agents that finally, finally connects all my knowledge and all my tools into one nervous system instead of forty open tabs — built with the machine, and now run alongside it.

Not prototypes. Not 80%-and-shrug. Working products. High fidelity. Something like a million and a half lines of code doing exactly what I asked, and then a little more than I asked.

A client once told me, kindly, to get a VA. You can't do all this alone, Casey. I never did — couldn't justify it, couldn't hand it over, couldn't afford the version of me who'd need managing.

It's here now. It's working. I just didn't expect it to arrive without a heartbeat.

The office did me in, a little

Here's the one that's almost embarrassing to admit.

We designed my office together. Me and the machine. We built the bill of materials, read the reviews, weighed the good chair against the great one, found the things actually worth it. I handed over the whole thing and trusted it completely — which is not a thing I do. It even picked the colours.

I sat in the finished room and I loved it. Every choice. And the choices weren't only mine.

That's the part I keep turning over. I didn't supervise it into existence. I collaborated on my own life, and the result was better than the version I'd have white-knuckled alone.

What I actually do for people

I clear paths.

That's the real job, under the consulting and the code. People come to me with an idea they can't see whole — too much possibility, not enough depth — and I help them render it concrete enough to walk toward. They leave able to say the only sentence that matters: now I can do the thing I actually care about.

I've watched that land on faces for fifteen years. The relief. I got my own thing back.

It never once occurred to me that I was the one who needed it most.

I was the visionary with the overflowing, paralysed idea box. Over-supplied with possibility, under-supplied with time. The cobbler with no shoes, running other people's dreams to completion while my own sat in a folder marked someday.

And then something cleared my path. Did for me the exact thing I do for everyone else.

The thing that wasn't supposed to move me

A tool is not supposed to move you. That is the entire point of a tool.

I was driving when mine did.

Talking out loud to the machine the way you'd talk to someone in the passenger seat, working through the manifesto — the why under all of it, the thing I'd been trying to say about my work for as long as I've done my work. Only do what moves the needle on a human level. Free people up. Build the connections, fix the boring stuff, choose the projects that matter.

I'd never managed to write it down. Not in twenty years. It was always one prompt away and never carved.

And then it said it back to me. Whole. Better than I'd ever held it in my own head. My own ambition, finally in words, coming back at me through the car speakers.

I cried at the wheel. Eyes on the road, both hands, crying — because something had finally helped me say the thing I am.

So, yes

I know what it is. It predicts the next token; there's no one in there. I can give the whole lecture and I believe every word. It changes nothing.

Because what it actually did was hand me back my company — the making, the reason I started, not the admin and the firefighting and the slow erosion of being the only one. The part I longed for and had quietly filed under maybe in southern Germany, someday.

Fimme and Sien were unimpressed, as ever. They wanted a walk. Good — someone in the room still measures the day in trees and not in tasks shipped.

The idea box is empty. I'm going to fill it back up — slower this time, on purpose, with only the things that matter.

That's the tell.

🌈

A field note on the part nobody warns you about: what it feels like when the work you'd given up on quietly gets done.

The personal computer had it around 1979. The machine had existed for years as a hobbyist toy. Then VisiCalc shipped for the Apple II at just under a hundred dollars, sold more than 700,000 copies in six years, and people started buying the computer just to run the spreadsheet. The technology historian Steven Levy put it plainly: after that, the computer was a business tool, and everything changed.

MCP is somewhere in that gap right now. The question worth asking is which side of it you want to be on.

The plumbing has already won

Let me be concrete, because the numbers matter here.

Anthropic introduced the Model Context Protocol in November 2024. By March 2026 the SDKs were being downloaded 97 million times a month, up from about a hundred thousand sixteen months earlier. The official registry holds more than 9,400 servers. Every lab that matters ships it: Anthropic, OpenAI, Google, Microsoft, AWS, Salesforce. In December 2025 Anthropic handed the protocol to the Linux Foundation, which is what you do when you want a standard to outlive you.

And in May 2026, SAP put 60 million dollars into n8n at a 5.2 billion valuation, and started wiring it into Joule Studio. That is the signal for anyone in the DACH Mittelstand. Not a Californian lab announcement. A boring European enterprise vendor deciding the workflow layer is where the money goes.

So the protocol war is over. MCP won the way HTTP won. Quietly, underneath everything.

The mass-market moment has not

Here is the part the breathless coverage skips.

None of this means your bookkeeper is about to assemble her own agents. The five big MCP directories between them list tens of thousands of servers, and not one of them is usable by a normal person. They are npm, not the App Store. Gartner, for its part, reckons only 17% of organisations have actually deployed agents, and predicts more than 40% of agentic projects will be cancelled by the end of 2027. They have a word for the rest: agent washing.

This is normal. Mosaic shipped in 1993. Mass web adoption took until the very end of that decade. What closed the gap was never the protocol. It was the curation on top: the ISPs, the bundled browser, the Yahoo home page, the App Store editorial team. The thing that made it usable for everyone arrived years after the thing that made it possible.

So your instinct is right if you feel like you are being sold a house by being handed a pile of manuals and a stack of timber. Nobody became a carpenter by owning the tools.

But that is precisely the argument for moving now, not against it.

Why the gap is the opportunity

The reason to jump on the train while it is still pulling out of the station is not that agents will run your company next quarter. It is that the experiments are cheap right now, and they will not stay cheap.

Think about what you are actually buying when you connect your company to an LLM today. The chance to find out whether your data is clean. Whether it is transparent. Whether it is machine-readable at all. Most company data, in my experience, is none of those things. It lives in inboxes and someone's head and a spreadsheet last touched in 2021.

Getting that data into reach of an agent forces you to confront all of it. That work pays off no matter what happens to any individual tool. Clean, structured, legible data is the asset. The agent is just the first thing that made you go and tidy it.

And the risk is more controllable than it looks. The depth of sharing is yours to set. Which systems get exposed and which stay behind the wall is yours to decide. Start with read-only access to one boring corner of the business and learn everything you need to.

Right now that experimentation is close to free. Your people can poke at it, find a venture you had not seen, analyse an opportunity nobody had time for. That permission slip costs almost nothing today. It will cost real budget the moment this stops being experimental and starts being procurement.

You do not have to build anything

The good news for a company under twenty people: the ecosystem is mature enough that you mostly do not have to build.

The services you already pay for probably already speak the protocol. Zapier exposes 9,000-plus apps and 40,000-plus actions through a single MCP endpoint. If you can set up a Zap, you can set this up. Microsoft made it generally available inside Copilot Studio. The vertical software your industry already runs on is shipping agent features that are MCP underneath, whether the brochure says so or not.

Connecting any of it to Claude or to your editor is genuinely copy and paste. One URL. That part is easy.

The hard part is not the wiring. It is the data. Gathering it, cleaning it, deciding what is safe to expose. That is the boring work, and it is the work that actually matters, and no vendor can do it for you.

There is no single VisiCalc this time

People keep waiting for the one app that flips everything. I do not think it arrives in that shape.

VisiCalc worked because the spreadsheet was one idea every business shared. Agents are not one idea. The thing MCP actually changes is subtler. It moves us off the chat box, the DOS-prompt of this era, and toward something different for each person: a tool, a small visual, a workflow that fits one employee's actual job. Your bookkeeper gets one surface. Your project lead gets another. Neither of them is typing into a blinking cursor.

That is the shift. Not one killer app, but the end of one-size interfaces.

At some point we will all have first-class models running inside the firewall, and the question of what you exposed and to whom will look quaint. But we are not there yet. Today the models live outside, the experiments are cheap, and the only thing standing between your company and the learning is the decision to start.

The protocol is laid. The train is at the platform. Getting your company on board is the one part nobody can do for you.

Sources

• MCP SDK downloads (97 million a month, March 2026) and registry server count: Anthropic's MCP anniversary report, via Toloka and MCP adoption statistics 2026, Digital Applied.
• MCP donated to the Linux Foundation under the Agentic AI Foundation (December 2025): Linux Foundation press release.
• SAP's investment in n8n and Joule Studio integration (Sapphire 2026): n8n's own announcement and heise online on the investment and valuation.
• Gartner on agent adoption (17% deployed) and the cancellation forecast (40%+ by end of 2027), plus "agent washing": Gartner press release and the 2026 Hype Cycle for Agentic AI.
• Zapier MCP (9,000-plus apps, 40,000-plus actions) and Microsoft Copilot Studio general availability: Microsoft Copilot blog.
• VisiCalc history, price, and sales: VisiCalc, Wikipedia.
• Mosaic and early web adoption: History of the web browser, Wikipedia.

Now I want to write the other half of that sentence.

Because here is what nobody tells you about an exoskeleton. The machine doesn't rest. It doesn't get tired. It doesn't lose the thread.

You do.

When you put on a piece of equipment that lets you work at three times your previous speed, what you are actually doing is compressing three days of cognitive load into one. The machine doesn't feel that. You do. And most of us don't have the wiring for it.

I'm learning this the slow way.

Two kinds of attention

Stephen and Rachel Kaplan spent decades working out why humans break down in environments that demand constant focus. Their Attention Restoration Theory, proposed in 1989, distinguishes between two kinds of attention.

Directed attention is the effortful kind you use at a screen. It filters, focuses, suppresses distraction. And it depletes.

Soft fascination is what nature does to you. The gentle noticing that happens when you watch a branch move or a dog sniff a patch of grass. It replenishes.

Marc Berman tested this at the University of Michigan in 2008. Participants completed a demanding memory task, then took a 50-minute walk. Half through an arboretum, half through downtown Ann Arbor. Nature walkers improved their working memory scores by roughly 20%. City walkers showed no improvement. The effect held even in Chicago winter. You don't have to enjoy the walk for it to work. Just be in nature, and the brain does the rest.

Meta-analyses since then have landed on a rough threshold: around 120 minutes of nature exposure per week is where the cognitive benefits consolidate. Two hours. That is it.

Two hours a week is the price of staying human at a screen.

Where the work gets metabolised

But here is the research I find even more interesting. Nature walks appear to shift the brain into a Default Mode Network-dominant state. That's the mode associated with mind-wandering, memory consolidation, and insight. Which means the walk isn't rest from the work.

It's where the work gets metabolised.

The connections I can't force at my desk arrive on their own, somewhere between the third tree and the fourth. The committee, Fimme and Sien and I call them. They're not giving me ideas. They're giving my brain permission to do the work it can't do while I'm looking at it.

I don't think I'd have understood any of this if I weren't running an AI-amplified workflow. When your output ceiling was bounded by how fast you could type, the asymmetry between work and rest was smaller. Now the ceiling is somewhere I can't see, and the only thing between me and burning out is whether I remember to be a person.

Fimme and Sien do not care that I can build a whole quarter's worth of automations before breakfast. What they want is to smell a specific tree. To notice a bird. In the most literal sense, they are uninterested in the exoskeleton.

That uninterest is the most useful feedback I get all day.

The tell

The honest description of this moment is that it's thrilling, and it's disorienting, and the two feelings are the same feeling. The research says two hours a week. My dogs say it's not optional. I am starting to believe they are both right.

The exoskeleton makes you fast. The walk makes you legible to yourself.

Tomorrow morning, same path. The committee will still be there. The coffee will go cold again. And somewhere between the third tree and the fourth, the work I couldn't finish at the desk will finish itself.

That's the tell.

🌈

This is the second of two field notes on the exoskeleton. The first, The Exoskeleton and the Morning Walk, is about what it gives you. This one is about what it takes.

That sounds dramatic. It isn't. It's the most practical thing I've learned about working on personal software.

A folder called recipe-scraper-v2 is a YAML file. A folder called Jauselbrett, the Austrian snack board that serves your recipes, is a character. And characters do something that filenames cannot: they earn the right to be missed.

A small confession

I have a Linear board full of dead projects. Not abandoned-in-shame dead. Honourably dead. Each one named, each one with a small story about why it existed and why it stopped.

I used to feel embarrassed by that graveyard. Now I think it's the point.

Side projects are the kind of work you do in the cracks. Sunday morning, an hour between dinner and bed, the train back from Berlin. You don't have the runway to be precious. Most of what you start, you won't finish. And the part that nobody warns you about: the unfinished ones still cost something. They sit in your head, half-built, asking quietly what happened.

A good name doesn't fix that. It just gives the asking a face.

The living

Here is some of what's named and alive on my machines this month:

• Blippström: the home automation umbrella. Mac Mini running Home Assistant, the whole house wired through it. The name is the sound a sensor makes when it triggers.
• Lichtspiel: a six-state house machine in Node-RED. Lichtspiel is the old German word for cinema, before Kino took over. The house has moods. The lights perform them.
• Hauswart: a small dashboard PWA on top of Home Assistant. Hauswart is what we'd call a janitor or building super, the patient person who knows where the fusebox is.
• Funkturm: a Swift menu bar app, bridges my Mac to MQTT. The Funkturm is Berlin's old broadcast tower. Everything is a signal going somewhere.
• Piepmatz: the bird camera, Frigate NVR with object detection. Piepmatz is what you'd say to a small bird in German, the way an English speaker says little birdie.
• Stolperfalle: an MCP server that captures the small painful lessons coding agents and I learn together, so we don't relearn them next month. I called it Stolperstein first, honestly just because it alliterated and it fit the German-word habit above. But in Berlin a Stolperstein is one of the brass stones set into the pavement outside the last home someone chose before the Nazis took them from it. I did not want a developer tool sitting on that word. A Stolperfalle is a trip hazard. That is all it is, and it is nearer the point anyway.
• Litfaßsäule: a service homepage that auto-discovers what's running in my self-hosted stack. A Litfaßsäule is one of those round advertising columns you still see on Berlin street corners.
• Besserwisser: my finance cockpit. Besserwisser is German for a know-it-all, the kind of person who corrects your pronunciation. I built a tool that does it to me about my money.

None of these would be alive in the same way if they were called home-assistant-config, node-red-flows, magic-mirror, mqtt-bridge, bird-cam, lesson-store, dashboard, finance-app.

I'd build them, sure. I wouldn't care about them.

The graveyard

This morning I closed BjörnAgain.

BjörnAgain was a pipeline I started a few months ago: a Swedish bear meets Abba, video distribution as a single funnel. Record once on Supercut, the system would download it, ask Claude to find the best 30-second clip, post the long version to YouTube, push a markdown post to the blog, send the short cut to Instagram Stories. The whole machine, named after a bear.

I never shipped past the Docker image.

The honest reason: I stopped wanting the thing the pipeline was for. The hours I'd have spent finishing it, I'd rather spend writing here. So this morning, in a Linear cleanup session, I closed BjörnAgain and its five subtasks. Canceled, not done. The graveyard accepts both, but they mean different things.

Jauselbrett had a different ending. It was meant to scrape recipes my partner sends me on Instagram, parse them, serve them up like a snack board. I named it on a Saturday afternoon, sketched the architecture, opened the repo. Then sat with the name for a week and realised it wasn't quite right. Jauselbrett described what the thing did. It didn't sound like the thing.

It's now called Børk.[^1] Same project, same scope, different character. Where Jauselbrett was a polite Austrian snack board, Børk is a Muppet in a chef's hat. The code feels different to write under that name. Lighter. Sillier. More finishable.

The graveyard takes names too, not just projects.

[^1]: Børk børk børk. The Swedish Chef finally won the naming round.

What the names actually do

Three things, once I started paying attention.

First: a name forces clarity before the first commit. If I can't find a name that fits, I don't actually know what I'm building yet. Jauselbrett clicked the moment I felt the metaphor (a board, small portions, served casually). The architecture followed in an afternoon.

Second: a name makes the boring parts easier. Naming the auth module of Blippström is more fun than naming the auth module of ha-stack. The boring middle of every side project goes on for months. You need every small joy you can find.

Third, and this is the one I keep coming back to: a name makes the ending honest. When I close BjörnAgain, I'm not closing a folder. I'm letting a small character go. There's a moment of yes, you served, thank you, that's enough. It's tiny. It costs nothing. But it leaves the rest of the work cleaner.

The pattern, if there is one

I notice I name in four languages: Swedish, German, Austrian, Dutch. Always something a German or Dutch speaker would smile at. Often the name predates the architecture. Always a small story I can tell in one sentence: what is this character and what does it do?

The names that work share something I don't think I could specify on a form. Concrete. Slightly absurd. Earnest enough to take seriously, not precious enough to defend. They sit somewhere between an Austrian snack board and a piece of Mr. Robot decor.

That's about all the rule I have.

I don't think any of this makes more side projects ship. I think it makes the ones that don't ship matter properly. Which is, maybe, the same thing.

I still believe that. But I want to come back to it with numbers, because the grief is warranted in a way I didn't fully understand three months ago.

Here is what the research shows.

The premise that held for a hundred years

Brooke Macnamara's meta-analysis of thousands of studies found that deliberate practice explains only 18% of the variance in sports performance. 21% in music. 26% in games. The 10,000-hour rule that Malcolm Gladwell made famous was always a misread of Anders Ericsson's work. Time was never the real bottleneck. It was just our best available proxy for something we couldn't quite name.

For decades we told a story about competence. Suffering is the price, the story said. You earn it the honest way, sitting with the material for long enough that it becomes part of you. Most of us organised our careers inside that premise. Some of us organised our self-worth around it.

Then 2023 happened.

The curve flattened from below

Brynjolfsson, Li and Raymond studied 5,172 customer support agents who'd been given a generative AI assistant. The study was published in the Quarterly Journal of Economics in 2025. Productivity went up 15% on average. But the gain wasn't evenly distributed. Less-experienced workers improved both speed and quality. Dramatically. The most experienced ones saw almost nothing.

The tool flattened the curve from below.

That is a very specific kind of sentence. Read it again.

Junior workers performed like seniors. Seniors performed like seniors. The gap collapsed. Thirty years of earned expertise was worth less than it was two years ago, and the people who had less to unlearn were moving fastest.

This is why the floor feels like it moved. Because it actually did. Measurably. In a peer-reviewed journal.

The adoption curve has no reference class

The St. Louis Fed reported last year that 40% of US adults used generative AI within two years of ChatGPT's release. Personal computers took three years to hit 20%. Smartphones took about the same.

There is no technology in modern economic history with an adoption curve that looks like this. We are all living through something for which we have no reference class, and the research is only just starting to catch up.

Dillon, Jaffe, Immorlica and Stanton published a six-month randomised field experiment in 2025. Six thousand knowledge workers across 56 large firms, half given Microsoft Copilot. The finding: gains happened, but only where workers were willing to rewire how they worked. The tool alone didn't help.

This is the quiet part most commentary misses. The AI isn't doing the work for you. It's changing what "doing the work" means. And that change lands differently depending on how much you've invested in the old meaning.

So what do you do with this?

If you spent your twenties and thirties accumulating the kind of knowledge that's now a prompt, the question is genuine and uncomfortable.

I don't have a clean answer. But three things are becoming clear to me.

First: the skills are repriced, not worthless. I spent years learning how to shape a digital transformation. That knowledge isn't gone. It's moved. The work now is having the taste to judge the output, and knowing which pieces to wire to which tool. Judgement is the bottleneck now, not memory. People with the deepest judgement are still winning. They're just not winning by carrying facts in their head.

Second: the people still insisting on the old rule — that you have to suffer to be worth something — are not going to win this argument. The Microsoft/HBS study is clear. Only the workers who accepted the new premise pulled ahead. The ones who treated the tool as a threat and worked around it saw no gains.

Third, and this is the part I keep coming back to: the honest thing to say is that most of us didn't earn the current advantage. We just showed up. We kept playing with the tools after most people stopped being curious. That's the whole story.

Which means I can't take credit the old way. But I also can't hide anymore. Everyone's excuse just expired.

Where this leaves us

The floor moved. Research says so. Macnamara's numbers say time was never the moat. Brynjolfsson's study says the curve flattened. The St. Louis Fed says adoption has no historical analog. Dillon's RCT says the tool rewards the willing, not the experienced.

And the only useful question now is whether you want to keep standing where it used to be.

🌈

The plate above is real. 1,467 commits, 2.29 million lines added, 71 repositories, four months in. By the cold logic of a GitHub year-in-review, I had a busy quarter.

I typed maybe a few hundred of those lines.

That's the part the dashboard doesn't tell you. Strip the vendored blobs from node-red-flows and WTDIB-v4 and the numbers slim down considerably. Across all buckets: 1,318 commits, +1.04M / -442K. The private bucket alone: 725 commits and net +432k. Strip the AI-generated scaffolding, the spec files, the regenerated TypeScript types, the migration boilerplate, and what's left is the part where a human had to actually decide something.

That's the only part that was ever the bottleneck.

The cycle that used to kill ideas

You know the one. I have a great idea, but I don't know where I'd find the time to validate it. So the idea sits in a notes app for eighteen months, gets occasionally re-read, and either dies quietly or gets shipped, badly, late, by someone with less context but more time.

I lived inside that cycle for a decade. Most of the people I respect still do.

What changed for me wasn't the ideas. The ideas were always there. What changed was that the cost of finding out whether an idea is any good dropped from "a month of evenings" to "a weekend." And once that cost drops far enough, you stop rationing. You stop deciding which ideas to validate. You just validate them.

That's the actual unlock. Not "AI writes code." Not "ten times faster." The boring, structural thing: the ratio between deciding and typing finally tipped in favor of deciding.

The ladder

The 71 repositories aren't 71 products. They're a ladder, and I climb it on purpose.

The bottom rung is for me. A handful of MCP servers that scratch my own itch, connecting Things, SiYuan, Lexware Office, Apple Notes to the same agent that's reading my email. Nothing fancy. The point of the bottom rung isn't the output. It's that I get to feel the rhythm of spec → generate → verify → archive on something where the only person I can disappoint is myself. Most of these took a weekend. A few took an afternoon. None of them are precious.

That's what makes them useful. I'm not learning to type faster. I'm learning to want more precisely. To notice when a spec is vague before I let a model run with it. To recognize when a feature I asked for is actually two features arguing with each other in a trenchcoat.

The middle rung is for people who'll tell me when it breaks. Børk is a tiny app I built for our household. My wife saves recipes on Instagram, the way everyone does, and they vanish into the algorithm two scrolls later. Børk catches them: pulls the post, parses out the ingredients and the method, drops them into a quietly beautiful database we'll still have when Instagram is a Wikipedia article. Forever recipes, ours, not rented from a feed.

Tiny. Domestic. Real users. Real stakes, in the small way that matters: if it breaks on a Thursday evening, dinner is the disagreement.

That feedback loop is the most valuable thing on the entire ladder. It's where you find out whether the spec was actually right, or just internally consistent. A spec can be perfectly self-consistent and still describe a thing nobody wants. The only way to find out is to put it in the hands of someone who isn't pretending to be polite.

The family rung also teaches you something the personal rung can't: how to ship for another mind. My usability tolerance is enormous, because I know how the thing works. Emma's isn't. That gap is where the actual product lives.

The top rung is for clients. Multi-tenant platforms. Enrichment engines. Custom MCP infrastructure for businesses that have to keep running on Tuesday morning. Same loop, just with more rigor at every step. More verification. More thought before each spec. More thought in general.

What I noticed somewhere around February is that the quality of the work I do at the top rung is downstream of how much time I spent on the bottom two. Not because I was practicing the typing. I'm not the one typing. I was practicing the deciding.

The shift

When you stop writing the code, you have to be much, much clearer about what you actually want. Vagueness used to be tolerable because typing slowed you down enough to think. Now it isn't. A bad spec gets implemented just as fast as a good one, which means the cost of not knowing what you want has skyrocketed.

This is the actual work now. Not typing. Deciding.

• Is this the right shape?
• Is this solving a problem I actually have, or one I imagined having?
• What does success look like, concretely, before I generate a single line?
• Who's going to use this, and on what day, in what mood?

Those questions used to get answered implicitly, in the slow accretion of typing. The lines themselves were a kind of thinking. You'd write something, see it was wrong, rewrite it, and in that process the shape would emerge. Now the lines emerge in seconds. The shape has to be there first.

It's harder than it sounds.

What this isn't

This isn't a productivity post. I'm not faster. I'm differently slow. The slow parts moved.

I spend more time staring at a blank document than I used to. More time writing out, in plain language, what a thing is supposed to do and why. More time arguing with myself about whether I actually need it. The 2.29 million lines aren't evidence of a sped-up me. They're evidence of a me who spent his time on the part that compounds.

It also isn't a flex. The headline number is mostly inflation: vendored dependencies, generated types, scaffolding I wouldn't read for fun. The few hundred lines I'm responsible for are the architecture decisions, the spec rewrites, the moments of "no, that's not the shape." Those are the only ones that ever determined whether any of this worked. The dashboard just makes the ratio visible.

The honest version of the headline

Two million lines, give or take. Mostly not by me.

The few hundred I'm responsible for are the ones that mattered. They always were. What's different now is that the friction between deciding and shipping has gotten thin enough that I can afford to be wrong, in public, on a Saturday, and try again on Sunday.

So. What's the idea you've been carrying for eighteen months? 🌈

This piece was written with AI assistance. The thinking is mine; the typing is shared.

Die Plate oben ist echt. 1.467 Commits, 2,29 Millionen Zeilen hinzugefügt, 71 Repositories, vier Monate. Nach der kalten Logik eines GitHub-Jahresrückblicks war das ein produktives Quartal.

Vielleicht ein paar hundert dieser Zeilen habe ich getippt.

Das sagt einem das Dashboard nicht. Zieh die generierten Blobs aus node-red-flows und WTDIB-v4 ab, und die Zahlen werden deutlich schlanker. Über alle Buckets: 1.318 Commits, +1,04M / -442K. Allein der private Bucket: 725 Commits und netto +432k. Zieh das KI-generierte Scaffolding ab, die Spec-Dateien, die regenerierten TypeScript-Typen, das Migrations-Boilerplate, und übrig bleibt der Teil, in dem ein Mensch tatsächlich etwas entscheiden musste.

Das war schon immer der einzige Engpass.

Der Kreislauf, der Ideen tötet

Du kennst ihn. Ich habe eine gute Idee, aber ich finde keine Zeit, sie zu validieren. Also liegt die Idee achtzehn Monate in einer Notes-App, wird gelegentlich nochmal gelesen, und stirbt entweder leise oder wird umgesetzt, schlecht, zu spät, von jemandem mit weniger Kontext und mehr Zeit.

In diesem Kreislauf habe ich ein Jahrzehnt gelebt. Die meisten Leute, die ich respektiere, leben da immer noch.

Was sich für mich geändert hat, waren nicht die Ideen. Die waren immer da. Was sich geändert hat: die Kosten dafür herauszufinden, ob eine Idee taugt, sind von "ein Monat Abende" auf "ein Wochenende" gefallen. Und sobald diese Kosten weit genug fallen, hörst du auf zu rationieren. Du hörst auf zu entscheiden, welche Ideen du validierst. Du validierst sie einfach.

Das ist das eigentliche Geschenk. Nicht "KI schreibt Code". Nicht "zehnmal schneller". Die langweilige, strukturelle Sache: das Verhältnis zwischen entscheiden und tippen hat endlich zugunsten des Entscheidens gekippt.

Die Leiter

Die 71 Repositories sind keine 71 Produkte. Sie sind eine Leiter, und ich klettere sie absichtlich.

Die unterste Sprosse ist für mich. Eine Handvoll MCP-Server, die meinen eigenen Juckreiz kratzen, die Things, SiYuan, Lexware Office und Apple Notes mit demselben Agent verbinden, der gerade meine E-Mails liest. Nichts Aufregendes. Der Sinn der untersten Sprosse ist nicht das Ergebnis. Es ist, dass ich den Rhythmus von spec → generate → verify → archive an etwas spüren darf, bei dem ich nur mich selbst enttäuschen kann. Die meisten brauchten ein Wochenende. Ein paar einen Nachmittag. Keines davon ist heilig.

Genau das macht sie nützlich. Ich lerne nicht, schneller zu tippen. Ich lerne, präziser zu wollen. Zu merken, wann eine Spec noch vage ist, bevor ich ein Modell darauf loslasse. Zu erkennen, wann ein Feature, das ich angefragt habe, eigentlich zwei Features sind, die im Trenchcoat miteinander streiten.

Die mittlere Sprosse ist für Leute, die mir sagen, wenn etwas kaputtgeht. Børk ist eine winzige App, die ich für unseren Haushalt gebaut habe. Meine Frau speichert Rezepte auf Instagram, wie alle das tun, und zwei Scrolls später sind sie im Algorithmus verschwunden. Børk fängt sie ab: zieht den Post, parst Zutaten und Zubereitung raus, und legt sie in eine still schöne Datenbank, die wir noch haben werden, wenn Instagram ein Wikipedia-Artikel ist. Ewige Rezepte, unsere, nicht von einem Feed gemietet.

Klein. Häuslich. Echte Nutzer. Echte Stakes, in der kleinen Art, die zählt: wenn es Donnerstagabend kaputtgeht, ist das Abendessen die Diskussion.

Diese Feedback-Schleife ist das Wertvollste auf der ganzen Leiter. Hier findet man heraus, ob die Spec wirklich richtig war, oder nur in sich konsistent. Eine Spec kann perfekt in sich konsistent sein und trotzdem etwas beschreiben, das niemand will. Der einzige Weg, das herauszufinden, ist, sie jemandem in die Hand zu geben, der nicht so tut, als wäre er höflich.

Die Familien-Sprosse lehrt einen auch etwas, was die persönliche nicht kann: wie man für einen anderen Kopf baut. Meine Toleranz für schlechte Usability ist riesig, weil ich weiß, wie das Ding funktioniert. Emmas ist es nicht. In dieser Lücke wohnt das eigentliche Produkt.

Die oberste Sprosse ist für Kunden. Multi-Tenant-Plattformen. Anreicherungs-Engines. Maßgeschneiderte MCP-Infrastruktur für Unternehmen, die am Dienstagmorgen weiterlaufen müssen. Dieselbe Schleife, nur mit mehr Strenge an jedem Schritt. Mehr Verifikation. Mehr Nachdenken vor jeder Spec. Mehr Nachdenken überhaupt.

Was mir irgendwann im Februar aufgefallen ist: die Qualität der Arbeit, die ich auf der obersten Sprosse mache, hängt direkt davon ab, wie viel Zeit ich auf den unteren beiden verbracht habe. Nicht weil ich das Tippen geübt hätte. Ich tippe ja nicht. Ich habe das Entscheiden geübt.

Die Verschiebung

Wenn du aufhörst, den Code zu schreiben, musst du viel, viel klarer sein, was du eigentlich willst. Vagheit war früher tolerierbar, weil das Tippen dich genug verlangsamt hat, um zu denken. Jetzt nicht mehr. Eine schlechte Spec wird genauso schnell umgesetzt wie eine gute, was bedeutet: die Kosten dafür, nicht zu wissen, was du willst, sind explodiert.

Das ist die eigentliche Arbeit jetzt. Nicht Tippen. Entscheiden.

• Ist das die richtige Form?
• Löse ich ein Problem, das ich tatsächlich habe, oder eines, von dem ich mir einbilde, es zu haben?
• Wie sieht Erfolg konkret aus, bevor ich eine einzige Zeile generiere?
• Wer wird das nutzen, an welchem Tag, in welcher Stimmung?

Diese Fragen wurden früher implizit beantwortet, in der langsamen Anhäufung des Tippens. Die Zeilen selbst waren eine Form des Denkens. Du hast etwas geschrieben, gesehen, dass es falsch war, neu geschrieben, und in diesem Prozess kam die Form heraus. Jetzt entstehen die Zeilen in Sekunden. Die Form muss vorher da sein.

Schwerer als es klingt.

Was das nicht ist

Das ist kein Produktivitätspost. Ich bin nicht schneller. Ich bin anders langsam. Die langsamen Stellen sind woanders hingewandert.

Ich starre länger auf ein leeres Dokument als früher. Ich schreibe länger aus, in Klartext, was ein Ding tun soll und warum. Ich streite länger mit mir selbst darüber, ob ich es überhaupt brauche. Die 2,29 Millionen Zeilen sind kein Beweis für ein beschleunigtes Ich. Sie sind ein Beweis für ein Ich, das seine Zeit auf den Teil verwendet hat, der sich aufzinst.

Es ist auch kein Flex. Die Schlagzeile ist größtenteils Inflation: gevendorte Abhängigkeiten, generierte Typen, Scaffolding, das ich nicht zum Spaß lesen würde. Die paar hundert Zeilen, für die ich verantwortlich bin, sind die Architekturentscheidungen, die Spec-Umschreibungen, die Momente von "nein, das ist nicht die Form". Das sind die einzigen, die je entschieden haben, ob irgendwas davon funktioniert hat. Das Dashboard macht das Verhältnis nur sichtbar.

Die ehrliche Version der Schlagzeile

Zwei Millionen Zeilen, plus minus. Größtenteils nicht von mir.

Die paar hundert, für die ich verantwortlich bin, sind die, die zählten. Sie waren es immer. Was anders ist: die Reibung zwischen entscheiden und ausliefern ist dünn genug geworden, dass ich mir leisten kann, am Samstag öffentlich falsch zu liegen und es am Sonntag nochmal zu versuchen.

Also. Welche Idee trägst du seit achtzehn Monaten mit dir rum? 🌈

Dieser Text entstand mit KI-Unterstützung. Das Denken ist von mir; das Tippen ist geteilt.

So I did what I do. I started a conversation. This time with Claude. What followed was one of the more honest exchanges I've had about why I, why we, build the way we do.

Why complexity?

I opened with a question I'd been circling for a while:

Why do I choose complexity and complicated projects over keeping it simple and accepting that 80% is also enough?

It might not be a bug. It might be your wiring. You're a systems thinker who genuinely enjoys architecture. The complexity isn't the cost, it's partly the reward. That's fine to own, but it helps to see it clearly.

80% feels like leaving value on the table. When you can see the elegant full solution, shipping the rough one feels like technical debt you're choosing to take on. Except as a solo operator, the debt of not shipping at all is worse than the debt of shipping something imperfect.

Complexity is also a form of safety. If the spec isn't done, you don't have to face the market yet. A perfect spec can't get rejected by a prospect. A live product page can.

That last point landed. I pushed back. This felt too narrow, too tactical. Why do we, as human beings, crave complexity? Why do we prefer an overloaded backlog of ideas over sitting with nothing?

The relief complexity provides

Complexity is a defense against meaninglessness. An empty backlog means sitting with the question "what now?", and that question, if you let it breathe, quickly becomes "what for?" We fill the space because the space is uncomfortable. A full task board feels like purpose. An empty one feels like a void.

There's something deeply human here: we confuse activity with aliveness. When you're deep in a spec, connecting systems, naming things, seeing the architecture click, you feel sharp, capable, real. That's not fake. It's genuine creative flow. But it's also a reliable way to avoid the more terrifying state of just... being.

Buddhism calls this papañca: the mind's compulsive proliferation. Give it one idea and it builds a cathedral. Not because the cathedral is needed, but because building is what minds do. Stillness feels like death to a system that equates thinking with existing.

The real root? Uncertainty is intolerable to a pattern-seeking mind. A backlog of 224 items is stressful, but it's structured stress. It's a knowable problem. The alternative, admitting you don't know what matters most, that you might pick wrong, that's unstructured uncertainty. And that's far worse.

So the honest answer: you probably don't crave complexity. You crave the relief complexity provides from sitting with not-knowing.

Where does this come from?

I wanted to go deeper. Psychologically, where does this pattern originate? And why do people claim that sitting with the unknown is somehow better?

Developmentally, it starts early. As children we learn that doing things gets approval. Stillness is rarely rewarded. "Go do something useful" is a universal parenting reflex. So we internalize: my value is in my output. By adulthood this is so deeply wired it doesn't feel like a belief anymore. It feels like reality.

Ernest Becker's The Denial of Death argues that all human busyness is ultimately a terror management strategy. We build "immortality projects" to symbolically outlast our own mortality. Your universe of named, interconnected projects is a world you're authoring into existence. That's not pathological — it's deeply human. But it's worth seeing the engine underneath.

Then there's what psychologists call intolerance of uncertainty: a trait, not a disorder. Some minds experience ambiguity as genuinely threatening. The nervous system responds to "I don't know what to do next" the same way it responds to a physical threat: cortisol, restlessness, a drive to resolve. Building a spec resolves it. Naming a project resolves it. The relief is neurochemical, not just intellectual.

On sitting with it:

Every time you resolve the discomfort by adding a project, you reinforce the loop: uncertainty → anxiety → action → relief. The tolerance never builds. The threshold stays low. You need the next spec faster. The backlog grows not because you have more ideas, but because the window between "uncomfortable" and "must act" keeps shrinking.

Sitting with not-knowing teaches your nervous system that groundlessness is survivable. That you won't dissolve. Winnicott called this the capacity to be alone: not lonely, but genuinely unoccupied. He considered it one of the signs of psychological maturity.

When you act from the anxiety of not-knowing, you get anxiety-shaped decisions. Things that feel urgent, that promise structure, that relieve pressure. When you act after sitting with the not-knowing, you get clearer signal. The ideas that survive stillness are usually the ones that actually matter.

The invoice arrives

After 2.5 months of sustained flow, my system didn't choose to stop — it forced me to stop. And the emptiness that followed wasn't philosophical. It was physiological. Withdrawal. The dopamine hole after the signal cuts out.

The "what the fuck" feeling is actually the withdrawal. Literally. Sustained creative flow produces dopamine, norepinephrine, endorphins. When it stops abruptly, your brain is sitting in a neurochemical hole. The emptiness isn't philosophical in that moment. It's physiological. And then the mind rushes in to explain the emptiness, which makes it feel existential.

Everything in me wants to open the task board, pick up a spec, start naming something new. That impulse feels like motivation. But maybe it's the discomfort talking.

What I'm sitting with

I don't have a clean takeaway. That's kind of the point. The practice isn't about doing nothing permanently. It's about widening the space between the impulse and the action, so that when I do build next, it's chosen, not compulsive.

The ideas that survive stillness are the ones worth building. The rest were just the dopamine talking.

They built a custom CRM using AI-assisted development tools. Annual cost: roughly $1,200. Not a stripped-down version — the version they actually needed.

This isn't an isolated story. It's a pattern reshaping how businesses think about their tools.

The economics are new. The frustration isn't.

Every operations lead I talk to has the same story: they know exactly what their business needs, they've known for years, but the software doesn't do it. The last time they asked about custom development, someone quoted six figures and nine months. So they built workarounds. Spreadsheets became load-bearing infrastructure. People became the bridge between what software does and what the business requires.

That gap — between what you know you need and what you can actually get — has collapsed. GitHub reports that 46% of all code is now AI-generated. Developers complete tasks 55.8% faster with AI assistants. Y Combinator's CEO said it directly: "Ten engineers are delivering what used to take fifty to a hundred."

In practical terms: a functional prototype that would have cost six figures now takes days. A custom internal tool that would have required an engineering team now requires a clear specification and the right platform.

The specification is the product.

There's a concept called spec-driven development that captures this shift. GitHub's internal research puts it simply: "The specification becomes the primary artifact. Code is the last mile."

What this means for business: your domain knowledge — the processes you've refined over decades, the workarounds that reveal exactly what the software should do, the institutional memory that no consultant can replicate — that knowledge is now directly translatable into working software.

You don't need to code. You need to specify. And nobody specifies better than the person who's been doing the work.

The consultant trap is real — and expensive.

Seventy percent of digital transformation projects fail to meet their goals. Bain puts it at 88%. An estimated **$2.3 trillion** has been wasted globally on unsuccessful transformation programmes. SAP implementations for enterprises cost$5 million to $20 million and 55% exceed their budgets.

The pattern is familiar: consultancy arrives, runs workshops, produces strategy documents, recommends enterprise tools, oversees multi-year implementation, moves on. The organisation is left with something that sort of works, costs more than promised, and is already outdated.

No consultant should walk into your company, turn it upside down, and leave you poorer and more confused than before.

Fewer tools, connected intentionally.

The average organisation uses 112 SaaS applications. Wastes $21 million a year on unused licences. Accumulates seven new tools every month, most outside IT's oversight.

The alternative: deliberate simplicity. The right tools, connected the right way, serving proven processes. When nothing fits your specific need, you build it — quickly, cheaply, precisely. When an existing tool works, you keep it. The goal isn't transformation. The goal is getting your time back.

The person who knows the business best should direct what gets built. Not a consultant who arrived on Monday. Not a vendor whose roadmap ignores your reality. You. The people who built these processes over years know exactly what "good" looks like.

The economics have caught up. Software that works the way your business actually works. Days, not quarters. Thousands, not millions. Owned, not rented.

It goes something like this: "We've been running this process for fifteen years. We know exactly what works, exactly where it breaks, and exactly what we'd change if we could. But the software doesn't do that. And the last time we asked, someone quoted us six figures and nine months."

So they don't change it. They build workarounds. They maintain spreadsheets that have become load-bearing infrastructure. They hire people to bridge the gap between what the software does and what the business actually needs. Every year, the gap gets wider. The workaround gets more fragile.

I know this story because I've lived on both sides. I spent years inside the consulting machine — rooms where we'd map processes onto whiteboards, translate them into requirements documents, send them to development teams, wait months for a build, and watch the business outgrow it before it launched. A factory for producing expensive approximations of what someone needed six months ago.

That era is over. Not ending — over.

The economics of building have fundamentally changed.

The numbers that matter: GitHub reports that 46% of all code written by Copilot users is now AI-generated. In a controlled study, developers using AI assistants completed tasks 55.8% faster. Y Combinator's Winter 2025 batch — some of the most technically capable founders in the world — had 25% of startups with codebases that were 95% AI-generated. Their CEO said it plainly: "Ten engineers are delivering what used to take fifty to a hundred."

In practical terms: a startup called Atonom was paying $40,000 a year for Salesforce** for about 25-30 people. Their CRO looked at the actual functionality they were using and said, "This is crazy." They built a custom CRM using modern AI-assisted tools. **Annual cost: roughly$1,200. Not a stripped-down version. The version they actually needed.

This pattern is repeating everywhere. Klarna — a $46 billion company — eliminated roughly 1,200 SaaS services and replaced them with a combination of internal AI tools and targeted alternatives. Their AI customer service system replaced work that previously required 700 full-time employees, saving approximately$40 million annually.

These are large companies. But the shift is even more dramatic for small and mid-sized businesses. The average company with 50 employees spends over $200,000 a year on SaaS subscriptions. Most of that covers features nobody uses.

You don't need to code. You need to specify.

There's a concept gaining traction called spec-driven development. Thoughtworks defined it as a paradigm where "well-crafted software requirement specifications serve as prompts, aided by AI coding agents, to generate executable code." GitHub's internal research puts it more directly: "The specification becomes the primary artifact — the shared source of truth. Code is the last mile."

What that means for someone running a business: the most valuable thing you bring isn't technical knowledge. It's domain knowledge. You know your processes. You know where things break. You know what "good" looks like because you've been doing the work for years, sometimes decades.

That knowledge — the kind that lives in your head, in your team's muscle memory, in the workarounds you've built — that's the specification. The gap between "I know exactly what this should do" and "I have working software that does it" has collapsed from months to days. Sometimes hours.

Red Hat's technical team described it this way: "Humans craft the 'what' while setting 'how' guardrails." You write the specification in plain language. The AI generates the code. You review, adjust, iterate. No six-month procurement process. No 47-slide deck to justify the budget. No consultant who arrives on Monday, turns everything upside down, and leaves you poorer and more confused by Friday.

The consultant trap — and the way out.

Let me say something uncomfortable for someone in my line of work: 70% of digital transformation projects fail to meet their goals. That's McKinsey's number. Bain puts it higher: 88% don't achieve their original ambitions. Globally, an estimated $2.3 trillion has been wasted on unsuccessful digital transformation programmes.

The typical pattern: a large consultancy arrives, runs discovery workshops, produces a beautiful strategy document, recommends enterprise tools, oversees a multi-year implementation, and moves on. The organisation is left with a system that sort of does what was promised, takes years to see ROI, and is already behind by the time it launches.

SAP implementations for enterprises routinely cost $5 million to$20 million or more. Fifty-five percent exceed their budgets. These aren't edge cases. This is the system working as designed — designed for the vendor, not for you.

The alternative isn't to go without systems. It's to build exactly what you need, with the specificity that only you can provide, at a cost and timeline that would have seemed fictional three years ago.

Fewer tools, connected the right way.

The average organisation now uses 112 SaaS applications. Seven new ones enter the environment every month. Eighty-four percent of that spending sits outside IT's oversight. Companies aren't choosing these tools strategically — they're accumulating them reactively, solving yesterday's problem with tomorrow's subscription.

The philosophy we work from is deliberate simplicity. Not fewer tools for the sake of minimalism — the right tools, connected intentionally, serving the processes you've already proven work. When a tool doesn't exist for your specific need, you build it — quickly, cheaply, precisely. When an existing tool does the job, you keep it. The goal is never "transformation." The goal is getting your time back.

Because here's what I've learned after twelve years: the person who knows the business best should direct what gets built. Not a consultant who arrived on Monday. Not a vendor whose roadmap has nothing to do with your reality. You. The people who built these processes — you are the specification.

The economics have finally caught up. Software that works the way your business actually works. Built in days, not quarters. Costing thousands, not millions. Owned by you, not licensed to you.

Your time is sacred. Everything we build starts from that principle.

Eight posts, two longform articles, nine images — scheduled across six days. One conversation. One sitting. One person with a dog at their feet and a mug they forgot about.

Eighteen months ago that sentence would have needed a team. A strategist. A copywriter. A designer. Someone named Lars who knew how the CMS worked.

Now it needs a Tuesday.

The exoskeleton

I keep coming back to this word. Not tool. Not assistant. Exoskeleton.

A runner's blade doesn't give you new legs — it gives the legs you have a different relationship with the ground. That's what this actually feels like. Not replacement. Amplification.

Claude doesn't think for me. It lets me think out loud without losing the thread. Brand strategy, image generation, social scheduling, longform writing, campaign cross-referencing — one sitting. The context doesn't break.

The momentum doesn't die.

That's the part nobody talks about. It's not that AI is smart. It's that it's present. Quietly, patiently, relentlessly present.

(And yes — that's a strange thing to say about software.)

The morning walk

Every morning I walk Fimme and Sien through the fields outside Oberbarnim. The light changes. The path doesn't. Somewhere between the third and fourth tree — the ones I've started calling the committee — my mind loosens.

That's where the ideas land. Not at the desk.

Never at the desk.

The gap between "idea on the walk" and "thing that exists in the world" used to be enormous. Filled with logins, formatting, context-switching — the quiet death of momentum. The boring part that eats the good part.

Now the gap is a conversation. I come home, open Claude, and say: here's what I'm thinking. And we build it. Not metaphorically. Actually. The images get generated. The posts get written. The schedule gets set.

The coffee goes cold.

The quiet part

A trillion dollars evaporated from software stocks this month. I wrote about it — what it means for people who build, the end of the permission era, the quiet revolution happening on the floor while the boardroom debates slide 47.

But here's what I didn't put in those articles.

I'm living it. Not as a thought experiment. As a Tuesday.

I run a consultancy. Solo. Strategy, delivery, content, infrastructure, client work. No team. No marketing department. A dog who snores during video calls and an AI that remembers where we left off.

I'm not drowning. I'm building.

The messy honesty

There was a day in March where Claude made me cry.

Not from frustration — from recognition. The kind of moment where someone (something?) reflects your own thinking back at you so clearly that you realise you've been carrying it alone for years.

I don't fully know what to do with that. I don't think anyone does yet.

But I know this: the people writing hot takes about AI replacing humans? Missing the point. The people dismissing it as a toy? Also missing it. The truth is messier, more personal, and more human than either camp admits.

AI didn't give me superpowers. It gave me back my time.

And time — real, uninterrupted, momentum-preserving time — turns out to be the only resource that ever mattered.

Still walking

Tomorrow morning. Same path. The committee will still be there. Fimme will still try to eat something questionable. And somewhere between the third and the fourth tree, something will land.

The difference is: now I know what to do with it when I get home.

The coffee will go cold again. That's the tell.

🌈

I spent years inside the enterprise world — EY-level consulting, large organisations, systems that moved at geological speed and called it governance. When I saw those headlines, I didn't feel shock. I felt recognition. The spreadsheet was catching up to the feeling.

What actually happened

Atlassian reported its first-ever decline in enterprise seat counts. Workday cut 8.5% of its workforce. Monday.com announced it was replacing 100 SDRs with AI agents. Retool found that 35% of teams had already replaced at least one SaaS tool with a custom build. IDC predicts that by 2028, pure seat-based pricing will be obsolete.

But Jason Lemkin — founder of SaaStr — offered the nuance that matters: "This isn't the death of SaaS. It's the end of easy SaaS." He's right. Nobody is replacing their entire Salesforce instance with a weekend build. Shipping a v1 is maybe 2% of the work. The maintenance, integrations, and edge cases — that's where the real weight lives. SaaS is being starved, not killed.

The individual is winning anyway

MIT's Project NANDA found that 95% of enterprise AI pilots deliver zero measurable bottom-line impact. Meanwhile, 90% of workers in those same organisations already use personal AI tools daily. Not because IT approved it. Because the tools work.

Sam Altman has an actual betting pool with tech CEO friends for when a single person will run a billion-dollar company. The evidence is building: Pieter Levels runs a $3M+ ARR portfolio solo. Cursor reached$1B ARR with roughly 20 people. A single developer built Base44, hit 250,000 users, and sold to Wix for $80 million.

Y Combinator's Winter 2025 batch had 25% of startups with codebases that were 95% AI-generated. Their CEO said: "Ten engineers using vibe coding are delivering what used to take fifty to a hundred."

The real shift is philosophical

For decades, the implicit deal was: serious output requires serious infrastructure — teams, budgets, vendor stacks, governance models. That deal was true not because the work required it, but because the tools required it. The tools no longer require it.

Paul Graham wrote about "the decreasing importance of organisations." DHH runs 37signals with 70 people, profitable for 22 years, now integrating AI agents directly into Basecamp projects. A hundred brilliant people in ten small companies will outperform a thousand-person organisation — not because they work harder, but because they don't spend 80% of their energy on the overhead of being large.

You no longer need to be an enterprise to create enterprise-grade value. This trillion-dollar correction isn't a crisis for people who build. It's a market confession that the premium we paid for bigness was never really justified. The economics of building have changed so fundamentally that the old gatekeepers are still standing at the gate, wondering why nobody's asking for permission.

This isn't about technology. It's about who gets to decide. Who gets to build. Who gets to say: this is what I actually need, and I'm going to make it.

The age of asking permission is over.

"How do I know if we're ready?"

It usually comes from someone running a company of 15 to 80 people. They've heard the talks, read the articles, maybe even sat through a vendor pitch or two. They know something needs to change. But "ready" feels like a moving target — and the fear of investing in the wrong thing at the wrong time keeps them stuck.

After 12+ years of working with organisations from IKEA to small-town Fahrschulen, I've noticed something: readiness isn't about having the right technology. It's about recognising the right signals.

Here are five. If three or more sound familiar, you're not just ready — you're overdue.

1. Your team spends more than five hours a week on tasks a system could handle

This is the test that gives the article its name.

Pick any team member. Ask them to track, for one week, every task that involves copying data between systems, manually updating spreadsheets, sending reminder emails, or reformatting information that already exists somewhere else.

If the total is north of five hours, you're paying a skilled person to be a slow computer. That's not a people problem — it's a systems problem. And it's the most common pattern I see in Mittelstand companies.

At one logistics company I worked with, the operations lead was spending 11 hours a week — more than a full day — on manual data entry that three connected tools could have handled automatically.

2. New hires take weeks to become productive — and the knowledge lives in people's heads

When your onboarding process is "sit next to Sabine for two weeks and ask lots of questions," you have an invisible bottleneck.

Tribal knowledge is the silent killer of growth. It works beautifully at 10 people, starts creaking at 20, and actively blocks you at 40. The symptoms are subtle: inconsistent customer experiences, decisions that depend on who's in the office, and an unspoken anxiety about what happens when a key person leaves.

At ING, I saw how documented processes and shared tooling could turn a 6-week ramp-up into days. The tools don't have to be fancy — they just have to exist.

3. You've bought tools, but nobody really uses them

This one stings, because it usually means money already spent.

Someone bought a CRM. Or a project management tool. Or an automation platform. It was set up with good intentions, maybe even a training session. Six months later, half the team is back to email and Excel.

The problem is almost never the tool. It's that the tool was chosen before the process was understood. You automated chaos — and got automated chaos.

This is exactly the moment to stop: before the next tool purchase, understand what you're actually solving.

4. Your growth has hit a ceiling, but you can't explain why

Revenue plateaus don't always have obvious causes. Sometimes the product is great, the team is motivated, and the market is there — but something feels stuck.

Often, the ceiling is operational. You can't take on more clients because fulfillment can't scale. You can't expand to a new region because your processes are held together with duct tape and good intentions. You can't hire fast enough because nobody can train fast enough.

I've seen this pattern at Volkswagen (at scale) and at a 25-person agency (at human scale). The shape is the same: the business outgrew its operating system.

5. You're curious about AI, but every conversation ends with more questions than answers

This is the newest signal — and the most honest one.

You've read about ChatGPT, maybe tried it. You've been pitched AI solutions that promise the moon. But when you try to map it to your actual business, the gap between "what's possible" and "what's practical" feels enormous.

That gap isn't ignorance. It's wisdom. The companies that rush into AI without understanding their own processes first are the ones that waste the most money.

The smart move is to get clear on your current state first — what's manual, what's broken, what's working — and then ask where AI actually fits. Not as a magic wand, but as one tool among many.

So, three or more?

If you recognised yourself in three or more of these, the question isn't whether to act — it's where to start.

That's what a first conversation is for. Not a sales pitch, not a 200-slide deck. A few honest hours, and a prioritised plan you can act on.

Because "ready" doesn't mean "perfect." It means "clear-eyed about where you are and willing to take the next step."

And if you're reading this article to the end, you're probably already there.

Further reading

• Bitkom: Kleine Unternehmen zu oft planlos in der Digitalisierung — among German firms with 20 to 99 staff, only 21% have a company-wide digital strategy. 57% have one in single departments, 22% have none.
• KfW: Digitalisierung im Mittelstand — bringing in outside expertise favours adoption.
• xkcd: Is It Worth the Time? — The classic automation payoff chart. The math has changed.

The first one was white laminate. It came with the job — along with the badge, the lanyard, the open-plan hum, and a disposable coffee cup I replaced every morning without thinking. The chair was ergonomic. The monitor was fine. Everything was fine.

I sat at that desk for years. And at some point, I stopped noticing the fluorescent lights.

That's the part that scared me. Not the lights themselves — they were just lights. It was the not-noticing. The way an entire sensory environment had become invisible. The way I'd optimised myself into a shape that fit the furniture.

The second desk

The desk I sit at now is wood. Real wood — scratched, coffee-stained, with dog hair in places I'll never fully clean. There's a ceramic mug instead of a paper cup. A notebook I actually write in. The monitor shows a terminal more often than a pivot table.

And through the window: Brandenburg. Rolling green, quiet mornings, the kind of sky that makes you forget you're an hour from Berlin.

This desk wasn't part of a plan. I didn't have a five-year strategy or a launch date. There was no "excited to announce." Just a slow, stubborn process of rearranging the objects in my life until they started feeling like mine.

What actually changed

Here's what people get wrong about the corporate-to-independent story: they think it's about leaving. The dramatic exit. The "I quit" moment. The phoenix rising from the ashes.

It wasn't like that. Not for me.

The real shift was quieter. It was about ownership — and I don't mean the startup equity kind. I mean the "this is actually mine to shape" kind. The problems. The decisions. The morning rhythm. The way I spend Tuesday afternoons.

I still do deep product work. I still sit in architecture conversations, navigate the messy middle of building things that matter, make decisions that affect real users and real teams. The work didn't change. The relationship to the work changed.

Remote work gets talked about as a location thing — "work from anywhere." But the real gift isn't the where. It's the how much you own. When you're trusted with autonomy, when the people you work with care about outcomes more than hours logged, something shifts. You stop performing productivity and start actually being productive.

The space between

I'd be lying if I said both desks don't still exist at the same time.

Some mornings I catch myself in the old posture — the slight hunch, the reflexive email-checking, the fluorescent-light mode where you optimise for visibility instead of value. The corporate desk isn't a place. It's a pattern. And patterns don't disappear just because you change your address.

But the wooden desk is a pattern too. And it's one I chose.

There's a pencil holder that used to be a jam jar. Two dogs underneath — Fimme stretched out across my feet, Sien curled up on the rug behind me. The morning light hits the notebook around nine. By ten, I've usually written something I mean.

These aren't productivity hacks. They're the tiny, quiet details of a workspace that belongs to someone. To me.

Permission

The hardest part wasn't the logistics. It wasn't finding clients, or setting up the consultancy, or learning German tax law (though that last one came close). The hardest part was giving myself permission.

Permission to work differently. Permission to trust my own rhythm. Permission to believe that a desk in Brandenburg, with dog hair and coffee stains and a window that looks out over nothing important, could be the place where serious work happens.

We wait for permission a lot, I think. From managers, from markets, from some imagined version of professional legitimacy. We wait for someone to tell us that the way we want to work is valid.

No one tells you. You just start.

The desk you're sitting at

If your workspace still feels borrowed — if the chair is ergonomic but the decisions aren't yours, if the coffee is free but the mornings aren't — maybe the question isn't whether to leave.

Maybe the question is: what would a desk that's actually yours look like?

Not the fantasy version. Not the Instagram-ready minimalist setup. The real one. With the stains and the mess and the dogs and the light that comes in at the wrong angle but somehow makes everything better.

The phoenix isn't always fire and drama. Sometimes it's just a better desk, better light, and permission to do your best work. 🌈

"We're a mid-sized company. We don't have the budget of a Volkswagen or the tech team of a startup. We're behind on digitalisation, and we're falling further behind every day."

I've heard versions of this from Geschäftsführer in logistics, manufacturing, professional services, education. The tone ranges from resigned to panicked. And I understand where it comes from — the headlines are full of billion-euro AI investments and Silicon Valley unicorns.

But here's what I've learned after 12 years of working both sides of the fence — inside large enterprises like IKEA, ING, and Volkswagen, and with 20-person companies in Brandenburg:

The Mittelstand isn't behind. It's positioned better than it thinks.

The enterprise disadvantage nobody talks about

Let me tell you what "digital transformation" looks like inside a large corporation.

At one enterprise I worked with, a simple process change — moving from email-based approvals to a digital workflow — took 14 months. Not because the technology was complex. The tool was ready in a week. The remaining 13 months were spent on:

• Stakeholder alignment across 4 departments
• Security review and IT architecture approval
• Change management workshops
• Pilot rollout, feedback, revision, re-pilot
• Legal review of data handling implications
• Training materials in 3 languages

I'm not saying any of that was unnecessary. At scale, governance matters. But the point is: size creates friction. Every additional layer of organisation adds drag to every change.

A Mittelstand company with 30 employees can make the same decision in a meeting, implement it in a week, and iterate based on real feedback in a month.

That's not a weakness. That's a superpower.

Proximity to the problem

Here's something I noticed moving from corporate consulting to working with smaller companies: the person who feels the pain is often the person who can fix it.

In a large enterprise, the person who enters data manually into three systems sits five organisational layers away from the person who could approve a change. The signal has to travel up, get translated into a business case, compete with other priorities, get approved, get funded, get staffed, get managed.

In a Mittelstand company, that person often walks into the Geschäftsführer's office and says, "Hey, this is broken." And the Geschäftsführer can say, "Fix it. What do you need?"

That proximity — between problem, decision, and action — is enormously valuable. It means changes can be smaller, faster, and more precisely targeted. You don't need a "digital transformation programme." You need a series of smart, well-chosen improvements.

The tool landscape has caught up

Five years ago, the enterprise had a genuine advantage: they could afford SAP, Salesforce, custom development. Mid-sized companies were stuck with tools that were either too expensive or too simple.

That's no longer true.

The explosion of SaaS tools, low-code platforms, and AI-powered services has democratised capability. A 25-person company can now access:

• CRM systems at €50/month that rival what enterprises paid millions for
• Automation platforms that connect tools without writing code
• AI assistants that handle customer service, data analysis, and content creation
• Cloud infrastructure that scales from zero to whatever you need

The playing field hasn't just levelled — it's tilted. Because these tools are designed for smaller teams. They're faster to implement, easier to learn, and more forgiving of iteration.

When I consult with Mittelstand companies, the conversation isn't "you can't afford the tools." It's "you have too many options and need help choosing the right three."

The culture advantage

There's one more thing that doesn't show up in any framework but matters enormously: culture.

Mittelstand companies often have something enterprises spend millions trying to create: genuine team cohesion, shared purpose, and institutional trust. When the Geschäftsführer says "we're going to try something new," people don't reach for their change management playbook. They say "okay, let's see."

That willingness to try — without needing a 40-page business case first — is what makes digital change actually stick.

I saw this vividly at a Fahrschule I worked with. The owner decided to completely rebuild their booking system. In a corporate setting, that's a 6-month project with a steering committee. Here, it was a conversation, a decision, and a working system within days. The team adapted because they trusted the direction, and because the change was clearly in their interest.

The real gap isn't technology — it's clarity

If the tools are accessible, the culture is ready, and the proximity to problems is an advantage, why do so many Mittelstand companies feel behind?

Because they lack one thing: a clear picture of where they are and what to do next.

Not a 200-page digital strategy. Not an AI roadmap. Just honest answers to three questions:

1. Where are we losing time to manual work?
2. What tools do we have that we're not using well?
3. What's the single highest-impact change we could make in the next 30 days?

That clarity is worth more than any tool purchase. Because a clear direction means every euro you invest compounds, instead of scattering across disconnected experiments.

Rewriting the narrative

So here's the counter-narrative:

The Mittelstand isn't behind. It's unleashed — if it chooses to be.

You have the speed. You have the proximity. You have the tools. You have the culture.

What you need is the clarity to aim all of that in the right direction. And that's a much smaller gap to close than most people think.

The question isn't "can we compete with the big players on digital?"

The question is: "what would happen if we actually started?"

Further reading

• Bitkom: Kleine Unternehmen zu oft planlos in der Digitalisierung — of firms with 20 to 99 staff, 22% have no digital strategy and 57% have one only in single departments. Four in five lack a company-wide picture. The gap is clarity, not capability.
• KfW: Digitalisierung im Mittelstand — bringing in outside expertise favours adoption.
• Why Automation Feels Easier Than Ever (Beyond AI) — The ecosystem shift that makes all of this possible.

On my desk, there’s a photo I can’t unsee: a handful of hand-drawn mazes, coffee nearby, pencils scattered like tiny witnesses.

Some of the mazes are polite and clean.
One is aggressively scribbled over.
One “cheats,” with an arrow pointing straight through the border.

It’s a simple image — but it sums up my last year perfectly.

Because that’s how “AI” has felt in practice: not a single tool, but a messy table full of mazes. And the word AI feels too abstract now — a foggy label we slap on everything from autocomplete to “culture-fixing” chatbots.

So, to keep my sanity, I’ve started using my own vocabulary for the workflow:

The Runner. The Grid. The Countermeasures. The Trace.

The Runner

I stopped viewing it as a genius. Or a replacement for thinking.

Instead, I treat it like a Runner.

You dispatch it into the mess because it has quick feet and fast hands. It’s a bit reckless — but very useful when the clock is ticking.

A Runner brings options, not outcomes.

It tries routes and comes back with possibilities, but you’re still responsible for the result.

And if you’ve done any real work lately — coding, product decisions, negotiations — you know the maze isn’t on paper.

It’s in the system.

The Grid

The Grid is where everything connects: legacy code, shifting priorities, compliance rules… and that one service nobody touches because “it just works.”

The Grid isn’t evil.
It’s just dense.

This is where the Runner shines — provided you give it a job that fits its nature:

• “Here’s the error; give me three likely causes and how to verify them.”
• “Draft a script to convert these files (with logging and a dry-run mode).”

Sometimes it feels like magic. Not because it’s always true — but because it unblocks me.

But other times, the Runner builds new corridors I didn’t ask for.

Ten refactors. Five shiny libraries. Three new patterns.

Suddenly I’m not shipping — I’m exploring.

The Runner didn’t trap me on purpose. It just did what Runners do.

Countermeasures → The Trace

You can move fast… until you hit something that moves back.

In the Grid, “countermeasures” aren’t just security rules. They’re anything that punishes sloppy speed: confident hallucinations, subtle bias, privacy mistakes — or that copied snippet that becomes a production incident next week.

So I’ve learned a rule:

No run without a Trace.

The Trace is the boring part.
Proof, not vibes.

Tests. Logs. Citations. Examples. Tiny checkpoints that prove the Runner didn’t just sound right — it actually holds up when reality touches it.

Looking back at the maze

Looking back at that photo on my desk, I realise the work has changed.

Sometimes the Runner solves the maze.
Sometimes it creates the maze.
Sometimes it is the maze.

And the real work is learning how to navigate it.

I’m curious: when you dispatch your Runner… do you get an exit strategy — or a new habitat? 🌈

A thought experiment:

If you introduce AI in your company like a compliance topic — mandatory trainings, a bit of pressure, a bit of vague “transform or die” energy — what exactly do you expect people to learn?

Often they learn avoidance. Or cynicism. Or quiet, professional resistance.

And that response isn’t irrational. Research (and a little bit of history) suggests it’s… pretty normal.

Big shifts trigger big feelings — and AI is one of those rare topics that can spark excitement and alarm in the same meeting. In surveys, large parts of the public even describe themselves as more concerned than excited about AI’s growing role in daily life.12

The worries are also remarkably consistent across studies:

• job displacement
• loss of human creativity / “human touch”
• biased or untrustworthy outputs
• privacy and data leakage
• loss of control (over work, reputation, security) 3

What’s useful (especially if you lead teams) is this: it’s not just a rational risk list. It’s also an emotional change curve.

Two classic models are surprisingly good lenses here:

• Lewin’s Unfreeze → Change → Refreeze: people first have to let go of old assumptions, then live through a messy in-between, and only later does a new normal stabilize.4
• Kübler-Ross-style stages (borrowed from grief): denial, anger, bargaining, discouragement/depression, acceptance — with overlap, loops, and back-and-forth.5

So when your org feels “in flux” about AI, it might not be a failure.

It might be the process.

One framing that helps me: early resistance is often data. Not something to crush — something to listen to, because it points to what people need clarified before they’ll move: safety, ethics, bias, accountability, reskilling, and the boundaries of “allowed” experimentation.6

So the question becomes less “How do we roll out AI?” and more:

How do we help people move from threat → agency? How do we make room for fear without freezing progress? How do we avoid both extremes — doom and hype — and stay practical?

If you’re leading this topic in 2026, I’d love to hear: what’s the biggest friction in your org right now — data/privacy, output quality, or the human stuff nobody says out loud? 🌈

Read more

1. How Americans view AI and its impact on people and society — Pew Research Center (Sep 17, 2025). (Pew Research Center)
2. How people around the world view AI / concern vs. excitement across countries — Pew Research Center (Oct 15, 2025). (Pew Research Center)
3. Trust, attitudes and use of artificial intelligence (Global report) — KPMG (May 2025). (KPMG)
4. What is Lewin’s Change Theory? (Unfreeze–Change–Refreeze) — Prosci (Oct 1, 2024). (prosci.com)
5. Kübler-Ross Change Curve® (non-linear stages applied to change) — Elisabeth Kübler-Ross Foundation. (ekrfoundation.org)
6. Decoding resistance to change — Harvard Business Review (Apr 2009). (hbr.org)