AI eliminated the reps that used to build judgment as a side effect. If you want to develop judgment now, you have to seek it deliberately.

• The traditional ladder (write specs, ship V1s, debug production) built judgment accidentally. That ladder got pulled up.

• Not all friction is bad. AI removes bureaucratic friction. The friction that built judgment was reality friction. Keep it.

• The people treating AI as a productivity tool are getting faster. The people treating judgment as a practice are getting more valuable. The gap is widening.

You Took the Diagnostic

In the last post, I asked you two questions. What would you have contributed if AI had produced every artifact for your last feature in two hours? And when did you last sit with a real user?

If you loved your answers, this post isn’t for you.

If you didn’t, keep reading. Nearly every high performer I’ve talked to since that post is feeling some version of the same thing. Strong track records, promoted fast, trusted with hard problems. The version I keep hearing: “I feel like my strengths aren’t strengths anymore.”

These aren’t people who lack skill. They’re people whose skills were validated by an artifact-production model that is now compressing. The fear isn’t incompetence. It’s relevance.

Your strengths aren’t obsolete. The system that rewarded them changed. What follows is how you rebuild on different ground.

Three Readers, Three Problems

Not everyone reading this is in the same position.

If You’re Senior or Executive-Level

You probably have more judgment than you realize. Thousands of decisions, hundreds of customer interactions, dozens of product failures. Your problem isn’t a judgment deficit. It’s that you’ve never explicitly named what you do as judgment.

Stop apologizing for the fact that you think for a living. The shift is naming your judgment, leaning into it deliberately, and dropping the reflex to prove value through artifact production.

A distinction worth being honest about. Twenty years of varied decisions across different contexts, with real feedback loops, builds genuine depth.

Twenty years of the same call in the same domain builds pattern-matching that works until the frame breaks. AI is breaking the frame. If your experience has been narrow, the mid-career section below may be a better fit.

For those with genuine depth: your next move is naming what you already do. What are the three things you always push back on in reviews? What patterns make you uneasy before you can articulate why? Name them. The “Naming Your Judgment” section later in this post will show you how.

If You’re Early in Your Career

Here’s the good news first. For the first time, a PM can build a working prototype that demonstrates their judgment in action. You don’t need permission, a team, or a quarter of engineering time. You can show your thinking in a working product, not a slide deck.

But the portfolio isn’t the prototype. It’s the judgment trail behind it. Why this problem. Why this solution. What was killed along the way.

Now the honest part. The traditional path that built judgment for the people above you is disappearing. Junior PMs used to write dozens of specs before developing intuition about what makes a good one. Junior engineers used to debug production incidents until they could smell architectural risk. Junior designers used to iterate through dozens of mocks before developing taste.

Those reps are compressing or vanishing. AI writes the first draft. AI suggests the architecture. AI generates the variations. The reps that built judgment as a side effect of doing the work are being removed from the work itself.

You don’t build muscles by watching workout videos. You build them by doing the reps. If you have a job, seek out the hardest judgment calls on your team and volunteer for them. If you don’t, pick a real problem and build a real solution. Not a case study. A working product.

If You’re Mid-Career

You have some judgment and some artifact skill. Your daily work is a mix of both. The shift isn’t dramatic. It’s a gradual reallocation: less time polishing documents, more time in the activities that sharpen judgment.

The danger is that this reallocation feels unproductive. You’ll feel like you’re doing less. You are doing less, of the thing that’s compressing in value. The question is whether you’re filling that time with the thing that’s appreciating.

Here’s a filter. Writing a strategy doc is one task, but the 10x impact lives in the thesis and the bet, not in the formatting or the appendix.

The 10x question: For any piece of your work, ask: if I were 10x better at this specific part, would it produce 10x the outcome? Where the ceiling is low, automate ruthlessly. Where it’s high, protect and invest.

The Friction You Actually Need

Most people celebrate AI’s speed without noticing what the speed removed.

Bureaucratic friction (formatting requirements, status update meetings, elaborate quarterly planning ceremonies, manual reporting, copy-pasting between tools) doesn’t improve the quality of anyone’s thinking. AI is excellent at removing it, and good riddance.

Reality friction improves the quality of your thinking. It’s the resistance you encounter when your beliefs meet evidence. A customer who contradicts your thesis. An assumption you test and find wrong. Data that challenges what you believed.

This friction doesn’t slow work for the sake of slowing it. It slows work at exactly the moments where speed would substitute polish for understanding.

When AI removes all friction from your workflow, it removes both kinds. A PM who iterates a product doc through AI feedback ten times in an afternoon will produce a polished document. But if none of those iterations involved a customer, an uncomfortable assumption, or evidence that challenged the thesis, the friction removed was the kind they needed most.

The new reps are deliberate reality friction. Practices you choose to keep in a world that’s making everything frictionless.

The New Reps

These aren’t productivity hacks. They’re the equivalent of a doctor’s clinical rotations. Four practices that build judgment when the old path through artifact production is gone.

Proximity Reps

The PM who knows their customer deeply generates prototypes grounded in reality. The PM who builds based on how they feel about the problem generates prototypes grounded in projection. AI makes this gap catastrophically wider. The disconnected PM goes from assumption to polished-looking-but-wrong prototype in two hours. Polish masquerades as insight.

The practice: one customer conversation per week. Not a survey. Not a dashboard. A conversation where you can ask follow-up questions and notice what they don’t say. Watching users use your product, not reading summaries about how they use it.

After each one, write one sentence about what surprised you. If nothing surprised you, your sample isn’t varied enough.

When we were building an enterprise API platform, I assumed the decision was which API gateway to license. The safe path was obvious: pick the vendor backed by the Gartner quadrant and move on. Nobody would have questioned it.

Then I talked to the developers who would actually use it and the business stakeholders who would sell through it. The surprise: nobody cared about the gateway. Gateways are commodities. What developers wanted was the experience around the gateway: discovery, exploration, try-before-you-buy, quick-start guides, monetization hooks, support. We built an end-to-end platform shaped by those conversations.

I walked in with a vendor selection question. I walked out building a different product. That reframe didn’t come from a dashboard or a competitive analysis. It came from sitting across from the people who would use the thing.

Decision Reps

Judgment develops through making calls with incomplete information and tracking whether they were right.

AI makes it easier to avoid this. You can always generate one more analysis, one more scenario, one more option set. The tool becomes the avoidance mechanism. But the decision itself is the rep. Not the safe decision that everyone agrees with. The judgment call where reasonable people would disagree, where you’re taking a position based on your read of the situation.

The practice: when you make a non-obvious call, write down what you believe and why before the outcome is known.

Revisit in 30 days. The goal isn’t a batting average. It’s calibration: learning which signals you overweight and which you miss.

Kill Reps

The most undervalued judgment skill is knowing when to stop.

Before AI, killing a project was painful because building was expensive. You’d invested a quarter of engineering time. Sunk cost made killing feel wasteful. Now building is cheap, which should make killing easier. But it doesn’t. You can build a prototype in an afternoon, and the prototype looks good, so the emotional case for continuing gets stronger even when the strategic case doesn’t.

The practice: pick one thing on the roadmap and ask: “If we had never started this, would we start it today?” Not “does the prototype work” but “would customers choose this over doing nothing?” If the answer is no, ask why it’s still alive.

Early in the cloud migration wave, we partnered with a middleware vendor who pitched a compelling story to our executives: a seamless bridge from legacy to cloud without rearchitecting. The thesis made sense on paper. We started the work on one of our largest, most complex product areas.

A few months in, the signal was clear. The “seamless bridge” was adding a layer of abstraction that would age poorly. The cloud-native path was harder, but it was where the industry was going. Every month we spent on the intermediary was a month we weren’t building the real thing.

We killed the partnership and redirected the resources to go cloud-native. The decision wasn’t popular. The original pitch still looked good in slide decks. But the thesis underneath it had expired. The hardest part of killing it wasn’t the sunk cost. It was that the original logic was still defensible. It just wasn’t current.

Wrongness Reps

This is the uncomfortable one. Deliberately reviewing where your judgment failed.

Not a retro designed to make everyone feel okay. A private, honest examination of the calls you got wrong. The feature you championed that customers ignored. The assumption you carried too long. The competitor signal you dismissed.

The practice: monthly, pick one judgment call that didn’t land. Reconstruct your reasoning at the time. Not what you couldn’t have known, but what was available and you didn’t weight correctly. This is the rep that separates people who have ten years of judgment from people who have one year of judgment repeated ten times.

A note on AI scaffolds. Review tools, rubrics, and frameworks can accelerate the early stages of all four reps. Use them when you’re learning the territory. But recognize when the scaffold is doing the cognitive work for you.

A PM who prepares for a hard review by asking “what will my leader challenge?” is practicing the skill of finding their own blind spots. An AI pre-review that answers that question in advance shifts preparation from “find my blind spots” to “fill in the blanks.” The output looks identical. The learning is categorically different. The scaffold should come down before it becomes load-bearing.

Naming Your Judgment

If you’re experienced, the four reps above will sharpen skills you already have. But there’s a practice specific to your level: making your judgment explicit.

Most experienced leaders have never named their judgment model. They review a product doc and have a reaction. They push back in a meeting. They redirect a team. But ask them “what are your three recurring questions when you evaluate a product decision?” and they struggle to articulate it.

What they think is intuition is actually a set of structured heuristics they’ve never made explicit.

Here’s what the exercise looks like. A product leader sits down to answer one question: “What do I always push back on in reviews?” They start listing:

• Has the PM talked to customers directly?

• Is the hypothesis named and falsifiable?

• Is the pre-mortem honest or performative?

• Is opportunity cost acknowledged?

• What’s the strongest case against this?

They end up with eleven dimensions. Not invented from theory. Extracted from years of their own review conversations.

Then they go further. They add gates: before the review even starts, has the PM talked to customers directly? Were they surprised by anything they heard? If not, the review doesn’t proceed. Not because the rubric says so, but because the leader knows from experience that a doc built without customer contact isn’t worth reviewing at the detail level.

This is the portable layer of judgment: your repeatable questions, standard frameworks, and known failure modes. The stuff you can name and encode.

The live layer is different: recognizing when your own framework doesn’t apply. You can only develop it through direct exposure (that’s what proximity reps and wrongness reps are for). But the better you articulate the portable layer, the more bandwidth you free for the live layer. You stop spending energy on the patterned decisions and start noticing where the patterns break.

Stepping Back

The AI discourse is dominated by tools, techniques, and capabilities. Learn this framework. Master this prompt pattern. Use this tool. Technical proficiency is a real advantage, and it’s foolish to ignore it.

But the deeper game isn’t tools. It’s the quality of thinking you bring to what the tools produce. The tools will keep getting better. The quality of thinking will only improve through the specific practices in this post.

The irony is that the people most drawn to AI productivity tools are often the people who most need to slow down and do the judgment reps. The tools feel productive. The reps feel slow.

The order matters.

Treat judgment development as continuous. Not something you did on the way up and left behind. A permanent practice, like a surgeon who continues clinical rounds regardless of seniority.

In Practice

Pick the rep that maps to your biggest gap:

• If you can’t remember your last customer conversation: Proximity reps. Start Monday.

• If you make safe decisions that everyone agrees with: Decision reps. Start logging the calls that scare you.

• If you keep features alive too long: Kill reps. Ask “should this exist?” before “is this good?”

• If you haven’t examined a recent failure honestly: Wrongness reps. Pick one. Reconstruct.

• If you can’t articulate what you review for: Name three of your recurring questions. That’s where the “Naming Your Judgment” work begins.

Not all five. One. The one where your answer is weakest. That’s where judgment grows.

Next in this series: how customer diagnosis and solution evaluation work in practice when AI is doing the building. That’s where the judgment reps meet the daily work.

AI collapsed the production layer of knowledge work. The existential question isn’t whether AI will take your job. It’s whether you were ever providing judgment or just producing artifacts.

• Specs, code, designs, prototypes: all producible in minutes now. If your value was the artifact, you have a problem.

• Judgment (deciding what to build, evaluating whether it’s right, knowing when to kill it) is the durable skill. It applies across PM, engineering, and design.

• Speed without judgment is dangerous. The faster you can build, the more judgment matters, not less.

The Question Everyone Is Asking

A few weeks ago, a senior executive I know well pulled me aside after an alumni reunion. Twenty years of experience. Strong track record. Led large teams through multiple product cycles. He asked me, quietly: “With everything AI can do now, do they still need someone like me?”

He’s not alone. I’ve heard versions of this from PMs, engineers, engineering managers, and designers. It shows up in three flavors. “I don’t know where to start with AI.” “I’m not technical enough to survive this.” “My entire role is at stake.”

Different words, same fear underneath. And it’s not just hallway anxiety. It’s a boardroom strategy.

The people building AI are saying it plainly. Anthropic’s CEO Dario Amodei wrote in January 2026 that AI will “disrupt 50% of entry-level white-collar jobs over 1 to 5 years” and called the coming disruption “unusually painful.” Mark Zuckerberg told investors that AI will do the work of mid-level engineers.

And the enterprise results are already here. Klarna’s AI agent handles the equivalent work of 850 human agents, and the company has seen a roughly 50% workforce reduction through attrition since 2022. Salesforce cut its customer support headcount from 9,000 to 5,000. Block cut 40% of its workforce, with Jack Dorsey explicitly attributing it to AI enabling smaller teams.

These are not pilots. These are not experiments. This is the new operating reality at companies with tens of thousands of employees. The question that the executive asked me is the question the entire industry is asking. The rest of this piece is my answer.

The Misdiagnosis

I know a PM who spent a weekend taking a prompt engineering course. An engineer who doubled down on LeetCode prep. Multiple designers who started learning to code. All smart, driven people. All responding to the same instinct: the threat feels technical, so the solution must be technical too. Learnable. Controllable.

But the threat isn’t technical. The threat is that your value was defined by the artifacts you produced.

For decades, specs, code, mockups, and test plans were the job. You produced them, stakeholders consumed them, and the quality of the artifact stood in as a proxy for the quality of your thinking. AI now produces those artifacts. Fast, cheap, and increasingly well.

If the artifact was your value, then yes, you have a problem. But the artifact was never the real value. It was a container for something else.

That something else is what this piece is about. Not the organizational shift (I’ve written about that). This one is about you. What’s left when the artifacts disappear?

What Judgment Actually Is

An AI tool generates a prototype in two hours. Two people review it. One says, “Looks great, let’s show stakeholders.” The other says, “This solves the wrong problem. The user doesn’t need a dashboard; they need an alert that fires before the problem happens.”

Same prototype. Same tool. Same speed. The difference is judgment: the ability to distinguish between correct and right.

Correct means it works as specified. Right means it solves a problem worth solving, for a person who actually has that problem, in a way that fits how they work.

What remains when production collapses is this distinction, applied dozens of times a day. Deciding what to build and, harder, what not to build. Evaluating whether the output is right for the problem. Knowing when to kill something that isn’t working, even when the team is excited about it.

Shaping iteration toward an outcome that matters, not just toward something that looks finished.

This isn’t one skill. It’s knowing your customer deeply enough to spot the wrong problem before anyone builds it. Understanding your business model well enough to kill a feature that users love but economics don’t support. Reading a stakeholder’s objection and knowing whether it’s political or substantive. The instinct that says “this will break at scale” before anyone runs a load test.

None of these are AI skills. They’re accumulated through proximity, reps, and paying attention. AI doesn’t replace any of them. It just makes them the only ones that matter.

The value is shifting from production to judgment, and from judgment to the speed of the judgment loop. How fast can you go from insight to prototype to validated learning? That loop speed is the new measure of effectiveness.

Klarna’s CEO, Sebastian Siemiatkowski, put it bluntly: during the first two years of their AI strategy, they focused on hiring engineers. Then it “switched, actually. It’s almost the opposite.” The business knowledge of non-coders, people who can use AI to build, but also know what dashboards or features are needed, has become more valuable.

The engineers? “They’re like, ‘okay, I coded this feature. What do I do next?” That’s the artifact-producer without judgment, described by a CEO who’s lived through the transition.

The Same Shift, Every Role

Siemiatkowski was describing engineers. But the pattern is identical across every knowledge work role. Wherever the artifact was the identity, the same reckoning is happening.

Developers who define their value as “I write clean code” are in the same position as PMs who define their value as “I write good specs.” The artifact is being commoditized.

The junior dev valued for cranking out CRUD endpoints? Fully automated now. The mid-level dev valued for React expertise and well-structured components? AI does that reliably. Even the senior dev who prides themselves on elegant architecture gets nervous when Claude Code scaffolds a whole system in minutes.

But here’s where it gets interesting. The developer who looks at AI-generated code and says, “This won’t survive 10x load,” or “this data model becomes a nightmare when we add multi-tenancy,” or “this is solving the wrong problem at the wrong layer.” That person is more valuable than before, not less.

AI produces plausible code at incredible speed, and the cost of bad judgment is now multiplied by the speed of production.

The PM who can go from customer insight to a validated prototype in a day. The developer who can evaluate, reshape, and stress-test AI output faster than the AI produces it. Both are operating as editors of AI output, not producers of artifacts.

The role is different. The judgment layer is the same.

The Uncomfortable Truth

Production was slow enough to hide weak judgment for decades.

When a spec took two weeks to write, nobody asked whether the PM had genuine insight or was just organizing inputs from stakeholder meetings. The slowness looked like rigor.

When code took a full sprint to ship, nobody asked whether the engineer understood the problem deeply or just implemented the ticket as written. The effort looked like a value.

When a design went through three rounds of review, nobody asked whether the designer was making real decisions or just iterating toward consensus. The process looked like a craft.

Think about how many sprint retrospectives you’ve sat through where the team debated velocity, story points, and estimation accuracy, but never once asked: “Was this the right thing to build?” The process machinery was so consuming that judgment never came up. The speed of the cycle was the measure of success, not the quality of the decisions that fed it.

AI compresses the timeline and makes the gap visible. The PM who never had a strong point of view now has nothing to hide behind. The engineer who never questioned requirements is exposed when AI can implement any requirement instantly. The designer who relied on iteration-toward-consensus discovers that AI converges on “acceptable” in minutes, and that was apparently all they were doing too.

The creamy layer, the top that rises to the surface, is the people who remain indispensable. Their judgment was always the real value. They also happened to produce the artifacts. AI just made this truth undeniable.

And the economics confirm it: Klarna’s workforce shrank by 50%, but revenue per employee went from $300,000 to $1.3 million. The people who stayed got more leverage and more compensation. As Siemiatkowski put it: “My employees know that they’re driving efficiencies, but they are also participating in getting the benefit of that.”

If AI writes the code, what is the developer? If AI writes the spec, what is the PM?

The answer is the same in both cases: you’re the person who knows what to build and whether it’s right. The ones who thrive are the ones who were always doing that. The ones who were primarily valued for the mechanical act of production are the ones in trouble.

The False Confidence Trap

Speed without judgment isn’t just useless. It’s actively dangerous.

Picture this: a PM uses AI to build a prototype in two hours. It looks production-ready. It has real interactions, plausible data, and smooth flows. The PM shows it in a stakeholder review.

Excitement builds. A team forms around it. A roadmap shifts. Resources redirect.

The prototype solved the wrong problem. But nobody questioned it because it looked so real. Polish masqueraded as insight.

The reasonable objection: “If I can build something in two days instead of two months, what’s wrong with getting it wrong? I’ll throw it away and start over.” For personal projects, this is genuinely true. The throwaway cost is trivial.

In an organization, nothing is truly throwaway. The artifact was cheap. The organizational momentum it created is expensive to reverse. Decisions crystallized around that prototype. A VP mentioned it in a board update.

The cost isn’t the code. It’s the conviction that builds around a convincing wrong thing.

And even individually, not all throwaway cycles are equal. The PM who builds and discards five prototypes grounded in deep customer knowledge is triangulating toward the right answer. The PM who builds and discards five prototypes grounded in vibes is just busy. One is iterating toward insight. The other is doing random walks.

Klarna learned this at the company scale. Their AI chatbot replaced the equivalent of 850 human agents. The efficiency metrics looked like a proof of concept. Then service quality declined, and the company had to rethink.

CEO Siemiatkowski now says they’re reversing course on full AI support: “We think it’s going to be like the future to offer human support. It’s going to be like the VIP treatment.” The initial metrics masked a judgment gap. Knowing which interactions need a human and which don’t is itself a judgment call, and they got it wrong by optimizing for speed alone.

What Fuels Judgment

If judgment is what remains, what fuels it? The answer is unglamorous: customer proximity.

Not quarterly research rituals. Not persona documents. Not reading a summary of someone else’s user interviews. Actual proximity.

Knowing your user’s workflow, their frustrations, their workarounds, the emotion they feel when something breaks.

The PM who knows their customer deeply generates prototypes grounded in reality. The PM who builds based on how they feel about the problem generates prototypes grounded in projection. AI makes this gap wider and the consequences steeper.

The informed PM goes from insight to validated prototype in a day. The disconnected PM goes from assumption to polished-but-wrong prototype in two hours. The speed of production amplifies whatever customer understanding you bring to it, strong or weak.

The existential fear (”AI will replace me”) asks the wrong question. What AI actually exposes is whether you were ever providing judgment value, or just organizing the process. Customer proximity is what separates the two.

The Existence Proof

My wife trades a specific swing trading strategy. Not day trading. Not position trading. Swing trading, with its own universe of techniques, edges, and traps. She has her own rules, her own stock universe, her own journaling discipline for every position she enters and exits.

There are dozens of commercial trading apps. Some do scanning well. Some handle journaling. None does all of it integrated into a single workflow that matches how she actually thinks about markets. So I built one for her, using AI as the execution layer. Real money is at stake, which means precision matters.

The application pulls real-time quotes, runs market scans, calculates position sizing and risk parameters, tracks opportunities through her specific pipeline, and journals every entry and exit. I’m not reviewing code line by line. The judgment that mattered was knowing her domain deeply enough to specify what “right” looked like.

A quarter of the way in, I hit a wall. I’d started with a rapid prototyping framework that worked for the initial build. But the app needed real-time streaming for live price tickers and direct front-end integration with multiple APIs. The framework’s architecture wasn’t built for that interaction pattern.

Could a more experienced developer have made it work? Maybe. But the point isn’t the technical choice. The point is that I recognized the mismatch because I understood the need, not because I understood the framework’s internals.

I redirected to a stack built for the interaction model the app required: proper streaming, direct API calls, and a front-end architecture that matched how a trader actually uses the tool. That decision was the needs driving the tech, not the other way around. Someone without domain knowledge wouldn’t have known the current behavior was wrong. The judgment to redirect early, a quarter of the way in instead of all the way through, came from understanding what the user actually required.

If I’d been wrong about her workflow, if I’d been building from assumptions instead of proximity, AI would have helped me build the wrong thing beautifully. Twice. The tool is neutral. Judgment is the variable.

Stepping Back: What It Means for You

Remember the executive from the beginning of this piece? Twenty years of experience, strong track record, asking quietly: “Do they still need someone like me?”

Here’s my honest answer to him, and to you: it depends on what “someone like you” actually means.

If it means the person who coordinated the team, organized the process, and delivered the artifacts on time, then the ground is shifting under your feet. That’s real. Pretending otherwise helps no one.

Roles will compress. The disruption is already happening, and it will accelerate.

But if “someone like you” means the person who knows the customer deeply enough to spot the wrong problem before it’s built, who has the judgment to redirect a team when the polished prototype is solving the wrong thing, who understands the domain well enough to know what “right” looks like before anyone writes a line of code, then you’re more valuable than you were a year ago. Not less.

The path forward isn’t “learn to code” or “learn to prompt.” Those are technical solutions to a judgment problem.

The Judgment Diagnostic

Here’s something concrete to do this week.

Pick the last feature or project you shipped. Ask yourself one question: if AI had produced every artifact (the spec, the code, the design, the test plan) in two hours, what would you have contributed that the AI couldn’t?

If your honest answer is “I coordinated the team” or “I wrote the requirements clearly” or “I implemented it cleanly,” that’s the artifact layer. That’s what’s compressing.

If your answer is “I knew this was the right problem because I’ve watched 30 customers struggle with it” or “I caught a flaw the team missed because I understood the second-order effects” or “I killed a direction that looked promising because the unit economics didn’t work,” that’s judgment. That’s the layer that becomes more valuable, not less.

Be honest about which answer is yours. Not which answer you aspire to. Which one is true today.

Then ask: when was the last time you were with a real user? Not reading a research summary. Not reviewing analytics. Actually watching someone use your product or describe their problem in their own words.

If you can’t remember, that’s your starting point. Not learning to prompt. Getting closer to customers. That’s where judgment comes from, and judgment is what remains.

If you did this exercise and didn’t love the answer, the next post is for you. Judgment isn’t fixed at birth. It can be cultivated deliberately. But the path isn’t what most people expect. More on that soon.

In case you missed it, my earlier post on the topic:

• The separation of Product, Engineering, and Design was an artifact of expensive building. That constraint is gone.

• The new competitive unit isn’t a cross-functional team. It’s a domain expert with judgment and AI leverage.

• Moats have shifted from what you build to how deeply you understand who you build it for.

Three Builds, One Pattern

My wife trades a specific swing trading strategy. Her own rules. Her own universe of stocks. Her own journaling discipline for every position she enters and exits.

There are commercial trading apps. Dozens, in fact. Some do scanning well. Some handle journaling. Some are strong on position management.

None does all of it the way she needs it, integrated into a single workflow that matches how she actually thinks about markets. So she’s always stitching tools together, compromising on one dimension to get another.

So I built one for her. Not a toy. Real money is at stake, which means precision matters.

The application pulls realtime quotes, runs market scans, calculates position sizing and risk parameters, tracks opportunities through her specific pipeline, and journals every entry and exit. Under the hood, it integrates with multiple data providers and systems. When your P&L depends on the accuracy of what’s on screen, “close enough” isn’t an option.

I’m not an engineer. I used to be, a long time ago. That background helps at the margins: I know the terminology, and I have intuition for what an AI assistant means when it discusses system architecture.

But I’m not reviewing code or debugging implementations. I built this because I understood her domain, I knew what “right” looked like for her workflow, and the distance between “I want this” and “this exists” has collapsed to a conversation with an AI coding tool. The skill that mattered was product judgment, not engineering expertise. And the biggest barrier for most people isn’t technical skill; it’s the mental block that says “I can’t build software.”

Then I built a workout tracker for the family. An iOS app that does exactly what we need. A few more iterations and our Strava subscription cancels. Not because Strava is bad. Because its value proposition was building what I couldn’t build myself, and that constraint no longer holds.

Then, in a professional context (that I can’t talk freely yet): enterprise-grade software, built in compressed timeframes that would have been a full quarter’s roadmap a year ago. Not a prototype. Not a toy. Production-ready, with feature upgrades beyond the existing solution.

Three different scales: personal, consumer, enterprise. The complexity is genuinely different. A personal tool answers to one user. Enterprise software answers to SLAs, compliance requirements, and thousands of concurrent users.

What you need around each is different: the trading app needed my judgment alone; the enterprise project needed a small team of domain experts. But the pattern is the same. In none of these was I acting as an engineer. I was acting as a domain expert with AI leverage, deciding what to build, evaluating whether it was good, and directing an AI to handle the implementation.

The interesting question isn’t that I could do this. It’s what it means for the way we organize teams, companies, and entire industries around building software.

This Isn’t Just Me

A reasonable objection: “Sure, you built some personal tools. But is AI-generated code actually production-grade?”

The data from the last twelve months says yes. Decisively.

The head of Claude Code at Anthropic hasn’t opened an IDE in months. He shipped 259 pull requests and 497 commits in a single month, all written entirely by AI. Anthropic reports that 70 to 90 percent of their code company-wide is now AI-generated. At OpenAI, nearly all engineers now use Codex, merging 70 percent more pull requests weekly.

Spotify’s co-CEO told investors on their February 2026 earnings call that the company’s best developers “have not written a single line of code since December.” Engineers use an internal system integrating Claude Code with Slack: direct a bug fix from your phone on the morning commute, receive a working build before you arrive at the office.

But here’s the distinction that matters: not all AI coding is equal. Early studies showed AI-assisted code introducing more bugs and higher churn. Those studies measured developers using basic code completion: autocomplete on steroids.

The real shift happened with agentic tools. Systems like Claude Code and Codex don’t just suggest the next line of code. They understand entire repositories, navigate across files, run tests, interpret failures, and iterate autonomously. The gap between prompting a model and directing an agent is the gap between dictating to a typist and collaborating with an engineer who works at machine speed.

SWE-bench, the industry standard for measuring AI’s ability to resolve real software engineering tasks, went from a 2 percent resolution rate in early 2024 to over 80 percent by late 2025. A 40x improvement in under two years. At the frontier companies, the shift has already happened. For the next tier, it’s happening now. The direction is not in question.

The scale shows up in the commit logs. Claude Code alone now accounts for 4 percent of all public GitHub commits, with SemiAnalysis projecting 20 percent by end of 2026. That only counts commits explicitly attributed to the tool, and it’s only one tool. Factor in unattributed usage and competitors like Codex, and the real share of AI-authored code is already considerably larger.

This matters because agentic AI changes what the human needs to do. You’re no longer writing code or even reviewing code line by line. You’re setting direction, evaluating output, managing context, and deciding when to reframe a problem the AI is stuck on.

Sitting back and asking the agent to do everything produces useless output packaged beautifully. The builder has to be an active orchestrator, learning and refining tactics with every feedback loop. That skill compounds.

This piece isn’t about pasting code from a chatbot. It’s about domain expertise and active orchestration producing production-grade software. That capability is real, it’s here, and it changes the economics of everything downstream.

Why the Roles Blurred

The separation of Product Management, Engineering, and Design into distinct functions was never a law of nature. It was an economic response to a constraint: building software was expensive.

To be clear: the underlying skills are real and valuable. Understanding users deeply is a craft. Visual and interaction design is a craft. Systems architecture is a craft. None of that goes away.

What was an artifact of cost was the organizational separation of these crafts into distinct roles connected by handoffs.

Product Management existed to reduce waste. When building the wrong thing cost six months of engineering time, someone needed to figure out what to build before the meter started running. The entire discipline of product discovery (user research, prioritization frameworks, roadmap negotiations) was a risk mitigation strategy against the high cost of building.

Design existed to get it right before implementation. When a redesign meant throwing away a full sprint of engineering work, you needed high-fidelity mockups and usability testing upfront. Iteration was too expensive to do in code.

Engineering existed as a distinct, specialized discipline because writing code was the scarce skill. Translating business requirements into working software required years of training and hard-won experience.

Each function represented genuine expertise. Together, they created an organizational structure optimized for a world where building was the bottleneck.

That world is gone for the companies paying attention. For the rest, it’s going. The timeline is the only question.

When building costs approach zero, when you can prototype in hours, iterate in minutes, and ship in days, the rationale for separating these functions into handoff-based pipelines dissolves. You don’t need a separate design phase when redesign costs nothing. The entire waterfall-in-disguise that most “agile” teams actually run becomes overhead without a purpose.

The spec doesn’t die, but it transforms. Writing is thinking, and the discipline of articulating what you’re building and why remains valuable. But the spec as a handoff document between PM and engineering loses its reason to exist. It becomes a living collaboration artifact between the builder and their AI tools: a place where agents surface gaps in your thinking, suggest directions you haven’t considered, and keep context updated as the product evolves.

The Abstraction Layer Shift

What happened is a steady climb in the layer of abstraction at which builders operate.

At each step, the barrier to entry dropped and the relevant skill shifted. When the abstraction layer was code, you needed an engineer. When it was frameworks, you needed a full-stack developer. When it was APIs, you needed a product engineer who could wire services together.

Now the abstraction layer is intent. The builder works in natural language. The AI handles implementation. The bottleneck is no longer “can you build it?” It’s “do you know what to build, and can you tell whether it’s good?”

The New Builder

The old hiring question was: “Can this person build it?”

The new hiring question is: “Does this person know what’s worth building?”

Think of it as a Venn diagram. On one side, the PM who develops technical comfort and leans into AI as a building tool. On the other, the engineer who builds genuine product sense and judgment about what’s worth creating. The new builder lives in the overlap.

The people who struggle are on the edges: PMs who only coordinated without developing product instinct, engineers who only wrote code without building judgment about what to build. Both roles, as traditionally defined, are under pressure. The intersection is where the leverage lives.

When code is commodity, five things define that intersection:

1. Discernment. Knowing what good looks like. And, harder, knowing what “good enough” looks like. The ability to evaluate AI-generated output and decide whether it meets the bar. This is the quality of your internal evaluation function, and it compounds with experience.

2. Judgment. What to build. What to kill. When to ship. When to stop iterating. These are product decisions, but they’re no longer the exclusive domain of product managers. Anyone building with AI is making these calls continuously, in real time, as part of the building process itself.

3. Domain depth. Understanding the problem space better than a model can infer from its training data. My wife’s trading rules aren’t in any dataset. The specific compliance requirements of a regulated industry aren’t captured in a general-purpose model. Domain expertise is the input that makes AI output actually useful.

4. Systems thinking. Not writing the code, but understanding how the pieces interact. Where the failure modes live. What breaks at 10x scale. What the second-order effects of a design decision are. This is engineering judgment without the engineering implementation. It becomes more valuable, not less, when AI handles the implementation.

5. Distribution instinct. When building is free, the only true waste is building something nobody uses. Distribution isn’t marketing. It’s the instinct to put something in front of real users fast, read their reaction, and iterate. The builder who ships to 5 real users on day one learns more than the builder who perfects in isolation for a month. Distribution is part of the building process now, not a phase that comes after.

Think of it like a film director. They don’t operate the camera. They don’t edit the footage frame by frame. But they know exactly what the shot needs to look like, why this scene matters to the story, and when to call cut. The quality of the film depends on their vision, not their technical execution.

The new builder is a director, not a camera operator. And like a director, they have checks and balances: build a feature in one session, then open a fresh session and ask it to review what was built as an independent consultant across architecture, coding standards, tests, and spec. Agents checking agents. More rigorous than most human code review, if you set it up deliberately.

But this raises an uncomfortable question. If a smaller subset of people with domain knowledge, discernment, and AI leverage can build production software in hours, what exactly is the 40-person product organization doing? Not all 40 are doing coordination work. But more of them than anyone wants to admit.

The Agile Industrial Complex

Here’s the honest answer: most of what a large product organization does is coordination.

Standups to sync blockers. Planning poker to estimate specialist effort. QA handoffs.

Backlog grooming sessions that are really prioritization theater. Status updates. The weekly sync about the other weekly sync.

These aren’t make-work. They’re genuine solutions to a genuine problem: when building requires many specialists working in concert, you need mechanisms to keep them aligned.

Not all rituals are equal, though. Retrospectives (learning from what happened) and architecture reviews (systems thinking across a complex product) remain valuable even in small teams. What becomes overhead is the coordination machinery: the rituals that exist to synchronize handoffs between specialists.

I call this the agile industrial complex. Not to be dismissive of the people who operate within it, but to name what it is: an organizational structure purpose-built for a constraint that is rapidly disappearing.

If one person can hold the full context of what needs to be built, the coordination cost drops to zero. No handoff from PM to engineering. No translation from design mockup to code. No standup to sync on who’s blocked. The entire overhead vanishes. Not because it was wasteful, but because the problem it solved no longer exists at the same scale.

What Dies, What Survives

What dies is the coordination layer. Scrum masters. Program managers. Release managers. Managers whose primary function is orchestrating handoffs between specialists.

An important distinction: managers whose value is orchestration go. Managers whose value is technical mentorship, architecture guidance, or strategic prioritization transform into the domain experts the new model needs. They don’t disappear; they become more leveraged.

What survives, and becomes more valuable, is domain expertise. This deserves more attention than the things that die, because this is where the opportunity lives.

When a product needs to scale, you still need someone who deeply understands operational reliability. When it operates in a regulated industry, you still need someone who knows compliance inside and out. Security, infrastructure, data governance: these require genuine expertise that AI can augment but not replace. These experts, wielding AI, become dramatically more productive than the teams they replace.

The critical distinction is this: you need the expert, not the team.

CapabilityOld ModelNew ModelBuilding features8-person squad (PM, 4 engineers, designer, QA, EM)1 to 2 domain experts with AI leverageScale and reliabilityOps team of 6Ops expert + automated infrastructureSecurity and complianceSecurity team + audit cyclesSecurity expert directing AI-powered toolingCoordinationManagers, scrum masters, program managersRadically lighter. Organic alignment replaces managed coordination.

This is not the argument that one person can do everything. At enterprise scale, you still need teams. But the difference is why the team exists. In the old model, the team existed to coordinate the act of building. In the new model, 3 to 5 domain experts collaborate because their domains intersect, not because the building process demands it. The team’s value is combined judgment, not coordinated labor.

The expert who knows what needs to be true in security, in compliance, in operational resilience becomes more leveraged than ever. The coordinator who existed to manage the handoffs between those experts and the engineers who built things? That’s the role the new model no longer requires.

Two Games, Two Moats

The AI era splits software into two fundamentally different games. The rules are different. The moats are different. Conflating them is a strategic error.

Game 1: Build for Myself

I built a trading application and a workout tracker with zero intention to monetize either. This category is growing fast. For friends-and-family scale, you just deploy and start using it. No distribution required. No go-to-market strategy. No fundraising.

The impact on SaaS is death by a thousand cuts. Every customer who builds their own tool is a cancelled subscription. Not a competitor. Something worse. A customer who simply doesn’t need you anymore. They didn’t switch to an alternative. They just... left.

The Strava example is instructive. What was Strava’s moat against me building my own tracker? Feature parity? I’ll match it in weeks. My data? It lives on my phone; they don’t own it. Their brand? Irrelevant to a user who can build exactly what they need.

What might survive is Strava’s social graph: the community, the leaderboards, the network effects. But the core product (tracking workouts, analyzing performance) is pure commodity now. The moat was never the features. It was the assumption that users couldn’t build those features themselves.

Game 2: Build for Others

If features are increasingly cloneable, what actually defends a company?

The answer depends on complexity. A simple workflow tool or dashboard can be replicated in days. A compliance platform with jurisdiction-specific logic across 50 countries takes longer. But even for complex B2B software, the timeline to functional parity has compressed dramatically. What used to take a competitor years now takes months. What took months takes weeks. Feature accumulation is no longer a durable advantage.

What remains is harder to copy and slower to build:

• Depth of customer understanding. Knowing their problems before they can articulate them, because you’ve spent years immersed in their context.

• Relationship capital. Earned trust, demonstrated reliability, and switching costs built on consistent delivery.

• Proprietary data. Years of accumulated customer interactions, workflow patterns, and edge cases embedded in the product. A new entrant can clone your features but not your data. Feed that data into AI-powered systems and it becomes a compounding advantage that widens over time.

• Helping customers win. The value isn’t your product; it’s what your product enables them to achieve. How effectively are you making your customers successful?

The moat is not your product. The moat is how deeply you understand what your customer needs to succeed, and how effectively you help them get there. This is a knowledge moat, not a technology moat. The moment “build it myself” becomes easier than “this vendor truly understands my needs,” the subscription cancels.

In Practice: The Incumbent’s Playbook

For established companies, the org chart is now the biggest liability. It was designed for a world where building was expensive and coordination was the primary challenge.

A caveat: none of this happens overnight. No innovation is embraced equally across an ecosystem. There’s a bell curve of adoption, and the agile industrial complex has institutional defenders: SAFe training programs, Scrum Alliance certifications, an entire consulting industry built on the current model. It won’t go quietly.

But the organizations that resist this shift won’t just fail to thrive. They’ll fail to survive. The pace of AI acceleration is breathtaking. What felt like a 5-year transition window in early 2025 looks more like 18 months from where we stand now.

The prudent path for large enterprises is the lab model: make a small bet, prove the new operating model with a single team, measure the results, and expand gradually. Not a company-wide reorg announced at an all-hands. A quiet experiment that generates undeniable evidence.

Here are four moves that matter.

1. Collapse functional silos into outcome teams.

This is the structural move that everything else depends on. Not a “squads” rebrand with the same handoffs under a new name. Actual teams of 3 to 5 people with end-to-end ownership of a customer outcome. No PM-to-Engineering-to-Design pipeline.

Each person is a domain-expert builder with AI leverage who can take something from concept to production. The team exists to learn together, not to coordinate the building process. Start with one team. Give them a real customer outcome to own. Measure what happens. That’s your lab model in action.

2. Weaponize your data advantage.

Your accumulated customer data is the moat that strengthens with AI rather than weakening. Feed it into fine-tuned models. Train systems that get smarter with every customer interaction. Make your institutional knowledge a compounding advantage, not a static archive.

3. Invest in distribution, divest from differentiation.

Features are commoditized. Accept it. The assets that matter now are brand, trust, sales relationships, compliance certifications, and enterprise procurement approvals. These are slow to build, hard to fake, and genuinely defensible. Double down on them instead of trying to out-feature a startup that can ship faster.

4. Accept a smaller, more leveraged organization.

Same revenue. Fewer people. More leverage per person. This is the hardest move because it’s the most human one. It means acknowledging that roles people have built careers around may no longer be necessary.

But here’s what the leaner organization enables: faster decisions, shorter feedback loops, domain experts who are closer to customers and closer to the product. The companies that get this right don’t just cut costs. They move faster, learn faster, and build things that fit their customers better than the bloated competitor ever could. The constraint was never the number of people. It was the coordination overhead those people required.

The Startup’s Dilemma

Startups face the inverse problem. Starting has never been easier. Surviving has never been harder.

EraHard PartEasy PartPre-AIBuilding the productFinding a market (if the product was good)Post-AIDefending the productBuilding the product

The opportunity is real. A 2-person team can go from idea to production in days, at near-zero cost. You can test 10 hypotheses in the time it used to take to test one. The cost of failure approaches zero, which means you can afford more swings at bat. For founders with domain expertise and AI leverage, this is the best time in history to start a company.

But everything that makes it easy for you makes it easy for everyone else. If you can build it in a weekend, so can 500 other people. Every niche is suddenly crowded. Every feature you ship can be cloned before your launch post finishes trending.

So the startup game has shifted. Building is no longer the hard part. The hard parts are learning and distributing.

Speed of learning, not building. The winning team isn’t the one that codes fastest. It’s the one that goes from “shipped” to “understood why it failed” to “shipped the fix” fastest. Learning loops, not build cycles, are the competitive advantage.

Integration depth. Shallow tools get replaced overnight. Deep embedding in customer workflows, the kind where ripping out your product would mean rearchitecting their process, creates switching costs that survive the AI era.

Distribution as a first-order capability. In a crowded niche, the product that wins isn’t necessarily the best one. It’s the one people find first and trust most. Community, brand, go-to-market: these matter more when every competitor can match your features in a week.

Stepping Back: The Human Question

Everything above is an operating model framework. It’s clean and strategic and makes sense on a whiteboard. But operating models are made of people.

A lot of those people are about to find that the skills they invested years in (coordination, process management, translating between specialists) are the skills this new model no longer needs. The problem is structural, not personal.

There’s a counterargument worth engaging with: if building gets cheaper, demand for software explodes, and we need more people, not fewer. The Jevons Paradox applied to code.

I think that’s directionally right and strategically misleading. The freed capacity absolutely does create net new innovation. Humanity will tackle problems in the next two years that were logistically impossible last year.

But the “more demand creates more jobs” framing misses a critical variable: individual agency. The demand is for domain experts who can wield AI, not for the coordination roles the old model required.

The transition isn’t automatic. It takes real effort, real time, and the willingness to step outside a comfort zone that the market rewarded for years. This could be zero-sum for specific people who don’t make the shift. That’s the honest part.

The honest guidance, not optimistic spin but honest:

Pick a domain. Go deep. Become the person who knows what needs to be true in a specific area: compliance, security, customer success, an industry vertical, a technical discipline. Then learn to wield AI as your leverage to make those things true.

The path isn’t starting over. Consider the program manager who spent 3 years coordinating between the compliance team and engineering. They already understand the compliance domain better than they realize. The shift is recognizing which domain knowledge you’ve already accumulated and deepening it deliberately, rather than maintaining the generalist coordination skills that the market valued five years ago.

The market right now is flooded with generalists and starved for domain experts who can wield AI. The people who hear this early and redirect their trajectory will find themselves disproportionately valuable. The window is open. It won’t stay open indefinitely.

The Moat Is Clarity

The transition is real and it’s moving fast. Some of it is painful. But here’s what makes it exciting: for the first time, the distance between understanding a problem and solving it has collapsed to nearly zero. A domain expert with AI leverage can build in days what used to take teams months. A 2-person startup can test ten hypotheses before a traditional company finishes its planning cycle. Problems that were too niche, too expensive, too logistically complex to tackle are suddenly within reach.

More software will be built in the next two years than in the previous twenty. Most of it will be built by people who would never have called themselves builders before.

The operating model for when building is free isn’t a theory. It’s already here. The people who see it clearly aren’t waiting for permission. They’re already building.

The debate over the future of product management has been polarized. On one side, the “PM is Dead” crowd argues that AI automates the coordination layer, making the role obsolete. On the other hand, the “Tech-PM” advocates insist the role is simply shifting closer to the code.

Recently, LinkedIn picked a side. In a conversation with Lenny Rachitsky, LinkedIn’s CPO, detailed how they restructured their Associate Product Manager program (traditional product management training) and replaced it with the “Associate Product Builder” program. Their new mandate? Full-Stack Builders, while acknowledging that the specialists have a vital role to play. Not mutually exclusive, but there’s a trend building.

This isn’t just another tech company tweaking job titles; it is a signal that the market has moved. The era of the “Product Trio” (where a PM writes requirements, a designer draws mocks, and an engineer writes code) is buckling under its own inefficiency. In its place, we are seeing the rise of the Augmented Architect: a single operator who leverages AI to vertically integrate strategy, design, and execution.

This shift validates a harder truth: the administrative layer of product management is dying. The traffic cop who manages handoffs is being automated away. What survives is the Builder: someone who uses AI not just to speed up, but to reclaim the full creative stack.

Here’s what’s ahead:

• Why the Product Trio model collapsed under its own latency

• How LinkedIn built infrastructure to enable Full-Stack Builders at scale

• What “Building to Think” means and why it’s not the “jack of all trades” trap

• The three investments required to make this work in your organization

Why the trio is breaking down

The “Product Trio” (PM, Design, Engineering) wasn’t a mistake; it was a necessity. The complexity of the stack demanded hyper-specialization. One person couldn't master strategy, sophisticated UI systems, and distributed backend architecture simultaneously. Splitting the brain was the only way to scale.

For a decade or so, it worked. But it came with a hidden tax: Latency.

We built a supply chain of talent. The PM defines the ‘Why,’ Design defines ‘What’ it looks like, and Engineering defines ‘How’ to build it. Every handoff creates a delay, and every delay creates a leak. Context is lost when a strategy deck becomes a wireframe. Nuance evaporates when a wireframe becomes a Jira ticket.

To patch these leaks, we built an entire ecosystem of coordination. Far removed from the original Agile Manifesto, we invented the Agile Industrial Complex: a bloat of standups, retro rituals, and endless syncs.

...creating an artificial divide between the Product Manager (Strategy) and the Product Owner (Backlog). Now, we didn’t just have handoffs between functions; we had handoffs within the brain of the product leader.

This created a management nightmare. Entire career paths in Program Management emerged just to coordinate the coordinators.

Today, many Product Managers spend 70% of their week servicing this complex. They aren’t building products; they are managing the friction of the process.

The tragedy is what gets displaced. When a PM is drowning in ticket grooming and alignment meetings, the first thing to go is the customer. Ask a modern product team, “How many customers did you talk to this month?” and don’t be shocked when the answer is single digits, or zero. The system designed to build products has cannibalized the time needed to understand who they are for.

This latency tax was acceptable when the alternative was not building at all. But today, when AI can generate a functional prototype in 60 seconds, the calculus has shifted.

Building to think

When some industry voices warn against the “Full-Stack PM,” their argument is familiar: “Don’t be a jack of all trades and master of none.” They fear that asking a PM to code or design will dilute their focus on the customer.

This fear is rooted in an obsolete definition of “building.”

The goal of the Augmented Architect isn’t to replace the Senior React Engineer or the Principal Product Designer. You aren’t building production code to save money on headcount. You are Building to Think.

We need to distinguish between mastery and fluency.

• Mastery is your deep, irreplaceable expertise. For a PM, this is Customer Insight, Evidence, Strategy, and Inspiration.

• Fluency is the ability to use a tool well enough to unblock yourself.

The Augmented Architect uses AI to gain technical and design fluency, specifically to reinforce their product mastery.

• Customer Insight (Mastery): Instead of writing a spec and waiting two weeks for a mock, you use AI to vibe-code a functional prototype in one hour. You put it in a user’s hands immediately for feedback. Your technical fluency didn’t distract you from the customer; it got you to the customer faster.

• Evidence Mindset (Mastery): Instead of waiting for a data analyst to prioritize your ticket, you use an AI agent to query the warehouse directly. Your data fluency didn’t replace the analyst; it allowed you to validate your hypothesis instantly.

LinkedIn explicitly codified this (more on this below). They found that when execution is automated, the “human” responsibilities don’t disappear: they become the only things that matter. They define these as the Five Traits: Vision, Empathy, Communication, Creativity, and Judgment.

Notice what isn’t on that list: “Ticket Writing,” “Backlog Grooming,” or “Status Reporting.”

The “Jack of All Trades” critique misses the point. The Augmented Architect doesn’t do more work. They use AI to automate low-leverage coordination work, so they can spend more time on the high-leverage traits of Vision and Judgment. They aren’t diluting their role; they are distilling it.

Critics like to invoke the Swiss Army Knife analogy: you wouldn’t use one to build a house. They’re right, but they are missing the core point of this proposal. The Full-Stack Builder doesn’t use the Swiss Army Knife to frame walls and install plumbing. They use it to sketch the blueprint, test if the foundation makes sense, and validate whether the house should be built at all.

That’s the 0 to 0.5 phase. Once validated, they bring in the specialists with proper tools to take it from 0.5 to 1.0. The knife isn’t replacing the hammer. It’s accelerating the decision about whether to pick up the hammer in the first place.

How LinkedIn built the infrastructure for full-stack builders

The latency trap of the Agile Industrial Complex was not a secret. But for years, the solution felt out of reach. How could a single individual navigate strategy, design, and complex engineering? LinkedIn’s ambitious “Full-Stack Builder” program doesn’t just offer an answer; it redefines the question.

But here’s the critical reality: this transformation doesn’t happen with ChatGPT and good intentions. It requires systematic organizational investment. Individual builders can move from 0 to 0.5 instantly with today’s AI tools. Scaling that capability across an organization demands platform thinking, shared infrastructure, and cultural rewiring.

This isn’t about simply asking PMs (or engineers, designers, and even researchers, the program is role-agnostic) to take on more work. It’s about providing the infrastructure of autonomy that empowers an individual to vertically integrate the talent stack, collapsing the traditional handoffs and accelerating value creation. LinkedIn’s pioneering effort rests on three pillars:

Platform: Rearchitecting for AI Fluency

LinkedIn understood that off-the-shelf AI tools wouldn’t suffice. To enable a “Full-Stack Builder” model, they had to re-architect their core platform to allow AI agents to “reason” and build directly. This involved:

• Composable UI: Building server-side UI components that AI could manipulate and assemble seamlessly.

• Design Systems: Adjusting internal design systems to ensure AI agents (like Figma plugins or internal tools) could export code directly compatible with LinkedIn’s repositories.

This foundational investment meant builders weren’t just prompting generic AI; they were interacting with a system designed for deep integration.

Tools: The Custom Agent Ecosystem

The true force multiplier lies in LinkedIn’s suite of specialized internal AI agents. Trained on LinkedIn’s “golden examples” and historical data, these agents automate the process complexity that once bogged down product teams. A Trust Agent identifies vulnerabilities and harm vectors in product specs before development. A Growth Agent critiques feature ideas by analyzing LinkedIn’s history of growth funnels and A/B tests. Similar agents handle research, QA, and maintenance tasks autonomously.

These agents act as an invisible, always-on “squad” for the builder, handling tasks that previously required multiple specialists and endless coordination.

Culture: Incentivizing the New Builder

To ensure adoption, LinkedIn didn’t just build the tools; they reshaped their culture and incentives:

• Performance Reviews: AI fluency and agency are now explicit components of performance evaluations.

• Pod Model: Teams are reorganized into small, cross-functional “pods” to foster rapid execution.

• Pilot Exclusivity: A strategic rollout created internal demand and “FOMO,” accelerating adoption among top talent.

LinkedIn’s results are compelling: top performers are saving hours per week, shipping higher quality products, and even transitioning between traditionally siloed roles with unprecedented ease. A user researcher, for instance, transitioned to a Growth PM role by leveraging these tools.

A Key Distinction: LinkedIn’s model may push builders closer to 0.9 or even 1.0 on the execution spectrum, relying less on specialist handoffs than the framework I’m advocating. Their heavy infrastructure investment (custom agents, re-architected platforms, curated training data) enables this. But most organizations won’t have LinkedIn’s resources or appetite for that level of platform buildout. The 0 to 0.5 model I’m proposing is more pragmatic: use AI for rapid validation, then strategically partner with specialists to scale. This preserves craft while accelerating learning.

What This Means: The “Full-Stack Builder” isn’t a mythical unicorn, and it’s not about individual heroics. You don’t need LinkedIn’s exact stack, but you cannot skip the investment. Individual builders gain the 0 to 0.5 capability instantly with AI. Scaling that across your organization requires platform thinking: shared agents, composable systems, and dismantling the coordination overhead that still suffocates most teams.

The shift is both personal and organizational. One without the other hits a ceiling fast.

What it takes to make this work at scale

The possibilities are here, right now. A PM can build a functional prototype in an afternoon. A designer can generate code. An engineer with product sense can ship a feature end-to-end. This isn’t speculative; it’s happening today.

However, what separates the individual win from organizational transformation is infrastructure.

Let’s address a cynical reading of this trend head-on: ...corporate code for do more with less. They argue it’s a cost-cutting play dressed up as innovation, a way to squeeze three roles into one headcount. If that’s what your organization is doing, the critics are right to be skeptical.

But that’s not what we’re describing. The model I’m advocating requires more investment, not less. Investment in training, in custom tooling, in platform capabilities, in cultural change. Organizations that treat this as a headcount reduction strategy will fail. The ones that treat it as a capability investment will pull ahead.

The Full-Stack Builder isn’t limited to Product Managers. Engineers with product sense, designers who can expand their scope, and researchers who can prototype their hypotheses; any role can adopt this model. The role is less important than the mindset: taking an idea from 0 to 0.5 rapidly, validating it with real users, then bringing in specialists to scale it to 1.0.

Making this work at scale requires investment in three areas:

People: Building AI Fluency

Your team needs training, not in “prompt engineering tips,” but in the mindset shift of Building to Think. This means:

• Understanding when to build for validation vs. when to hand off for production.

• Developing computational fluency and judgment about when AI helps vs. when human expertise is non-negotiable.

Many organizations are already investing here. The question is whether your training is tactical (how to use ChatGPT) or strategic (how to rewire your operating model).

Platform: Shared Cross-Functional Capabilities

This is where most organizations fail. They give everyone AI tools and wonder why the gains don’t scale. Without shared infrastructure, every team reinvents the wheel. Some do it well. Most do it poorly. The result is fragmentation and technical debt.

The investment required:

Composable systems: Design systems, UI libraries, and APIs that AI can manipulate.

...curated datasets that teach AI what good looks like.

You need platform thinking. Without it, individual builders hit a ceiling, and the organization never captures the compound value.

Process: Tearing Down the Agile Industrial Complex

You cannot layer the new way of working on top of the old ceremony. If your builders are shipping prototypes in a day but still spending the majority of their time on standups, retros, and grooming sessions per week, you haven’t changed anything. You’ve just added AI to a broken system.

This requires hard organizational choices:

• Eliminating coordination theater: meetings that exist to manage handoffs you’re trying to collapse.

• Reorganizing into small, autonomous pods rather than large functional hierarchies.

• Changing incentives: rewarding speed of learning and commercial impact, not story points and ticket throughput.

The timeline question

The question isn’t whether this transformation takes 6 months or 18. It’s whether you’re starting today. Individual builders can adopt the mindset immediately with tools that already exist. Organizations need to invest in infrastructure, and that takes intention, budget, and leadership conviction. But the urgency is real: if your competitors are building this capability while you’re debating it, the gap compounds fast.

What the new operating model looks like

What does this distillation of the product role actually look like in the day-to-day? It’s a dramatic departure from the “traffic cop” model. Imagine two PMs in 2026, both working on similar problems:

The Traffic Cop PM: Their week is a blur of meetings. They manage dependencies, chase updates, groom backlogs, refine tickets, and present status. Their primary output is documentation and coordination. When asked about customer conversations, they sigh and promise to fit them in “next week.”

The Augmented Architect: Their week is characterized by rapid customer iteration. They build functional prototypes with AI in hours, test them with users directly, analyze patterns from session data, and present validated insights with working demos to their engineering partners. They stop at 0.5 and bring in specialists to scale to 1.0. Their time goes to deep work and strategic planning, not status meetings.

The widening gap

Two groups are emerging: Augmented Architects who use AI to validate faster, and Traffic Cops who treat AI as optional while clinging to coordination rituals.

The choice isn’t whether AI impacts product management; it’s whether you’re adopting the builder mindset today. Your organization may lack custom agents or re-architected platforms. Start with individual capabilities available now. Build prototypes. Validate faster. Demonstrate value.

But understand: your organization must invest in shared infrastructure to scale this, or individual builders hit a ceiling. The mindset shift is personal and immediate. The infrastructure shift takes sustained commitment. Both are necessary.

Those who start now, even with imperfect infrastructure, position themselves to accelerate when organizations invest. Those who wait will find themselves 12 to 18 months behind. If you’re coordinating handoffs while competition is shipping, the gap won’t be closeable.

The era of the architect

The Product Trio model, while effective for a time, has succumbed to the latency and inefficiency of its own specialized handoffs. The rise of AI has exposed the “Agile Industrial Complex” for what it became: a system that prioritizes process over customer insight, trapping product managers in a cycle of coordination rather than creation.

But this isn’t a eulogy for Product Management. It’s a call for its evolution. LinkedIn’s bold move to replace its APM program with the “Associate Product Builder” isn’t an anomaly; it’s a leading indicator. It illuminates a future where the most valuable product professionals are Augmented Architects: individuals who leverage AI to vertically integrate the talent stack.

They are not generalists. They are masters of the core PM competencies (Customer Insight, Evidence, Strategy, and Inspiration), who use Fluency in adjacent domains (enabled by AI) to reinforce and accelerate their Mastery. They are “Building to Think,” reducing the latency of validation, and owning the full creative and commercial arc of a product.

The era of the Augmented Architect isn’t coming. It’s here. The question isn’t whether you understand this shift. It’s whether you’re shipping differently this quarter than last. The choice is stark: embrace this evolution and reclaim your role as a direct creator of value, or remain a traffic cop in a system that no longer requires one.

Internal product managers often believe a dangerous myth. They think they don’t have to worry about churn.

Since the company mandates the use of their API gateway, design system, or data warehouse, they assume their user base is guaranteed. They have a captive audience.

But in platform product management, users don’t churn. They rot.

When users are forced to use a tool they hate, they engage in malicious compliance. They do the bare minimum. They build “shadow IT” workarounds.

They complain to leadership until your budget gets cut. Every internal platform falls into one of two buckets: it is either a Tax or a Multiplier.

If you don’t know which one you are, you are probably a tax.

The platform tax

A tax is something you pay because you have to. In the context of a platform, it is a tool that slows users down in exchange for organizational compliance.

Your platform is a tax if it adds friction (“I have to file a ticket and wait three days just to get an API key”), requires distinct effort (“I have to rewrite my code to fit your rigid schema”), or delivers abstract value (the user feels the pain, the company gets the gain).

When you operate as a tax, your relationship with users is adversarial. You are the police. They are the citizens trying to avoid a ticket.

The multiplier effect

A multiplier gives users leverage. It abstracts away the boring, hard, or dangerous parts of development so product teams can skip infrastructure setup and go straight to feature development.

Your platform is a multiplier if it removes friction (“I dropped my code in, and the platform handled auth, logging, and scaling automatically”), accelerates velocity (“This saved me two weeks of integration work”), and delivers immediate value (the user feels the gain directly in their sprint velocity).

When you operate as a multiplier, your relationship with users is a partnership. You are the pit crew. They are the driver.

The mandate trap

The biggest enemy of the multiplier mindset is the corporate mandate.

When a CTO says, “Everyone must use Platform X,” the platform team stops selling. They stop treating their users like customers. They start treating them like subordinates.

This is where the product rot begins.

A “tax” team leans on the mandate to explain away their bad UX. They say things like, “They have to use it because of security compliance.”

A “multiplier” team ignores the mandate. They build a product so good that teams would voluntarily choose it even if they were allowed to use AWS directly.

Shifting from tax to multiplier

If you suspect you are building a tax, the shift starts with reframing your value proposition. You cannot just be a gatekeeper. The role shifts to gardener.

Sell the “boring” work. Don’t sell compliance. Sell the fact that you handle the tasks nobody wants to do. “You must use our library for security compliance” is a tax pitch. “You never have to worry about patching a security vulnerability again” is a multiplier pitch.

Measure time-to-hello-world. Tax teams measure uptime. Multiplier teams measure how fast a new user can ship value. If it takes three days to get onboarded, you are a tax. If it takes five minutes, you are a multiplier.

Compete with the open market. Assume your users can leave. If they could use Vercel, Stripe, or Auth0 instead of your internal tool, would they? If the answer is no, find out why. That gap is your roadmap.

The litmus test

There is one simple question to determine where you stand.

If the executive mandate were removed tomorrow, how many teams would keep using your platform?

If the answer is “nobody,” you are a tax. You are living on borrowed time.

If the answer is “most of them,” you are a multiplier. You are building leverage.

The choice is clear: gates or ramps. Most teams are still building gates.

And yet, customers are churning.

The problem isn’t the data. It’s the definition. We treat “customer satisfaction” as a single bucket. We dump everything into it: bug fixes, new features, polite support emails, brand colors. If the bucket is full, we assume we are winning.

But satisfaction isn’t a bucket. It’s a hierarchy.

To fix retention, the question isn’t “Are they satisfied?” It’s “Which layer of the hierarchy is leaking?”

Level 1: The removal of friction (hygiene)

This is the basement. The basic expectations: the login works, the page loads, the data saves, the bill is accurate.

The defining characteristic of this layer is asymmetry. You get zero credit for getting it right. Nobody writes a thank-you note because the “Reset Password” button worked.

But if you get it wrong? You lose everything.

When you fail at this level, the customer emotion is anger. Angry customers submit tickets. They tweet. They churn loudly.

Many product teams confuse fixing friction with “delivering value.” They spend quarters squashing bugs and refactoring code, thinking they are improving the product. They aren’t. They are simply stopping the bleeding.

This is the floor. You cannot build a strategy here, but you can certainly die here.

Level 2: The delivery of outcome (utility)

This is the ground floor. This is why the customer hired your product in the first place.

This layer isn’t about whether the software works. It’s about whether the customer works. Did they get the result?

A tax software user doesn’t want a delightful interface. They want their taxes filed without an audit. A ride-share user doesn’t want a chatty driver. They want to be at the airport by 5:00 PM.

When you fail at this level, the customer emotion isn’t anger. It is indifference.

This is the most dangerous emotion in business. An angry customer submits a ticket. An indifferent customer just leaves.

They don’t complain because you aren’t worth the energy. You didn’t solve their problem, so they drifted to a competitor who would. They churn silently, without warning, without noise in your support channels.

This is where many product roadmaps fail. Teams ship features users requested, check them off the list, and wonder why retention doesn’t move. The features worked. They just didn’t matter.

The customer got the output. They didn’t get the outcome.

What this means in practice: Sometimes, delivering the outcome requires adding friction. You might force a user through a complex setup wizard because that is the only way to ensure they get value later. You might require a compliance step that slows onboarding.

A focused product team prioritizes the outcome over the friction. They recognize that a frustrated user who succeeds will stay. A delighted user who fails will not.

This is the “success vs. satisfaction” trap. Optimizing for satisfaction at this layer often means optimizing for the wrong thing. The metric that matters isn’t “Did they smile?” It’s “Did they get the job done?”

The silent churn problem

Most analytics dashboards are built to catch Level 1 failures. Support tickets spike. Error rates climb. Alerts fire.

But Level 2 failures are invisible. Users log in. They click around. They complete workflows. From a product instrumentation perspective, everything looks fine.

Then they stop renewing.

The gap between “using the product” and “getting the outcome” is where most SaaS companies lose customers. The product works. It just doesn’t work for them.

This is why engagement metrics can mislead. High DAU (daily active users) with high churn means users are trying and failing. They are putting in effort and not getting results.

The diagnostic question isn’t “Are they using it?” It’s “Are they succeeding with it?”

Level 3: Emotional resonance (connection)

This is the penthouse. This is how the product makes the user feel. Do they feel smart? Do they feel secure? Do they feel like they are part of a club?

When you win here, the result is loyalty. Customers who reach this level don’t just renew. They advocate. They recruit their colleagues. They defend you in comparison threads.

Think of Notion users who evangelize the tool unsolicited. Or Linear users who badge their workflows with pride. These products deliver outcomes (Level 2), but they also create identity (Level 3).

The mistake companies make is trying to decorate the penthouse while the basement is flooded. They invest in “delighters” (fun animations, gamification, swag, personalized emails) while their core loop is broken.

You cannot delight a user whose login just timed out. You cannot build community with a user who isn’t getting results.

Resonance is a multiplier. But anything multiplied by zero is still zero.

Diagnosing your product

When you look at your backlog or your churn data, use this hierarchy to diagnose the root cause.

High volume of support tickets? You have a friction problem. The product is breaking promises.

Stop building new features. Fix the foundation.

High churn, low noise? You have an outcome problem. Customers are leaving silently because you aren’t solving the core job.

No amount of UI polish will fix this. You need to rethink the value proposition. Talk to churned users. Ask what they were trying to accomplish and why they left.

Often, the answer isn’t “your product is bad.” It’s “your product wasn’t for me.” That is a positioning problem, not a product problem.

High retention, low growth or advocacy? You have a resonance problem. People use you because they have to, but they don’t love you.

This is where you invest in brand, community, and delighters. But only after the first two layers are solid. Resonance compounds success. It doesn’t create it.

The hierarchy in practice

Here is a real pattern I’ve seen across B2B SaaS companies:

Year 1: The product barely works. Every customer interaction is firefighting. Support volume is high. Churn is high. The team fixates on stability.

Year 2: Stability improves. Churn drops slightly. The team celebrates and shifts to “customer delight” initiatives. They add gamification, personalized dashboards, a community forum.

Year 3: Churn creeps back up. But this time, it is quiet. No tickets, no complaints. Customers just don’t renew. The team is confused because they have been investing in satisfaction.

What happened? They fixed Level 1 (friction) but never validated Level 2 (outcome). Customers could use the product. They just weren’t getting results from it.

The team optimized for delight before they earned it.

This is the trap of treating satisfaction as a single metric. Green scores can hide red outcomes.

Where teams get stuck

The hardest transition is from Level 1 to Level 2. It requires a shift in how you measure success.

At Level 1, you measure usage: uptime, error rates, support tickets. At Level 2, you measure results: customer outcomes, workflow completion, ROI.

Most product teams are better at the former. It is easier to instrument “Did the button work?” than “Did the customer achieve their goal?”

But the companies that break through are the ones that obsess over outcomes. They build customer success into the product. They instrument not just clicks, but progress toward the job.

They stop asking “Are they using it?” and start asking “Are they winning with it?”

The takeaway

Most teams optimize for smiles before they have earned them. They invest in delight while customers are still struggling to get basic outcomes.

The hierarchy matters. Friction first. Outcome second. Resonance only after you have delivered both.

The question isn’t whether your customers are satisfied. It’s which layer you are losing them.

If they are angry, you have a reliability problem. If they are indifferent, you have a value problem. If they are satisfied but not loyal, you have a resonance problem.

Fix the right layer. The rest will follow.

Google’s Gemini 3 landed last week with impressive reviews: frontier-class performance that beats OpenAI and Anthropic except for its agentic code. Conventional wisdom said Google was lagging behind OpenAI, which remains true in adoption. But on capability, they have a real chance to catch up. The tech press is focused on benchmarks and capabilities.

They’re missing the real headline: Google trained these models entirely on TPUs. Zero NVIDIA dependency.

While competitors debate model quality, Google just decoupled its cost structure from the entire market. OpenAI and Microsoft pay massive margins to Jensen Huang. Google is paying cost-plus to its own hardware division.

It’s the margin war

In a commodity market, the low-cost provider eventually wins. AI inference is racing toward commoditization. Google’s vertical integration is the ultimate cheat code.

Consider the math. NVIDIA-dependent companies must price APIs to cover energy, cloud operations, and NVIDIA’s 75% gross margins. Google prices APIs to cover energy and silicon fabrication costs.

This allows Google to trigger a race to the bottom on pricing that no NVIDIA-dependent competitor can survive. They can effectively subsidize the model indefinitely to protect Search.

Competitors, meanwhile, burn capital paying premium rents for compute. This is “compute sovereignty”: scaling capacity without third-party permission.

Amazon proves it’s not just Google

Google isn’t alone. Amazon is running the same playbook with AWS Trainium chips.

Anthropic is training Claude 4.x on 500,000 AWS Trainium2 chips, with plans to scale to one million by year-end. AWS claims 30-40% better price-performance than NVIDIA equivalents. That’s structural cost advantage, not incremental improvement.

Amazon’s approach mirrors Google’s vertical integration but with a different business model. Where Google optimizes for its own models, AWS sells compute sovereignty as a service.

The software moat is deeper than the hardware

Cheap chips don’t matter if nobody knows how to program them. This is the “Island Problem”: great infrastructure developers won’t adopt. It remains the single biggest risk to Google’s strategy.

NVIDIA is just not a hardware company. They are a software platform disguised as a chip manufacturer. The CUDA ecosystem is the deepest moat in tech.

Every researcher coming out of Stanford or MIT learns PyTorch on CUDA. Every major open-source library is optimized for CUDA first. Moving a production workload from NVIDIA to TPU isn’t just a “recompile.” It often requires rewriting code in JAX or dealing with XLA compiler friction.

If Google wins on efficiency but loses on developer mindshare, they end up with the best internal infrastructure that nobody else wants to use.

The model is the only leverage left

On the flip side, if Google cannot break the CUDA stranglehold, its TPUs remain a private island. In this scenario, their only path to victory is abstracting the hardware away entirely.

They must force the market to consume Inference APIs, not raw compute.

If Gemini 3 is sufficiently powerful (and sufficiently cheap) developers won’t care what silicon it runs on. They will never touch the metal. They will just hit the API endpoint. Google’s strategy relies on turning the TPU from a developer hurdle into a hidden margin engine.

The industry is splitting into two distinct camps.

OpenAI, Meta (training Llama 4 on H100s), and most startups rent NVIDIA capacity. They optimize for speed-to-market and developer familiarity but remain locked into NVIDIA’s margin structure and the CUDA ecosystem.

Google with TPUs and Amazon with Trainium optimize for unit economics. They’re betting that price-performance eventually trumps developer familiarity, and that vertical integration becomes the only sustainable path in a commoditizing market.

The question isn’t which group is right. It’s which advantage compounds faster: ecosystem lock-in or cost structure.

I stumbled on David Maister’s 1985 research on waiting psychology while thinking about loading screens. His foundational principle: occupied time feels shorter than unoccupied time. But he uncovered something deeper. Anxiety, uncertainty, and unexplained delays make waits feel exponentially longer.

That got me thinking. Most product teams treat waiting as friction to eliminate. Load faster. Reduce checkout steps. Skip the queue.

But you can’t eliminate all dead time. Users will wait during loading, onboarding, checkout, processing. The question isn’t whether they wait, it’s what you do with that captive attention.

Look at how the best products handle waiting

As I explored this more, I started noticing patterns everywhere.

Look at how Disney handles theme park queues. They don’t just move lines faster. They build interactive games into waiting areas. Characters parade through crowds. Space Mountain’s twisting paths hide the full queue length, reducing anxiety about what’s ahead.

Consider how Asana onboards new users. They don’t overwhelm people with Gantt charts and dependencies upfront. They start with basic project creation, then gradually reveal advanced features as users gain confidence. The onboarding wait becomes capability building.

The pattern: people tolerate waits when they understand why they’re waiting, see progress toward completion, and have something meaningful to occupy the time.

What separates high performers from the rest

The best SaaS products get dramatically higher onboarding completion than industry averages. They use progressive disclosure: revealing one valuable feature at a time, teaching as users engage, turning configuration into discovery.

E-commerce brands fighting cart abandonment don’t just optimize checkout speed. They explain shipping timelines transparently, show order progress in real-time, and use recovery emails that provide value (product recommendations, size guidance) alongside the nudge to complete purchase.

These companies understand that dead time isn’t just infrastructure to optimize. It’s experience to design.

Why this matters more than you think

Page speed matters. Even small delays tank conversions. Amazon, Google, and others have documented how milliseconds of slowdown directly impact revenue.

But speed alone doesn’t solve this. Pinterest discovered something interesting: they reduced perceived wait times dramatically without dramatically changing actual load speeds. Better skeleton screens and progress indicators made the experience feel faster. The result was measurable increases in both search traffic and sign-ups.

The insight: perception matters as much as performance.

Where is your dead time?

Look for moments where users have no choice but to wait:

• Onboarding flows with account setup and data imports

• Checkout processes with payment verification

• Loading states during search or complex calculations

• Processing delays for reports, exports, or deployments

• Queue systems for high-demand access

Each one is captive attention. Each one is an opportunity to educate, build confidence, reduce anxiety, or deepen engagement.

The question isn’t whether your product has dead time. It’s whether you’re wasting it on spinners, or turning it into story time.

Everyone’s celebrating velocity. Who’s checking if you’re solving the right problems?

Creation velocity isn’t validation velocity

Recent research shows contradictory results on AI’s impact. Some studies report significant productivity gains, others find developers actually slow down when using AI tools. The pattern emerging is clear: AI accelerates code generation, but delivery stability often decreases and quality concerns rise.

You can ship faster. But are you learning faster?

The real gap isn’t speed. It’s the mismatch between how quickly you can build and how quickly you can validate what to build. As I explored previously, AI amplifies senior strategic judgment while commoditizing tactical execution. Without that senior judgment directing what to build, teams become feature factories.

Most teams obsess over who builds features (PMs? Engineers? Designers?) and how fast they ship. Almost nobody asks whether those features matter to customers.

The warning signs aren’t dramatic. In B2B, users don’t immediately churn. Instead, adoption stays low. Features exist but go unused. Customer success teams field more “why did you build this?” questions. Renewal conversations get harder six months later.

Traditional product-market fit frameworks assume you’re testing hypotheses at a measured pace. You build, you measure, you learn, you iterate. AI tools break that rhythm. You can generate and ship features faster than your instrumentation can tell you if the previous batch worked.

The path-of-least-resistance problem

Teams pick AI use cases based on what’s readily available, not what aligns with strategic goals or delivers meaningful customer impact.

You have a new AI tool that generates UI components. So you build features that need UI components, whether or not those features solve real user problems. The tool shapes the roadmap instead of customer needs shaping tool selection.

Amazon’s principle of working backwards matters more now, not less. Start with customer needs, then figure out what to build and how to build it. Most teams do the opposite: start with what AI tools can do easily, then justify it with assumptions about customer value.

Research on AI project failures consistently points to the same issue: too much attention on technical capabilities, not enough on actual market needs. Most AI projects fail not because the technology doesn’t work but because teams built the wrong thing quickly.

Speed as tactic, not strategy

The companies navigating this well treat speed as a tactic, not a strategy. They use AI to accelerate after they’ve validated direction, not to spray features and hope something sticks.

This requires different metrics. Not just “features shipped per sprint” but “validated learning per sprint.” Not just “time to market” but “time to meaningful user engagement.” Not just “productivity gains” but “impact per unit of effort.”

Product managers still balance the same three dimensions: user needs, business viability, and technical feasibility. What changes is the first pillar. Understanding user needs now means distinguishing between what users actually need and what AI makes easy to build.

AI can help with validation too. Synthesize user interviews at scale. Analyze support tickets for patterns. Enable rapid prototype testing. But the craft of knowing what to validate and interpreting results still requires human judgment. That’s where the gap lives.

The test that matters

Ask what you learned this week, not what you shipped.

If the answer is “we shipped five features,” you’re measuring activity. If the answer is “we validated that users struggle with X and confirmed that approach Y doesn’t solve it,” you’re measuring learning. Fast teams don’t ship more, they learn faster.

AI tools are incredible for accelerating learning. Generate multiple variations, test them quickly, and see what works. But only if you’re testing the right problem.

Speed is a compounding advantage when paired with direction. Speed without direction just gets you lost faster.

Even when you’re building the right features at the right pace, there’s another bottleneck most teams ignore. AI can generate code quickly. Someone still has to ensure it’s production-ready.

The debate splits into two camps: one believes product managers will code their way to replacing engineers, the other thinks engineers will own strategy and eliminate PMs. Both narratives miss what’s actually happening. AI isn’t replacing entire functions. It’s splitting each function into three tiers, and only one of them is shrinking.

The same pattern across three functions

Look at what’s happening to engineers first. Employment for software developers aged 22-25 has declined nearly 20% from its peak in late 2022, according to Stanford’s Digital Economy Lab. Computer engineering graduates now face a 7.5% unemployment rate, one of the highest across majors.

What’s getting automated? Boilerplate code. Unit tests. API maintenance. The tasks companies used to assign to junior developers to help them learn.

Now look at designers. Many studios used to hire junior designers specifically for wireframing. Those roles are shrinking. The State of AI in Design Report found that 89% of designers improved their workflow with AI this year, but the improvements concentrate on production work: variant generation, copy filling, visual polish.

Product managers see the same split. McKinsey found that generative AI improved PM productivity by 40%, but the gains came from automating tactical work: user stories, performance reports, backlog maintenance, PRD drafting. The strategic work, the judgment calls, the stakeholder dynamics? Still human.

Three tiers emerging

The pattern is clear across all three functions. Entry-level tactical work gets commoditized. Senior strategic work gets amplified. Mid-level roles transform into something new.

Tier 1: Commoditized Junior engineers who write boilerplate code. Junior designers who create wireframes. Junior PMs who draft user stories. AI tools handle these tasks faster and often as well as someone in their first year on the job.

Marc Benioff announced Salesforce will hire “no new engineers” in 2025, citing AI-driven productivity gains. Anthropic CEO Dario Amodei warned that AI could wipe out half of entry-level white-collar jobs. But AWS CEO Matt Garman pushed back, calling the idea of replacing junior developers with AI “one of the dumbest things I’ve ever heard.”

The debate reveals the tension: AI can do the tasks, but those tasks serve a purpose beyond just getting work done. They’re how people learn.

Tier 2: Transformed Mid-level roles aren’t disappearing. They’re morphing into hybrid positions that require both AI literacy and deep domain expertise. These are the people who know enough to guide AI tools effectively and spot when AI outputs miss the mark.

The new job descriptions reflect this: “AI Orchestrators,” “Product Engineers,” “Full-Stack PMs.” People who move fluidly between strategy and execution, using AI as a force multiplier rather than a replacement.

Tier 3: Amplified Senior roles gain value. System architecture. Product vision. Strategic design decisions. User empathy. These capabilities matter more, not less, in an AI-enabled world.

Here’s why: the more skilled you are at your craft, the better results you get with AI. A senior engineer can spot architectural flaws in AI-generated code that a junior might miss. A seasoned designer knows when AI-generated variants sacrifice usability for aesthetics. An experienced PM can tell when AI-drafted requirements miss the strategic context.

The hollowed-out career ladder

This creates a systemic problem nobody wants to talk about: if entry-level roles commoditize but senior expertise remains valuable, how does anyone become senior?

You need plenty of seniors at the top. AI tools handle grunt work at the bottom. But there are very few juniors in the middle learning the craft.

This threatens the long-term talent pipeline across product, engineering, and design. Companies benefit from AI productivity gains today while quietly eroding their ability to develop senior talent tomorrow.

The skills that make someone valuable at Tier 3 develop through years of doing Tier 1 work. You learn system architecture by first building components. You develop product sense by first writing user stories and seeing what ships versus what sits in the backlog. You understand good design by first creating wireframes and getting feedback.

Remove the learning ground, and you cut off the path to expertise. The question of whether curiosity beats tenure in this environment isn’t academic: it determines whether companies can develop the senior talent they’ll need.

What this means in practice

The conversation shouldn’t be “will AI replace PMs or engineers or designers?” It should be: “How do we structure learning when tactical work gets automated?”

Some companies respond by raising the bar for entry-level roles. Junior positions now require AI literacy plus traditional fundamentals. That solves the immediate hiring problem but makes it harder for people to break into the field.

Other companies may be experimenting with new mentorship models: pairing early-career people directly with senior staff and using AI tools to accelerate their learning rather than replace their contributions.

The companies getting this right recognize that AI doesn’t just change how work gets done. It changes how expertise develops. They’re designing career paths that acknowledge both the productivity gains from AI and the human judgment that AI amplifies but cannot replace.

But commoditization is only part of the story. The bigger question is what teams are actually building with all this newfound speed. Shipping 3x faster sounds great. Whether that speed translates to customer value is a different question, one I’ll tackle next.

Read next: The Feature Factory Problem AI Amplifies

The WebArena benchmark proves the gap quantitatively. Researchers created realistic web environments (e-commerce sites, forums, development platforms) and asked GPT-4-based agents to complete end-to-end tasks like “Find the cheapest phone case and email me the link.” Success rate: 14.41%.

The architecture is brittle

Current agents follow a ReAct cycle (Plan, Act, Observe, Repeat) as I explored previously. This looks like reasoning, but it’s sequential token prediction choosing from pre-defined tools. When one step fails, the entire chain collapses.

The problem isn’t the architecture alone. It’s what happens when reality deviates from the plan.

If an agent struggles through a task and eventually succeeds, it retains zero memory of that success. Next session, it repeats the same mistakes. There’s no mechanism to update its knowledge base or behavior from experience. (Research like Meta’s Early Experience approach explores ways agents could learn from their own rollouts, but these methods aren’t yet production-ready.)

Error propagation compounds this. A single wrong click or a misread file in step two ruins the entire workflow. Attempted fixes like self-reflection or multi-agent debate act as band-aids. They sometimes amplify false reasoning rather than correct it.

Why coding works

AI-assisted coding (GitHub Copilot, Claude Code) is the exception. Agents genuinely deliver value here.

The environment is constrained. The IDE provides clear boundaries. The data is primarily text and code. Feedback loops are immediate. You run the code, see if it works, and adjust.

This reveals the requirements for agents to succeed elsewhere: constrained environments, homogeneous data types, and fast feedback loops.

Real-world business tasks fail all three tests. A financial audit requires juggling emails, database logs, PDF invoices, and regulatory texts simultaneously. When a document is missing or unreadable, agents hallucinate results rather than problem-solve like humans do.

Business workflows assume human common sense. Nobody emails a contact ten times in one minute. Nobody needs explicit instructions not to delete the production database. Agents require rigid IF…THEN rules for everything. They can’t handle dynamic obstacles (a file moved to a new database, a contact out of office) without being explicitly programmed for each scenario.

We’re a decade away from autonomous?

The market hype suggests we’re approaching the “Observer” level, where machines work fully autonomously. Sukhareva argues we’re actually at the “Collaborator” level where humans guide machines. Citing Andrej Karpathy, she estimates it will take at least ten years to fix these fundamental cognitive issues.

The gap isn’t just technical. It’s architectural. Current agents lack the cognitive structure for proactive learning, robust error recovery, and multimodal reasoning.

Companies investing in “agentic AI” based on hype videos and demos should understand what they’re actually buying: brittle sequential machines that work in constrained environments with immediate feedback. Not autonomous decision-makers.

The coding success proves agents can work when the environment matches their capabilities. The question for product teams isn’t whether to use agents. It’s whether your use case looks more like an IDE or like a financial audit.

The interesting part isn’t that infrastructure fails. It’s what gets exposed about the gap between architected resilience and actual resilience.

The multi-cloud gap

Companies might use AWS for one application and Azure for another, but any given application typically runs on a single cloud. Redundancy within that provider (multiple regions, availability zones) but the provider itself is treated as permanent infrastructure.

Then Cloudflare goes down and everything stops.

The pattern shows up consistently: sophisticated redundancy for compute, single-provider dependency for CDNs, DNS, and edge infrastructure. Like installing a backup generator but leaving your electrical panel connected to a single grid.

Configuration as failure mode

All three outages share the same root cause pattern: configuration changes, not hardware failures or attacks.

Azure’s outage started with a networking configuration that created inconsistent state. AWS’s disruption began when two automated systems tried to update the same database simultaneously. Cloudflare’s global failure came from a database permissions change that corrupted the Bot Management system.

Infrastructure complexity creates failure modes that are hard to predict. Routine configuration changes can trigger cascading failures across regions or global networks.

This shifts the threat model. Traditional redundancy focuses on external threats: datacenter failures, provider outages, hardware degradation. But when configuration complexity is the primary failure mode, redundancy alone doesn’t solve it. You need loose coupling so failures don’t cascade.

The CDN blindspot

Multi-CDN strategies exist. Load balancing across providers, health checks, automated failover: these are solved technical problems. CloudFront, Bunny.net, Akamai, Azure CDN all offer alternatives.

What’s less common is treating CDN infrastructure with the same redundancy thinking applied to compute. When Cloudflare went down, companies with sophisticated multi-cloud architectures went offline just as completely as companies running on a single EC2 instance.

The gap shows up in infrastructure assumptions. Most organizations cluster around accidental multi-cloud. Different teams chose different providers over time, creating redundancy architectures that exist on paper but haven’t been tested under actual failure conditions.

What changes this is intentionality. Some organizations have made explicit decisions about where redundancy matters and where it doesn’t. They’ve calculated the cost of downtime for different parts of their product and architected accordingly.

They’ve also made a harder decision: accepting that some level of downtime is inevitable and building products that degrade gracefully rather than fail catastrophically.

As infrastructure complexity increases, new failure modes emerge faster than old ones get solved. The organizations that navigate this aren’t the ones with maximum redundancy. They’re the ones who’ve thought clearly about what they’re optimizing for and built systems that fail gracefully.

I’ve been following world models with growing curiosity. The contrast with LLMs is stark. Where language models learn statistical patterns from text, world models learn by watching: absorbing spatial relationships, temporal dynamics, and cause-effect from video and sensory data. They’re designed to answer the question LLMs fundamentally can’t: what happens next in physical space?

What’s happening now

There is a clear acceleration in 2024-2025. Google’s Genie 2 generates playable 3D worlds from a single image. NVIDIA’s Cosmos trained on 20 million hours of real-world footage, creating physics-aware simulations that companies like Uber and XPENG are deploying.

Meta’s V-JEPA 2 learns 5-6x more efficiently by predicting abstract representations rather than raw pixels.

Fei-Fei Li’s World Labs just launched Marble, the first commercial world model product. The technology she’s building toward: spatial intelligence, AI that understands the physical world the way humans do.

In a recent WSJ profile, Yann LeCun (Meta’s Chief AI Scientist) is telling PhD candidates to focus on world models instead of LLMs. His prediction: world models could replace the LLM paradigm within 3-5 years.

What this could unlock

Autonomous vehicles are the obvious application, but I’m watching a broader pattern. Robotics companies use world models as virtual simulators, training robots in generated scenarios before deploying to reality. Industrial automation benefits from synthetic data generation for rare edge cases.

The shift runs deeper. LLMs process language, world models process reality. One understands how to describe gravity, the other understands falling.

Where this seems to be headed

This feels like 2018-era LLMs: early, expensive, limited to well-funded teams. Genie 2 generates 10-60 seconds of stable video. Cosmos requires massive GPU clusters for training. The sim-to-real gap remains a real challenge: small simulation differences cause real-world failures in safety-critical systems.

But the trajectory is visible. Google formed a new team for world simulation models. NVIDIA is making Cosmos open-source to accelerate the robotics community.

For most companies, there’s no tangible bet to make yet. This technology isn’t accessible enough for broad experimentation. But it’s worth following closely.

World models feel like they’re approaching their ChatGPT moment. GPT-3 existed for years before ChatGPT made it accessible enough to spark the LLM application wave. When world models hit that inflection point, the teams that have been tracking the space will know where to tinker first.

LLMs taught AI to speak. World models are teaching it to see.

AI agents are different. They have decision-making authority. You give them a goal, and they figure out the path, making choices on the fly based on context. That shift from scripted execution to delegated judgment changes what happens to your workload.

What the data shows

A recent study from Faros AI analyzed over 10,000 developers across 1,255 teams to understand what happens when AI adoption goes high. The productivity story looks clear at first: teams completed 21% more tasks and merged 98% more pull requests.

But the same data revealed the downstream effects. PR review time increased 91%. Bug rates went up 9%. The agents didn’t just speed up the work developers were already doing. They revealed new work that hadn’t existed before.

Someone has to review what the agent produced. Someone has to validate the decisions it made. Someone has to integrate its output with the existing codebase. The cognitive load didn’t disappear: it moved downstream and multiplied.

Two different reads of the same pattern

One interpretation: this is Jevons Paradox for knowledge work. When you make something more efficient, consumption increases rather than decreases. The efficiency gains are real, but they’re not reducing the total work in the system. They’re expanding what’s possible, which creates new categories of work that didn’t exist before. Agent management. Agent training. Quality control for autonomous decisions.

The other interpretation: Anthropic CEO Dario Amodei warned that AI could eliminate roughly 50% of all entry-level white-collar jobs within the next one to five years. His logic centers on a shift from augmentation (AI helps people do jobs) to automation (AI does the job). If agents can handle the execution work, you don’t need as many people doing it. The efficiency doesn’t create more work. It reallocates the dollars to different problems.

The core tension

Both patterns are showing up simultaneously. The Faros data demonstrates work multiplication downstream. The Anthropic warning points to headcount reduction upstream, particularly at entry-level roles where tasks are more structured and agent-friendly.

It’s too early to tell which dynamic dominates, or whether they operate in parallel across different types of work. But the pattern is clear enough to plan for. If you’re deploying agents expecting simple headcount reduction, you might be underestimating the new work they create. If you’re assuming efficiency always expands the team, you might be overestimating the number of people you’ll need to manage what agents produce.

The shifting baseline

Here’s what complicates both interpretations: the definition of “entry-level” is moving. What we consider entry-level today might be three notches higher in eighteen months. College graduates entering the workforce with AI fluency might start at what we’d call mid-level today, because the baseline expectations have shifted.

The agents aren’t just changing how much work gets done or who does it. They’re changing what counts as foundational capability. If that’s true, continuous leveling up isn’t optional. It’s the only defense available. The landscape is changing too fast for static skillsets to hold value.

What new work will your agents reveal that you can’t see yet? And what work will disappear faster than you expect?

It is also a goldfish. Every conversation starts from scratch. Every user is a stranger. Every context is new.

Google just released a whitepaper on context engineering that tackles this fundamental problem. The paper introduces a systematic framework for making LLM agents stateful using two core primitives: Sessions and Memory.

The framework formalizes the architectural patterns that separate toy demos from production AI systems.

The statelessness problem

LLMs are fundamentally stateless. Outside their training data, their awareness is confined to the immediate context window of a single API call.

You can craft the perfect prompt, tune every parameter, and still end up with an agent that forgets the user’s name between conversations. The model doesn’t remember. It doesn’t learn. It processes each turn in isolation.

Context Engineering is the discipline of dynamically assembling and managing all information within that context window to make agents stateful and intelligent. It is prompt engineering evolved: shifting from crafting static instructions to constructing the entire state-aware payload for every turn.

The business impact is direct. Stateless agents can’t personalize. They can’t maintain coherent multi-turn workflows. They can’t reduce repetitive questions or remember user preferences.

Sessions: The temporary workbench

A Session is the container for a single, continuous conversation. Think of it as the workbench where the agent does its immediate work.

Every Session contains two parts. First, the chronological event log (user inputs, agent responses, tool outputs). Second, the temporary working memory or state (like items in a shopping cart or the current step in a workflow).

The core operational challenge is managing growing conversation history. Long context creates four production problems: exceeding the model’s context window limit, escalating API costs (charged per token), increasing latency, and degrading model performance (“context rot”).

This is where compaction strategies become critical. Simple approaches truncate old messages after a token limit. Sophisticated systems use recursive summarization, where an LLM periodically condenses older conversation segments into compact summaries.

Here’s the trade-off in practice. A customer support agent handling 50 turns would send thousands of tokens per request without compaction. With recursive summarization (triggered every 20 turns), the system replaces verbose dialogue with a summary: “User confirmed Order 456 had missing item, requested refund.” Context preserved, costs and latency slashed.

Memory: The long-term filing cabinet

If Sessions are the temporary desk, Memory is the meticulously organized filing cabinet. This is where the personalization value lives.

Memory captures and consolidates key information across multiple sessions. It transforms agents from chatbots that reset every conversation into assistants that remember your preferences, context, and history.

The architecture is typically a combination of vector databases (for semantic similarity and unstructured facts) and knowledge graphs (for structured relationships and reasoning). But the real sophistication is in how memories get created and maintained.

Memory generation is an LLM-driven ETL pipeline. Extract meaningful content from conversations. Transform and consolidate it by handling conflicts and duplicates. Load the refined knowledge into persistent storage.

The consolidation stage is where most systems fail. Without it, memory becomes a noisy, contradictory log. With proper consolidation, the system compares new insights against existing memories, decides whether to update, create, or delete entries, and actively prunes stale information.

The critical distinction: Memory vs RAG

Product teams often conflate Memory with Retrieval-Augmented Generation (RAG), but they serve fundamentally different roles.

RAG injects static, factual knowledge from external sources (PDFs, wikis, documentation). It makes the agent an expert on facts. The data is typically shared across all users and read-only.

Memory curates dynamic, user-specific context derived from conversation. It makes the agent an expert on the user. The data must be highly isolated per user to prevent leaks.

Think of RAG as the research librarian providing universal knowledge. Memory is the personal assistant who knows your preferences, history, and context. Both are essential, but they operate at different layers of the system.

Here’s the strategic framework at a glance:

Production challenges you can’t ignore

The whitepaper highlights three critical production risks that context engineering must address.

Latency and blocking UX. Memory generation requires expensive LLM calls and database writes. If this runs synchronously (blocking the user response), the experience becomes unacceptably slow. The solution is to handle memory operations asynchronously as background processes after responding to the user.

Data isolation and privacy. Sessions and Memory must enforce strict per-user isolation. A user cannot access another’s conversation data or memories. PII should be redacted from session data before persistence to mitigate breach risks.

Memory poisoning. Malicious users can attempt to corrupt the knowledge base by feeding false information. Safeguards like validation, sanitization, and trust scoring (memory provenance) must be employed before committing data to long-term memory.

These aren’t edge cases. They’re the difference between a demo that works in development and a system that scales in production.

Memory provenance: The trust layer

Not all memories are equally reliable. Some come from explicit user statements (“I prefer aisle seats”). Others are inferred from implicit behavior or bootstrapped from external systems like CRMs.

Memory provenance is the detailed record of a memory’s origin and history. Each memory carries metadata about its source, confidence score, and how that confidence changes over time (increasing with corroboration, decaying with age).

During consolidation, when new information conflicts with existing memories, provenance establishes a hierarchy of trust. A fact from a high-trust CRM system might override casual user dialogue. At inference time, the confidence scores are injected into the prompt, allowing the LLM to weigh evidence and make nuanced decisions.

This is the difference between a memory system that amplifies errors and one that becomes more accurate over time.

Procedural memory: Learning how, not just what

Most memory systems focus on declarative memory (facts and events). The whitepaper emphasizes procedural memory: the agent’s knowledge of skills and workflows.

Procedural memory captures the correct sequence of tool calls, the optimal strategy for recurring tasks, or the playbook for handling specific scenarios. It is extracted from successful interactions and distilled into reusable patterns.

The value is online adaptation. Instead of the slow, expensive process of fine-tuning model weights offline, procedural memory provides fast adaptation by injecting the right plan into the context via in-context learning.

For product teams, this means agents can learn and improve their workflows without requiring model retraining. That’s a significant operational advantage.

What this means in practice

For teams building stateful AI agents, the whitepaper provides a clear architectural roadmap.

Session management starts with conversation history persistence and compaction strategies. Simple token-based truncation handles basic cases. More sophisticated systems use recursive summarization to preserve context while controlling costs. Storage must be robust, retrieval fast, and per-user isolation strict.

Memory systems layer in gradually. Declarative memory (user preferences, key facts) provides the foundation. Asynchronous memory generation prevents blocking latency. Consolidation logic handles conflicts and prunes stale data.

Provenance tracking establishes trust and enables conflict resolution.

The architectural choices matter. Teams treating context engineering as foundational infrastructure get personalized, reliable agents. Those treating it as an afterthought face escalating costs, latency issues, and degraded user trust.

The shift that matters

Context Engineering represents the maturation of AI agent development. It moves the focus from crafting clever prompts to building robust systems that manage state, persist knowledge, and adapt over time.

The primitives are clear: Sessions for immediate coherence, Memory for long-term personalization. The challenges are well-defined: managing context length, ensuring data isolation, building trust through provenance.

Google’s whitepaper formalizes what production AI teams have been learning through experience. Not every use case requires stateful agents. But for applications where personalization, workflow continuity, or multi-turn context matters, this framework provides the architectural foundation.

The distinction between Sessions and Memory, the emphasis on consolidation and provenance, the recognition of procedural memory as distinct from declarative facts: these concepts clarify the design space and highlight the trade-offs that matter in production.

The advantages used to be resources, data, distribution, and customer relationships. Those still matter. But only if you can deploy them before the market moves.

The real enterprise problem isn’t speed

It’s coordination.

Everyone knows the goal. “AI transformation.” “Double growth.” “Modernize the platform.” Leadership repeats it constantly. Town halls, all-hands, strategic decks.

But goal clarity without strategy clarity is paralysis.

Teams know the destination but have no shared map. So they make local decisions that feel rational but don’t compound. Five teams each moving at reasonable pace, solving adjacent problems in isolation. Velocity looks fine locally. Strategic progress is zero.

The turf wars amplify this. “That’s my lane.” “No, it’s mine.” Some of this is healthy. You need clear ownership. But it becomes extreme when there’s no strategy to adjudicate scope conflicts.

The coordination paradox

Here’s the tension: You need input from multiple teams to form a coherent strategy. You need to identify who’s already doing adjacent work, who controls critical capabilities, and who has context that would change the plan.

But decision-by-committee is doomed. If everyone needs to agree, you ship nothing.

The resolution isn’t eliminating coordination. It’s designing coordination for a 10x faster cycle time.

Include for input. Decide with authority. Move with speed.

Time-box strategy formulation to weeks, not months. Three weeks from “we need a strategy” to “teams are executing,” not three quarters. Separate the input phase (broad consultation) from the decision phase (narrow authority). Default to leveraging existing capabilities unless there’s a specific blocker.

Pre-negotiate escalation paths so turf conflicts get resolved in 48 hours, not 48 email threads.

Why this matters more now

Because the execution gap is narrowing. If a startup can prototype in 4 weeks and your enterprise takes 14 months to coordinate, your advantages evaporate.

Data moats, distribution, brand trust, and enterprise relationships only matter if you deploy them before competitors establish alternatives.

The question isn’t whether you’re moving fast in absolute terms. It’s whether you’re moving fast enough relative to how quickly the market is learning.

What’s missing from your coordination system?

If you’re in an established company trying to move with purpose:

Is it the actual decision-making structure? Who has authority at each level, and is that explicit?

Is it the incentive alignment? How do you get teams to cooperate instead of compete for scope?

Is it the measurement system? How do you know if you’re actually moving faster, or just feeling busy?

Is it the cultural shift? From “coordination equals consensus” to “coordination equals speed”?

The answers determine whether your resources compound into leverage or fragment into theater.

The difference isn’t work ethic or talent. It’s what they optimize for. Slow teams measure velocity by features shipped. Fast teams measure it by hypotheses validated. One counts outputs. The other measures learning rate.

The Learning Rate Problem

Shipping is easy. Learning is hard. Most teams can release code weekly but take months to figure out if it worked.

They ship a feature, watch some dashboards, have a few meetings, and eventually form an opinion. By the time they know what happened, the context has shifted and the team has moved on.

Fast teams collapse that loop. They don’t ship faster because they cut corners. They ship faster because feedback arrives in hours, not weeks.

Each deployment answers a specific question. The instrumentation was built before the feature. The rollback is one click. The metrics update in real time.

By most accounts, Amazon’s two-pizza teams work this way. Each team owns metrics, deployment, and learning. They don’t wait for data teams to build dashboards or ask permission to roll back. The loop from “we think this will work” to “here’s what actually happened” runs in days, sometimes hours.

What Fast Actually Means

Fast isn’t about more features. It’s about more learning cycles in the same time period. A team that ships one feature and validates it in a week is faster than a team that ships three features and validates them in a month.

The constraint isn’t coding speed. It’s learning infrastructure. Can you deploy without friction? Can you measure what matters automatically? Can you see results without waiting for someone else? Can you kill a feature as easily as you launched it?

Reportedly, Stripe optimized for this early. Every experiment had clear success metrics defined upfront. Results populated dashboards automatically.

Teams could see within 48 hours whether their hypothesis held. That learning rate compounded. More cycles meant more validated insights. More insights meant better decisions. Better decisions meant sustainable velocity.

The Real Metric

Your velocity metric shouldn’t count story points or features shipped. It should measure time from hypothesis to validated learning. How many days from “we believe X” to “we now know Y”?

This is the same principle behind measuring outcomes rather than outputs. The question isn’t what you built. It’s what you learned.

If that number is more than two weeks, you don’t have a shipping problem. You have a learning problem. And no amount of faster coding will fix it.

What’s slowing down your learning loops right now?

None of it moves the number because the retention problem wasn’t created in month six. It was locked in during week one.

This isn’t about better onboarding flows or slicker tutorials. It’s about product decisions made before launch that determine whether users stay or leave months later. By the time your growth team measures retention, your product team already decided it.

Time-to-Value Determines Everything

Users don’t leave because they forgot about your product. They leave because they never experienced its core value. The gap between signup and first meaningful outcome is where retention dies.

Consider Slack versus most enterprise tools. Slack delivers value in the first conversation. You invite a teammate, send a message, get a reply. That loop completes in minutes.

Most B2B products make you wait weeks: configure settings, integrate systems, import data, train your team. By the time value might arrive, the user already decided you’re not worth it.

The best products collapse time-to-value ruthlessly. Figma lets you design in the browser with zero setup. Stripe processes your first test payment in minutes. Linear creates your first issue before you’ve read the docs.

Each optimized for the moment a user thinks “this actually works.”

Complexity Curves Kill Quietly

Every feature you add increases the burden on new users. The complexity that delights power users in month twelve crushes new users in week one. This tradeoff is unavoidable, but most teams get it backwards. They design for the expert and hope beginners will figure it out.

Notion is the cautionary tale. Infinitely flexible, incredibly powerful, and overwhelming to 90% of new users who just wanted a place to write notes. The product’s strength became its retention weakness.

Compare that to Linear, which hides advanced features behind progressive disclosure. New users see a clean issue tracker. Power users discover shortcuts, automations, and integrations as they need them.

The complexity curve should match the value curve. Early experience should be simple with obvious wins. Advanced capability should reveal itself gradually as users build competence and need more leverage.

Habit Formation, Not Feature Adoption

Retention isn’t about using all your features. It’s about embedding one habit that brings users back without thinking. The products with the best retention aren’t the most feature-rich. They’re the ones that become part of your daily rhythm.

GitHub doesn’t retain engineers because of Actions or Projects. It retains them because checking pull requests becomes a morning ritual. Superhuman doesn’t retain users through keyboard shortcuts.

It retains them by making inbox zero feel achievable daily. The habit is the moat.

Your onboarding should optimize for one thing: get the user to repeat the core action enough times that it becomes automatic. Three times is a trial. Seven times is a pattern. Thirty times is a habit.

The Real Metric

The metric that predicts retention isn’t MAU or feature adoption. It’s how many days until a new user completes the core loop three times. If that number exceeds seven (factor in your domain complexity), you have a retention problem that no growth campaign can fix.

The window to build retention is narrow. What product decision are you making today that will determine whether users are still here six months from now?

Each path blocks something you need: viral growth, sustainable economics, or both.

For years, platforms have picked their poison. SaaS tools charge creators monthly fees, killing casual sharing. Consumer apps eat infrastructure costs to drive growth, then scramble to monetize. Marketplaces take cuts that creators resent.

None of these models naturally align creator incentives with platform growth.

Anthropic’s Artifacts feature tests a fourth path. When you build and share an interactive app in Claude, you pay nothing for distribution (no hosting fees, no infrastructure costs, no matter how many people use it). Instead, anyone who uses your shared artifact authenticates with their own Claude account, and their usage counts against their subscription.

The cost doesn’t disappear. It just shifts to whoever’s getting the value.

How the Model Works

Artifacts let you build interactive applications directly inside Claude. React-based UIs powered by Claude’s API. You can create data analysis tools, games with adaptive AI, educational apps, writing assistants, or multi-step agent workflows.

Once you’ve built something, sharing is a single click. No deployment pipeline. No server configuration. No domain setup.

Here’s where the economics diverge from traditional platforms. Users must authenticate with their Claude account to interact with shared artifacts. That authentication isn’t just for access control. It determines who pays.

Every API call your shared app makes runs against the end user’s Claude subscription, not yours. If you’re on the free tier and share a tool that goes viral, you still pay nothing.

The platform handles scaling, hosting, and infrastructure. Users burn their own credits.

This creates unusual incentives. As a creator, you have zero reason to limit distribution. More users cost you nothing.

As a platform, every shared artifact that gains traction becomes a potential acquisition channel. New users must sign up to try it, and power usage drives upgrade decisions.

The current constraints reveal the roadmap. Artifacts can’t make external API calls yet. No persistent storage. Text-based completion API only.

These aren’t permanent limitations. They’re guardrails on a beta feature. Each constraint will likely fall as Anthropic validates the model.

The Hypothetical Flywheel

If this model works, the growth dynamics look different from traditional platform plays. Anthropic is betting on a self-reinforcing loop: zero-cost sharing drives more artifacts into the wild. Shared artifacts require authentication, converting casual users into registered accounts.

Those users engage with AI tools, generating usage signals and burning through free-tier credits. Some percentage hit their limits and upgrade to paid subscriptions.

The early adoption signal is real. Users have created over 500 million artifacts since launch. Community infrastructure emerged organically: artifact galleries, GitHub collections cataloging shared tools, diverse use cases from productivity apps to educational games.

But we don’t have the data that would prove the flywheel actually spins. What percentage of those 500 million artifacts get published versus staying private? Do shared artifacts meaningfully drive new signups, or are people mostly sharing within existing Claude users?

When someone discovers Claude through a shared artifact, do they convert to paid tiers at different rates than other acquisition channels? How much of Claude’s overall growth (18.9 million monthly active users, enterprise market share jumping from 18% to 29%) is attributable to Artifacts versus other features or marketing?

Those are the questions that determine whether this is a clever distribution hack or a fundamental shift in platform economics. Anthropic hasn’t published those metrics. Maybe they’re still figuring it out themselves.

What This Reveals About Platform Strategy

The model matters whether or not it works for Anthropic. It shows that AI platforms are actively experimenting with distribution models that don’t map to traditional SaaS or consumer app playbooks. The assumption (and it’s just an assumption for now) is that small, useful utilities can become repeatable acquisition channels if you make sharing frictionless enough.

This isn’t just Anthropic. OpenAI tested similar mechanics with custom GPTs and Canvas sharing. The specifics differ, but the pattern is consistent: make it trivial to create and share AI-powered tools, require authentication to use them, and see if community-driven distribution can compete with paid acquisition channels.

The unproven bet underlying all of this: that casual sharing actually creates viral growth at meaningful scale. Consumer social products proved that sharing photos and messages could drive exponential user curves. But those were inherently social activities. Sharing a YAML-to-JSON converter or a flashcard generator is utility-driven, not social.

Does utility sharing have the same viral coefficient? Or does it top out at small, engaged communities that never break into mainstream adoption?

If it works, if AI platforms can turn every creator into a distribution channel, the competitive dynamics shift. Platforms would compete not just on model capabilities or pricing, but on how easily you can build, share, and remix community creations. The platform with the lowest friction for turning ideas into shareable tools wins distribution mindshare. That’s a different game than the current race for benchmark scores and enterprise deals.

The Question That Matters

This is a strategic model worth understanding, not a proven playbook. Anthropic made a bet that eliminating distribution costs for creators would unlock a new growth engine. The early adoption numbers suggest people like building with Artifacts. Whether that translates to sustainable platform growth (new users, engagement, conversion) remains unproven.

The question isn’t just “does this work for Anthropic?” It’s “can small, shareable utilities become a repeatable acquisition channel for AI platforms?” If the answer is yes, we’ll see every major platform racing to reduce sharing friction. If it’s no, Artifacts becomes a power user feature that doesn’t move growth needles (still valuable, just not transformational).

For now, it’s an experiment. But one that reveals where platform thinking is headed: away from traditional SaaS unit economics and toward models where distribution cost approaches zero, user acquisition happens through utility sharing, and the platform captures value by sitting between creators and consumers. Whether that future arrives depends on data we don’t have yet.

The categorization reflects tool architecture. Lovable and Bolt for prototyping, Claude Code, and Cursor for production. UI-first tools abstract complexity and accelerate visual validation. Terminal-based tools expose code and configuration, giving engineers control over reliability, observability, and scale.

But that architectural difference doesn’t lock tools into single purposes anymore.

What’s Shifting

Claude Code sits in both camps. Non-technical product managers can use it to generate working prototypes that run on live data and simulate complex business logic. Then they hand that same generated code to engineering, who refactor what’s useful and discard what isn’t. But they continue building in the same environment with the same tool.

This isn’t theoretical. It’s happening now with Claude Code, Codex CLI, and tools like Droid Factory. The learning curve exists. Terminal interfaces intimidate at first, but the investment pays off in continuity. One tool, two phases, no translation layer.

Why the Convergence Matters

When prototyping and production share infrastructure, handoffs get cleaner. Product managers generate testable hypotheses in code, not static mockups. Engineers inherit working logic they can evaluate and extend, not wireframes they interpret from scratch. The gap between discovery and delivery narrows.

This doesn’t erase Cagan’s core warning: prototypes still aren’t products. Business complexity, runtime demands, and operational constraints (reliability, telemetry, fault tolerance, compliance) remain non-negotiable for commercial-grade systems. Prototyping sophistication doesn’t eliminate that work.

But it does change the question. It’s not “Can this prototype become a product?” It’s “How much of this prototype’s logic survives into production, and how quickly can we validate the rest?”

The Implications

For product managers: Learning terminal-based tools is now a leverage move, not a technical detour. If you can prototype in the same environment engineering uses for delivery, you reduce interpretation overhead and accelerate feedback loops.

For engineering teams: Code generated during discovery becomes a starting point, not a distraction. You’re evaluating real logic against real constraints, not translating concepts across tool boundaries.

For organizations: The “build-to-learn versus build-to-earn” framing still holds. Separating discovery from delivery remains essential. But the tooling gap that once reinforced that separation is closing. That’s a workflow shift, not a conceptual collapse.

Open Questions

Can these converged tools handle the full complexity Cagan describes (thousands of use cases, enterprise-grade reliability, zero-downtime deployments) within the next three years? Unknown. The spec-driven development is picking up, so I am optimistic.

If tools serve both discovery and delivery well enough to accelerate learning and reduce handoff friction, that’s sufficient. Perfect continuity isn’t the goal. Better sequencing is.

The hype Cagan warns against (thinking prototypes are products) still deserves the warning. But the tools enabling that confusion are also solving a different problem: making the path from prototype to product less lossy. That’s not hype. That’s progress.