One track: classic machine learning. The “old” hard core way of doing things. Just a couple of years, I went crazy when there way no application for ML in one of my clients’ product universes. But it was tough and hard core: training your own models, data engineering done the way it’s been done for ten years but deeper, better. A field with its own rigor, its own career paths, its own community. The other: vibe coding, context engineering, the full SDLC with agents in the loop. Autonomous pipelines. Local models running on a laptop at a level unimaginable 12 months ago.

All vanity o small differences away, this was one direction. The direction of zero doubt, seeing valid, high quality results from the work they are doing. Solving the puzzle that remains. But the clarity and the evidence that this world exist is clear and there is no doubt.

Just on example: At the social event on the first evening I ended up next to the CTO of a seventy-person company. Over the last year they’d completely pivoted from software for regulated industries like banking to building a harness for the full development lifecycle. Requirements, feedback loops, the whole thing. Supporting the AI based SDLC end to end. For builders, by builders. All in on the bet, which they don’t even see as that much of a bet.

He’d gone deep. Learned the new techniques properly, been surprised how well they work. Then moved on. Not as a convert. As someone who checked, found out they work, and got back to building.

As I said: just one example. But the whole conference was filled with examples like this. Small, medium, big companies already living that future.

Looking at my feed, though …

I’m not saying the feed is stupid. The concerns are based on legitimate concerns.

Ongoing IP lawsuits about training data — court decisions that will reshape what’s legally possible. Well, beyond lawsuits, there is obvious, ruthless IP theft! The carbon cost of large training runs is documented and significant. In some sectors, entry-level content work has already disappeared. AI-generated content is degrading parts of the information commons in ways that are hard to reverse. These problems are real life, with super high social impact. They can’t be ignored. They are happening. And of that we don’t “know” the direction.

And all of that comes with emotional baggage. People who spent years developing craft - writing, analysis, strategic thinking - are watching tools appear that can do a first raw draft of that work in seconds, ok minutes. A twenty-year career built on knowing something deeply can turn into a prompt. That’s not paranoia. It’s happening in real time..

The empirical claims of the loudest criticism are weaker, though, than research suggest. I read the research so you don’t have to. Brain rot memes - screenshots of study headlines, shared thousands of times. The lead researcher of the most-cited one said clearly: “we observed no brain rot”. These are memes, not findings.

On the main site documenting the research , the first FAQ item literally says the following:

”Is it safe to say that LLMs are, in essence, making us “dumber”?

No! Please do not use the words like “stupid”, “dumb”, “brain rot”, “harm”, “damage”, “brain damage”, “passivity”, “trimming” , “collapse” and so on. It does a huge disservice to this work, as we did not use this vocabulary in the paper, especially if you are a journalist reporting on it.”

So: careful with that axe, Eugene. The researchers say that because the memes and the superficial reporting are off.

Research on the impact o AI on creativity research is also worth looking at more carefully. There are two types of studies. 1) AI is increasing individual creativity but decreasing collective creativity (by lowing the entry hurdle). 2) AI is lowering individual creativity but raising diversity in collective creativity. The trick of the memesters is to always use the negative part of each sentence.

The most famous experiment for research direction 1) was that the same prompt for getting started with writing an essay was given to 300 people. the same prompt. To 300 people. And surprise: The results converged. The overall verdict was: each individual for themselves wrote better stories, but overall the stories got more similar.

That’s like handing 300 people a digital camera in front of the same landscape and being surprised that it’s easy to make a photo but that most photos roughly look alike.

Other studies look at creativity as a systemic process in which AI can have a role. In which case the entry barrier is lowered without lowering the ceiling.

Color (or later: digital photography) photography didn’t destroy photography. It changed the production process, changed what curation meant, and became its own art form. In hindsight all voices that warned of color photography were just wrong. Yes, a niche still favours black / white for individual taste, but there is no worse color art than black and white.

One of the most famous color photographers - William Eggleston - made an art of using color photography to depict the mundane as an object of art. Huge criticism in the beginning, now one of the most influential photographers of all times.

Lots of criticism is slop

Looking deeper into the criticism, you can read from the contributions that the people never experienced first hand the good results you can achieve by going beyond chatting with an AI. They didn’t do the hard work of context engineering - in engineering or more general knowledge work. It means they’re judging the technology from the slop - that obviously exists. If you don’t know how to work with these tools, the output is hollow and generic. That’s a fact. You might convince your doc with a first ok diagnosis of your symptoms.But that’s it. It’s not what the tools do at depth.

The people actually working with these tools aren’t debating whether they’re good or bad. They moved past that question months ago. They’re already asking the next questions: how far can local models go today in a high quality SDLC? What does the full SDLC look like when agents handle the loops? How do you supervise agents in production? What does judgment density look like when you’re not writing the code yourself?

In my calls with the people learning AI augmented product management and in general client calls, this comes up.

One participant, a product manager working through the course: “I’m somehow lost in the universe — what ist Product Management? What is it and what not? What is the thing I am able of that the machines can’t do? ” And then, a few minutes later, same conversation, higher abstraction level from a distance:: “That’s what we did all the time — how cool, that there’s now a tool that glues it all together”

A digital PM at a mid-size e-commerce company, someone who’d had Claude for data work for over a year: “In my Product-Management reality, it’s eye-opening. What you can now do with data - it’s a monster. Three years ago we had a Data Analyst in our team — but in practice that didn’t work half as good. Availability.”

A CPO managing several product teams, on the divide: “There are some, who really already work in a totally different mode. Since months, 3 or 4 months. Others — I don’t know if they ever did anything with Claude Code yet.”

while others yet in my feed make funny, not helpful jokes on tokenmaxxing as a first approach on getting people onto the tools, sheer adoption. Not citing when tokenmaxxing was already stopped because it did it’s duty

Two realities. The same industry. Sometimes the same company, the same org chart.

Inverse time arrow: from forward directed to backward directed

Something is historically strange about this moment.

Technology has always been the thing that directed the arrow of time forward. For better or worse. Easy in hindsight. if we lied it or not, the direction was always the same: forward. The Luddites weren’t ignorant, they were skilled craftsmen who understood exactly what the mechanised looms would do to their communities. They broke the machines anyway (for the best reasons) but - again, I we like it or not, lost anyway. The carriage industry understood the car. Taxi drivers understood Uber. In every case, the people whose livelihoods were threatened knew precisely what was coming and fought it and the arrow moved forward regardless.

The dissent always came from outside tech (simplification, sure) - from the people absorbing the costs, from communities being displaced, from regulators trying to catch up. The people building the technology believed in it. That was the structure of the argument.

Now something different is happening.

The people resisting - loudly, publicly, with manifestos - are not outside the industry. They’re inside it. They are, in many cases, the people who spent the last fifteen years evangelising change, embracing ambiguity, disrupting themselves. They were the apostles of forward. And now they are writing documents that say: stop. Protect. Don’t let this one through. And they feel like a majority.

That’s interesting and new. I think it comes from the fear that the arrow might be turning — that this is not just another wave of automation but something that touches what people understood to be genuinely defining who we are as humans. The writing, the reasoning, the judgment. The fear is probably also very rational. A lot of what defines us now becomes automated, replaced, displaced. It touches our human exceptionalism.

And the question of AGI - is this really human - is casually not helping but simply noise. The technology we have already automates a lot of what we felt human “good enough”.

Two manifestos, one braking with the past, the other protecting from a future

I keep coming back to two documents.

The Agile Manifesto — 2001. Seventeen people in a ski lodge in Utah. Four values, twelve principles. The document broke cleanly with what came before. Heavyweight process, documentation over working software, contract negotiation over people. The manifesto didn’t even argue. It simply pointed forward. It polarised. Maybe unthinkable today after all the watering down of whatever agile was in the beginning. But the polarisation was because it wanted to get rid of the past. People felt the old way of doing things was a waste of valuable life time. So it was perceived as a threat. A small niche pointed towards a future.

Enter The Makers Manifesto. It mentions leaning on the Agile Manifesto. But the direction is inversed. Where the Agile Manifesto was a break with the past, the Makers Manifesto protects the past from the (bad?) influence of the present or future. It lists things we should hold onto - craft, judgment, real understanding - against the threat of a new technology, the future. The argument is: don’t let this compromise your values, your work, what makes you you.

There are a million issues with the manifesto and I don’t want too much of a focus.

The main thing is: It wants to keep the present present. Things should not change so much. While the Agile manifesto said: here’s what’s next. The other says: hold your horses.

The name itself is another problem. A makers manifest that task exclusively about validating but no opening discovering. Which asks for validation through paying customers and thus probably excludes real makers working simply on open software or whatever.

It’s a really cool, legit Product Management manifesto in a very specific Horizon 1 scenario of Product Management. It does that well.

I only mention it becasue it signifies this moment. And I understand both impulses completely. The fear is real. The things being protected are real. And simultaneously, when I sit with a CPO whose team is splitting in half — some in a completely different mode for months, some who haven’t touched it once — I can see the gap opening faster than any conversation about protection can close it. And the gap is not helpful

Each organisation needs to cleary define their own future. You will not survive a divide for long. That the bubbles exist and are seemingly polarised is tough but you won’t survive it in your org.

Quality is not the bottleneck any longer, explainability is

Six months ago the question in my sessions was whether the output was any good. Now the quality is premium — the quality is better than expected, sometimes uncomfortably good. And that has created a different problem - in my life and bubble.

When I hand someone a finished output — a strategy analysis, critical assumptions about your market, a simulation of a workshop you haven’t run yet - the push back is because the analysis is too clear. Not because it’s wrong. It’s too uncomfortable without human translation layers and buffers. In knowledge work outside of coding. if you don’t watch it happen, you can not process the sense making. It’s as if you missed the meeting. How did you get there? Why should I believe this? You need to see the agents n discussion, discovering the verdict.

In a real workshop that doesn’t happen. People share in the room, argue, ight over wordings, yet and yet again. It’s part of the alignment. The outcome is theirs — even if a twenty-minute simulation would have reached the same conclusions. They saw it happen. If they gave one idea into the simulation, they own it.

I run simulations of strategy workshops before the actual sessions. The simulation is often sharper and faster than the human discussion. That’s not because humans are weak, it’s because the role of a workshop is not exclusively “thinking hard” but also “alignment”. Simply handing my agent output, of course, does not help. As a participant said: “Handing over the protocol of the simulation helps a lot, to follow the thinking.” Not just the result — the path to the result.

While it’s clear that this happens, it also shines a light on the other aspect: A huge function of us humans mangling wordings is emotional or sometimes vanity, not factual. It’s cool. It’s fine, but it is what it is.

Quality is fine. The hard part in 2026 is: how do you make results that nobody watched being produced feel like something people can stand behind?

Walking past the divide

I understand every protection instinct. I honestly do.

The concerns about IP, about ecology, about what happens to the people whose entry-level work has already disappeared, none of this gets resolved by building faster. They require political decisions, legal frameworks, redistribution of benefit. I’m welcome all of them.

And I understand the sense that the time arrow is turning. That for the first time, the technology feels like it could take the thing you thought was yours. That this is the matrix, the singularity. (Well, if it is, we have bigger problems anyway ;)

At the same time: I no longer have energy to spend on the question of whether this really works. If it’s really true that Boris Cherny works on loops that write the prompts, that he does not write the prompts for his agents anymore, while weeks ago the reckoning was that he does not look at the code and weeks before that, that he did not write any code by hand any longer. The CTO I met at the conference checked, found out it works, and got back to building. The people in my sessions who are four months in are operating in a different world from the people in the same company who haven’t started. The gap between those two groups is not closing on its own.

And I decided not to convince people on “how well this works”. Who wants to see it, learn it: welcome. Who doesn’t: great personal decision. I can’t argue against it. Who am I?

The open questions are: how do you build trust in outputs people didn’t watch being produced? How do you bring a team across when some are deep in and some haven’t started? How do you talk to a C-level who saw a demo and now thinks everything is trivial? How far can local models go?

As a company: define your future clearly and make it happen. Wherever in the spectrum you want to be. But don’t have it figured by your employees. The number one hint I have for you: Create that clarity and make it happen. The rest follows.

The other discussion, for a couple of months, had its place. I leave it behind.

• AI made writing code cheap and fast. Three feedback loops turn code into value — review, market measurement, customer absorption. Especially customer absorption does not get faster.

• We spent fifteen years building CI/CD to be able to ship a single line code change cheap and fast. Now we pump thousand-line, zero-cost changes through the same pipeline. The constraint moved from writing to reviewing, measuring, and being absorbed, but the pipeline is mostly unchanged.

• Small batches only ever helped wherever a loop was closed. CI/CD closed the technical loops; we rarely bothered with the market loop.

• The work is flow discipline, not a limit: build everything, but level the input to each loop (set up a stop light system), build many options and ship few (option storming), and limit customer-facing change to what you can measure and what customers can absorb.

• Mature teams measure the output into the loops that validate it. The rest ship because they can. Your choice.

Setup

Gladly, now the code arrives faster than I can read it. An agent writes in twenty minutes what used to take me a week. The eternal busy beaver, it gives me four thousand lines, and waits for me to approve them. 5 Features in 6 variants if I want: I can judge when it’s done. Don’t have to overthink if I even get started. Cool. We spent fifteen years making code creation cheaper. And getting the code done, was also what set the pace for everything before and after code creation.

The premise we built on for the last 20 years

Software is malleable in a way hardware is not. You can change it after it ships, cheaply, again and again. That property is the foundation under everything the product discipline learned and executed in the last twenty years.

As a consequence, in the physical part, we cut the metal, start the CNC, push the button on the expensive production line, after a correct design, mostly based on actual customer orders (i.e. the product OS already validated). Hardware most times has a solid economic, validated model, before the production is started. Software, though, is mostly built on assumptions and ideas - about what users need, about what will work, about what will pay for itself. And those assumptions are not known to be true when the work starts. They have to be checked. (Except in bespoke software, where actually the deal is to deliver after the correct order.) Difficult enough, but a different game. The rest of the software world is a different beast. A whole huge org from Marketing and Sales over R&D to Product Development trying to figure out what the strange animal, the customer, actually needs.

The check happens at two moments. First, before building. Code is expensive, in money and time, so it is worth asking how true an assumption is before betting on it. And, secondly, after release, to find out whether the thing we shipped really creates value for anyone, pays the bill, gets adopted, changes behavior, etc. Each check is a loop: do something, watch what happens, adjust, go again.

That’s what Eric Ries coded into Lean Startup’s “Build, Measure, Learn”, lean always more elegantly (and with more far reaching consequences) called the OODA loop. You get it.

The central lesson of that era was that smaller batches make all of this better - cleaner code, faster correction, better, more precise market signal. Each small batch ideally just one change, so when something changes you know why it had to be changed. And if it actually did (was there outcome to the output?). Despite all that knowledge, we mostly ignored the core requirement: even a tiny, small batch only helps if the loop around it exists and is closed. A small change without the measurement loop produces no learning.

While the two inner loops often got closed, even if only to monitor what these guys in IT do (the most probable reason why is much effort is spent on these loops), the third one was mostly ignored. It would also fall back on the higher deciders.

CI/CD closed the technical loops. The inner loop is the developer’s own cycle - edit, run, see the result - in seconds. The outer loop is the integration cycle - integrate, test, review, release - in hours. Continuous Integration automated the testing; Continuous Delivery automated the release. Running the loops became cheap enough that a single-line change was worth shipping on its own. Small batches paid off, and feedback on correctness came back fast.

Hold the thought: We spent the last ten to fifteen years, optimising for the smallest code change to be “free”, low cost, low impact. Lower transaction cost for small releases, so we can release the smallest changes.

The market loop, though, stayed open in most orgs. It is the slowest one - release, measure how customers behave, learn, adjust - over weeks and quarters. All lagging indicators. But required to replace the crystal ball. Some teams approached this with the occasional A/B test and / or a product-analytics tool like Pendo, and little more. Closing that loop is actually, genuinely hard. It takes tech, grit, patience and a lot of late gratification psychology vs the instant dopamine hit. So while we got very good at shipping small correct batches quickly, most of us remained really bad at knowing if and which were actually worth shipping.

What free code actually changed

Generated code is fast and nearly free. The step that used to be slow and expensive - writing the change - has collapsed and the little agent genies do it for us, remote controlled from the iPhone on the porch. The patience is waiting for Claude to come back from its work.

What we ignored is that this rises the batch size of production. An agent produces a large, coherent change in the time a person once spent on a small one. Production no longer paces itself to how fast a human can type, and that human pace had set the rhythm of the whole system for decades.

We spent ten or fifteen years building this pipeline for one purpose: to make a single small change cheap to ship. AI now pushes the same pipeline changes of a thousand lines at once, at no cost, and they run straight through the machine we built for the opposite problem. The infrastructure that was tuned for the smallest possible batch is now being hammered with the largest batch produced over night for free, and nothing in it complains: the checks go green, the deploys fire. The only thing that changed is the size of what flows through, and that stays invisible until it reaches a human. The human might suffer under the PR load as long as the infra job of adding a gazillion automated tests to that step is not done. At least to forces us to define what a PR actually is. But that’s the easy part, sorry to say.

So production got faster and the loops did not. Speed up one station and leave the rest alone, and the work piles up in front of the next one, which Goldratt described forty years ago. Speeding up one station relocates the constraint to the next one, and here it relocates to three places: review, measurement, market absorption.

Breakpoint 1: review

Changes now reach human review faster than humans can read them, and a person reviews at a fixed rate. And it’s supposed to be that way. Frontier AI augmented coding as per the Shapiro scale sees radical “productivity” increase from level three, which means “I don’t review my code at the line level”. Now, keeping the batches small and the number of reviews climbs until review, not production, caps the throughput - you have relocated the jam to the next stage: review. Making the batches big and each one affecting more code than a person can actually examine, means human review stops working and defects get through to production. Somewhere between those is a batch size that keeps the queue stable and review honest. It is larger than the small-batch optimum we are used to, and it is still bounded.

The way to raise that boundary, is the same thing that CI/CD made on deployment: automate the checking. Types, contracts, property-based tests, generated test cases - every tiny machine-checkable aspect that can be automated, takes the load off the human. Then the human can spends time checking intent - does the feature what it’s supposed to do, what we designed it to do, does the assumption hold at least locally - while the checker agents confirm correctness the lines in a gazillion of aspects. Building that infrastructure layer is the current post-AI version of the investment we made in deployment pipelines a decade ago. In parts, the old investment pays off, but we now add test infra on the micro / code level that was guaranteed by the human until now.

The second step is to stop fusing CI and CD. We always conflated them too often. When integration and release are the same thing, a change goes live the moment it is built. That was the art and we were actually proud of. Read what I mean by option storming later and you’ll see how dependent we are now on breaking the connection: There is judgement / filter after the CI step required. We can simply build too much and the customer has only a small max tolerance of change. Pull them apart and a change can be built, run, and inspected without reaching a single customer. That built-but-unreleased state is the check and decision point for everything downstream, and most of what follows depends on that filter.

Breakpoint 2: measurement

To say that a release caused a change in customer behavior, you need enough signal to separate it from noise. The sample you need grows with the inverse square of the effect you are trying to see. On a 10% baseline, detecting a 2% relative change takes roughly 350,000 observations per variant at ordinary confidence. Ron Kohavi did the work to show how few real experiments have any impact; most are underpowered and mislead, based on misleading assumptions, guesses.

How much traffic do you and what is the the number of changes you can measure with clear attribution in a quarter? The number is fixed, and often surprisingly small. Free code has no influence on that number. But the the number of changes you send to the customer rises - linear to your speedup factor. The gap between what you ship and what you can measure explodes. Everything you produce beyond what you can measure reaches customers with no way to attribute and measure the effect. So: zero learning. And now we’re back to judgement, opinion, taste, the very thing we wanted to get rid of for the last ten years. Now it’s used as the last line of defence against the AI. I doubt it. It gets decided by taste, or it ships and is never really evaluated.

You can test a built option against a model of the market before it ships - a simulation, a proxy metric, a panel reacting to the real artifact - and spend no live traffic doing it. That extends how much you can evaluate. So you save your handful of real experiments for the genuinely new bets, the ones a model of the market cannot predict.

Breakpoint 3: market absorption

The outer market loop, is the toughest one to handle. The hardest bottleneck. It’s beyond statistics. Metrics are coming in late and fuzzy, attribution is hard to find, little signal in all the noise. Customers accept change only up to a limit and that limit is also defined to the radically of change. Little changes with little impact are accepted easier and faster, are easier to measure. Bigger changes, the opposite. Hence a bias for smaller changes: easier to manage, easier to measure, we often do what’s easier to measure. Fundamental product changes can take years to show effect and until they can be reliably measured. You know that from your own experience when the CFO asks why the feature only shows revenue next year when it released this summer.

Take eBay as an example. The company had made auctions the definition of the product and marketed it as the real deal. Then they wanted the customer - all of a sudden and after amazon showed what’s possible with simply selling / buying stuff - to accept that the opposite “just buy on eBay” gets into customers brains. It then took years to convince people that fixed-price buying was also fine, and couple more years that the next level: classifieds also has a place nuder the same brand. There is no way that fast and free code would have made that faster. On that outer loop, faster code has close to zero impact.

Push customer-facing change faster than the base will take it and the excess returns as churn, support load, and disengagement, concentrated in your most habituated users - the ones whose established way of using the product you have just disturbed. Beyond the max absorption rate, one more release kills value even when the change itself is correct.

Consequence: Level the flow to the constraint

The fix for all three is the same: separate the rate at which you produce from the rate you deliver. Splitting CI and CD creates that filter. We always had it, we rarely used it, now it’s even more important. Functionality built but not released. It’s basic physics.

While AI increases the speed of code, it doesn't change the humans Macx acceptance rate. Goldratt’s Theory of Constraints predicts the consequence: the hardest bottleneck defines the throughput of the whole system. And speeding up anything but the bottleneck has no effect on the overall output. If the humans max acceptance rate, speeding uo code like crazy does not change that much. Funny - see the eBay example. Ten times faster code creation with review remaining at human speed, the constraint moves from writing to reviewing. Most amazement and AI investment today is focused on that single step. Output goes up, delivery does not.

Little’s Law predicts and measures the downside. Lead time equals work-in-progress divided by throughput. Generated code increases the work-in-progress in front of review; review throughput is fixed and human (until we did our infrastructure work); thus: the lead time of every feature climbs in proportion to the pile. More work in flight produces longer cycle times - a predicted result. And the pile is dead capital: code waiting to be reviewed for ages creates a mess on the next merge, and it will never see the day of light of the feedback loop that would tell you whether it was worth writing. No one would run the stamping press three times faster while the paint shop has reached its limit; no one has the idea to fill the factory with bodies that can’t be painted.

Toyota’s answer is heijunka - leveling. You enter work into the system at a smooth, even rate that matches the slowest step - the biggest bottleneck - instead of releasing it in the max spikes that upstream capacity can produce. The aim is flow time, not throughput, and the two are different goals. Queueing theory has shown for a century that driving utilization toward one hundred percent makes queues and cycle times grow without bound - a system loaded to the brim has the longest and least predictable lead times. Under uncertainty - and we probably agree on current uncertainty - learning rate trumps production volume. And learning rate is a function of flow time. So you deliberately hold slack and accept less than peak output in exchange for short, predictable flow.

This is where two famous flow ideas differ. Goldratt: exploit the constraint - never starve it, subordinate the rest of the system to it, get the most through it. True. But exploiting the constraint is not the same as maximizing demand you push at it. Instead, load the bottleneck to capacity and maximize the queue in front of it - protecting flow time. Feed the constraint steadily; do not flood it.

Leveling does not need to be a rigid and fixed, which always makes teams paranoid. It can be an event-driven, dynamic limit - a pull signal on the review queue. A stop light system. While the queue is clear, generation runs at full speed, no limit. As it fills, people stop starting new features and pick up a colleague’s review. When it crosses the threshold, everyone - including the fastest AI users - stops producing new code and swarms the backlog until it clears. Freed capacity is redirected to the constraint: into review, and into the automated checks that raise review throughput, rather than into more work-in-progress.

None of this means build less. Build everything the tools will produce. It tells you when building creates value and when it creates a mess. The discipline is about how output enters the system, not about capping it: level the input, and convert the speed the AI gives you into help at whatever step is currently binding. Thus maximise value created. Resist the instinct to keep everyone busy. An engineer idling for an hour is cheap in comparison to a feature stuck in a queue for three weeks. A fully utilized pipeline is slow, a traffic jam. Pushing mire traffic into is useless, actually diminishing value. Even cheap code pays off only as smooth flow to done; a clogged pipeline converts it straight back into waste.

We’ve all been there: The first “extended work bench expirements” had the same problem: who reviews the code form the new partner? Who guarantees quality until the new partners knows are quality system and boundaries? Now the partner sits in the same room and the name is Claude Code. Same challenge.

Option storming

But here something counter intuitive. For ages we never had enough developers to do everything we want to do. We had whole departments busy with overthinking: what of the million things we could will actually done by the engineering bottleneck? Choices, prior lists, changed prior lists, confusion about versions of prior lists? When can we trust the lists? Which is final.

What if we use the new capacity given us by the machine to stop overthinking and just do whatever. Whatever is in the scope of the product direction.

Then cheap building changes not only throughput but it fundamentally changes how to choose.

When code was expensive, you could afford to build only one version of a thing, so you chose it on paper, based on assumption, or better said: bias. No crystal ball, only intuition. Sometimes informed intuition. You ranked options in a document, argued the merits, and committed before even the first line was written. Selection happened upfront, against whatever forecast. Building all the options simply to see them was unaffordable.

When building is nearly free, you can stop choosing based on theory. You build several real versions of everything and judge the ones that seem to work better. After the fact. I call this option storming: instead of brainstorming options and betting on one, you generate a ton of options of everything and let the strongest survive. Judgment moves from before the build, on a spec, to after the build and before release, on the working thing. That’s fundamentally different than the old pre-judgment of “I have a better glimpse of the future than you”. Now it’s about. team having a look at the feature and validate if it is what we wanted and if it could do what we intended. If not: kill it now.

Hence the built-but-unreleased state. The options sit there at no cost to any customer, they don’t weigh against the max acceptance rate of the customer and you can compare them against each other, against your (AI-?)model of the market, against your guardrails. 90% get thrown away, and that is the point: only few make it beyond this point and earn it to weigh against the max acceptance rate of the customer. You drop the rest before they reach a user. Build many, ship few.

Boris Cherny has a whole system that feeds his agents: suggests from twitter, automated agents that fix bugs collected on GitHub threads, suggestions from colleagues. Why bother ranking, let the agents do the work, see what fits the products intent and keep those. Ignore the rest, kill them. With each o them he angered in a mother Claude Code terminal for 10 minutes. Why bother.

Option storming is the upside of free code. Putting things on their head is not often discussed, but you can copy it rom the masters. The win is a wider field of real created options, resting the final choice on visual evidence of the real thing rather than a vague, unfounded forecast. More output is incidental.

It’s like a mood board, but for real rather than “imagine this”.

What mature AI product development looks like

With all the old-school theory applied to the new world, we can actually say more and be more specific about AI augmented product development.

It lets production run flat out and embraces the cheap build.

It has option storming at the core. That’s the best way to leverage valuable developers that never had time, but now have it as they orchestrate the agents. building several versions of whatever might be in scope, deer judgment to after the build, keep this that work and kill those that obviously don't. learn the right threshold. Don’t judge early, based on specs.

It scales correctness with machine-checkable verification, human review is at the intent / feature level, away from code level.

It measures customer-facing change of the two market rates: what you can measure and what customers can absorb. It then uses a model of the market to validate what live date can’t afford to.

The old scholl version without thinking the new level field is: let the production rate set the release rate. Build because we can, release because we built it, see what happens, don’t close the market loop, don’t correct your model and trust your “product sense”, intuition, taste.

Your choice.

Both versions produce a ton of software. They differ in how explicit loops enable learning and that learning is formed into future knowledge.

The actual test

None of this is new economics. It relies on the batch-size logic Don Reinertsen (The Great!) wrote down years ago, and the TOC constraint logic Goldratt wrote down before him. We learned it once, encoded one of its answers - small batches, ship continuously - and slowly came to treat it as a law of nature rather than an answer to a question about cost. Free code changes the costs and the batch size and flow economics. The teams that understood why they were shipping small batches already will have no problem to find the new optimum. If you were excellent in having software flow, you’ll be fine. Else, it’s a great time to learn to leverage the new systems to max outcome. Orgs that never cared and remained mediocre will not understand what’s happening to them and how to fix it under the new constraints. They’ll watch the traffic jams in their systems amazed but without options to resolve them. Again: choices. But the traffic jams are much harder nor that the amount of code explodes. We all had time to learn, if the new constraints are not a trigger to learn now, what will be? Then, free code produces no value.

Technology made code creation free. The thinking required to turn that into value is still ours. The thinking was always our job.

In the next piece, to turn the volume to the max, I’ll sketch a set of AI models that help set up and manage the loops I described.

AI can’t do what we do because what we do is judgment, taste, the art of product.

Thinking about this deeply, the defense is actually an admission.

The scene: an experienced high quality PM tells me (and I concur) that autonomous agents in his work make no sense. Why? Because he needs to judge the results before he enters the meeting.

A developers code “simply” has “to work”, the PM has to convince.
To make sure that their software works, devs have built tools since decades that automate verification steps.

As PMs, meanwhile, we can’t make up our minds: If the boss comes with opinion, we counter “data driven, science”. Once AI comes around the corner with data, we counter with “judgment, taste, art”.

The metric that makes a PM a good AI augmented PM is not “I use a ton of skills” but “I can describe what good looks like” and “I can describe how things are connected”.

If we had done this for years, rather than declaring our role is so different, so much more than a glorified project manager, we would have already developed the tools that make us even better with AI. That’ll be the next step. Not trivial skills that “write some PRD”, “do some market research”. And some are already figuring it out.

The infrastructure devs built

Software developers spent sixty years codifying the standards for “good” out of human heads and into machinery. Type systems. Test suites. Schemas. Linters. Formatters. ArchUnit rules. Performance budgets. Bundle size guards. Pact contracts. SAST. CODEOWNERS. Feature flags. ADRs. SBOMs. Each describing a piece of what the senior engineer used to have on their in their mind, and now lets them hand it over to an agent. When an agent ships code, fourteen layers of codified standards do their work before a human opens the diff. The “taste” is in the machinery. While it hurts the old school engineer, the ones embracing the genie are thrilled.

Product management did the opposite. We kept it all in our heads. We never had a clear body of knowledge, we never had a clear education path, most of us transitioned into the role from the side. We rebuilt from scratch with each new team. The literature? Give me a break. Marty Cagan is more aspiration than description of what works. “Empowered. Transformed. Inspired”. Cool, aspirational, but hardly something that helps steer an agent. We invented frameworks that sounded like standards — JTBD, OST, RICE, ICE, OKRs — but they were vocabularies. A PRD can be written in perfect JTBD vocabulary and still be wrong. A schema check can’t be.

The same job. Twenty-five years of not doing it.

When a PM says AI can’t replace what we do because in the end all of it is judgement or taste, experience, probably 10% are. The other 90% are laziness.

→ Our standards were never written down.

→ They were never written down because we never made them rigorous enough to write down.

→ Only one or two people per team know them.

→ When they leave, the standard leaves.

→ When AI arrived, the standard couldn’t be handed over because there’s nothing to hand.

→ Therefore, AI can’t do what we do.

And while every word is true, every word is also an admission.

And, yes, while there is taste and judgement needed: How many people in the company need that taste and judgement?

Basically, product never decided if it wants to be art or science and we weasel around that decision and use whatever fits us. Now that bites us in the back.

The dev version of the same sentence, that AI can’t replace what we do, there’s an architectural piece, a correctness piece, a design piece, is backed by ArchUnit, the type system, the test suite, formal review. It’s based on systems and their boundaries. And, yes, of course, also developers feel sorrow over the lost value of 90% of their skills. But our “this can not be replaced” is based on no work and on no system. The moment we let Claude Code run over our context, it finds a ton of noise next to the signal and we spent a lot of time creating that noise. and most of it is vanity, not value.

Human exceptionalism as cover

We didn't write it down. So we pointed at the people who knew it. They became the brand. Judgment. Taste. Vision. Art.

The ethereal words work as the moral high ground because they can’t be checked. A standard that can be described can be checked and then enforced, automated, transferred, scaled, and held against the holder.

If you don't describe it, you can't be checked. You’re hiding.

Human exceptionalism in product management is basically the cover we’re hiding behind. You can’t audit us, because what we do isn’t auditable. The unauditable part is a fact about us, not about the work. The work is auditable. We never built the audit.

I call BS. So much of what we do can be checked. So many implicit decisions can be made explicit, are detectable by AI. So little of what we create is signal, so much is noise. And the AI is really good in figuring that out. Most of the noise is vanity, wording that does not matter and an excuse.

The cultural reflex

Software developers treat a lack of formal definition as a problem to solve. As Feynman says about social sciences, he would say about us: “They don’t do the hard work”. We don’t have a way to check this, let’s build one. That has brought progress to a thousand industries. It also makes us more repeatable. Hmm.

Product managers treat a lack of formal definition as evidence of cognitive superiority. You can’t check this, it’s judgment. That sentence has shipped careers forward, not much else.

The difference between the two disciplines is not tech but culture. Devs externalize and scale. They want to automate. PMs internalize and gatekeep. As long as the work was rare and slow, gatekeeping was a nice position be in. AI produces a hundred plausible artifacts a day. Gatekeeping doesn’t help any longer. The Mexican standoff between the disciplines that AI triggers, won’t allow for that “moat”. Devs never saw the value of esoteric, elitist PM talk. Their patience will get bigger. Will the product engineer come from the dev or the PM side? I guess both, but only those who embrace “describability”.

Every “we need judgment” sentence is an infrastructure question

There’s a translation available, and almost no PM team is using it.

“We need judgment about what a strong PRD looks like.” → A checklist, a worked-example library, a counter-example library, a schema-of-thought. It can be built in a quarter. A check against decisions, strategy, available tech, customer knowledge etc. None of that is abstract and none of that can not be described.

“We need taste about what counts as a real customer insight.” → A definition of evidence, a magnitude threshold, a recovery test (can the customer’s actual phrasing be reconstructed from the synthesis?), a rejection library. It can be built in a quarter.

“We need judgment about which strategic options to pursue.” → A set of forced explicit trade-offs, a reversibility classification, a pre-mortem template, a stakeholder-room simulator. Can be built in a quarter.

None of these need AI to be useful. But all of them make AI useful when it arrives. And they boost you, who made them describable. They make the team better in the meantime. They make the senior PM scalable instead of bottlenecked.

The ultimate PM skill therefore is not taste but to be able to describe what we hide behind taste.

The reason most teams haven’t built any of this isn’t that it can’t be built. It’s that building it would expose how much of the previous “judgment” was vagueness. Codifying a standard forces a team to find out it never agreed on it. Vagueness is comfortable. Standards are expensive. Most teams choose comfortable. Then they call the comfort taste.

To be concrete: My insanely great Marzocco machine is nit great because an esoteric PM has singular judgment and taste, but because the Marzocco has accumulated ca. a hundred patents that keep the temperature more constant than in other machines during brewing and a design language that is not esoteric but very well described. None of that is abstract taste. And if you talk to the people at Marzocco they might not tell you everything but they can describe every little bit that makes their machines unique. a Marzocco looks like art but is hard science and engineering.

The guild defense

The political content of the taste discourse in 2026 is straightforward.

PMs claiming taste, judgment, art against AI are mostly not protecting craft. They’re protecting their position as the only person in the room who knows what good looks like. AI threatens the monopoly, not the work.

A team with a codified PRD standard doesn’t need the senior PM in every PRD conversation. A team with a customer-insight rejection library doesn’t need the senior PM in every synthesis review. A team with a strategy-doc schema doesn’t need the senior PM as the single authority on whether a strategy doc is finished.

For the team (and for the company) that’s improvement and progress. For the discipline that’s improvement. For the individual whose career was based on being the gatekeeper and the bottleneck it isn’t.

The taste claim defends the gatekeeper, not the work and certainly not the product. AI doesn’t care about gatekeepers, which is why the defense becomes useless.

Stop claiming what you don’t have

The change is small and can be done now.

Stop saying “we need judgment” to protect yourself from what AI will bring along anyway. Start saying “we need a checklist for this artifact type that captures what we used to mean by judgment.” Build it. Check the agent’s output against it. Update it when the check misses things.

Devs externalized their judgment over decades until judgment was the test passed. That’s not a loss of taste. That’s taste codified. The senior engineer’s taste is written into the test suite, scaling to a thousand engineers and ten thousand agents.

We can do this. We have to. Others will do it without asking. It’s not that hard.

The reason it hasn’t been done is institutional, not technological. The institution preferred to be indispensable rather than scalable. AI made that preference unaffordable.

When Brian Chesky trusted “product” as a disciple and gave up after not seeing the results, that was a first sign of PMs not wearing clothes. It doesn’t matter that much if Brian Chesky was right in every detail. But AI will bring the verdict.

“We need judgment” is a confession. Treat it as one. Build the thing the confession admits we never built.

I discovered that thread went on X yesterday evening about the current vibe in San Francisco (see below)

The run down: Over five years, a group of maybe ten thousand people — employees at the AI labs, a handful of founders — crossed into retirement-level wealth. Everyone outside that group, including people with excellent, well-paying jobs, feels they could work their whole lives and never get close. Layoffs are running in parallel. Software engineers describe their life’s skill as suddenly worthless. Talk about a “permanent underclass” is normalised among younger people. Even the ones who made it sound hollow — one founder explains he won’t sell his company because then he’d “only have money,” while right now everyone wants to talk to him.

The thread ends on a note of genuine torment: Am I in the right place? Should I move? Is there time still left? Am I gonna make it?

What happened next was more interesting than the thread. The feedback split, fast and hard, into two camps. One side: this is absurd — these are champagne problems, it’s grotesque to feel bad about them. The other side: no, for these people it’s genuinely difficult, the suffering is real.

The thread really makes yo wonder what to make of it and I realised: most any response would have been wrong. All of my first intuitions would’ve been wrong.

Interesting, what both camps did. Both were looking for final judgment, a verdict, some truth. Confronted with that thread, the mind does what minds do — it scrambles to evaluate, find a pattern. Deserved or undeserved. Real suffering or fake suffering. What’s fake suffering for me might be real suffering when it hits you, etc. Winners and losers, scored.

I’d like to make the point that the verdict reflex is pointless. What the thread mirrors goes deeper. But to reveal that, let’s go deeper in the thread. Because: the best response in the thread didn’t take a side at all. It zoomed out.

The turn

The best reply didn’t argue at all about whether the suffering was legitimate. It said, roughly: this is what Heidegger called thrownness.

And that’s what characterizes what’s going on in many of us. We are trying to look for the verdict on who is behaving how in the AI craze. Hype! Enthusiastic! Blocking. Waiting! Overwhelmed (all of us!?). The fun point is, though: we are going through a collective moment of thrownness and the bewilderment that it causes in most of us.

You didn’t choose your starting conditions. You didn’t choose the year you graduated, or whether your college roommate happened to be starting a company in 2018, or whether you walked past the door of an AI lab in 2023 when it was open. The people outside that wealth circle aren’t failing. They’re experiencing what every human being always has — the radical contingency of life. The San Francisco Petri dish makes this unreal, very improbable throw of the fate that AI is, unusually visible. Most people never get that data. But now here, we are, these days we get it every day, in real time.

Heidegger’s answer, the reply went on, is authenticity. You don’t overcome thrownness. You own it. You stop measuring your throw against everyone else’s and you ask what you actually want to do from here.

I read that, then I went and looked up Heidegger’s original word and concept in German — Geworfenheit — because I was afraid that English flattens it. And it is so exactly to the point that I want to take it seriously and expand on it, first personally, then structurally. What is happening in that thread is happening to all of us. We have been thrown into this world, into this moment, and we did not get much of a vote.

Geworfenheit

The word comes from Being and Time, 1927. Heidegger’s claim is deceptively simple. To exist as a human being is to find yourself already underway — in a world, a body, a language, a family, a class, a historical moment — none of which you selected and none of which you were consulted about. You are, in his words and concept, thrown into the world. By the time you are able to ask “how did I get here?”, you are already here, shaped and in motion.

This is what he calls facticity. It’s not a / your failure. It’s not bad luck. It’s simply the basic condition. The “givens” of your life are not a verdict on you, because you weren’t in the room or even asked when they were assigned to you.

At the same time this means, and this is important: thrownness is not fatalism. Heidegger pairs thrownness with a twin concept — Der Entwurf, projection. To be thrown is also, always, to be throwing yourself forward. You are never just a product of your conditions; you are constantly relating to your possibilities, leaning into some future, interpreting what to do next. Thrownness without projection would be despair. Projection without thrownness would be a fantasy of the self-made person who chose everything. Real existence is both at once.

Which gives you a very precise division of labor. The options you have were not handed to you by merit. But what you do inside those options is entirely yours. Not partly. Entirely. That is the only thing that ever was.

In simple terms, The American Dream would be “your starting conditions" don’t matter” which is also expressed in the hustler’s “showing up is 80% of success”. While Heidegger would say “yes, for a few which were thron into the right starting conditions”. And the fatalist would say “why bother”, where I say: because inside your thrownness you have freedom and choice.

To give another very simple example: It is scientifically proven that the German education system has a specific hang for “thrownness” as it is pretty much stated that origin defines outcome to a large degree in the German school system.

I keep hearing the same sentence from people I work with, in different words. The skill set I spent fifteen years building lost most of its value in eighteen months. The 90/10 shock that Kent Beck formulated— ninety percent of what I was good at devalued, ten percent suddenly worth a fortune, and I don’t yet know which ten percent is mine. People with long, proud, hard-won professional histories. They are not lazy and they are not stupid. They were thrown. Behind all of our backs, the starting conditions are dealt / thrown again. The loom arrived. And the question they are actually asking — underneath the tooling questions — is what am I now?

The comparison is the herd

Notice the specific texture of the SF torment. It is not poverty. It is comparison. If I had joined that lab two years ago, I could retire. My roommate did. That person on my LinkedIn feed did. The pain is relational. It is the pain of holding your throw next to someone else’s and finding yours short.

Heidegger has a name for this too, and it is not flattering. He calls it das Man (the German “man”) — usually translated “the They,” or “the One.” It is the anonymous public self. The voice that says: this is what one does, this is what one should have, this is how one’s life should look by thirty. We mostly live inside “das Man” without realising it. We measure ourselves by a standard that belongs to no one and applies to everyone (depending on upbringing, probably), and we call the result an honest self-assessment.

It’s not. Measuring your own throw against the average throw is not an insight. It is the herd. “Comparison is the thief of joy” is the folk version of this; Heidegger gives it a structure and a diagnosis. The torment in that thread — am I gonna make it — is das “Man” asking a question on your behalf, in a voice youmigt think is your own.

You can see it everywhere. People scrolling LinkedIn with a low-grade nausea, watching the early movers, the ones who built a prototype on a train ride, the ones who already have agent systems running. Admiration laced with self-reproach: why didn’t I do that sooner — what does it say about me that I didn’t? That last clause is das “Man”. It converts a difference in throw into a verdict on your worth. It is doing this to you right now, probably, about something.

The opposite verdict is also happening. and it’s in teh form of one of the cheapest honeypots around currently: “I ams till thinking / writing / painting / doing myself. Agents will not come close to my thinking / writing / painting / doing”.

Angst is the doorway, not the disease

So the malaise — the frenetic, unsettled, can’t-focus feeling the thread describes, the exhaustion I hear from people who have gone through every emotional state with this technology, found it ridiculous then threatening then annoying then frightening — what is it exactly?

First instinct is to treat it as a problem to be solved. Manage it, medicate it, motivate it away.

Heidegger says something more useful. He distinguishes fear from Angst. Fear has an object — you fear a specific thing, a layoff, a deadline, a competitor. Angst has no object. It is the mood that comes over you when the whole familiar world goes quiet and slightly strange, and you sense, without being able to point at it, that the ground was never as solid as you treated it.

And here is his recommendation: Angst is not a malfunction. It is disclosive. It is the one mood that pulls you out of das “Man”, because das “Man” cannot answer it. But the herd has no comfort for groundlessness. Angst sets you in front of your own thrown, finite existence and says: this is yours, and no one else can live it for you.

The malaise is not the disease. It is the doorway. It is the moment the borrowed question — am I gonna make it — stops working, and your own question becomes audible underneath it. Most people, Heidegger says, never get to that question. They flee the Angst back into the herd. The frantic ones in that thread, doom-scrolling AI capabilities, “vibecoding their path to economic enlightenment” — that is the flight. Running back into das “Man” at high speed and calling it ambition.

Authenticity — Eigentlichkeit — is the alternative, and it is much smaller and less heroic than it sounds. It is not escaping your thrownness; you cannot. It is not reinventing yourself into a winner. It is one move: it is owning the throw. Taking the conditions you did not choose and saying these are mine to work with, and then asking the question das “Man” will never ask you — not “am I going to make it,” but “what do I actually want to do from here?”

That is the personal resolution. It is enough on its own. But it does not stay personal, because the thing producing the malaise is not personal.

AI is a thrownness machine

Now let’s step back from the San Francisco thread.

The mistake in the thread — the mistake in most of the takes about it — is to treat SF as exceptional. The unique gold-rush town, the warped bubble, the place where the divide is the worst anyone has seen. All true. But SF is not exceptional. It is just early. It’s the microcosm that mirrors us all.

The condition the thread describes — a skill set revalued overnight, a window that feels like it’s closing, real-time visibility into who got the better throw, winners / losers) a daily referendum on whether you are on the right side of history — that condition is not staying in San Francisco. AI is exporting it. To every knowledge worker, every consultant whose firm sells time and expertise, every design lead, every PM, every middle manager whose layer is being flattened for the “agentic era.” The layoffs are not a San Francisco story. The comparison feed is not a San Francisco story.

Here is the precise way to say it. AI did not make life more contingent. Life was always totally contingent — your birth, your decade, your openings, all thrown. What AI does is make the contingency impossible to ignore. It surfaces the throw. It takes the radical groundlessness that was always true and was always politely hidden by slow-moving careers and stable job categories, and it puts it on a screen, in public, in real time, updated daily.

AI is a thrownness machine. That is the structural fact. It is not destroying a stable world; it is revealing that the world was never stable, only slow. San Francisco simply put the spotlights on that existential issue first. Stakes and contrasts are simply higher there.

Stop scoring the throw

Which brings back the verdict reflex — the thing both feedback camps did — and lets me say what I actually think, and it is the part some people will not like.

Stop scoring the throw. Yours, and everyone else’s.

The person who joined an AI lab in 2023 was thrown. They will tell you it was vision and skill, and some of it was, and the decisive part was that the door was open when they walked past it and they were the kind of person, on that day, who walked through. Just that. The middle manager whose function is being hollowed out was thrown. The engineer whose craft devalued was thrown. And the Luddites were thrown.

Whan I mentioned the Luddites last week, I got interesting feedback. Do I mean their resistance was useless? And I was read as delivering a historical verdict: that what the Luddites did was wrong, that they were stupid to resist. No such edict from me, ever. I said one thing only: their resistance did not help them, and it did not stop the technology. That is not a judgment about their worth or their cause. It is a description of a throw. They were delivered into the arrival of the power loom exactly as involuntarily as a software engineer today was delivered into the arrival of the model. Judging the Luddites — heroes or fools — is none of my business and the same error as judging San Francisco’s winners and losers. It is the verdict reflex that people expect. But it’s neither required nor helpful.

“Tenure, intelligence, and hard work can be loosely correlated with outcomes.” That was a line from the thread, and a lot of weight is in the word loosely. In a normal decade, merit and effort track outcomes closely enough that the story “I earned this” and the story “I deserved better” both roughly correspond. In a transformation, they don’t. At all. The throw — the timing, the cohort, the open door — explains more of the variance than merit does. For a while. And that is causing the unsettling feeling.

Mentioning that sounds a bit cynical. It is the opposite. Cynicism is “it’s all luck, nothing matters, why try.” It’s not that. It is: the options are largely thrown, and what you do inside them is wholly yours, and confusing the two is what messes with people. With a lot of them, in fact, today. If you believe your outcome was pure merit, the first bad throw will break you. If you believe it was pure luck, you will never project at all. The accurate view — thrownness and projection, both, always — is the only one you can actually act from.

Caveat warning. The idea has a dark history and I don’t want to identify with it. Adorno spent a career attacking what he called the “jargon of authenticity” — the way Heidegger’s vocabulary watered down into a hollow badge people wore to feel deep, and worse, into a rhetoric of submission to fate and destiny. And he was right about it. So let me be exact about what I think authenticity is not. It is not about accepting your situation. It is not a doctrine of “everything is as it should be.” It is not a personality you perform. It is about one thing: owning your throw, refusing anyone’s verdict on it — including your own — and projecting from where you actually stand:

Deal with it

So here is the whole thing in one paragraph.

The thread about San Francisco made everyone ask for a verdict. The verdict was the mistake. The throw — who got rich, who got hollowed out, who moved early, who didn’t — was never the right thing to score. It was thrownness: the part of every life that was never up for a vote.

Personally, that means the situation is not your failure. It is Angst, and Angst is the doorway. It hands you back a question das “Man” stole from you: not whether you’ll make it, but what you want to do from here.

Structurally, it means AI is a thrownness machine. It is taking the contingency that was always total and making it visible to everyone, at the speed of a feed. San Francisco was just early, a test. The rest of us are being thrown into the same room now. All of us.

We were all thrown into the AI era. None of us chose the year. None of us were asked. The options were never in our hands — not which model arrives, not which skill keeps its value, not which door is open when we walk past it. What we do inside those options was always, entirely, ours.

Realizing this is not resignation. Resignation is about staying in the herd, scoring throws, asking the borrowed question. I am talking about the other thing. It is the only authentic position actually available — and, not incidentally, the only one that lets you do good work while everyone around you is still grading the throw.

We’re all collectively experiencing existential thrownness. Fine. Let’s deal with it. Make the best of it. Let’s not shrug. Well understood, without judgement, it is the whole answer.

The other day, I came across a LinkedIn post that asked a series of careful questions about AI’s economic future.

Examples: What if AI coding becomes so expensive that hiring humans is cheaper again? What if companies build products on unit economics that break when subsidised plans end? What if employees become so AI-dependent that their cognition atrophies? What if rising costs create a closed talent pool — only those already employed can afford to learn the technology?

The post ended: “No doomer. Just trying to understand risks better.”

I replied in a comment that the answers are unknowable in the formative years of any transformative technology — and that using unknowability as a reason not to act is itself a position. It doesn’t feel like a position. It feels like really smart. But it isn’t neutral, and it isn’t as safe as it assumes.

Let me break it down a bit.

Jevons’ Paradox and the cost fear

As a lot of people know, in 1865, the economist William Stanley Jevons observed something quite counterintuitive about the steam engine. As steam engines became through wider use and accessibility became more efficient, and thus requiring less coal to produce the same output, total coal consumption went up, not down.

That’s the paradoxical law: Efficiency makes a resource economically viable for more use cases. More use cases means more usage. More usage means more infrastructure investment. More infrastructure investment drives further efficiency and cost normalisation.

Jevons called this the rebound effect. We now call it Jevons’ Paradox, and it has held across nearly every resource-technology pairing since. (One discussion, of course currently is: Is AI breaking the matrix, is it the black swan, the ultimate discontinuity, the end game of all innovation that ends this law, e.g. because work becomes meaningless and thus only and finally we don’t have a clue at al what’s going on. As interesting as that may be: well - if we all die, we will all die, right? So that extreme is not that interesting to watch and think, ironically.)

Applied to AI: the fear that “AI coding will become too expensive” assumes a static economy. If AI coding becomes more efficient — which is the direction of every technology after adoption begins — it becomes viable for more use cases, which drives usage growth, which drives infrastructure investment, which normalises costs over time. This happened with computing, with cloud storage, with internet bandwidth. The cost concern gets the direction of travel backwards.

And if AI stays expensive? Then only the highest-value use cases survive, which is a market working as intended. That’s not a catastrophe. That’s selection.

Ultimately, beyond any of that detailed reasoning, take my prediction: Even if OpenAI and Anthropic will economically die, the tech will stay. So better get used to that.

The historical cascade

Let’s ask the same questions about other transformative technologies.

The printing press. Gutenberg, 1450. Did it have exclusively positive effects? No. It enabled mass propaganda, accelerated religious conflict, destabilised institutions that had held power for centuries. The Reformation was partly a printing press story. So were some of the bloodiest wars in European history. Was it society’s task to manage the consequences? Yes. Did we do it well or quickly? Libraries took centuries to build. Copyright law came 250 years later. Censorship battles are still ongoing. Did the negative effects and the incomplete management stop economic engagement? No. Books, newspapers, mass literacy, knowledge spread — unstoppable from the moment it started.

Electricity. The Current Wars between Edison and Tesla were a literal industrial battle over standards, involving deliberate electrocutions of animals in public demonstrations to discredit a competitor’s system. There were fires, deaths, monopoly battles, and decades of pollution from coal-powered generation that still hasn’t been fully resolved. Did society develop building codes, safety standards, grid regulation? Yes, imperfectly, over decades. Did it stop? No. Electricity reached into everything.

Cars and traffic. Approximately 1.35 million people die in road accidents every year globally. Urban air pollution from vehicle emissions remains a public health crisis. Entire city architectures were redesigned around the car at enormous social cost — displacement, inequality, lost public space. Seatbelts weren’t mandatory in most countries until the 1970s. Emissions standards came even later. The regulation has been partial and perpetually behind. Did that stop adoption? More cars exist today than at any point in history.

The pattern is consistent. Were the effects exclusively positive? Never. Is it society’s task to manage the downsides? Yes. Do we always manage it well? No. Does that stop economic engagement? No. Must the economy continue engaging? Yes. Can innovation be contained? No.

The problem with using the unknown as a brake

This is the flaw in “No doomer, just understanding risks.” (And no pun to the person written that LinkedIn post, we exchanged nice DMs afterwards.)

Using unknowability as a reason not to act looks like caution and insanely smart. It is a position — a bet that the unknown will stay unknown, that costs will stay high, that the higher-order value container won’t emerge. That is the speculative claim. Smart framing doesn’t change what it is.

But it’s worse than just being a losing bet. It’s self-defeating.

Consider the specific risks the LinkedIn post raised. Cognitive atrophy — employees who can’t function without AI. The protection against this isn’t avoidance. It’s learning how to work with AI without losing your own judgment. That knowledge is only available from inside the practice. You cannot develop it from outside.

Or the risk of a closed talent pool — only those already employed with AI access can develop competence. Waiting makes this worse, not better. The gap between those engaging and those abstaining compounds over time. Every month of “let me wait until I understand the risks better” is a month of compounding disadvantage.

Or the unit economics risk — products built on AI that become unviable if costs rise. The companies that will navigate this best are the ones deeply familiar with the technology, building the flexibility and optionality to respond. That knowledge isn’t available from the outside.

In every case: the risk you’re trying to avoid by waiting is made worse by the waiting. The protection against AI-related risk is not less AI experience. It’s more.

In more simple terms: even if you are “against” AI and want to avoid the risks, you better lean in t learn the etch. Else you have no chance to harness it responsibly.

What the historical examples actually teach us

Gutenberg didn’t give societies the option of not adopting the printing press. The societies that mattered — that shaped what came next — were the ones that engaged with it, understood it, built institutions around it, learned to manage it.

The same with electricity, with cars, with the internet.

The negative effects were real, obvious and simply can not be negated. They also can not be avoided fully. The societal management was and will always be imperfect. None of that is in dispute. But the question was never whether. It was always how. And “harm can be done” is used as a useless, helpless brake, simply signalling an assumed higher, better morale. Virtue signalling. No bit will touch my code. Have fun with that position in the real economy, outside of a tiny niche. Think vinyl: great for enthusiasts, but not a huge thing.

The “how”question is the only question available with AI.

Not: should we? That’s a done deal, like it or not. And it’s not a decision any individual or company makes, but it’s done by the same dynamics that made the printing press, electricity, and cars inevitable.

The question is how. How do you engage intelligently? How do you build knowledge that lets you influence the how-society-manages-this conversation, rather than watch it from outside? How do you size the bet appropriately as part of your life — staying in without betting the house?

Treating the unknown as a brake doesn’t give you safety. It gives you less information, less capability, and less influence over exactly the outcomes you’re worried about.

A defensible position

Treat it as a bet. It’s not recklessness — it’s accuracy. You are placing a bet either way. The question is whether you’re placing it consciously.

Size the bet relative to your capacity. You don’t bet everything on year one of any infrastructure wave. You stay in long enough to find what becomes possible — browsers didn’t exist before the internet; SaaS didn’t exist before cloud; the higher-order AI container hasn’t been found yet.

Build knowledge, not avoidance. The knowledge of how to work with this technology, how it fails, where it adds real value, where it creates new dependencies — that’s the only real protection against the risks being raised.

The Gutenberg option — opting out of the printing press — was never available to the societies that created what followed and build upon it (e.g. widespread education). The electricity option was never available. The car option was never available.

The AI option isn’t available either. The only question is how you engage with what’s already in motion.

Most of us and practitioners in companies right now are in exactly that phase with AI. They’ve got their setup dialed in. Custom instructions. A few skills. Everyone is heroic about them (“look at my skill!”). Maybe a structured Claude project or two. It works. They feel fast.

The most advanced build their agentic Chief Of Staff, even share it on github.

And then, at some point, we all hit the ceiling. It can’t go on like this. All of this needs to become shared, and we need the infrastructure to share it.

I see it in my AI-augmented PM course. Participants come in as individuals. They learn to work systematically with AI - on research, on strategy, on prioritization. By the end of the course, they ace it. All of them. Real progress.

But then all of them come up with the one realization: “I’m going to go back and be an island.”

And everyone in the room recognizes it. Immediately. In that moment.

Because the organization hasn’t moved yet. Teammates still work the old way. The AI doesn’t know what the product team decided last quarter. The marketing brief lives in someone’s head. Strategy exists as a slide that was shown once in an all-hands and never written down properly.

The individual got faster. The organization didn’t. Welcome to yesterday.

The problem is not exactly new

This is a human problem first problem - and it existed already without any AI.

(The objections you will read later on are also orthogonal to the topic of AI)

It’s simple: If you want someone to work in your direction — human or AI — you have to make sure they have your information. In a form they can actually use. That they understand. The implications of that are the same whether “someone” is a new hire, a contractor, or a model running in your SDLC pipeline.

For a human, we think it’s easier to patch the gaps. We are more resilient. But: Are we? Most suffering in companies exist because we are actually not.

Even for humans, then: You answer questions. You have context from two years of working together. A smart person infers the rest and adjusts. Organizations rely on this mechanism constantly. (This is also why so much context leaves the building every time someone quits.)

AI can’t do any of that. It needs the information written down. Precise. Accessible. In a form it can process and act on.

So when teams try to use AI at scale and it produces misaligned output — that’s usually not an AI problem. It’s an information problem that was already there. AI just stops pretending it doesn’t exist.

I’ve watched organizations that weren’t particularly process-oriented suddenly become very interested in structure and “standards”. Not because a consultant told them to. Because they saw what happened when AI finally had something solid to work with. The output difference is stark enough to make its own argument. If you get greedy on leveraging AI, you get greedy on process and standards.

On the upside, AI rewards organizational clarity. On the downside, it punishes confusion and unclarity with the same precision. It amplifies both directions.

Your room and the living room

There’s a mental model I keep coming back to, because it gets the dynamic exactly right.

Think of two spaces.

Your room is yours. You experiment . You try out a new AI setup, draft a positioning idea, play with a prompt, develop a heuristic. Nothing in your room is a commitment. It’s your sandbox. Working fast and dirty there is a feature, not a problem. Nobody should tell you how to arrange your own room.

And you need your room. You can not start thinking freely in the shared context. It’s teh same problem, I described in earlier posts: My brain freezes when I have to start on the developers command line. In the settled infrastructure. That’s for later. My room only carries my own constraints.

The living room is shared. It’s what everyone works from — the marketing team, the engineer, the product manager, the AI agent running in your pipeline. What’s in the living room is agreed upon. Truth. It’s the strategy that’s been decided, the brand tone that’s been validated, the technical constraints that are real. It’s the context your AI reads when it needs to work in the same direction as everyone else.

The asymmetry matters: what’s in your room is your business. What’s in the living room is everyone’s business. The living room has rules.

And there’s a process that defines how things move between your room and the living room. You don’t just dump your room into the living room when you’ve had an idea. Or don’t have your dirty, sweaty sports dress lying on the sofa in the living room. You try things. You discuss. When there’s actual agreement — not just “nobody objected” but real alignment — it gets committed to shared truth. That act of commitment is the moment where “I think we should do this” becomes “this is what we do now.”

Before the commit: your freedom. After the commit: your right to be heard when someone ignores it.

You want someone to follow your “truth” - or you even insist on it? - it’s your obligation to commit and explain and make sure it’s understood.

That distinction is the line of accountability. It’s simple. It scales across organizations of any size. And it works whether your “living room” is a Git repository, a well-maintained Confluence space, or something else — as long as it’s genuinely shared and genuinely up to date.

It is really simple. Rationally.

The friction - real and imagined

That’s the simple model. And I can already hear the objections — because I hear them every time this topic comes up. Last week at AI Camp Berlin it was the same. A lot of attention, a lot of friction. Three sessions from three people on the same topic. I’ll take that as evidence that something real is at stake.

The first wave of friction isn’t about tools. It’s about the model itself.

“Who keeps the living room? Who decides what goes in?” Reasonable question. The answer: the team does, together. Which means someone has to care. There’s usually one person per organization who takes this seriously — call them the guardian of the living room. Not an enforcer. Just someone who notices when the shared context is stale, contradictory, or missing, and does something about it.

“We already have Confluence and nobody reads it.” Yes. Because Confluence is a dump, not a living room. The difference isn’t the tool. It’s the discipline of keeping it current and the expectation that people actually use it. An unmaintained living room is just another room.

“You can’t expect this from the CEO.” I find this one interesting, because it conflates the tool with the ask. The ask isn’t “learn Git.” The ask is: if you want a hundred people — or a thousand — to work in your direction, you have to make your direction-giving documents available to them. That’s it.

“I told them in a meeting” stopped being a strategy before AI was here to stay. It just used to work better, because humans are good at patching gaps from memory and inference. AI can’t do that. The meeting wasn’t in the context. It might as well not have happened. The truth isn’t shared in the repo, then it does not exist. No way around it. Simple. Show me an alternative, if you don’t like it, modulo details.

What the infrastructure actually looks like

The living room needs content. Specifically: the context that any discipline might need from any other.

Strategy. Positioning. Tone guidelines. Technical constraints. User research findings. What “done” means for your specific product. Who the user actually is and what they struggle with. Each discipline maintains its own layer — product writes for engineers and AI, marketing writes for product and AI, design writes for everyone. Everyone reads everything. The AI reads everything.

The key question for any document: Does someone else — or an AI — need this to work in the same direction as me? If yes, it belongs in the living room. If it only helps you personally, it stays in your room.

But if your -hopefully - highly efficient, tuned up AI fed production machine needs the info, there’s now way not to enter it into the infra. You might as well throw the whole agentic acceleration out of the window.

In practice, it looks something like this:

Each discipline writes its own layer. All disciplines read all layers. The AI reads all layers. That’s the whole system. (Yes, I do know that skill under .claude are not organized in layers, take this sketch as conceptional, please, and let’s not dilute the discourse.)

Alongside the context, you share the tools. Custom skills, prompt patterns, agent configurations that the team has developed and validated. Not every experiment from every room — only the ones that have proven themselves worth sharing. The skill a PM built to synthesize research faster shouldn’t stay with that PM. But it shouldn’t go into the living room until it reliably works for others too.

The result, of course, compounds. Every discipline makes every other discipline’s AI work better. The marketing context helps the product AI. The engineering constraints help the design AI. Context shared deliberately is context that doesn’t have to be rediscovered from scratch every time someone starts a new conversation.

About those three Git commands

Talking about friction: The tool question always comes up eventually. “Not everyone can be expected to know Git.”

I find this argument strange — not because Git is trivial, but because of what we’ve already normalized. People in organizations manage password managers, VPN configurations, SSO setups, two-factor authentication, enterprise access control systems. Nobody says “you can’t expect a marketing manager to deal with SSO.” It’s just infrastructure. You learn it because it gives you access to what you need.

Three Git commands — commit, push, pull request — are genuinely less complex than the average enterprise access management workflow. And they give you a shared, versioned, auditable living room in return. That’s not a technical luxury.

But here’s the thing: not everyone has to do it themselves. Someone on the team can handle the mechanics. The CPO doesn’t have to run git push. They do have to write down the strategy. Those are different problems, and only one of them is actually hard.

Git is the human excuse. The real question is simpler and harder: do you want a real living room, or not?

The real unlock

The teams that figure this out don’t just get better AI output. They get a clearer organization. And they will ace execution and minimize exhaustion.

Because you can’t write a decent positioning.md or a shared product strategy document if you haven’t actually decided what your positioning or strategy is. The act of writing it down — clearly enough that an AI can act on it — forces the conversation that should have happened anyway.

That’s the forcing function.

Not “AI does the work.” Not “AI replaces the thinking.” Just: AI makes it very hard to keep pretending your organization is aligned when it isn’t.

If you’re a solo act right now — that’s fine. That’s where all of this starts. The ceiling is right before you, though, and you’ll hit it. The teams pulling ahead aren’t just better at prompting. They’ve figured out how to share context deliberately. How to make their work legible — to each other, and to the machines working alongside them.

That’s the next game now. Forget about the fog of “should we do this”.

And these days, he is one of the best devs driving AI use to the max and bing able to verbalise the change that’s happening. In one of my last posts, I looked into all the reports of how Boris Cherny and his team write software and came up with the term option storming. In the case of Simon Willis, it’s much easier to distill

• how he works,

• what it means for companies trying to get there and especially

• what learnings are hidden in this style of working for PMs.

If you like to study the sources, here is the whole video.

Simon Willison is not great at what he does now because he learned a couple of new tricks and hacks. he’s good because he knows what good looks like, and he basing his productivity on 25 years of pattern recognition, architectural taste, and engineering judgment he now throws at these tools. As he puts it: “Using coding agents well is taking every inch of my 25 years of experience as a software engineer.” Without that foundation, he’d be another mediocre AI engineer producing mediocre slop, just at higher speed.

That’s the first thing PMs need to understand. AI doesn’t replace expertise. It amplifies it. People getting the best results aren’t the ones who learned the newest tool first. They’re the ones who brought the deepest judgment to the table. Just like Simon is a good AI developer because he always was a good developer, those PMs will be great AI-PMs who know the trade. Sitting in front of Claude Code do augment your PM work, teh first rule to be successful with Claude’s output is: you have to know what good looks like, else all you produce is trash. But lots of it.

Now here’s what that means for us. A couple of topics and insights, transferred to our jobs.

Code is cheap. Not software. Code.

Writing code used to be the bottleneck. You’d hand a spec to engineering, wait three weeks if you were lucky. Same thing now - three hours, max. Simon : “Today, probably 95% of the code that I produce, I didn’t type it myself. I write so much of my code on my phone. I can get good work done walking the dog along the beach.”

But cheap code is not cheap software. Cheap code just moves the bottleneck. It moves it in two directions at once. That’s really basic Theory of Constraints.

Down into infrastructure: testing, quality, reliability, security. All the things that make code actually usable in production. Someone still needs to figure out if the thing works. If it’s safe. If it doesn’t break what you shipped last week.

And, secondly, up into decisions: what to build, why to build it, for whom, in what order. Taste. Judgment. Strategy. That’s PM territory. And it just became the scarcest resource in the room.

and that’s why you now need to understand how AI sped up coding works now. It changes the interfaces. It changes how handover and connection between product work and engineering work is happening. You need to understand how engineering works to be able to best leverage it. And this is now fundamentally changing.

“We’ve taken the writing code bit and we’ve massively accelerated that,” Simon says. “Now the bottlenecks are everywhere else.”

And we are part of that “everywhere else”.

Hint: While it is true that job descriptions become more polyvalent and generalist (or: M shaped people) will be in higher demand, and thus Product Management has the chance to go into more tactical and strategic directions at the same time, you should beware to try to become a paid designer, analyst and developer at the same time. The mental will become unbearable and we talk about that later in this article.

Option storming: prototype more, decide after

A major shift is that prototyping is now basically free and that changes the PM approach drastically.

Simon - his strong suit was always prototyping, now this is meaningless, not a differentiator anymore. He now prototypes three different ways a feature could work. Not one. Three. Because it costs almost nothing. Then he experiments, tries them, sees which sticks. “Any sort of feature that I want to design, I’ll often prototype three different ways it could work because that takes very little time.”

That’s the real core designer task: “Look at this, a little more in this direction, a little more of that?”

Think about what that does to how we make product decisions. We used to filter ideas early because building was expensive. We had to be right before we built. Our “intuition” was really just a filter born from scarcity. We killed ideas not because they were bad but because we couldn’t afford to try them.

Now we can afford to try them. All of them. So we need less filtering upfront and more judgment after the fact. Less predicting which idea will work and more recognizing which one does work when we see it running.

I call this option storming. Don’t pick the winner from a list. Build several. Watch them. Let the answer reveal itself.

“A UI prototype is free now,” Simon says. “Anyone who’s doing product design and isn’t vibe coding little prototypes is missing out on the most powerful boost.”

But at the same time, the complexity hits us a t a different stage: “You’ve got three options now instead of one. How do you prove to yourself which one of those is the best? I don’t have a confident answer to that.” His best guess? The old-fashioned way. Get a real human on Zoom, screen share, watch what happens. “You can tell the AI to simulate your users. I don’t think that’s credible.”

Intuition was always just bias mistaken for experience. Now you don’t need it as a filter anymore. You need it as a lens — to see what’s working → but only once you’ve built it.

A year of less focus, more learning

Simon’s New Year’s resolution of this year is different: “Every previous year, I’ve always told myself, this year I’m going to focus more. I’m going to take on less things. This year, my ambition was take on more stuff and be more ambitious.”

That’s counterintuitive. But it’s the right move when the landscape is shifting this fast. This is not a year for rigid plans and clean OKRs. This is a year for leaning into the tools, dealing with AI on the ground level, learning on the go. Not a ton of structure. More reps. More experiments. More surface area.

Because right now, the only universal skill is being able to roll with the changes. And that’s valid beyond Simon. Have fun planning focus this year.

This is draining. That matters.

The dark side of the new game:

“I can fire up four agents in parallel and have them work on four different problems. By 11am, I am wiped out for the day.”

Simon Willison. One of the most productive engineers alive. Wiped out by 11am. And he’s not alone. Steve Yegge, one of the other AI coding wizards, discovering all the new technologies, called it the AI Vampire effect.

AI is supposed to make us more productive. Give us more time. Let us sit around. Delegate Admin and focus on what matters, what makes us human. Instead, the people most into AI are working harder than they’ve ever worked. There’s an element of gambling and addiction to how we’re using these tools. People are losing sleep. Setting off agents at midnight. Waking at 4am to check results. While Boris Cherny and the Claud Code team hand us remote control, so we “g, touch grass”.

This is a massive context change. On the macro level: your entire industry is restructuring. On the micro level: every task you do feels different than it did six months ago. That’s draining in a way that doesn’t show up on a task list.

The smart companies won’t just fire people to “save money” with AI. They’ll figure out that the bottleneck moved to human cognition and attention. They’ll build systems that account for that. The ones that burn out their best people for short-term throughput will regret it. (While probably too late, again. Dumb before AI → dumb with AI)

On a personal level, this needs to be dealt with. Not pushed through. Dealt with.

The 90/10 split

Kent Beck said it best, already a couple of years ago: “ 90% of my skills now have zero, value, the other 10% have 1000x value”. Yes, and that’s Kent Beck.

As a society and as individuals, we need to figure out which is which. Most of what we did as knowledge workers was execution. Translating decisions into artifacts. Writing the spec. Building the deck. Formatting the report. Drafting the email. That’s the 90% that just got cheap and lost value to the LLMs- let them handle it. Proudly.

The 10% that exploded in value? Judgment. Taste. Knowing what to build, when to stop, what to kill. Reading a room. Understanding a user. Making decisions nobody else will make.

Which leads us to the one thing AI fundamentally cannot have.

Agency as the moat

“I would argue that the one thing AI can never have is agency,” Simon says. “It doesn’t have human motivations. Sure, you can tell it to make more money or whatever, but it’s never going to be able to decide on its own what makes sense for it to act on next.”

AI agents have no agency. Zero. They can execute brilliantly. They cannot decide what matters. They cannot care. They cannot commit to a direction when the data is ambiguous and the stakes are real.

That’s what we do. PMs, designers, Management, humans - we decide what problems to take on. Where to go. What to ignore. That’s agency. And it’s the one irreplaceable human skill in a world where execution is getting automated.

Invest in your own agency. The rest is tooling.

The middle gets squeezed

Thoughtworks gathered a bunch of engineering VPs to figure out who benefits most from AI. Their finding: experienced people and beginners. The experienced ones amplify and leverage on decades of judgment. The - AI native - beginners ramp up faster than ever — Cloudflare and Shopify hired a thousand interns each because onboarding that used to take a month now takes a week.

Who is in trouble? Mid-career. Not senior enough to have deep expertise to amplify. Not new enough to get the onboarding boost.

This is true for PMs and designers too. New people who are AI-native ramp up fast. Senior people leverage decades of pattern recognition. The middle is exposed.

So what do you do if you’re in the middle? Lean in harder. Embrace the new tolls and techniques. You don’t wait for the company to figure it out for you. You use these tools to take on more ambitious work, learn faster, build judgment faster. Close the gap or get caught in it.

What a PM should do now

What does all of this mean for a mid manager, a strategist, finally and foremost a PM? Learn a harness. Claude Code, Cursor, Codex — pick one or two. Get comfortable. The specific tool matters less than building the muscle of working with AI agents.

But know this: it’s not about the harness. Learning the tool is not about learning the tool. It’s about how you think with it. Simon doesn’t get great results because he picked the right tool. (He’s actually switching between them a lot.) He gets great results because he knows what to ask for, when to push back, and when the output is wrong.

We can now go downstream into coding and upstream into strategy. But just because you can doesn’t mean you should. Choose wisely aligned with your profile, your context, your ambitions. Becoming a paid developer is probably not the move. Becoming a PM who can prototype, test, and ship without waiting for a sprint? That’s the move.

Concretely, things Simon’s work suggests PMs should be doing now: prototype features yourself before writing a spec. Build three versions, not one. Use AI for the first two-thirds of brainstorming, then push past the obvious. Run your own research — feed context to Claude and let it synthesize. Hoard what you learn: techniques that worked, experiments that failed, prototypes that surprised you. Store them somewhere you trust. Feed them back into future work. “The AI is absurdly good at reusing context you make available to it.”

Test ideas with real humans, not simulated ones. “You can tell the AI to simulate your users. I don’t think that’s credible. I don’t think you’re going to get as good results from ChatGPT pretending to click around on your prototype than you would from an actual human being.”

Lean in, embrace that change, enjoy the ride and be ambitious. This is the year.

The dark factory: questions we couldn’t ask before

The Extreme idea.

StrongDM, a legitimate security company, ran an experiment.

Two rules:

• Nobody writes code.

• Nobody reads code.

Everything is AI agents. In production. → For security software.

They built swarms of simulated employees in a simulated Slack channel, making requests 24 hours a day. “Hey, could somebody give me access to Jira?” Thousands of simulated users testing the software around the clock. $10,000 a day in tokens. They built their own simulated versions of Slack, Jira, and Okta because the real ones have rate limits.

It’s insane. And it asks questions we couldn’t even begin to ask before: How do you know your product is good if no human is reviewing the code? How do you build quality without human eyes? What does a QA department have to look like when it never sleeps and runs on API calls?

These aren’t really engineering questions. They are also product questions. They are strategy questions. And they’re coming at us fast.

The Challenger disaster is coming

Simon has been predicting what he calls the “Challenger disaster of AI” for three years. It hasn’t happened yet. But the logic is obvious.

“Lots of people knew that those little O-rings (of the Challenger) were unreliable. But every single time you get away with launching a space shuttle without the O-rings failing, you institutionally feel more confident in what you’re doing.”

Or just as experienced Skit Tourers always get closer to the edge, because - hey, it worked out fine until here.

We’re doing the same with AI. Using these systems in increasingly unsafe ways. We’re still getting away with it, feeling more and more confident. “We’ve been using these systems in increasingly unsafe ways. This is going to catch up with us.”

His “lethal trifecta” for any product: private data plus exposure to malicious instructions plus the ability to send data back to an attacker. If your product has all three, you have a problem no matter what AI guardrails will reliably solve. “You can get to 97% effectiveness on those filters. I think that’s a failing grade.”

We will probably not prevent the disaster to happen. But we can be aware. And we can learn from it when it comes.

People want to augment themselves

Open Claw went from first line of code to Super Bowl ad in three and a half months. Hundreds of thousands of people set it up even though it’s non-trivial, not secure, and actually messy and not really fun (don’t ask!).

The signal is out there ein the open: people desperately want a personal AI assistant that can actually do things. Read their email, take actions, figure stuff out. They’ll tolerate terrible UX and real security risks to get it.

Give my AI those claws!!!

Look at Anthropic’s Claude — reacting in real time, taking actions, remembering context. Look at every company scrambling to build their own version. It’s not about fulfilling simple feature requests. They’re noticing the basic human needs expresses beneath: remote control over the complexity of your own life.

Just like the smart phone was not about smartness, but safety, reachability and ubiquitous information. Now these smart phones become really smart and they have claws.

For PMs, this is a goldmine of signals. What people tolerate tells you what they crave. The unsafe things people do with AI (like setting up OpenClaw unprotected and giving it root access, something you don’t give to your college normally) tell you what the safe version should be. “If you can build safe OpenClaw, that’s a huge opportunity. I don’t know how to do it. If I knew how to do that, I’d be building it right now.”

Read those signals. Build for those needs.

Agency and exhaustion

Let’s close where we started.

Simon Willison is one of the best engineers in the world. He’s shipping more than ever. He’s more ambitious than ever. And he’s exhausted by 11am.

The tools are extraordinary. What they demand of us is also extraordinary. Not typing. Not building. Deciding. Judging. Holding context. Making calls. Caring about whether the thing actually works for real people.

That’s agency. That’s what makes us matter. And it’s the one thing that doesn’t scale with compute.

Invest in it. Protect it. Don’t burn it out chasing the dopamine of one more agent run at midnight.

The AI doesn’t get tired. You do. And your judgment when you’re exhausted is worth exactly nothing.

Nico Noll: Actually Using Product Data – with AI

Nico Noll has been a product specialist for years. Has trained hundreds of PMs – inside companies, in workshops, as a coach. And is now building his own thing: Product Analyst AI. A tool born from his own pain: years spent as a PM where data was theoretically available but practically out of reach.

The core idea is simple yet structural: product data exists in almost every company. But nobody really uses it to make decisions. The bottleneck isn’t the amount of data – it’s access and interpretation.

I am regularly giving trainings for Product Managers on how to live the new PM work augmented by AI - using Claude Code. It’s about PM work, not simply learning the tool.

Next cohort "AI Augmented PM"

The Data Gap in Product Management

Tracking runs. Events get logged. Mixpanel, Amplitude, PostHog, Google Analytics – at least one of them is almost always in the stack. But when a PM really wants to know which behavioral patterns predict churn, which users drop off after onboarding, which segments behave fundamentally differently – they’re waiting on a data analyst, a dashboard, or both. Both options: slow, expensive, often simply not available.

Nico experienced it as a luxury when he was a PM at Xing: a frontend analyst and BI analyst always on hand. That’s the exception. The rule: either no data team, or one that’s constantly overloaded.

Thesis 1: Most product decisions happen without current, granular data – not because the data is missing, but because access is too cumbersome. Granular questions take weeks. So they mostly don’t get asked.

Thesis 2: The real problem isn’t a technology problem. It’s an access problem disguised as an analysis problem.

What Product Analyst AI Does – and What It Doesn’t

No “vibe analytics” – no throwing a CSV into ChatGPT and hoping for the best. Instead, a system with clear guardrails: generalized statistical functions on one side. Company-specific context on the other.

The approach: separate what can be generalized (statistical methods, calculation logic, segmentation functions) from what is company-specific (event names, business definitions, segment structures). Both together create a system that delivers reliable answers.

What works today: everyday product management questions. How many users show this behavioral pattern? How does churn rate differ across our segments? What happens on average in the first 30 days after signup?

What doesn’t work yet: the exploratory two-hour sessions with a senior data analyst. The complex strategic analyses. That’s deliberately not the goal – Pareto logic. 80% of the questions teams ask daily are answerable. That’s where you start.

Thesis: When the same question comes from the CEO and from the PM, the same answer has to come out. That’s the difference between a tool for real decisions and one that just delivers the feeling of having analyzed something.

Context Engineering – The Real Differentiator

This gets technical. Worth it.

An LLM without context makes assumptions. And does so with alarming self-confidence. Markus shares a good example: reviewing a bootcamp curriculum. ChatGPT without specific context produces generic output. Then name the deep technical errors, ask again – suddenly the model says it has now activated the necessary knowledge and can actually go deep.

The LLM knows what it needs. It just usually doesn’t get it.

What Product Analyst AI builds because of this: a context layer. What do the event names actually mean – because they often aren’t called “conversion_event” but some cryptic string. How does this company calculate churn rate? Which segments come up again and again? Which metrics are already defined?

All of this gets built out once – currently still manually during onboarding – and then provided to the agent as structured context. The agent pulls context and calls deterministic calculation functions. Combines both. Delivers reliable answers.

Thesis 1: Prompt quality matters less than context management. Whoever builds in context in a structured way gets dramatically better results.

Thesis 2: The people already getting real value from AI, and those saying “it’s all generic” – they differ almost exclusively in how well they manage context.

Data Access for Everyone – Not Just Product

Customer Success wonders whether the upsell from last quarter is even being used by an account. Sales wants to know which customers are showing churn signals. Marketing would love to see which features actually drive activation. All of that is in the data.

But Mixpanel access is usually only for product. And even there, people often don’t really know what’s inside the data.

That’s the bigger picture behind Product Analyst AI: not just serving PMs, but enabling data access for all teams in the company. Without everyone having to learn Mixpanel. Without filing a ticket to the data team. Without waiting three weeks.

Thesis: Most companies have a data access problem – and mistake it for a data analysis problem. The fix isn’t building more dashboards. The fix is making questions directly answerable.

AI in the Entrepreneur’s Daily Life – What’s Really Changed

As a two-person founding team, Nico and his co-founder can now do work that would have either been left undone or required external resources a small team simply doesn’t have.

Concretely: filtering 5,000 relevant companies from a LinkedIn connection list. Automatically qualifying new signups – which company do they work at, what problem might they have, are they a fit? A Python script that would have meant half a day of manual work now gets built in minutes.

Nico says it plainly: it has revolutionized every part of his work. Not in the sense of “I don’t have to think anymore.” Quite the opposite – the quality of his own thinking is now the bottleneck, not the execution of manual tasks.

Thesis 1: AI doesn’t take away jobs. It enables work that simply didn’t happen before – because the resources weren’t there.

Thesis 2: With AI support, you don’t become more efficient at what you were already doing. You can suddenly do things that were simply out of reach before.

The Addiction Factor – and Why Distance Still Matters

Nico runs. A lot. Trail running in the mountains whenever possible. And he travels. Montenegro, Bali. Not as a break, but as a necessary change of contrast.

The background: when repetitive work disappears and almost only strategic thinking remains, mental clarity becomes the real bottleneck. Before, you could “switch off your brain and just do.” That’s no longer possible.

At the same time: AI tools have an extreme addiction factor. Fast results, constant dopamine hits – bang, result. Another iteration, bang, better. Markus directly compares it to social media. And hits a nerve.

Naval Ravikant has a fitting tweet: “Play long-term games with long-term people.” That’s exactly the opposite of the hustle-ADHD currently running through AI circles.

Thesis 1: The more powerful AI tools become, the more important the rhythm around them becomes. Whoever doesn’t actively shape that, burns out.

Thesis 2: Staying outside your own bubble matters strategically right now – not just personally. Living only inside the AI-early-adopter world means losing the feel for what most people actually need and understand.

Signal vs. Noise – How Not to Lose the Plot

Everyone has FOMO right now. The biggest names in the space included. The question is no longer whether you’re missing something – but how to stay able to act anyway.

Nico’s answer: find three or four people who don’t share opinions but show how they do things. Follow them. Tune out the rest.

Thesis: Going deep on AI tools tactically is one of the most strategic moves you can make right now. Whoever understands how these tools actually work has a fundamental advantage – just like at the rise of the internet or mobile.

The ideal they work towards is: people literally create their software futures by speaking them out loud.

People don’t need to understand what I unpack here, they feel and experience it naturally - and that’s what makes it so addictive to many.

Watch any video of the Claude Code team at work. Multiple terminals open. Parallel threads running. Experiments spun up and lots of them killed right away.

On the surface: hyper busy. ADHD style — which they even mention themselves.

That reading hides what’s actually going on. And decoding what’s underneath the cool story is worth a few minutes. Because it reveals something most teams haven’t understood yet. And probably won’t for a while.

What you’re watching is the visual signature of a completely different way to build things. They call it engineering. I’d call it option storming.

Brainstorming is dead. Long live option storming.

Brainstorming assumes execution is expensive. So ideas get filtered early — by discussion, by judgment, by committee. Most things die before they touch reality.

“IT is the place where nice things go to die” Remember that? That might be a thing of the past.

Option storming turns this upside down.

When execution is cheap and speed is insane, you stop filtering before the experiment. You run the experiment. Any experiment. Now. The moment it crosses your mind. Let reality do the filtering.

That might sound subtle and obvious at the same time. And it changes almost everything.

The Claude Code team operates on exactly this logic. They execute basically every thought they have. Ideas that didn’t work 6 months ago? Try again. People starting work on that team are explicitly confused about the perceived “waste.” The answer: Why not? Cost of re-testing: trivial. There’s high chance the environment changed: new models, better agents, different usage patterns: 100% real. Let’s see, give it a try. Nothing to lose.

Historical rejection becomes weak evidence when the world keeps moving.

And that explains a lot more than just code. Unfiltered observation of customer complaints on social media. Insights from dogfooding inside Anthropic. Let’s just follow all signals. Now. What’s there to lose, again?

All early filters are gone. Why do deep user research when it’s faster to create the reality, look at it, and keep or dismiss? What’s the actual value of overthinking? That’s why it feels so alien.

If you’re still running design sprints to decide what to build — you’re solving last decade’s problem. The bottleneck moved. You just haven’t noticed.

The 3D chess behind the scenes

The simplified story goes: AI writes code, engineers review, productivity goes up.

Totally true. And totally missing the point. Three games are running at the same time.

Layer 1: Build the product.

Layer 2: Build the tools to build the product.

Layer 3: Build the exploration infrastructure that makes discovery cheap enough to sustain Layer 1 and 2.

That’s the meta. That’s what those open terminals represent — parallelized discovery threads, each one probing a different part of the design space.

The engineers aren’t just building software. They’re designing the machine that builds the software that becomes the machine. Claude Code.

And they’re doing it inside the machine.

Claude Code builds Claude Code. The development environment is recursive. You’re observing agents, inside the system, while evolving the system. What seems like engineering is research lab work with tight integration gates, working on a moving target.

The necessary background skill they built: leveling exploration code to production quality. So what gets created as an experiment can simply go live. That’s where the guardrails come in — so the code doesn’t need to be reviewed. One stage less. Again.

Hold that moment: They removed the review stage by making exploration production-grade. Rather than that being a local process improvement it really creates an entirely different architecture of work.

How this puts the customer at the center

In this model, internal reasoning is now only secondary input. The primary guide:

• usage patterns

• friction in real workflows

• feedback from people actually using the thing, e.g. from internal dogfooding (Finance guys use it? Let’s create Claude Cowork for them. Because we can. Security? Let’s include a VM, who cares? Let’s see that thing. 10 days? Why think about it?)

The loop becomes: user signal → option implemented → real usage → keep or discard.

That’s why products built this way feel unusually well-tuned. They are not designed and filtered by assumption, but shaped by many small empirical corrections. Evolutionary selection can now finally win over big design upfront. Because: why think now? This is the next level of giving up the idea of control. Change user behaviour? Why? We can just give them what they need.

The shift to real evolutionary design of the machine that builds the machine — that’s the actual achievement. Not the code. Not the terminal count. The loop.

The real competitive advantage

What’s hard here isn’t generating ideas. Everyone can generate ideas.

What’s hard:

• building fast evaluation loops

• detecting real signal in the noise

• filtering coherently

• integrating what survives without creating chaos

The core competence moves from ideation and early-stage filtering to creating all options simultaneously and filtering as late as possible. Remember this: the core ability is now to filter as late as possible (or rather necessary!). The whole decision of what makes sense moves to the stage where the thing actually exists.

That is the revolution behind this.

It’s a pattern that shows up whenever generation becomes hyper cheap. Hardware: think Shenzhen where physical prototyping got so cheap that decisions moved to after the thing existed: cheapest prototypes enable late decisions. Software: think what’s happening right now.

The public narrative around “AI writes code” buries the real insight.

It’s not about the generation. It’s about what you do with the explosion.

The most powerful teams in these environments stop thinking of themselves as builders.

They become designers. More of this. Less of that. More like this? Let me look at the actual thing. And when the LLM doesn’t solve a use case cleanly? Never mind. Next one. The deficiencies of the models barely matter when your exploration surface is this wide.

That’s the game.

Most people watching from the outside are still counting terminals.

But here’s the part nobody wants to hear. If your business depends on fulfilling concrete promises — not exploration but delivery on commitments already made — this model might not work for you. At all. The Claude Code team can do this because their product IS the exploration tool. It’s turtles all the way down.

So the real question isn’t “how do I copy what Cherny’s team does.” The real question is: does your business model allow for massively parallel discovery? And if it doesn’t — would you dare to shift it so it does?

Because that’s where the divide is forming. And it’s getting wider fast.

What you needed to hear

What Cherny’s team is really working on, knowingly or not:

“The moment I think it, it exists”. Voice mode is just the latest approximation. If you think it and can speak it: it will exist.
And that’s what makes people so addicted to the tools.

People don’t need to understand what I unpack here, they feel and experience it naturally that they literally create their software futures by speaking them out loud.

The picture is the answer, honestly.

Nobody has the AI answers yet. (Altough I start thinking that’s just a thing we keep saying. probably we know more than we acknowledge.) The books aren’t written. But we already know something that works in the moment: something works: people sitting together, fiddling with a laptop, building their first agent. And the next and the next. Just doing it, no overthinking. No committees, no processes. The moment the first agent runs, changes everything. If you achieve that moment with a CEO, the whole company is accelerated. That tactic is the strategy of the moment. Everything else is second rate in this moment.

Note: I am currently offering a course for PMs on how PM work looks like now. It’s starts with learning the tool, then having it build your system, then doing your job like in the future. 4 weeks, starting 13 March 2026. Click if interested, ignore of not.

More info

Insane Questions, insane height of falling

Where does AI lead your company? Your career? Society? What’s the end game?

Is it the singularity? Does it kill jobs, or does it only shift work around in dimensions unseen? The back pushers, who still try to deny it entirely. “It’s not as good as humans”. (Sure, but who cares? It’s amazingly betters in parts. It’s always on, it’s eager. It’s productive as hell.) You have complete polarisation: Some predict the future with perfect certainty. Then the doomers. The hype attention economists. All opinion, no answer.

Funny note: A week ago or so I was on a LinkedIn thread in which people complained about people complaining they have a hard time working when the tokens don’t keep coming. To them that seemed like bragging. They couldn’t imaging that there are people, working professionals, in systems that rely on tokens.

The predictions contradict each other. It’s not that people are stupid but because this thing is still partly unknowable right now.(Again, I think it became much more predictable since maybe 3-4 months. The monster showed it’s head: It can pragmatically can do more that we thought.) We’re in 1995 internet territory. The infrastructure is here. The value systems on top of it are not. We’re all fumbling.

And I mean all of us. Me included.

The simple pattern that I see working over and over again

The solution of the moment is absurdly simple.

Given the enormity of the question, one would expect the answer to be equally enormous. A grand strategy. A transformation program. A 200-slide deck from McKinsey. A three-year roadmap. All the overthinking you can imagine. Brainiac work through and through.

Nope.

Ironically overthinking and waiting and “perfect” of course is the recipe for disaster.

The one thing that actually works is comically small and absurdly trivial: Two people. Some people. One room. A couple of laptops. Fiddling. Tinkering. Maybe building their first agent. Struggling, ups, downs.

It’s part of my job currently because I think one of the best things we can socially do and in socialising our talents is that. Sit with people, open a laptop, and start. No other agenda: let’s see what this thing can do for your actual work. No demo. No presentation. Nothing smart. Just work with actual “context”.

Let it roll, and things happen. Insights come flying. What the thing can do, what it can’t (yet?) do, what it means for the org, where the current org hits the limits of the new thing. Just like that. It’s not that hard.

Once agent runs and does funny, or productive, or awesome or trivial things, the same person who five minutes earlier said “I can’t do this” or “CLI - that’s not for me” watches their messy spreadsheet get analyzed (20$ of tokens but a forecast like no other in the last 12 months), backlog structured, meeting notes synthesized (but now everyday, all of them. Oops, a new productive habit). Something that would’ve taken them half a day, now swooshing down in seconds. After the second it’s not magic anymore. It’s the new normal, a level for their data, their context, their problem. And addictive. No turning back.

That second changes things. I’ve seen it dozens of times now. It’s the same face every time. A mix of “holy shit” and “wait, what else can this do?”

I had a call with 15 strategists (you know: strategy being an art and all), denying the new toy, showing them analyses the thing did in minutes and 15/15 wanting to apply it next week.

Pandora’s box

If that person is a team lead, the team changes. If that person is a CEO, the company changes.

What the Forst agent actually does is mostly irrelevant. It’s a switch of the mental model. The idea of what’s possible just changed trajectory. After that, it doesn’t come back down. Agents then mean agency.

Pandora’s box opening. For better or worse. Because not everything is easy now. The person with the new won agency now starts seeing the entire workflow with from a different vantage point. Every repetitive task, every weekly report, every data pull that took three hours or was depending on the availability of that expert that never has time. Boom, from pain point to candidate.

And the ones who don’t have that moment? They’re still debating whether AI is “ready” or “reliable” or “safe enough” and focusing what it can’t do” and how “its not human at all” and how the other bubble is just “without any responsibility". Which are valid questions. But they’re questions you can only answer by doing it. Not by reading about it. And then, maybe knowingly, still own that position, earned from practice.

We’re touching maybe 1-5% of what AI can do

That’s volume and areas. I’m guessing of course. The remaining 95-99% aren’t an about knowledge, they are mainly about not applying practice. They are waiting for a pioneer just doing it and being surprised that it actually works. my next big bet is middle and top management. All the heroics, all the dirty work, figuring out the signal in the noise. The whiter the collar, the ironically better the AI is in filtering. And the clearer our vanity in discussing wordings for week, while the AI still gets the same signal, becasue the information content remains the same. The weeks of discussion were about socially coding the thing. Tribal rituals.

The people I work with are all smart. Many of them are senior. They’ve read the articles. They’ve seen the demos. They know, intellectually, that AI is a big deal. But knowing and doing are two different planets. The gap between “I’ve seen a ChatGPT demo” and “I built an agent that checks my strategy docs against reality every morning” is enormous. And you can’t close it by reading more articles. The thing that makes the difference now is not IQ, but leaning into practice and knowing it’s a strategic move.

The responsible position

Those in positions to decide must open the windows for this. Not next quarter. Not after the “AI strategy” is finalized. Now. Rather under- than overthink. Just like 1995. Those who won built, they didn’t think that mich. That came later, in exploitation times.

CEOs: build programs that let your people practice. Not one-off workshops. Not a lunch-and-learn. Actual time, actual tools, actual problems. Rituals, habits. Weekly. The ROI will be obvious within weeks. And the ones who practice will tell you things about your business that no consultant will.

Schools: teach kids now. They’re already using it anyway. The question is whether they learn to use it well or whether they stumble into it unsupervised. That’s not a technology question. That’s an education question.

Universities: shift your curriculae. I talked to a professor recently who still teaches the same software engineering course from 2019. 2019. That’s seven years and an entirely different reality ago. Students deserve better. Now.

Parents: show it to your kids. Sit with them. Build something together. That’s the laptop-in-a-room thing again, just at the kitchen table. This is better than the toy robots. It’s a ton of fun next to the learning.

Not tomorrow. Now. Today, this evening. That’s not even rushing it, and I don’t talk FOMO!

The absurdity

It makes me laugh every time I think about it:

The strategic questions AI is putting at our feet are astronomical. We’re talking about the restructuring of work, of education, of how decisions flow through organizations, of what jobs look like in five years. These are society-level questions. The kind that usually require commissions, think tanks, policy papers.

And the best strategic response right now? Sit in a room. Open a laptop. Build something. Together. See what happens.

Absurdly tactical.

If you are currently trying to figure out what is the next change or what you or your team or even your company could adopt, trying to understand the direction from the vantage point of the extreme, that already exists, might help.

Disclaimer: We probably don’t really know what they are really doing over at Claude. I tried to compile as much as I could and give a honest summary of what I found.

“Vibe coding” started as a name for AI-assisted prototyping. It has since become a label for everything - including the careful, structured work of the engineers who are actually pushing the frontier. The resulting confusion creates a ton of division and is worth clearing up. It creates an idea that there is production code without clear architecture, guardrails and constraints. The idea that code is only reviewed on the feature, not line level (what Shapiro describes as the psychological hurdle between level 2 and 3 - out of 5 - on his “vibe coding scale”) is fear inducing. Studying what Cherny (creator of Claude Code) and others are doing is telling a bit of the story of how their work is actually zero Yolo, but highly disciplined, structured and responsible. Also, it gives a bit of a peek into what future teams look like and how they align.

Andrej Karpathy coined the term “vibe coding” in early 2025. The idea: fully surrender to the AI. Stop reading diffs. Just describe what you want and see what comes out.

It caught on fast because it matched a “vibe” that was in the air, something polarizing, because it looked magical at the time. It was democratizing and at the same time, without guardrails, totally irresponsible. Tools were Lovable, Bolt, v0. Build a landing page in 20 minutes. Ship a prototype in an afternoon that would’ve taken a week before. That version of vibe coding is out there, still and has useful, limited applications. But then a lot happened and the label remained stuck to everything.

Karpathy moved on, and especially the people around Cherny at Claude moved on, and in his own way, also Kent Beck (see some quoted from him below). moved on

Until now that creates some fog over the debate, as any serious AI-assisted development got called vibe coding. Which is a problem. Because what Karpathy originally described - and the workflows the people at the actual frontier developed since then and execute everyday - are two different things entirely. Karpathy moved on, the team creating Claude Code moved on a lot, heck: Kent Beck moved on. Let’s see where they moved to.

What Boris Cherny Actually Does

Short version: research first, plan second, annotate until it’s right, then, and only then, implement. Humans check the thinking before any code runs. And then check again when the feature is built. If it works: fine. If not: next iteration. Good code is taken for granted and not being checked as the production pipeline is optimized through guardrails to ensure that.

Boris Cherny built Claude Code. He uses it like this.

Before any code gets written, he writes a research doc (you could call this PM work, he writes the spec for the feature). Claude reads the relevant parts of the codebase, documents what it understood. Cherny reviews it. As long as the understanding is wrong, no code is produced. Garbage in, garbage out - that doesn’t change when the code is written by an AI.

Next: a plan, ending in plan.md. It shows file paths, trade-offs, code sketches, which Cherny annotates directly, corrects constraints, kills what’s out of scope. Claude then updates the plan. They go back and forth until it’s right.

And only then does he say: “implement it all.” So: until here: plan mode and then the famous one-shot based on the iterations until a good spec was reached.

My course on PM work in Claude Code

The explicit instruction during planning is “don’t implement yet.” That’s one important guardrail. The agent can’t lock into wrong assumptions before a human has checked the thinking. The switch from “don’t implement yet” to “implement it all” is 0-1, but to get there is highly iterative. The one shot is the result of those careful iterations. Then he looks at the result and like a designer or a tailor, he iterates again to say “a bit more of this, a little bit less of that”.

During implementation, continuous typechecks and tons of guardrails are running. Tests are written first, based on the specs. Short, operational corrections. No architecture discussions at this point. If it goes the wrong direction, he doesn’t debug it to death. He reverts, in the worst case, he throws it in the trash. Re-scopes. Hard reset. Move on.

At any given moment he has 5 to 10 agents running in parallel. some of them in Claude Code, some in the browser, some on his phone. Balancing the work on a git worktree. Some tabs just get killed if the direction was wrong. That’s the default of Cherny and his team. And (yes, currently just) a couple of other teams. 90-100% of their code is written like this. Pull requests on the rise as well.

The Misunderstanding of the old Agile community: “But we proved spec driven coding does not work”

It should be obvious, but the word “spec” alone drives instincts - hundreds of pages of PRDs, waterfall, defining the outcome of the next 9 months: But here, the “spec” is for one iteration. Maybe an hour. Not eternity, not a sprint. Not even a day.

If it doesn’t work, depending on the outcome, you throw it away (totally wrong direction) or iterate on it. Cherny has multiple simultaneous attempts going precisely because he expects some of them to fail. The cost of a wrong direction is a closed tab, not a failed sprint.

This is not the same spec-driven design as “normal” teams practice it. The spec isn’t a contract. It’s a hypothesis. You test it. If it’s wrong, write a new one. Same word, different semantics.

What survives iteration isn’t the spec, but the judgment about what to spec in the first place.

Vibe coding as a word is already done

When Karpathy described vibe coding, he was describing exploration. Build something to see if it’s even worth building. Don’t worry about production. Don’t worry about edge cases. Just explore.

That was ok and it still is. But it’s not what happens when you ship real software.

What Cherny, Karpathy himself in production contexts, and, a bit with more hesitation or just “searching”, Kent Beck are working toward is something different: code generated at scale, with humans making judgment calls at the feature level.

Line by Line is gone and taken care of by “the machine”. Not even function by function. But: does this feature do what it should? Is the plan right? Is the architecture sound? Is this the right thing to build at all?

Those remain human decisions. What they say is that “taste” is more important than ever. Probably it’s more than that, and calling it taste is a sign of humility. It’s a well trained skill.

The implementation is increasingly mechanical. The judgment isn’t. So, there’s vibe coding and there is context engineering or whatever the word of the week may be. Different things.

The Five Levels of Vibe Coding

This is Dan Shapiro’s framework for where people currenrly stand with AI. Five distinct stages, each one requiring the human to step further back from the code:

• Level 0 - Spicy Autocomplete. AI finishes your lines. You’re still writing the software. Fewer keystrokes, same job.

• Level 1 - Coding Intern. You hand the AI a scoped task: write this function, refactor this module. You review everything that comes back. AI does tasks. Human does architecture.

• Level 2 - Junior Developer. AI handles multi-file changes and navigates the full codebase. Human still reads all the code. Shapiro says 90% of self-described “AI native” developers are here, thinking they’re further along.

• Level 3 - Developer as Manager. The relationship flips. You direct, the AI implements. You review at feature/PR level - not line by line. Most developers get stuck out here, because the psychological blocker is huge: let go of the code.

• Level 4 - Developer as Product Manager. You write a spec. You leave. You come back hours later and check if the tests pass. You’re not reading the code anymore. You’re evaluating outcomes. Almost nobody writes specs good enough for this yet.

• Level 5 - The Dark Factory. Specs go in. Working software comes out. No human writes code. No human reviews code. The factory runs lights-out. Barely anyone on the planet operates here.

L2 → L3 is the crucial and hard step. Level 5 probably Nirvana, but an Utopia, the place most of us don’t reach very soon.

What do teams look like now?

Claude Code started as a one-person project (Cherny) plus Sid Bidasaria. Now it’s ~10 engineers (judging on the output and outcome, they’re quite a lot more already this week?). Cowork - Claude Code for more general knowledge work - is also a ~10 people team (or was, a couple of weeks ago, when it was built in a couple of days).

There are roles. PM, design, data, engineering. But the boundaries are dissolving. The APIs between roles become less clear. Everyone goes more up- and downstream at the same time. Everyone codes. The PM writes code. The designer writes code. Half the sales team at Anthropic uses Claude Code weekly. The whole org dogfoods. They all improve the production chain.

Formal sprints don’t seem to exist. But what replaces the coordination overhead?

A partial answer lies in shared artifacts. CLAUDE.md files in the repo, team conventions, common mistakes, guidelines. Slash commands that embed shell steps and pre-approved permissions so agents can move fast without constant back-and-forth. Learnings from PRs fed back into those shared docs. Architectural decisions, “best practices”, learnings get “coded” into the machine and the shared infrastructure right away. Strategy and decisions are shared in .md files.

What used to be a recurring debate about shared practices, has become shared infrastructure.

Code review: Claude does the first pass, including security review. Humans approve. Every PR, same flow. ~95% of Claude Code’s own codebase was written by Claude Code. PR throughput reportedly went up ~67% as the team doubled.

Take those numbers with appropriate skepticism, they are self-reported and hard to benchmark. But the direction is clear.

There’s no clear PM-to-Dev ratio. No role in its pure form without some coding. The team isn’t organized around handoffs anymore.

“Heard the story of a programmer who didn’t want to use a genie because they would lose their programming skills. My dude, someone handed you a chainsaw and you are saying nah I’ll just keep using this cross cut saw because I don’t want to get weak” - Kent Beck

What’s the shift?

What looks like vibe coding from the outside is a carefully constructed pipeline, a finely honed machine.

Research artifact. Plan artifact. Annotation loop. Mechanical implementation. Continuous verification. Revert if wrong.

The trick is that the visible part looks so casual, probably for the sake of marketing: “here’s what I want.” “A third of my work is happening on my mobile phone in the mobile interface of claude code”. Sounds close to not being serious, but is to be taken into context. The interface doesn’t matter, it’s just a small window into a huge context and supporting scaffolding. The invisible, unattractive part is discipline: which decisions are human, where are the gates, what gets reverted when.

It’s the opposite of YOLO.

It’s a peek into what’s possible in engineering under the new conditions. The tools changed. The fundamentals, understand the problem, control scope, verify the output, learn from failure, didn’t.

The people who are best at this aren’t the ones who let go the most. They’re the ones who figured out where exactly they need to stay in control.

Why This Matters

Understanding how the extreme works already today is important for two aspects:

(I) There is a lot of disbelief and misunderstanding on how this can work and the narrative is often met with “this is just marketing” without looking deeper into why it works, where it works.

(II) There is a lot of discussion going on that this (being whatever vibe coding interpretation) is not as productive as claimed, which is often coming from people looking at it without full information and from an angle of “how does my work look like today”. Tinkering shows the way currently.

“Try It! The thing about rapidly changing, brand new tools is that nobody knows the answer to any of the questions you are likely to have. Exploristan is the Land of Try It.

Try it and then share. We’re all wondering.” - Kent Beck

(III) Most importantly: There are a lot of studies which are interpreted as “this” causes an undue amount of stress for people. Which is right. But the environments mentioned in those studies themselves did not react to this new way of work. “This” causes two things: a lot more context switching (not what humans are good at) and more ambiguity due to dissolving roles, more work options up- and downstream at the same time, thus more potential for confusion. The task for work environments is to set up new structures and rituals that create guard rails against burn out and support the new level of speed. Not everything that can be done, should be done. help structure the workday of workers according to the new challenges. But for that the new way of work first needs to be understood.

Sebastian Heide Meier zu Erpen and André Neubauer had me on their podcast. HMZE Beyond Vibecoding, episode fifty. Anniversary time, hat an honour to be the gust! We - of course - talked about AI, product development, and strategy. Went deeper than I expected.

A few things slipped out that made even me pause. Here’s the extract. Unfiltered.

TLDR

AI isn’t just changing how code gets written. It’s changing how decisions flow, which roles still make sense, and how close leadership needs to be to reality. Most companies are currently running the assembly line with the wrong model on it. And the line is running.

(Use English subtitles if necessary)

The Top Theses

1. Claude Code is the worst product name of all time

2. McKinsey reports are no better than an AI analysis fed with random documents

3. Middle management is about to become the real bottleneck — and the actual death blow

4. Two-week sprints don’t make sense anymore

5. 90 % of your skills became worthless — overnight

6. Strategy is becoming more important, not less

7. The information content of your strategy documents is so low that your wording debates are irrelevant

8. Decisions need to land in the infrastructure files today. Not once a quarter.
   

What’s Behind It

1. Claude Code is not for code.

Probably the worst product name ever. You read “Code” and think: not for me, I’m not a developer, next. And in doing so, every product person, strategist, COO, and CEO is missing the most powerful tool they could have right now.

I use it every day. Zero lines of code. I analyze user interviews. I build agents that check back-briefings against strategic briefings. I draw conclusions from Slack channels, Git commits, strategy docs. I filter out in real time where things are going sideways in the company. Every morning.

The trick compared to regular chat: your context is always there. You set it up once — who’s the company, what’s the market, what strategy are we pursuing — and it sticks. Every conversation. Every agent run. Once you’ve worked this way, regular chat is almost unbearable. Having to re-explain everything from scratch every time. Intolerable.

Björn Schotte gave me the decisive push: Forget the Lovable and Bolt toys. If you’re serious, go straight to Claude Code or Cursor. Because then your deliverables are right next to the developer. In Markdown. Directly pushable to Jira or Linear or wherever the hell you need them. That’s the actual point.

2. McKinsey reports are no better than an AI analysis.

Sounds provocative. I mean it. (And yes, I know they’re selling social safety, not actually great reports ;)

I throw in random documents. From all levels. Strategy slides. Back-briefings from middle management. Slack messages. Git commit metadata with descriptions of what they’re supposed to support. No clean set. No curated dossier. Just the stuff that’s there. And then I ask: What does this company actually want? What is it actually doing right now?

What comes out is so to the point that I have a communication problem. Not a quality problem. People get defensive immediately. “That’s not what we meant.” “But we were trying to.” “That’s not fair.” All true. Nobody intentionally did anything wrong. The analysis doesn’t say that either. It just says: You want this. You’re doing that. There’s a delta. We should talk about it.

The terrifying part: Zero politics. Zero deference to hierarchy. Zero agenda. Just what’s in there. Incorruptible. I’ve seen a lot of McKinsey bullshit in my life. The hordes come in, you’re four million poorer, they’re there for a quarter, they come back with a report — and I swear it’s no better than what a “random analysis” produces. Sometimes worse. Because it’s softer. Because it’s more political.

The biggest problem isn’t the quality of the analysis. It’s: How the hell do you communicate this to humans? When something is so much to the point, the normal human reaction is “duck for cover” first, no matter how smart people are. I’m working on that part. But the raw material is brutal.

3. Middle management: The death blow.

The CEOs /COOs currently hunched over their layoff spreadsheets are thinking about it backwards. They’re looking at: Where do I cut production costs? Who’s expendable? And they’re completely missing what the next bottleneck will be.

When your developers are so empowered that you can build 20 variants of five features a day — what slows you down then? Not the tech. The sluggish process around it. The committee that meets once a quarter. The absurd decisions that get painstakingly poured into presentations. Some assistant, some COO office rolling it out across the company over the next three months. And at the end, a fraction of it arrives as a Markdown file on the developer’s desk. Those are two systems that have nothing to do with each other anymore.

Picture VW. The assembly line is running — with the wrong model on it. Because the decision to retool is stuck somewhere on the third floor. It’s been decided, it’s been engineered, it’s sitting right there — but nobody’s retooling. Tough luck. Wrong car produced. That’s exactly what’s happening right now in every company that’s building speed on the development side without touching the decision architecture.

Bitter pill, especially for middle management: When your production speed dictates the pace, it doesn’t matter how useful the intermediate layers are — they’re slowing things down. You need systems so direct that decisions don’t trickle through five levels and create drift five times over. Very few layers. Or hyper-efficient ones supported by AI.

The jobs that existed aren’t as useful as they were. That’s not a judgment. That’s physics.

4. Two-week sprints: Goodbye.

Back to basics. The core principle from the original paper “The New New Product Development Game” — the ur-text that all Scrum people reference — was overlapping phases. Not sequential. Simultaneous. That was the dream.

What the sprint did: pack that ideal into a two-week container so reality could cope. Teams needed to sync. Stakeholders needed rhythm. Reviews needed planning. The sprint was a compromise with slowness. Nothing more, nothing less.

Now you have perfect overlap. Design in the morning, build at noon, review in the afternoon, ship in the evening. Not as a metaphor. Literally. What’s a two-week sprint supposed to do there? Probably even a daily sprint doesn’t make sense. You probably have a morning shift and an evening shift. Or just complete flow. Which was always the dream anyway.

And when work moves that fast — the problem of keeping oversight multiplies. Without end. That’s why you need the daily check: Is what’s being built right now going in the direction of the markers? Not once per sprint. Every day.

5. 90 % of your skills: Worthless. Overnight.

Kent Beck wrote this two or three years ago. 90 % of his skills lost their value from one day to the next. The remaining 10 % multiplied a thousandfold. That was bold back then. Today reality is staring you in the face with it.

Look at the specializations that emerged over the last 15 years. Product Marketing Manager. Product Owner. UX Researcher. Frontend Specialist. Backend Specialist. The list is absurdly long. All of it was an answer to complexity. If one person can’t know everything, then at least one person per thing. Sounds reasonable. It was. It isn’t anymore.

These specialized skills almost all fall into the 90 % zone. You can get the stuff done. Not perfectly. But good enough for the next step. And “good enough for the next step” in a system that improves every day eventually becomes “better than the specialist.” This isn’t future tense. It’s happening now.

What’s in the 10 %: Setting direction. Holding context. Noticing when the system is running wrong even though it’s running fast. Tolerating ambiguity. The human stuff. Figuring out your own 10 % — nobody can do that for you. But I wouldn’t wait forever.

6. Strategy: Now more than ever.

You might think: If everything’s so easy now, I’ll just do everything. 20 features a day. 100 variants. Why bother with strategy? Let it roll let the good times come..

That’s exactly when you need clear markers. Who are you? What don’t you do? James Bond doesn’t do just anything. James Bond does James Bond things. Coca-Cola does Coca-Cola things. eBay took years to explain to customers that you could now also buy directly. Not because the tech was hard. Because the identity shift was horror. Customers came for auctions. “Buy now? What? That’s practically fraud.” It took forever. Then classifieds got added. Another 5 years of explaining. Changing identity isn’t “oh, let’s just add that too.”

And the Elon Musk stuff everyone celebrates? Expensive car first, then mass market. That’s not genius. That’s the playbook for entering an expensive market that requires heavy investment. Of course you don’t start with the cheap car. How would that work? It doesn’t throw off enough for R&D. You can’t do it any other way. It’s a strategic pattern, not brilliance. 20 years later, if it works, everyone writes: Obviously, the guy’s smart. Nope. Standard playbook with good execution.

Marker-Options-Work resolves exactly this tension. Markers are identity — slow. Options are the ways to express that identity — medium speed. Work realizes the options — fast. The three layers must be coherent. Always. And the faster the work gets, the more often you need to check whether the coherence still holds. Not less often. More often.

Pace Layering explains it best: Fashion can push 200 collections a year because commerce, infrastructure, and politics underneath are stable. Zara doesn’t think about trade law. Doesn’t have to. It’s just there. You can only be fast at the edge — customer-facing — if you’re brutally stable on the inside. That’s the tension. And whoever can’t hold it flies apart.

7. Your wording debates are bullshit.

This epiphany hurt the most. Myself. My own vanity.

I throw strategy documents into the AI. The good version. The bad one. The latest draft. The one before. And then I ask: What does this company want? What is it doing right now? The answer: Exactly the same. Every time. Regardless of the wording.

The information content of these documents is so low that it makes zero difference whether you take the polished version or the first rough draft. Debated for months. Went over the phrasing one more time over red wine the night before. The final review meeting on Sunday before the offsite. All of it irrelevant. Zero difference. The direction is the information. Not the sentence.

And the humble insight behind it: The team feels better because they found this great wording. Maybe the drift goes one way, maybe the other. But operationally it makes zero difference. All those final polishing loops — irrelevant. Let that sink in.

Strategy isn’t unimportant. The energy is just completely in the wrong place. On phrasing instead of direction. On the paper instead of what happens after. And the strategist says: “I’m the artist here. I know how to maneuver people into position. We obviously need another two-day offsite.” No. You don’t. What you need is daily exchange between the layers. That’s the real work. The rest is theater.

8. Decisions into the infra files. Today. Not next month.

The most concrete thing from the conversation. And probably the most radical.

If you decide something today, it’s in the context documents for your agents and developers today. Not next month. Not after the next quarterly. Today. The machine is running. It needs the information to build the right thing. If it doesn’t have the information, it builds the wrong thing. Fast. A lot of it. Wrong. That’s VW with the wrong model on the line. Except the line runs ten times faster now.

I meet daily with the companies I work with. Mornings. Brief. Listen: What happened? Where is something going in the wrong direction? Where do we need a decision? And then not: Build a deck, prep the quarterly, roll it out. Instead: Straight into the infrastructure. Into the system prompts. Into the context docs. Into the dev environment. Today.

Sounds exhausting? It is. For humans. For systems, speed is irrelevant. And the COO I’m supporting with these experiments is absurdly faster — because he’s not waiting for some quarterly update to make its way through three layers. He sees what’s happening. Daily. He acts. Daily.

The side effect: Founders and CEOs report getting a completely different sense of control back. For years most of them built an increasingly indirect company. Another 20 developers. Another ten layers of middle management. Another structure, another one. Everything they did was buy a company they could steer less and less. And it annoyed most of them, if they’re being honest. Now they suddenly see again: I can steer directly. How great is that? Founder mode back. The problem is just that a few people need to be reshuffled. Because the jobs they had aren’t that useful anymore.

To Close with the beginning

We’re all fumbling around. That was the first sentence in the episode. Still true. Nobody knows what the organization looks like in three years. Same as during the internet revolution. Same as with mobile. The higher-order system that triggers Jevons Paradox and actually creates massive new jobs isn’t here yet. We’re building electric candles when there could be floodlights.

Until then: Figure out which of your skills are the 90 %. Automate them yourself. Don’t wait for someone else to decide that for you. Then focus on the 10 % that actually make you valuable.

Get into it. Today. Regardless of your role. It barely matters which tool you pick. Just pick one.

Not “explore AI.” Not “form a committee.” Not “wait for the enterprise version.”

Enable. Everyone. Now.

This is also the responsible thing to do. Your workers will depend on this skill in the future. Not enabling them now is negligence , you’re probably “waiting for the right moment.”

What makes me say this? Something happened! And there’s no doubt about it anymore.

The breakthrough is undeniable

Andrej Karpathy — co-founder of OpenAI, former head of AI at Tesla, Stanford PhD — wrote in December: he went from 80% manual coding to 80% agent coding in a single month. He says AI still makes mistakes. It overcomplicates some things. Consumer LLMs are sycophantic. But going back? No way.

Ryan Dahl — creator of Node.js, the runtime that powers half the internet — wrote on X: “The era of humans writing code is over.” (see image at top)

I’m intentionally not citing the CEOs of big AI companies. Altman, Amodei, Huang — they have skin in the hype game. Karpathy and Dahl don’t. They’re builders. Practitioners. They are selling no AI, they are finding out how to work with for us. They are high level users, looking into the future. When they say the game has changed, we can listen.

You can disregard the hype and still arrive at the same conclusion.

I’m running a free Zoom session next Wednesday, 25 February 2026, 9am Berlin time where I set up Claude Code from absolute zero — empty folder, blinking cursor — to a running PM workflow in one hour. After the call, you receive all the resources and the video to follow along.

Register Here

This is about more than code

Claude Code is the worst product name ever. The change is not for coders exclusively.

And right now, there are two bubbles out there.

Bubble one: People deep in agentic systems. Building workflows, automating the boring stuff, getting results that shock even themselves.

Bubble two: People firing off 20 ChatGPT prompts a day, thinking this is what AI can do. Frustrated by the results. Exhausted by the copy-paste cycles. Rebuilding context from scratch in every chat window.

The gap between these two bubbles is massive. And it’s growing every day.

Two moments that open minds

I’ve seen two specific moments that make people change perspective.

Moment 1: Seeing an orchestrated system in action.

Someone sees what happens when you set up an agentic system properly. From the ground up, with proper file structure, context and your real documents: strategy, interview notes, CEO briefings. No more copy-pasting between 20,000 documents. No more rebuilding your specific world in every chat window and cursing at the chat that it should casually remember. You set it up once. It knows your world. And it just works. Repeatedly.

Moment 2: Seeing the actual results.

This one is was harder to digest for me - and a bit of a soul crusher, honestly that cost me some vanity and time.

The real world example is a PRD, generated in a couple of steps from user interview notes. I assumes it’s generic. Surface-level. AI slop.

And yes, factually, a human could probably create a better one.

But when I start making a fair comparison to what actually happens in real life, it looks a bit different.

First, the AI-generated PRD is much better than you’d assume. Why? Because the context is there. Company strategy, goals, user research, constraints — all of that informs the output. The AI produces something with actual, surprising substance.

Humans could create a better one. But - surprise - they usually don’t. Time and effort. It’s the system, stupid.

What really happens in my life: I ask a PM when we can discuss the next product based on that research. Answer: two weeks. Then in 13 days, the evening before, he sits down and creates a version that barely survives our first conversation. Not great.

But two weeks ago, I already had a good, not great, PRD we could have discussed. We could’ve just started from there. Early friction instead of late mediocrity. Better results earlier, less risk later.

Same story everywhere. Evaluating features. Strategic review of a roadmap. Detecting drift between what the CEO wants and what you’re actually delivering. None of the AI results are perfect. But always good enough to start the discussion earlier and get to the relevant friction early and spot on.

The surprise: AI is better at abstract than you think

Here’s what really caught me off guard. The more strategic the topic, the better AI seems to perform. That takes the last bit of myth and human vanity out of the system.

A lot of the abstract soul-searching - weeks of debating the right wording - is vanity. The minute details make less of a difference than we think. They’re just vibes. The people on the work floor want to know what to do. Indicating the direction is good enough.

As Karpathy says: the main effect isn’t speedup. It’s expansion. You suddenly do things you wouldn’t have done because they weren’t worth the effort before.

That’s exactly what I’m seeing on the PM side. The work doesn’t simply get faster. The scope of what’s possible changes. You can now actually be more strategic.You can work talk to stores more and be more strategic. Everything we ever wanted. “Gestalten statt Verwalten” - my point since ten years. And it’s coming.

In fact, there’s little excuse left.

One hurdle remains

Even when both moments happen — when people see it and believe it — there’s still one last, huge wall that people run against:

Setting up your own system from zero. Empty folder to organized files. Terminal running. First agent executing. Spending that first hour. Getting comfortable. Creating the habit.

That’s where a lot of people are not simply getting stuck, but they don’t even get started.

But here’s the relief: it’s not hard. It’s only unfamiliar.

What this means for companies

Back to the top. The good news: the benefit is mutual.

The company gets more output, better quality, faster cycles. The workers get a skill that will define their career for the next decade.

How often does that align so nicely?

Not enabling your people now isn’t cautious. It’s negligent. The “right moment” was a few months ago. The second-best moment is now.

I’m running a free Zoom session next Wednesday, 25 February 2026, 9am Berlin time where I set up Claude Code from absolute zero — empty folder, blinking cursor — to a running PM workflow in one hour. After the call, you receive all the resources and the video to follow along.

Register here

PMs don’t have enough time, the role is over-defined. PMs need an always on senior assistant. The good news: You can build one. On your own. In Claude Code. You can’t code? No problem.

This article shows you what’s possible and that actually nothing should hold you back.

The example: Roadmap reviews, feature scoring and automated production of wireframe prototypes. All to engage in the crucial conversation early and often.

Meet me next Wednesday, 11 Feb 2026, 9am, Berlin time, to see it live and ask questions.

Register for free here

Short Preview (longer version below)

The Gap

The bottleneck of PMs was never the lack of tools or frameworks or techniques. We get lost in story splitting and the hundredth approach to that, while strategy is lacking due to missing quality time, deep work. AI augmentation through the use of — most of all Claude Code — has come to a point where that bottleneck is self-inflicted. We don’t have to wait for humans taking time for us when the perfect PRD, the final roadmap have been written. We can spar from the get go. Without tools like Claude Code, only using an LLM for chatting, this is tedious. Context has to be set up for each chat anew. The results have to be copied and pasted all over the place. With Claude Code, context is permanent, the tool works on our files and the handover to the devs is exactly that: we share the files.

To show the possibilities, I built such a thing. In four hours. Without knowing how to code.

The system is not the point. The fact that anyone can build one is the point.

The Situation

A PM sits in a room full of opinions. Stakeholders want their feature. The CFO wants margin. The CTO wants debt cleaned up. Everyone has a version of what the roadmap should look like. And the PM is supposed to synthesize all of that into something strategic — with no one around to tell them straight what the roadmap actually says.

No always on senior assistant. No second opinion. No one who looks at the whole thing without an agenda and goes: “You’re overcommitting on Horizon 1. Your capacity is at 200%. And this feature request from sales? It doesn’t even connect to your strategy.”

That doesn’t happen. Because everyone in the room has skin in the game. And the PM ends up navigating politics instead of making decisions.

So I built something more clinical, surgical for that.

What I Actually Built

It’s a system that solves a very specific (well, at least three ;) problem a lot of us have over and over again.

It connects to a roadmap in Airtable, pulls the data, and does a strategic review across a couple of angles. Actual analysis. What are the biases of the roadmap? The system shouts the analysis at me. In two minutes. Not days, weeks. Short-term cash or long-term bets? Am I overcommitting? Ignoring something obvious? And it suggests decisions. Not “consider this” — actual “do this or stop doing that.” The tone is “you should change this in the next 24 hours.” It even remembers the last conflicts and reports progress or decline.

In another flow, it ranks my stakeholder feature requests. Stakeholders can actually deliver requests through a form. (It could also connect to Slack or mail.) Every request gets weighed against the company context, the capacity, the strategic direction. Signal vs. noise. Sorted.

Next level: I can use it as a gating filter. You want your feature on my roadmap? Fine. But first, the system generates an analysis of your idea’s impact. And you — the stakeholder — need to spend a couple of minutes refining it. Based on the machine’s questions (which btw. make a surprisingly lot of sense). If you’re not even willing to engage with an AI’s take on your own idea, the idea is history. No conviction, no feature. That alone kills half the noise before it reaches me.

If a request passes my bar — and I define what that bar looks like — the system generates a wireframe prototype. On the spot. Not next week. Not after a design sprint. Now. I can take that wireframe into a conversation with the stakeholder and change it live, while we’re talking. Discuss, iterate, refine — in real time. In the system. I can even talk to the system to get the prototype changed.

This Creates Quality Time For You

All of that sounds like a lot. And it is useful. But the real impact is simpler.

I get support on the admin level.

The review, the ranking, the wireframes — they’re not final answers. They’re conversation starters. I use them to kick off discussions earlier, with something concrete on the table instead of gut-feel arguments. The human is always in the loop. Always. The AI doesn’t decide anything. It gives me ammunition and prepares me to have better conversations faster, now. Not in two weeks.

An always-on senior assistant at work. It doesn’t decide. It prepares you to decide. No context setup necessary. I actually type “/strategic-review” and the result is here in two minutes. No more copy / paste, upload, and other nasty tasks. It’s just there and knows and ready to help.

Most people still get it wrong about AI in product work. It’s not about removing the human. It’s not. It’s about the human walking into the room with the always-on senior assistant’s notes in hand — unbiased, strategic, relentless — and then doing what humans do best: discuss, negotiate, decide. It’s about more communication, earlier and more frequent.

Augmentation, with the human in the loop, not automation.

The crazy development speed up will make you the bottleneck, even more

If your engineers have not taken over on the right side yet, they will. The speed of software development, love it or hate it, will increase 10x or 100x. For some it already has. The knowledge is not yet evenly distributed. The idea still receives some hate. But economy will win.

This makes our job the bottleneck, even more. We are already running behind for reasons of an overloaded role. It will become worse.

Which is required when the software engineers are becoming 10x faster, and that’s honestly underdoing it. That means: We need to speed up, level up our game and use AI to the max: early, feedback-based on outsourced standard and admin work.

The good news: That’s what we always wanted. More time for the required, crucial conversations, leading to the best decisions.

It’s Not About This System

I built this for me. To solve my actual problem. Not to sell it to you. I can’t even.

It’s about showing what’s possible. Here is your always-on senior assistant you never had. Without an agenda, without politics, without ego. You can build one now. For your context, your strategic questions, your company. Set the context up once and here it stays. Always available. Surprisingly hyper smart. No vanity. Patient to do your admin work for you. The kind of review that used to require an expensive external consultant or a brutally honest colleague — you can get a solid first version from AI. In minutes. And then do what you always should have done: talk to people about it.

Not enough people switched already. It’s hidden in plain sight. Just like a lot of things in these early AI days. If you start now, you’re still early. In a year you will be behind.

The Barriers

The build. Because I know exactly what the first reaction is: “Cool, but I can’t do this. I’m not technical.”

I wrote my last code probably 20 years ago. Maybe more. I’m not a developer.

And I intentionally made this harder than it needed to be. I wanted database access — my roadmap lives in Airtable — and design capabilities — the wireframe generation — in the same system. Just to see how far I could push this. With Airtable, Claude, and Cursor.

Four hours. Build and test. The whole thing.

The only real mistake I made: the AI convinced me to use Python-based API calls to connect to Airtable rather than MCP. I should have pushed back. MCP would have been freer, cleaner. But I trusted the suggestion, ended up with Python scripts I honestly don’t fully understand — and it still worked. I know, though, MCP would feel much more free and explorative. This might sound like gibberish to you, but when you experience the explorative nature of this way of work, you will realize that predefined API calls feel like 2024. Or stone age. (Lesson learned: next time, MCP first. Don’t let the AI talk you into the complicated path when the simple one exists.)

Four hours. Database connection, strategic analysis, wireframe generation. For someone whose last coding experience involved Internet Explorer being state of the art.

That much about barriers. It’s not about “look what I can do.” If I can do it, you can do it. Gatekeeping is over. If a non-coder can wire up a database, strategic analysis, and design generation in an afternoon — the only thing standing between you and your own always-on senior assistant or high-quality insight is the decision to start. You will dance circles around the people who don’t use this.

See It Live

There’s a Zoom cast next Wednesday, February 11th, 9am Berlin time. I’ll walk through the system, show how it works, and you can ask anything. Challenge me. Tell me why it wouldn’t work for your context. I’m curious.

Register for free here

The tools are here. The barriers aren’t. Four hours and a decision — that’s all it takes to stop navigating politics and start making decisions.

→ 10 user Interview notes

→ pain point analysis

→ initial PRD

→ amazon Style Press Release

→ User Story Map

with as much or little human in the loop. I take that more as an example of what is possible in non coding flows in Claude Code.

I’ll demo that live in the live event. Join if you don’t know how to things like that in Claude Code yet. While you can do all that in the chat interface, the results are 1) much better in Claude Code because you can b) structure the input mich more, c) can update that input, d) repeat as often as you like and basically have a focus of e) automating the whole thing as much as you want.

Anyways, overall, the outcome isn't perfect. It shouldn’t be: The human in the loop invited at every step and should be the voice of reason.

But: This flow in Claude Code takes 10 minutes, not 1 or 2 weeks.
In real life, the discussion could start today or tomorrow, not next week - as would probably be the normal answer of most PM / POs I know.

Subscribe now

The question isn't: Does it replace the PM?
It's: What do you do with the time you're winning?

The point isn't that the flow is possible.
The point is the automation with human in the loop.
The repetition.

More info in the gallery below. Including sign up details.

For those who don't yet know how to do this: I show this simple flow live.
Cozy corner: watch, ask questions, get an impression if this is for you.
Wednesday, 28 Jan, 9am, Berlin time. Happy to meet you!

If you already work in Claude Code: Don't come. You'll be bored.
If not: Link / QR code in the carousel and comments.

If spots get tight, practitioners prioritized over non-practitioners.

Short overview video of the flow below.

• from analysing (in this case ten) user interviews

• to creating a PRD out of the identified problems / needs the customers mentioned

• transforming this to an amazon style press release and finally

• an initial user story map.

Short run through (caveat: It’s in German, but YouTube subtitles should work well)

The same thing can ofc be done in Claude Code - the much more prominent tool currently. I am doing a lot of strategy work in Antigravity due to its better built in memory. (Basically Antigravity without a lot of work has a better “understanding “ of drift in intent and decisions without doing a lot of work.) But none of that is needed and the transfer of this “system” to Claude Code would be trivial.

As you see, each step would also be possible to do in any chat interface. But as context gets bigger - in this case in one of the folders, the company strategy, principles, options they are working on etc. are laid down - the more complicated it gets to load the context again in a simple ChatGPT chat interface. Ofc,, the magic of the automation only starts for repeated execution of the same task. So, in this case: new interviews → next run.

Longer version with more explanation:

Important: Of course, the human in the loop can directly change all output documents at all times to inject knowledge and wisdom into the flow.

I will soon also make video of the more strategic work I am doing in these systems. Let me know what you are interested in and what you’d like to see!

And a short version with 4 quick statements from Matthew E. May, Christian Riedel, Mohammed El-Nabulsi and Tim Steigert.

The great people who contributed:

• Matthew May,

• Christian Riedel,

• Mohammed El-Nabulsi,

• Tim Steigert,

• Sohrab Salimi,

• Kerstin Neumann,

• Holger Nils Pohl,

• ✨ Büşra Coşkuner,

• Patrick Sauerwein,

• Konstantin Diener,

• Jan Hegewald,

• Dominique Winter,

• Tim Klein and

• Stefan Roock

Thanks to all.

Have fun with the video! What were your challenges and consequences?

Factors: Macroeconomic volatility or even downturn in which no one decides and buys. This is contrasted with the relentless pace of AI disruption and insanely accelerated geopolitical shifts. This has fundamentally altered the nature of strategy. The default response of organizations is often one of strategy-by-panic: an immediate, existential temptation to give up all former plans and rebuild from the ground up.

Or, the wave of AI adoptions:

• ChatGPT wrapper: “We need something AI.”

• Surprise: No customer value created.

• Realization: Real customer value is more than simply throwing AI on your product.

• The chase: Agentic dream, the vibe coding flash… you name it.

It’s easy to lose your way.

This impulse for radical, untethered change is the source of strategy nausea. A desperate pursuit of speed that ironically results in paralysis: The organization loses its ability to distinguish between signal and noise. Everything is noise. Value is hiding in plain sight, and the goal—who we are—is covered in dust. Hard to remember. The vision is dying on a graveyard of wisdom in our documentation system. Instead of giving direction, we sacrificed our hard-won identity for market fashion and pressure.

The core thesis of resilient strategy is counter-intuitive and dialectic: Strategic speed is achieved not by eliminating stability, but by doubling down on it. To adjust quickly and coherently, you must first preserve and protect your core identity.

Beyond the read: Mastering Strategy Execution

The principles and insights expressed here at “The Intentful Company” form the philosophical basis for my 12-week Blended Learning format: The Strategy Collective.

If you are ready to move from reading about strategy to owning it, the Collective is designed to give you a quick start in execution, deep insights into anchoring this role within your organization, and the path to becoming the go-to expert on this topic within your job environment and career.

The Format: Highly curated content, self-study modules, and small group coaching calls.

➡️ Learn more about the curriculum and cohort details here. If you have any questions on how to be part of the Strategy Collective, simply contact me.

The MOW Framework: Balancing Inertia and Agility

Any good strategy (framework) does this, but the property of balancing inertia and nimbleness is a first-class citizen of my MOW Framework (Markers - Options - Work). It provides a system necessary to manage this eternal tension between organizational inertia and market agility. It segments your strategy into three constantly coherent, interconnected layers, each operating at a different velocity:

1. Markers (Identity and Purpose)

The Marker represents your organizational identity, core purpose, and long-term positioning. It answers the question: Who are we, and why do we exist? Who are we and who are we not? What is our Identity?

The Marker’s most essential property is Inertia (Trägheit). Markers are slow, by definition. Thus, they must be difficult to change, and only adjusted in the face of existential necessity, not in response to simple quarterly market swings. The Markers are your strategic anchor; they are the gravitational center required to ensure all quick reactions are still heading toward the same destination. An organization that frequently changes its Marker is one that has abandoned strategy entirely.

Example: Apple does not change its identity on a yearly basis following some trend. They changed from Apple Computers to Apple once, signalling that computers are not the focus anymore, while becoming a personal device and digital service behemoth.

Markers can easily be understood by looking at a person. What makes me me? I was always a sportsman, MTB rider, runner. My kids changed that and my identity. While I still did some sports on the side, I did not identify as a sports- but as a family man. Now, that my kids grew older, I changed back to sportsman, although on a different level: more focusing on health than performance and competition. My identity defined what I am doing. The ways to express my identity are the options I have. As a sportsman, I now do workouts 5 to 6 times a week again. Habit follows identity. But I can’t follow all of them. I need to choose.

2. Options (Paths and Possibilities)

Options represent the concrete, mid-term paths and strategic bets designed to strengthen or realize the Markers. This is where Product Strategy lives.

In contrast to Markers, Options must be Nimble (Flink). They should be generated and evaluated as a portfolio of potential pathways, adhering to the principle of low downside, high upside. Strategic maturity is profoundly visible in the quality and agility of the Options layer. It involves treating significant resource investments not as locked-in expenditures, but as Real Options—investments that retain the right, but not the obligation, to pivot or scale based on rapid validation.

Hint: Options management well done in hindsight looks like master strategy. In fact, no one creates a strategy that predicts the future, and thus is a five-year masterpiece. Great strategy is always the whole of committing to options in the direction of our Markers, one by one. No one option will be winning. It is the cumulative effect of realizing the right options piece by piece that creates value.

3. Work (Flow and Execution)

The Work layer is the daily, operational process required to execute and realize your current, validated Options. It includes all agile (or non-agile) practices (Scrum, Kanban, etc.) and execution streams.

The primary objective of Work is Flow (Fluss). This layer must operate at maximum speed and efficiency. Crucially, the Work is not simply “doing stuff”; it is the mechanism of execution that validates the Options. Work provides the rapid feedback loop necessary to determine which Option should be scaled up (reinforcing the Marker) and which should be discarded (preserving resources).

Engine of Coherence: The Cost of Incoherence

The MOW Framework makes coherence a first-class system and helps to design and test for coherence at all times. The three layers are not organizational silos; they form a tightly coupled, closed-loop system of communicating vessels.

• Work realizes the Options.

• The realization of Options reinforces or strengthens the core Marker.

Note: The framework is agnostic towards the marker being a future vision or a wish for now on purpose. If you wish to express the wish for change, define your future markers as a friction to today’s state and choose options accordingly. If you want to reinforce who you are, have Markers remain even more stable and choose options according to that.

When the three layers M-O-W are falling out of alignment, when the Work being executed does not genuinely feed the current Options portfolio, when the Options are inconsistent with the core Markers, the organization suffers from incoherence. The employees sense that immediately. The resulting lack of clarity is killing sense of achievement, satisfaction with work and finally denies purpose. This is the root cause of the Strategy-Execution Gap and results in wasted resources, team fatigue, and an inability to respond effectively to external challenges.

Strategic discipline means meticulously protecting the slow-moving Markers from direct operational influence and ensuring dynamic alignment between Options and Work. Thus your organization gains the fundamental capacity to handle market disruption without losing its identity, ensuring that strategic speed is always true to the ultimate goal.

The idea of a stable core enabling nimble choice of actions is heavily influenced by the brilliant concept of Pace Layering by Steward Brand (which may be one of the next topics).

In business, avoidance is the silent, pleasant killer.

Avoidance defined

Avoidance is: Avoiding the hard discussions, the friction necessary to create clarity, for the sake of social peace. Avoiding conflict by playing it “nice.” Avoiding the awkward moment of breaking with what feels like chill and peace, when a decision should be made.

Being part of many leadership groups I know this awkward feeling too well myself: leaving a meeting all smiling, drowning pseudo-agreements, and a vague sense of alignment. While each one goes back to their department, telling their story of decisions that were made, keeping up their own narrative. Now we have 5 truths and 5 narratives. Let’s have fun by extrapolation the non-agreements to our whole work force. A week or a month later, disaster strikes and reality brutally shows: we were not aligned, we avoided the clarity, because it felt better, the vibes felt more chill.

Avoidance felt peaceful in the moment. But the corporate equivalent of not opening your bills doesn’t make the problem go away. It just boomerangs back at you harder, later.

Avoiding avoidance with cadence

Of course here I need to refer back to the only silver bullet in my life: cadences (read about them more deeply in “Cadence or Die”). Cadences are the best medicine against avoidance. The harder avoidance, the faster the cadence, the more frequent the meetings.

And remember: Cadence meetings are not vibe meetings. They are not status meetings. Not therapy sessions for leadership anxiety. Cadence meetings are decision meetings. Repeat after me: cadence meetings are decision meetings.

They exist for one purpose only: to create clarity. Nothing more, nothing less. Clarity for everyone in the organization.

Everything else - exchange, monitoring, status updates - can exist as a part of the meetings but for the sole purpose of supporting the only outcome that counts: decisions creating clarity.

Keep your sensor systems up, and when the unclarity triggers are perking: clarity must be rebuilt. But motivational speeches really don’t help at all. Discipline does: structure and rhythm. The harder the problem, the more frequent the meetings. The deeper the avoidance the more radical the solution.

Why not have daily C-Level meetings if the issue has deep roots?

It doesn’t feel nice, but remember: no one’s to blame, the high cadence is not punishment but a solution.

Decisions, not tasks

One of the most common misunderstandings is that cadence meetings are about tasks. In these meetings, often people are waiting to get organized. Nope!

These meetings are not about tasks. Tasks are a downstream problem to be solved (maybe by the same people, elsewhere): projects and programs, which are reactions to decisions.

In cadence, we deal with: decisions → expected outcomes → responsibilities.

Once a decision is made, execution begins elsewhere (but stays connected like communicating vessels). We will watch outcome and stay informed but execution is not the issue we manage here.

That’s how clarity travels through the system without being diluted.

Avoiding avoidance

Some things I think about when trying to counter avoidance

1. Short cycles force contact with reality.

Avoidance is amplified by long gaps - where stories rewrite themselves.

High frequency kills that drift. Every well conducted meeting (remember: decisions, not vibes) hits the participants on the head like a hammer. It’s not pleasant, not supposed to be. It just works.

The harder the avoidance pattern, the shorter the required frequency. It needs to feel, at least slightly, annoying. Otherwise, we’re back to avoidance and giving it excuses.

2. Decisions as the only output.

Every cadence ends with decisions made, deferred (explicitly), or killed.

Anything else - “good talk,” “great discussion” - is just noise (ironically to be avoided).

Closing with decisions is the habit we create.

3. Repetition exposes inconsistency.

Saying the same things out loud every week reveals drift. Repetition often feels stupid, especially to the one repeating. Until there is a decision and the narrative holds, we repeat and reframe until we have clarity.

4. Documented memory prevents the narrative and goal posts from moving.

A written recap is the backbone of alignment and the required one shared truth. (No misunderstanding: disagreement is welcome, friction is needed but with the goal of decision and clarity.)

No write up → multiple truths → everyone tells their own version at home.

Documentation isn’t bureaucracy and can be lean - but it’s required and countering myth.

5. Predictable confrontation reduces fear.

When these meetings are the place and time for friction, bringing the heat is not exposure anymore. It’s a weekly practice that is expected as part of your work.

Cadence normalizes required healthy conflict as a routine for hygiene.

Thus the opposite of avoidance is not aggression but rhythm.

6. Cadence replaces “niceness” with clarity.

“Being nice” protects fake relationships by protecting the illusions of alignment - because it feels good, although the receipts are waiting.

“Being clear” protects real relationships by protecting truth.

Cadence operationalizes that difference.

7. Cadence as mirror of intent.

If a leadership team can’t keep up the decision rhythm, it’s not simply an alignment issue. It’s a leadership issue of dealing with reality.

Avoidance hides intent. Cadence brings it back, and puts it to the test every week or whatever your cadence is.

Avoidance wins when cadence disappears

Avoidance is not a moral failure of leadership, especially not of the individual, it’s a systemic failure of not setting up the right structure.

With a lack of a designed rhythm that forces decision and feedback, avoidance naturally fills the void.

Entropy always rises without energy being fed into the system regularly. Thus intent decays not because people are stupid or ill intended or simply change their mind, but because they stop meeting with enough rhythm to maintain the shared intent and keep it clean.

Done right (and I’m not saying it’s simple) cadences are more than a management technique. You can make them your company’s heartbeat.

It’s hard to do, it can’t be outsourced and it can’t be faked.

The slide back effect when avoidance takes over, makes companies feel aligned rather than being aligned.

Which is when you start losing your strategy until only reaction is left.

You feel the insane drop beneath you, the planks are wobbling, cables are swaying, wind is catching you. Your soul and body are exposed. Fear is 100% natural. Still nearly everyone makes it across and once you’ve done it, the fear is replaced by familiarity. The exposure is normalized.

That’s where we are with AI. It feels dangerous, unpredictable, full of risk. FOMO and urgency escalate. But then, step by step, it becomes normal.

While the last two posts laid out the context of wild predictions and opened up the parallel to 1995 – pre the Internet revolution – this post is about that paradox: why awareness is a must, but panic is useless. Why hype and prophecy don’t help, but hands-on learning does. What helps is trusting your acquired foundation and being hyper aware of new options and grabbing some once a good one comes around the corner.

Stuck between hype and disillusion: Discovery time, not ROI

The numbers seem damning: According to most of the studies, the value creation around AI projects in companies fails in 80% – 95% of cases / projects. Some people think that’s a terrible number. I think that’s normal. People are learning when and where to apply AI step by step.

The first wave was simply using LLMs directly and wrapping a conversational interface or a chatbot around whatever service or product one provided. It’s the most straightforward, most direct way. But most of the time this simply ignores the customer: Does the customer want to have non-deterministic behavior, does he want a conversational interface? Does it make things better or worse? Or does it solve our own problem as a provider, that we actually don’t really know what the customer wants and think the LLM will figure it out and thus customize our mass product for our customer. But that’s not how things work. It does not solve a new customer problem. Mostly it solves an old problem, but worse. Gartner sees this wave of GenAI already on the “Trough of Disillusionment.”

The hype thing these days – still on the up – are agentic systems. As I said: Agents always follow quickly, because it’s a very tech idea. We can do it, so we build it and it satisfies the tech world dream of building autonomous machines. But for what? While this might open up new use cases, it will certainly not satisfy end users’ needs, given the limitations of LLMs listed above. Except in non-mission critical contexts. But then, it’s also really complicated.

The topics “agentic” and “AI-ready data” (being the basis of the work of agents) are listed in the phase of “Peak of Inflated Expectations.”

Vibe coding is already declining. And while the talk of the town is getting rid of those nasty human devs and customer agents, reports of what’s working successfully and sustainably are not overwhelming. A ton of CTOs are probably currently recalculating their 2026 budgets.

Interlude: price of tokens?

A funny, not often talked about side topic that I really like is the price of tokens. Currently no one selling tokens is making money off them. All of them are burning money and no one has a clue how OpenAI will ever become cash positive. The current business model is hope, and I don’t mean this cynical or negative. We need those pioneers. But in my fantasy, the day will come where a) those providers will realize that there is a certain vendor lock-in and b) that they could raise the prices for their tokens. Just like in cloud computing, the cost will rise. In cloud, companies first found that having people simply trigger the next instance and all that dynamic being unmonitored had a huge negative effect on cost (COGS). Providers realized that packaging and bundling and other ways of nifty price increases are a big deal. The same will happen to the price of tokens once the lock-in is sealed. Let’s see what this means for the millions of tokens that companies now blow liberally through the ether.

AI won’t go away. Just like the Net in 1995. The problem is you don’t yet know what works for you. Just like us in 1995. The way to deal with it is: go play. It is 100% essential that you make your whole company AI knowledgeable. It does not have to be very directed. You just mingle in AI and observe and become AI-literate. If you see one, commit on a small bet. And another one. You just need to show up, stay close to the development. You cannot miss it.

Three steps to keep up

1 – Immerse the whole company in AI

Involve the whole company in understanding AI. From payroll (“how can we reduce unnecessary manual routine labor?”) over marketing (“automated market and channel tracking?”), support (“which tickets are repetitive enough for AI to handle and can engineering help us automate?”) to finance (“in which areas of reporting can AI’s pattern recognition help us without dangers of hallucinations?”) and engineering (“how can we support other departments with our tech knowledge in reducing toil and how can we responsibly handle code with the support of AI, where does AI completely change our technical options?”).

2 – Treat it as discovery, not instant ROI and extraction

It will feel unsatisfactory. To some it will feel too fast, to some too slow. Too extreme, too undecided. It doesn’t matter too much. By focusing inside on reducing repetitive human labor first, you will instantly see some very pragmatic benefits and learn the technology and also its boundaries hands-on rather than from paper or LinkedIn half-knowledge.

By immersing yourself, be highly aware of bigger options to use your acquired knowledge towards outside-facing options: to really improve your customers’ lives.

This requires a strong stance on the next point:

3 – Stay anchored on your original vision and customers

All of this works only if you are stable in your vision and strategy. Stick to your vision. Stick to your niche, to the customer problems you want to solve. It’s tempting to get distracted by new options. It’s expensive and mostly damaging to simply switch the problem space. Your customer knows you for a certain problem you are solving. Stick to your long-term goals and be creative on short/mid-term options where there is an obvious bet. Stick to the rule that a good option has huge upside and low downside. Which firstly means that it can’t sink the ship. Don’t be blinded by tech optimism and change long-term trajectory for short-term enthusiasm-based tech solutions. It never pays off. Discipline is the word. It now pays off to have been explicit in your vision and what makes you different from the competition. Don’t surrender those past efforts.

Stay aware, act normal

Those who had the first successes after 1995 did not know what they were doing. They totally fulfilled the

“Stockdale Paradox”: “confronting the brutal facts of your current reality while maintaining unwavering faith that you will prevail in the end”!

Another one of those dialectic truths. Go all in with heads off, not knowing the outcome but hoping for the best. It sounds like handwaving and haha-ing our way through life, but remember: there is no certainty except: AI is here to stay and you better learn to co-exist. But there is no direct way to making it a success. You need to learn and be aware.

When the only certainty is uncertainty: Don’t listen to the prophets – instead immerse yourself in the uncertain reality (you know it best), look for small bets, fast learning, and the humility to be wrong. That’s how revolutions are not only survived – but used for your good.