Software Becomes Practice
A framework for building in the agentic-first era
I read an argument recently that AI hasn’t actually changed how products get built. Founders always claimed to talk to customers first and always quietly skipped that step. The only difference now is that the pretense is gone. People build from their hallucinations and call it a strategy. The conclusion: nothing structurally changed, the order of operations just lost its decorative layer of customer interviews.
The argument is wrong in two layers. The shallow layer is that the visible behavior (build first, ask questions later) hasn’t changed. The deeper layer is that the disciplined alternative the argument is invoking, proper customer development with market research and validated hypotheses, was always rare in practice. CB Insights consistently puts “no market need” at the top of the startup failure list, which would not be possible if most founders were actually doing the research the textbooks prescribe. Marty Cagan has spent two decades documenting that most enterprise roadmaps are feature factories, driven by stakeholder requests, single-deal commitments from sales, executive mandates, and trend chasing. Industry estimates put the share of shipped features that generate positive ROI somewhere in the 10-20% range, which tells you what you need to know about how those decisions were being made. The HiPPO effect (highest-paid-person’s-opinion as the de facto decision-maker) is the working reality at most companies, not the exception.
The pretense the argument complains about being lost was already the pretense. The real driver was usually an SVP promising an AI strategy at a board meeting, or a sales rep escalating a single customer’s request because the deal was three times larger than the rest of the pipeline, and that decision then percolated down to PMs and engineers who didn’t know who it was for or why. Vibecoding didn’t dismantle a discipline that was already mostly fictional. What it did was change the economics of the lazy alternative, and that flip in the underlying economics turns out to change everything downstream.
This post is an attempt to map what actually shifted, what new structure is emerging in response, and what that implies for anyone trying to build a software business in the next few years. It’s a reference document, not a thesis defense. I’m publishing it because I want to be able to point at it, and because the framework is more useful in other people’s hands than locked in my notes.
What actually changed
The traditional product playbook (interview customers, validate hypotheses, build MVP, measure, iterate) was optimized for a specific economic condition: building was expensive. The cost of being wrong was high enough that you needed to be right before you started. Every framework from Lean Startup to Jobs To Be Done assumes a world where building is expensive enough to justify validating first, even though some of them were explicitly trying to bring the cost of being wrong down.
The playbook had a second problem the cost-of-being-wrong frame doesn’t capture, which is that customers don’t actually know what the right thing is. The apocryphal Ford line about asking customers and getting “a faster horse” captures a real pattern (although Ford seems to have never said it). People extrapolate from what they have, not from what they would prefer if they could imagine the alternative. The cleaner version of the point is that the stated request (a quarter-inch drill) is rarely the actual job (a quarter-inch hole). The same pattern shows up at the company level. Incumbents who get displaced are usually the ones who listened most carefully to their existing customers, who kept asking for incremental improvements on the existing product right up until a competitor with a different shape of product (worse on the old axis, better on a new one) took the market out from under them. The Steve Jobs version of the same idea is more aggressive. “It’s really hard to design products by focus groups,” he told BusinessWeek in 1998, “a lot of times, people don’t know what they want until you show it to them.” You listen to customers in order to understand them well enough to lead them somewhere they can’t articulate, not to copy down what they say. So the playbook had two problems running together. The cost of being wrong was always high, and even when the methodology was followed correctly, what came out the other end was usually a faster horse.
There’s a third thing on top of those two, and it’s the dimension that matters most right now. AI capabilities are moving fast enough that customers don’t just struggle to articulate what they want, they don’t know what’s possible, and the confusion runs in both directions. Sometimes they underestimate. They don’t know what an agent can actually do for them, what a model can hold in context, what’s now solvable with a few prompts and a small vector store, so they reason from a 2023 mental model of software inside a 2026 world and ask for last-generation tooling. Other times they overestimate, asking for something they saw in an Instagram demo that doesn’t actually work the way it was shown, mis-described by someone who either didn’t understand the underlying tech or was happy to oversell it. Acting literally on what they say ships you either a 2023 product or somebody else’s marketing reel. The faster-horse problem isn’t historical anymore, it’s the live problem on every call this quarter, in both directions.
The builder doesn’t get a pass on this either. You can’t rely on previous experience anymore, because the capability stack underneath your last project no longer holds. Every customer ask becomes a research question of its own. What’s actually possible today? Did someone ship a model or a tool in the last few weeks that turns this from a six-month build into a weekend? What are the risks of leaning on it, latency, cost, reliability, the model getting deprecated in three months, the vendor changing the pricing tier under you? Pattern-matching from the last project is now the slow path. Looking at what shipped this week is the fast one.
This is why the path to the right hypothesis is the most crucial part of the experiment, and why the loop that works now starts with the founder, not the customer. Pick a problem you have reason to believe is real and underserved. Identify the ICP. Research actual companies that should be feeling that problem and form a specific guess about who is struggling with what, then test the guess. Ask them if they have the problem. Ask them again, differently, a few weeks later, because the first answer is the polite version and the second one is closer to the truth. Once you have signal, show them a working solution rather than a deck. Customize it heavily for the first ten to fifty customers until the patterns show through, and only then build the platform that compresses what you’ve learned into something that scales. The motion is land and expand, but the underlying structure is hypothesis, verify, customize, abstract. Customer development still matters, but its job changed. It’s no longer the source of the idea, it’s the calibration loop on a hypothesis the founder already brought.
The cost constraint dissolved. Building a working prototype for most B2B SaaS shapes (a CRUD app with a few real integrations) now costs an afternoon. The cost of being wrong dropped to single-digit dollars and a few hours of attention. When the cost of being wrong drops by three orders of magnitude, the optimal strategy flips. You no longer validate before building, you build in order to validate. The MVP isn’t the artifact you produce after hypothesis confirmation, it’s the instrument through which the hypothesis becomes legible in the first place.
The investor side of the market has already started recalibrating to the new economics. Julia Yu Goncharov, founder of Unicorns Club (a firm that matches VCs with early-stage startups), put empirical numbers on the shift in a piece on the new pre-seed. Pre-seed rounds now typically expect $300K-$1.2M ARR before serious money shows up, and angel engagement usually starts around $50K MRR. The ceilings on what pre-seed and seed rounds can absorb have roughly quintupled (pre-seed moved from $750K to $4M, seed from $4M to $10M), but the bar to enter rose with them. 91% of surveyed VCs say they’re now open to solo founders, which would have been unthinkable five years ago. The plain reading is that capability stopped being scarce, so traction became the price of admission. “Strong narratives and prototypes,” Goncharov writes, “are now table stakes that don’t even get you in the room.” The buyer side and the seller side of the market are converging on the same conclusion from opposite directions.
In a follow-up piece, Goncharov sharpened the framing further. The empirical entry bar moved up. What counts as “has traction” at the early stage is now roughly $5K-$25K in MRR with 10%+ month-over-month growth, not a polished demo. The pitch that used to win was “we spent a year building this” as a signal of commitment, and that same pitch now reads as inefficiency, because the underlying build cost dropped to roughly two weeks and a few hundred dollars. The pitch that wins now is closer to “we built this in two weeks for $300, and the capital you give us funds distribution, not development.” Team size flipped alongside it. A six-person engineering team at the pre-seed stage used to signal seriousness, and it now signals wasted capital, because the same product could plausibly be shipped by one founder using Cursor and a Claude subscription. Goncharov cites a striking gap to explain why solo founders keep underperforming on funding, 52.3% of successful exits are solo-founded yet only 17% receive VC funding, which she reads as cultural lag rather than evidence of risk. The defensibility question moved from “can you build it,” which AI commoditized, to “do you have distribution, proprietary data, vertical expertise, or iteration speed to compound advantages over time.”
The argument missed this because it was looking at behavior. The behavior (build first, ask questions later) hasn’t changed. The economic justification for that behavior is what changed, and that turns the lazy behavior into the correct strategy. What used to be a shortcut around proper customer development is now the proper development method. The frameworks haven’t caught up because they were written when the old constraint was real.
This is the small version of the insight. The bigger version is that almost every layer of the software business stack was optimized around the old constraint, and almost every layer has to be rethought now that the constraint is gone. MVP, outreach, validation, pricing, team structure, market structure. All of it.
The MVP became proof of empathy
When building was expensive, the MVP’s job was to demonstrate capability: can this team actually solve the problem at all. The functional question (does it work) was load-bearing because building anything was a real commitment. Customers evaluated whether you could deliver, which was a meaningful signal.
That signal lost its information value. Anyone with a Claude Code, Codex, or Cursor subscription can produce a functional prototype that solves a stated problem. Capability stopped being scarce, which means demonstrating capability stopped being meaningful. Sophisticated buyers recognize this immediately. Showing them a working prototype is no longer evidence of commitment or skill. It’s table stakes that takes you exactly to the starting line.
What’s scarce now is comprehension, because attention has been blown apart on the buyer’s side. A senior engineering or product leader at any company worth selling to is now receiving roughly a dozen cold inMails a day from vibecoders asking them to try a new product. Each one comes with a working demo, a polished landing page, a Loom, and a pitch that is almost identical to the previous eleven. The volume is large and going up. The signal-to-noise ratio collapsed at the same time the cost of producing noise dropped to zero, and the two effects compound. A working prototype no longer earns a meeting. It barely earns a reply. The thing that breaks through that flood isn’t another working demo, it’s evidence that you understood the recipient’s situation specifically enough that they couldn’t have gotten it from any of the other eleven messages.
The acronym itself stops being literal. The “V” used to stand for “viable,” the smallest thing that proved the team could build. It has to mean something closer to “value-added” now, the smallest thing that lands real empathy on one specific customer. And by empathy I mean the kind that shows in product texture, not the kind that shows up as a scripted “I know what you’re thinking about” opener in a cold email. The first earns trust because it can only come from someone who actually did the work of understanding. The second is exactly what makes the dozen-a-day flood feel like noise.
The new MVP’s job is to demonstrate that you understood the customer’s situation deeply enough to encode it into the product. Every default, every empty state, every piece of copy, every edge case you bothered to handle is a signal of “I know what your Tuesday looks like.” Generic defaults are now disqualifying, not safe. The functional layer is assumed. The signal sits one layer up, in the texture of the encoded understanding.
Every account, every customer, every logo in the CRM becomes “The Client,” singular and definite. The specific person whose workflow the defaults reflect, whose questions the empty states answer, whose dialect the product is written in. The Client never sees the others. As far as their experience goes, they are the only one this thing was ever built for, and the product’s job is to reinforce that conviction every time they touch it.
The paradox at the heart of this is that you’re building bespoke-feel software from off-the-shelf parts. You’re building for one specific persona so completely that they think you built it for them alone, but you’re actually building for the thousand of them who share that worldview. Pulling this off requires depth on one persona that most generic SaaS never bothers with. Without that depth, the product reads as commodity even when it’s functionally complete.
The implication for founders: ethnography matters more than feature lists. The hours you used to spend on customer development conversations should now be spent immersing in one persona’s actual world, their forums, their vocabulary, their workflow rituals. You’re not validating hypotheses. You’re learning the dialect well enough to write in it convincingly.
Outreach became magnetism
Cold outreach broke. Not because volume reached saturation (though it did) but because AI made personalization fakeable. Five years ago, a message that referenced your recent podcast appearance signaled that a human had spent twenty minutes on you. Today it signals that someone spent ten cents on Clay. Buyers learned this faster than sellers did. The surface markers of “I researched you” now read as evidence of automation. The signal inverted.
It also became the floor. The minimum bar is now real research, the kind that produces a sentence the buyer couldn’t have gotten from a Clay enrichment for ten cents. If you haven’t done that work, you’re out automatically, and the pun is intentional. Their mailbox filter has an AI doing the first pass on inbound. The absence of any specific signal is itself the signal that you treated them as a row in a CSV, and that’s enough to lose the reply before a human ever sees the message.
The asymmetry that made outbound work also flipped. Sellers used to have information buyers didn’t. Buyers can now ask their own AI “what tools exist for X” and get a better answer than any cold email provides. The seller’s information advantage is gone. What’s left is the seller’s taste advantage and their distribution into communities where the buyer already lives.
So the new outreach isn’t outreach in the traditional sense. The slowest channel, and the only one that compounds, is presence in the rooms where the persona congregates, contributing real value before anyone knows you sell anything. Most founders skip this because it doesn’t show up in a CRM. The ones who win in the agentic-first world are the ones who spent a year being useful in a Discord, a subreddit, or a niche conference circuit before they launched anything. Or who took on cheap, occasional consulting gigs inside the kind of companies they wanted to sell to and saw further into the workflow, the political fault lines, the unwritten rules of the operation, than any outsider ever could. Both paths buy depth the AI can’t fake, because the AI doesn’t have access to the rooms where that depth is sitting. Layered on top of that is the work of producing artifacts that travel. Instead of messages sent to people, you create things people forward to each other. A tool that does one specific thing for one specific persona shockingly well. A teardown of how their industry actually works that only an insider could write. This is outreach as gift, not interruption, and the artifact is the message and the medium and the proof of empathy all at once.
The newest channel barely exists yet but is coming fast. Buyers increasingly ask their own agents “find me something that does X,” and your job is to be the answer that agent surfaces. The mechanics of agent-mediated discovery are still being worked out (whether you optimize for being indexed by general agents like Perplexity, or for being recommended by specialized vertical agents that the buyer’s company has already adopted, or for showing up in the model’s training data through the body of work you’ve published), but the discipline is closer to building the substance an agent can summarize you with than to SEO or paid ads.
The deeper shift: outreach used to be a push activity with a conversion funnel. Now it’s a pull activity with a magnetism question. The question stopped being “how do I reach them?” and became “why would they come find me?” If you can’t answer that in one sentence, no amount of outreach mechanics will save you.
The latent-problem case
Pre-positioning solves the easy case: a buyer hits a wall, searches for help, finds you. The harder case is that most buyers aren’t at a wall. They’re operating at suboptimal-but-tolerable, don’t know they have a problem worth solving, and won’t search because they haven’t named the problem yet. The seller’s job in this case is to bring the latent problem into the buyer’s awareness without it feeling like manufactured demand.
And then there’s the case the AI agentic-first conversation forgets exists. Plenty of buyers, probably most of them, are not in the AI bubble at all. They use ChatGPT once a week to get an apple pie recipe or to proofread a strategy doc before a board meeting, and they could not care less about agentic capabilities, foundation models, or what shipped this week. They are not waiting for an AI-native solution. They have not named their problem because, from their vantage point, what they have works fine and the AI conversation is somebody else’s drama. Reaching them requires translating what you’ve built into language that doesn’t index on AI at all, because if your pitch leans on the word “agent,” they file you next to the crypto pitch from last year and stop reading.
Manufactured demand is exactly what high-functioning buyers have built immunity to. The ad that says “did you know you’re losing 30% productivity to X.” The LinkedIn post that says “if you’re not doing Y, you’re behind.” Sophisticated buyers detect it instantly because they know the problem is being defined by someone with financial interest in defining it that way.
The mechanism that works is what I’d call legitimate revelation. The seller has spent enough time inside the persona’s actual workflow to see patterns the persona can’t see from inside their own situation. Then the seller names the pattern in language the persona recognizes as their own, with examples specific enough that the persona thinks “wait, that’s exactly what I do.” The reaction you’re aiming for isn’t “interesting, tell me more.” It’s “how did you know that about me, and now that you’ve named it I can’t unsee it.” That recognition reaction is the moment latent need becomes acute need.
This is closer to what good therapists, coaches, and senior consultants do than what salespeople do. They listen for patterns the client is too close to see, then reflect those patterns back with enough precision that the client experiences the reflection as revelation.
This adds a hard constraint to the framework: you have to actually have insight into the persona’s latent problems, which usually requires having been the persona, having spent years working closely with them, or having the analytical taste to see patterns from observation. There’s no shortcut. The first investment of any new venture in this model is the public body of work that demonstrates pattern recognition about the persona, written or built or recorded over a long enough period that it can’t be faked.
What this actually is: software as professional practice
What I’m describing is software returning to something pre-industrial. Before mass marketing, before SaaS, before outbound sales as a discipline, commerce ran on standing relationships with people who understood your situation before you described it. The village blacksmith knew which horse you rode, what terrain you covered, what you’d broken last winter. The transaction was the smallest part of the encounter.
Industrial scale broke that. You couldn’t know millions of customers, so you built proxies: segmentation, personas, ICPs, intent data, lead scoring. Each layer of proxy moved you further from the person and closer to the abstraction. The whole apparatus of modern B2B is essentially industrial-era machinery for simulating knowing-you at scale, and buyers can now feel the simulation because AI made the simulation cheap and ubiquitous.
What’s interesting about the current moment is that AI, the same force that made the simulation cheap, also makes the original thing newly possible. Anticipating one customer’s needs deeply used to require a blacksmith’s lifetime in one village. Now one founder can hold genuine context on thousands of specific people, not as records in a CRM but as actual understanding, because AI handles the cognitive load of remembering, pattern-matching, and synthesizing across all those relationships. The blacksmith’s intimacy is suddenly available at scale, but only to founders who choose to use AI as a memory and synthesis layer rather than as a personalization-faking layer.
The reference class for AI-native software businesses isn’t HubSpot or Salesforce. It’s how the best independent professionals in any field have always built their practices. Doctors, lawyers, architects, senior consultants. They have reputations, networks, points of view, and bodies of work, and clients come to them. Outbound exists in the early years but it’s investment in standing rather than extraction of leads. Same activity, different objective function.
The studio model
The concrete form of this is a software studio with a component library, where the components are sophisticated enough that bespoke assembly per customer is economically viable, and AI is the assembly mechanism. The studio has a point of view, accumulates reusable building blocks over time, and each engagement is actually customized to that customer rather than reskinned from scratch. Every prior engagement makes the next one cheaper and better. The library is the moat. The taste in what to build into the library is the differentiation.
This model existed before in pockets (boutique consultancies, specialized dev shops) but was always margin-constrained because bespoke assembly required senior human labor. AI removes that constraint. The economics of a 50-person consultancy can now run with five people. That’s the actual structural shift, and it’s why this isn’t just consulting with extra steps. The unit economics are different enough to be a different business.
What this model needs that traditional SaaS doesn’t is, first, a real architectural point of view about what the building blocks are. Not features, not microservices, but conceptual primitives that compose. A studio that takes every problem with a fresh stack has no library and no compounding, while a studio with a coherent worldview about how a domain decomposes into reusable parts gets more powerful with every engagement. The taste in what to put in the library and what to leave out is the actual differentiation.
Second, the studio needs a pricing model that captures bespoke-feel without making bespoke-feel economically irrational. Pure custom dev pricing makes you look like an agency and caps scale. Pure SaaS pricing prices you out of the bespoke market. The shape that probably works is hybrid (a fixed scoping or diagnostic fee that compensates the senior thinking, a milestone-based engagement fee tied to the assembled solution, and a smaller ongoing platform fee for the parts of your library the customer keeps using), but the exact calibration is still being figured out per vertical. The simpler way to think about it: you charge separately for the senior judgment, the assembled artifact, and the continued access to the moat, and each of those three is priced against a different anchor.
Third, the studio needs a customer who values fit over price and is sophisticated enough to recognize bespoke-feel when they see it. Not every customer. SMBs often don’t, and large enterprises often have procurement that flattens everything back into RFP commodity. The sweet spot is mid-market and growth-stage companies, or specific verticals where the workflow is idiosyncratic enough that off-the-shelf is visibly painful.
The two-stage sales motion
Sales for this kind of practice splits cleanly into two stages, both of which already exist in mature service industries. The HVAC pattern is the most familiar version. You call an HVAC professional, they come out, they charge a diagnostic fee (typically a hundred dollars and change) to figure out what’s broken, and then they offer you a quote to fix it. The diagnostic fee is often credited toward the repair if you proceed, but it’s a real fee for real work, separately scoped from the resolution. You’re free to shop the resolution around or fix it elsewhere. The diagnostic creates value by enabling the next step, and the resolution is priced separately because it’s a different kind of work.
For software studios, this maps onto two stages:
Stage one: diagnostic. A real analytical engagement that produces a deliverable the buyer can keep regardless of whether they engage you for stage two. The output is a clear-eyed assessment of where the buyer actually is, not a pitch deck about where they could be if they bought your thing. The diagnostic should identify problems the buyer didn’t fully name and should include problems your studio can’t or shouldn’t solve, because those are the ones that prove the analysis is honest.
Stage two: solution. After diagnostic, the buyer has already received value, has already had their situation accurately seen, and has already experienced you as someone who understands their world. The proposal isn’t “let us prove ourselves to you,” it’s “here’s the subset of what we found that we’re best positioned to help with.” Conversion rates on stage two, after a well-done stage one, are dramatically higher than any traditional sales process, not because you’ve done sales better but because you’ve done the trust-building substantively rather than rhetorically.
There’s a deeper thing this two-stage split achieves. It changes the seller-buyer relationship from adversarial to collaborative before any money changes hands. In traditional sales, the buyer extracts information while committing to nothing, the seller extracts commitment while revealing minimum information. Both parties optimize against each other. In the diagnostic model, both parties work together on the buyer’s problem from the start. The adversarial dynamic dissolves, which is what allows actual understanding to develop, which is what allows the eventual engagement to be well-fitted.
There’s also a real two-tier structure on the diagnostic side. Reactive diagnostic (the HVAC pattern: customer presents a known problem, you diagnose, you quote) is one entry point. Proactive diagnostic (more like an annual financial review: you’re invited in to look broadly at the customer’s situation and surface things they didn’t know to ask about) is another. Both feed into the same stage-two engine. The public body of work serves a specific function in the proactive flow: it’s what makes a buyer think “I should have these people look at our situation, even though nothing is obviously broken.”
The trust problem
The free diagnostic model has a built-in failure mode. The diagnostician is also the seller of the resolution, which means they have structural incentive to find problems whether problems exist or not. This is the dealership pattern. You take your car in for a check, they tell you the tires are worn out (when they aren’t), you go to the place where you actually bought the tires, and you find out you were being upsold. The dealership probably got away with this many times before they tried it on you, but the cost of getting caught once is that you tell the story, the story travels, and the entire industry pays a reputational tax.
The free diagnostic in software has the same structural failure mode. Without a credible answer to “why should I trust your diagnostic when you profit from finding problems,” the model degrades into sophisticated sales theater, which is what most “free assessments” in B2B already are. Buyers know this, which is why they’re cynical about free diagnostics by default.
There are a handful of mechanisms that create diagnostic integrity, and they only work when stacked. The strongest is structural separation between diagnosis and remediation. Home inspector ethics codes and many state licensing rules prohibit inspectors from doing the repairs they recommend, and fee-only financial advisors sell their independence as the product (no commissions, no kickbacks, paid only by the client). The model embeds the integrity into the structure itself rather than relying on the diagnostician’s restraint. Adjacent to that is verifiable transparency about methodology, where the diagnostic produces evidence the buyer can independently evaluate against external standards. Show the data, show the reasoning, show comparable cases. The strongest form of this is open source. Free alone isn’t enough, because “free” is exactly what every dealership-pattern free-checkup advertises. Free plus open source is a different thing. The buyer can run the diagnostic themselves, read the code, fork it, and verify that the tool is doing what you claim it does rather than quietly tilting toward whatever upsell pays best. A diagnostic that can’t be audited is just an opinion with letterhead.
Then there’s reputation that’s costly to acquire and easy to verify. A studio that has been publicly thinking about a domain for years can do diagnostics buyers trust because the studio has too much accumulated reputation to risk on a single dishonest assessment, and that calculus has to be visible to the buyer for it to do any work. Reputation as a check requires that the buyer can see why dishonesty would be expensive for you. The fourth mechanism is willingness to deliver bad news that costs you the engagement, the “your problem is real but we’re not the right firm to solve it” moment that buyers remember forever precisely because it’s rare and costly to the seller. The fifth is third-party verification, the studio confident enough in its diagnostic to explicitly invite the buyer to validate the conclusions with another source. The offer alone changes the dynamic and defuses residual suspicion, even if the buyer doesn’t take you up on it.
A studio that stacks these becomes the rare thing in B2B services: a credible diagnostic, scarce enough to command a premium and generate referrals at rates other models can’t match. A studio that does none of them inherits the dealership’s reputation. The discipline is operationally hard, especially in year one when revenue pressure makes the dealership shortcut tempting, which is most of why most firms quietly skip it.
The three-entity ideal
The cleaner answer to the trust problem is structural rather than dispositional. Separate the diagnostic, the arbitration, and the execution into three independent entities, where the diagnostic entity’s only product is accurate diagnosis, the implementation entity’s only product is quality execution, and the arbitration entity’s only product is certifying that the diagnostic was sound and that the implementation matched the diagnostic before payment releases.
Three separated entities is the only configuration that avoids all the obvious conflicts. Diagnosis plus arbitration creates the captive consultant who writes diagnostics tailored to their preferred implementer network. Arbitration plus implementation creates the arbiter who routes work to themselves. Diagnosis plus implementation creates the dealership. Every pair conflicts in a different direction, which is why the three-entity model is what survives when you write down all the failure modes and solve them at once rather than one at a time.
This is the same shape as the building inspector / general contractor / specialist trade structure in construction, except the analogy is rough rather than exact. Building inspectors check code compliance against statutes, not quality against a prior diagnostic spec, and the GC is the prime contractor rather than an arbiter. The closer parallel is medicine, where the diagnosing physician, the surgeon who operates, and the hospital quality and credentialing apparatus are mostly separated, with insurers playing part of the arbitration role. The deeper point holds in both cases: mature industries that handle high-stakes transactions develop institutional separation precisely because integrated providers fail under the trust load.
It hasn’t existed in software because the industry is too young. Real estate took roughly a century and a half to develop title insurance (1876), formalized escrow, separate roles for home inspectors and contractors, mechanic’s lien laws (1791 onward), and the rest of the apparatus that makes large transactions trustworthy. Software is at the equivalent of pre-industrial real estate, where every transaction is an integrated provider hoping you’ll trust them. The agentic-first context compresses the timeline. Diagnostic outputs in machine-readable form can be matched to implementer capabilities by agents. Reputation can be tracked across engagements through verifiable transaction records. Disputes can be analyzed by agents that compare diagnostic specs to implementation outputs. The infrastructure that took real estate generations to develop could be built in years in software, but only if someone actually builds it.
The economic version of the model is arbiter-controlled escrow. The buyer puts payment into escrow at the start of engagement. The diagnostician is paid (partially) when the arbiter certifies the diagnostic is sound, with a holdback released when the implementation succeeds. The implementer is paid milestone-based with final payment on completion. This forces the diagnostician to have reputational and financial skin in the implementation succeeding, which means they can’t write diagnostics and walk away, and they have to remain involved through implementation to interpret the spec where reality requires adjustment. It’s how a good architect operates relative to a builder.
The honest caveat: arbiter-controlled escrow for B2B software does not exist as a market mechanism today. The closest live precedents are smart contract escrow patterns from crypto (where a release is gated by an oracle attesting that some condition was met), and the historical institutional patterns from construction and real estate. Smart contract escrow handles the funds-release mechanics deterministically but requires arbiter certifications in machine-readable form, which is a real engineering problem. Reputation systems substitute for legal enforcement only in tight communities. The first studios that build the diagnostic-implementation split into their own structure can run a stripped-down version of this model with a third-party reviewer they trust, well before anyone builds out the formal infrastructure. The model is most useful as a target architecture that explains why pure separation works structurally, even if year one is closer to “diagnostic firm with a strong principle and a few trusted implementer relationships” than to “smart-contract-escrow-as-a-service.”
How current software roles are splitting
The three-entity framework isn’t really a market structure proposal. It’s a description of what every knowledge work role becomes when execution is no longer scarce. The diagnostic-arbitration-execution split was always present in every role, but the execution component dominated the visible work because execution was the bottleneck. With execution absorbed, the other two components become the visible work, and they’re different in kind from each other and from execution.
Product management is roughly half diagnostic, half arbitration, with a thin execution layer that AI is already eating. The diagnostic part is understanding user problems and translating them into specifications. The arbitration part is mediating between engineering, design, marketing, and customer needs, and certifying that what gets built addresses what was specified. The execution part (writing documents, maintaining roadmap artifacts, running rituals) is being absorbed. Senior PMs are increasingly hired for judgment, taste, and customer insight. Junior PMs are increasingly squeezed because their work was mostly the executional layer.
Engineering has the most visible split. Senior staff and principal engineers do diagnostic work (understanding why systems fail, designing architectures) and arbitration work (code review, design review, deciding which approaches will work in which contexts). Mid-level engineering, which is mostly independent feature implementation, is being absorbed quickly because the work is well-specified and intermediate-scope, which is exactly the shape AI handles best today. This is why some senior engineers feel oddly secure while mid-level engineers feel acutely threatened. The role being eliminated isn’t engineering as a whole, it’s the executional middle, which is most of current engineering employment by headcount.
Design follows the same pattern. Diagnostic design (understanding user needs, articulating design principles) and arbitration design (design system stewardship, certifying implementations match design intent) survive. Execution design (producing variants of screens) is being heavily compressed.
QA, sales, customer success, DevOps: same pattern across all of them. Senior diagnostic and arbitration work survives and grows. Executional middle is being absorbed.
This explains why AI feels threatening to junior knowledge workers and exciting to senior ones. Junior work is mostly execution, while senior work is mostly diagnostic and arbitration. The traditional career path was junior execution, growing into mid-level scope expansion (more independent ownership of bigger pieces, still mostly execution), growing into senior judgment. That path required years of executional experience to develop the judgment. With execution absorbed, the path doesn’t exist anymore. New entrants can’t develop senior judgment by spending five years executing because there’s no executional work to spend the years on. This is a real problem nobody has a good answer for yet.
The implication for individuals is that everyone in knowledge work needs to figure out whether their actual strength is diagnostic, arbitration, or something else, and develop in that direction. The generalist who was decent at all three but excellent at none was viable when execution dominated time allocation. They’re going to be increasingly squeezed as execution disappears and the remaining work rewards specialization.
What this means for founders building now
The framework has specific implications if you’re trying to build an AI-native business in the current moment.
Pick which role you’re playing in the three-entity model. The diagnostic firm is the highest-trust and most reputational, the smallest market, and the slowest to scale. The arbiter is the most network-dependent and the rarest configuration. The implementer is the most execution-heavy but potentially the largest market. Trying to be all three under one roof reproduces the dealership problem unless you have real internal separation, which most small firms can’t sustain. Picking one and going deep is the durable choice.
Invest in the public body of work before you invest in the product. The body of work is what earns standing, attracts the right buyers, demonstrates pattern recognition, and creates the magnetism that replaces broken outreach. Founders who arrive with five years of essays, podcasts, or open source work in a domain have a structural advantage that founders who arrived last week cannot replicate quickly. You can’t AI your way to that. You can only have spent the years.
Run the body of work as laissez-faire as you can stand. Give diagnostics for free, with no conversion ask attached. Tell the customer about your solution as one option among several they could pick, name the situations where another approach would serve them better, and let them leave without a follow-up sequence chasing them. This isn’t strategic patience, it’s structural. The conversion-free posture is what makes the body of work read as a body of work and not a long-form sales funnel. Buyers who trust you because you helped them once without trying to close them are the buyers who tell three other people about you. The magnetism comes from the absence of the ask, not from a more sophisticated version of the ask.
Build the diagnostic offering before the product offering. Even if you’re playing the implementer role, your sales motion needs to start with a diagnostic that has real standalone value. The diagnostic teaches you the persona’s actual problems in detail, which compounds your understanding for the next engagement. After ten diagnostics in a single persona, you understand that persona’s problem space better than almost anyone, because you’ve done senior-level analysis on ten real situations. That accumulated understanding becomes the foundation of the building-block library, the public body of work, and the point of view that attracts the next ten diagnostics.
This idea isn’t new. “Get your free cybersecurity audit readiness report” has been a B2B lead magnet since the 2000s, and similar versions exist in every consultative-sale category, free SEO audits, free pipeline reviews, free architecture assessments. What is new is that the diagnostic stops being a one-page PDF behind a form and starts being the actual tool. You hand the customer not just the verdict but the instrument, the source code, the methodology, and the right to keep using it whether they buy from you or not. The previous era’s free report was a teaser controlled by the seller. The current era’s diagnostic is a service plus a working artifact in the buyer’s hands, and the giveaway is the point rather than the cost of doing business.
Don’t fake the integrity mechanisms. If you’re not actually willing to deliver bad news that costs you engagements, refer buyers to better-fit firms, expose your methodology to scrutiny, and walk away from misfits, the integrity claims will read as marketing language and buyers will detect it. The discipline has to be real or it’s worse than not claiming it.
Accept the slower timeline. The framework rewards patience and compounds in ways that aren’t visible quarter to quarter. Founders running this model spend a year or two looking like they’re not making progress while they build the body of work, do the early engagements, accumulate the library. Year three is when the compounding becomes visible. Year five is when the practice is actually defensible. This is incompatible with most venture-backed timelines, which is part of why most venture-backed companies will not run this model and will continue trying faster versions of traditional SaaS until they hit the trust ceiling and stall.
Closing
The framework I’ve sketched here is a hypothesis about how AI-native software businesses should be built. It might be wrong. The test is whether founders who run it produce results that match the predictions: better trust with sophisticated buyers, higher conversion rates from diagnostic to engagement, lower churn through better fit, referral rates that compound, durable defensibility against faster-moving competitors who are still running traditional playbooks.
What I’m reasonably confident about: the old playbook is broken in specific structural ways, and the breakage is going to get worse. The economics that justified validate-then-build are gone. The personalization mechanics that justified outbound are gone. The integrated diagnostic-and-sale model is inheriting reputational damage that compounds with every dishonest interaction in the market. Buyers are getting more cynical, faster, than sellers are adapting.
What I’m less confident about: which exact structural form replaces it. The three-entity model with arbiter-controlled escrow is one coherent answer. There are probably others. What’s necessary across all of them is some structural mechanism for trust integrity, because the dispositional mechanism (just be honest) doesn’t scale and doesn’t survive financial pressure.
The framework is most useful if you can use it to make a specific decision about your own work. Which role are you actually playing. What body of work would establish your standing in that role. What does your first diagnostic look like, concretely, with which persona, producing which deliverable. Working through those specifics is where the framework becomes real, and where the test of whether it’s right actually happens. I’d rather you used this and discovered where it breaks than treated it as authoritative.