Partners Won't Leave for AI-Native Firms. They'll Build Their Own.
Own the client. Control the pace of change. Walk out with an asset the firm can't keep.
The partners who see what's coming won't jump to an AI-native firm.
They'll leave to build their own.
Read Ted Theodoropoulos's How AI Will Kill Law Firms and the obvious conclusion is that the talent flees: rainmakers grab their books and defect to whichever firm is furthest ahead on AI. That's the move everyone is bracing for, but it’s missing a newly attractive alternative. A rainmaker who jumps to someone else's AI-native firm has traded one housemate for another who happens to have better software.
Two things break the jump. First, the more AI-native a firm becomes, the more it runs as a product, and a product-based firm owns the client, not your relationship. Second, and this is the part almost nobody is pricing in: even the best AI-native firm changes at its own pace. Its roadmap, its committee, its politics, and its risk tolerance decide how fast anything happens. Jump, and you are still a guest of your slowest partner’s change management.
The partner who actually wants to control their destiny needs two levers, not one: control of the client, and control of the pace of change. The only place you hold both is a firm you own. That used to be a romantic idea with a brutal economic floor. It isn't anymore, because AI compresses teams. Fewer people do the same work, and a lean boutique with a deep stack can now source the talent, judgment, and resources that used to demand Big Law's scale. So the real question is not which firm you join. It is what you have to build to leave on your own terms.
The on-ramp (everyone does this once, first)
Budget a weekend, not a sabbatical.
Stand up a workstation. Use a SOTA model, a terminal, a coding harness. Think Anthropic or OpenAI, Claude Code or Codex, and whatever terminal sits on your computer. Done when: you can open a terminal and a project folder without a tutorial open in the next tab.
Learn the few commands that matter. The five terminal commands you actually use, and three git commands: commit, push, and roll back. This is not computer science. It is the ability to save a working version and restore it when you break something. Done when: you can break a file on purpose, then restore the last good version from memory.
Write your first CLAUDE.md. One page that tells the model who you are, what good output looks like in your practice, and what it must never do. Done when: the model follows your house rules without you re-explaining them every session.
That's the on-ramp every builder shares. You can find all of this on PossibLaw. We are your home to become a builder. You don’t do this because you are going to become a software developer. You do this to start compounding your skills with AI. This is how you ensure you have a say in your future instead of just defaulting to someone else. You build one real thing, on real work, and you keep the receipts.
Rainmakers: own the stack, not just the book
Here is the trap almost nobody is pricing in. You are portable because your book follows your relationships, so the reflex move is to jump to whichever firm pays the most for the book. But the more AI-native a firm becomes, the more it runs as a product, and the more the actual work is done by the machine instead of by you. When the work is product-based, the firm starts to own the client, not your relationship. Jump to an AI-native firm on those terms and you have handed your book to someone else's machine.
So portability has to mean something new. It is no longer just relationships you can carry out the door. It is a stack you own: the spec, the machine that runs your matter, and a client tie that runs through your product rather than the firm's letterhead. You need a firm that can run the machine, and you need the machine to be yours.
There is a second force on your side if you build. AI compresses teams, so fewer people do the same work. Big Law's moat has always been three things: top talent, judgment, and resources at scale. The moment a small team with a deep tech stack can source all three, that moat drains. A rainmaker who can run their own machine does not just get to stay. They get a new option: go out on their own, or build a lean boutique that controls the client by controlling the firm, and that sets its own pace of change instead of waiting on a committee to approve it.
Pick your signature matter. The matter type that makes your book yours. You are going to turn it into a product the client comes to, not a favor only you can do.
Write the spec, not the code. Document the matter end to end: intake questions, decision tree, standard positions, the red lines you never cross, and the output a client values. This is the blueprint of your machine. Done when: a competent associate, or a workflow, could run the matter from your document and hit your standard, and all that is left is your judgment. Fails when: you keep the workflow in your head "because it's too nuanced to write down."
Build the machine and keep it yours. Commission the workflow that runs your spec, or build the first version yourself, but hold the asset in your name: your spec, your prompts, your evaluations, your client-facing product. Done when: the system produces a first draft you would put your name on after a review, and the intellectual property sits with you, not the firm's platform. Fails when: you let the firm's infrastructure own the build, because then you have only productized yourself for them.
Set the verification standard. You own the bar: what gets checked, what triggers human review, what never ships without your eyes. Done when: everyone downstream knows the exact line where the machine stops and your judgment starts. That line is what the client pays the premium for.
Anchor the client to the product. In a product world the client stays with the product. Tie the relationship to the thing you built and own, not to the firm's name on the door. Done when: if you walked tomorrow, the client follows the product, not just the friendship.
Run the two audits. First the firm: name which workflows actually changed this year, and whether there is a machine worth running or just a press release about buying Harvey. Then yourself: with your stack owned and teams compressing, could you run your book from a lean boutique or on your own? Done when: you can say in one sentence whether your future is inside this firm, inside a better one, or inside one you build.
You are building to stay in control of the client. You still do not need to be the one typing at 1 a.m. Owning the stack means owning the spec, the standard, and the business model, and directing the build, not hand-coding it. But a rainmaker who only changes firms is renting their portability from whoever owns the machine. A rainmaker who owns the stack can stay, move, or leave and start something lean, because the thing the client values now lives in a system they control. Big Law's scale stops being the only place top talent, judgment, and resources can live.
The only wrong move is sitting and watching
None of this is free. Every hour you spend building is an hour off billable work or business development, and the short-run scoreboard will not reward you for it. If your firm's leadership is genuinely moving, with real budget and real workflow change already underway, then join in. You are learning to compound your skills. Keep your eye out for where you can turn those skills into owned leverage.
If your firm isn’t moving fast enough or they are doing marketing theater, then its time to start building. The cost of building early is real and it shows up this quarter. The cost of building late is that you don't choose your terms when the layer beneath you gives way. So when someone says "become a builder," know that it isn't one act. It's a rainmaker owning the stack their clients run on.