I was catching up recently with a primary school friend—an ex–Jane Street developer who’s now helping a hedge fund build their technical infrastructure from zero to one. He’s also the type of engineer who has been rigorously testing every iteration of GPT since GPT‑1.
When I gave him a quick overview of the current legal tech landscape—especially the standard suite of Word add-ins that a lot of startups are building—he was genuinely confused. Not in a dismissive way. More like: wait, this is the center of gravity? He was surprised not just by the dominance of legacy tech (Microsoft Word), but by how delicate the ecosystem feels once you look under the hood.
That conversation stuck with me, mostly because it made something obvious feel newly strange: we’re trying to build “AI-native” workflows on top of a document format that was never designed to behave like a AI-native system.
The Double Pendulum Problem
My friend’s basic point was that a lot of modern legal tools—especially Word add-ins that manipulate documents—are operating in a fundamentally unstable environment.
He described it as a problem of balancing an inverted double pendulum: a system so sensitive to small changes that it becomes chaotic. You’re trying to layer automation on top of:
the Microsoft OOXML standard (the code behind .docx), and
Word’s proprietary rendering/editing engine (styles, numbering, track changes, cross-references, tables, etc.)
That combination matters because many tools want contracts to behave like structured data, but .docx is ultimately optimized for visual layout and human editing. It can contain structure, but it doesn’t reliably enforce semantic consistency the way a programming language or a database does.
This is where a lot of “it worked in the demo” pain comes from.
The Jane Street Difference: Code as Culture
This is where the Jane Street comparison comes in. At Jane Street, the line between “trader” and “developer” is often blurred. Code is not a support function. It’s the shared language of the firm. A lot of operational knowledge lives in systems people can inspect, test, and iterate on.
BigLaw’s current posture looks different. Most firms are buying external tools—Harvey, Legora, and various LLM wrappers—and trying to layer them onto existing workflows. That might be the right move in the short term. But it also raises a question I keep coming back to:
If every firm buys roughly the same tools, what’s the source of durable advantage?
The more I hear these conversations, the more the “own the stack” idea keeps showing up—not because every firm needs to become a software company, but because workflow is where differentiation tends to hide.
This conversation prompted me to re-read Tritium founder Drew Miller’s article on the same topic, this time with a bit more understanding and in awe that he had that vision several months back.
Core Hypothesis: Will all lawyers become coders—or just a few?
The tech story is only half of it. The other half is people.
So here’s the question I’m actually trying to get at:
Are we heading toward a world where most lawyers become marginally technical/AI-fluent, or a world where a smaller group becomes extremely technical and everyone else uses whatever interface they’re given?
I do think we’re already seeing a split:
On one side: lawyers using AI wrappers to do the same work, improving speed at the margin.
On the other: a smaller group who treat AI as infrastructure—something you configure, evaluate, and integrate into a workflow.
That second group is what I’m calling the Legal Quant.
What I mean by “Legal Quant”
A Legal Quant isn’t “a lawyer who uses ChatGPT.”
It’s a lawyer who is comfortable getting closer to the system:
comfortable in a terminal (or at least not scared of it)
understands why “just paste it into a model” stops scaling
thinks in terms of prompts + retrieval + evaluation, not just “ask nicer questions”
cares about data integrity and provenance (what the model is allowed to rely on)
has opinions on RAG architecture, failure modes, and UI/UX design
can build small tools and can collaborate tightly with engineers without getting lost in translation
This isn’t about coding as identity. It’s about control—the difference between merely using a tool and expanding the frontier of what’s possible. Over the past month, I’ve met 30+ lawyers who fit this “legal quant” profile, and we’ve formed a small but intensely active Discord group.
What we discuss isn’t “which legal tech startup is best.” It’s end‑to‑end automation experiments and bespoke stacks. Everyone is building their own little Iron Man suit. We share notes on adopting tools like Claude Code and Claude Cowork the moment they ship, on building open‑source infrastructure to solve common bottlenecks, and on how to deploy lawyer‑built apps at real scale.
The Law Firm as Liquidity Provider
If Jane Street is often described as a “liquidity provider”—reducing friction so transactions happen smoothly—what would the legal equivalent even be?
Legal friction (as it shows up day-to-day) seems to come from two places:
Mechanical friction: manual labor inside legacy systems (Word formatting drift, track changes complexity, versioning, iManage/Litera workflows, etc.) Law firms create dedicated document processing units just to delegate these software navigation tasks.
Productizable friction: practice areas that are already rules-based and repeatable. Tax, ERISA, IP, Employment, offshore advice, regulatory checklists—these are often closer to “structured logic + exceptions” and hold a support role for larger bespoke matters (M&A, IPO, fund formation). They would be needed by boutique firms that is trying to deliver competence quickly in a niche where they don’t have a deep bench.
A “Legal Liquidity Provider” would be a firm that removes this friction entirely. These shouldn’t be serviced by lawyers writing prose in Word; they should be serviced by systems that treat law and contracts as code.
Legal Superintelligence
I am increasingly convinced that the next great law firm would be a firm that “rolls up” these rare Legal Quants and gives them the mandate to build Legal Superintelligence. By Superintelligence, I mean meeting demands that clients do not yet know they need as of now. Here are some examples that feel directionally plausible:
negotiation simulation: pattern-based scenario planning (“when we pushed on X in similar contexts, what happened next?”)
benchmark visualization: interactive distributions and filters instead of static “market is…” paragraphs
It’s less about one magical model and more about building a system that can answer questions the old workflow makes too expensive to ask.
Challenges
A few issues seem like they matter more than the usual “AI is coming” discourse.
1) AI slop vs AI excellence
There needs to be a real distinction between “we used AI to go faster” and “we used AI to raise the quality bar.”
A lot of current usage is basically shortcut-seeking: high volume, thin oversight. That can be useful, but it isn’t a long-term strategy.
The Legal Quant mindset is closer to finance:
quants hunt alpha
legal quants hunt excellence (accuracy and speed above the market)
Excellence looks like: “Out of 5,000 provisions across 150 MFN election booklets, how many deviate from our standard position, what are the deviation patterns, show your work and visualise it in a client-friendly interface.”
Some of that can be done today with frontier tooling (Claude Code helps). It’s much harder to do reliably inside generic wrappers, partly because wrappers are designed to be general-purpose and safe—not deeply firm-specific and workflow-integrated.
2) Incentives and recognition
Jane Street identifies technical talent early and pays for it accordingly. BigLaw, by contrast, rarely recruits or compensates technical–legal talent in the same way. Among the ~30 legal quants in the Discord group, the shared frustration is that this skill set is rarely recognized internally as a first‑class form of legal leverage.
Which raises the real question: is the market accurately pricing this talent today, or are we simply early—meaning there’s a genuine opportunity for someone willing to underwrite it?
3) Clients: relationship business vs system business
BigLaw often operates more like investment banking than trading: relationship-driven, high-touch, “last mile” effort matters, and clients sometimes want process as much as they want output.
So the question isn’t “can we build the Jane Street of law.” It’s more specific:
which clients will pay for system-level capability?
which matters are repeatable enough to justify deep buildout?
what does trust look like when the interface is a workflow + dashboard, not just a marked-up Word doc?