Reactions to his piece were polarized. On one side were people who have actually used the tools he writes about and broadly shared his sentiment. On the other side, critics who haven’t used the tools decried the piece as propaganda from the AI industry to hype up its vaporware that amounts to little more than a novel form of Google search. Rather than engage with Shumer’s claims, these critics would denounce AI as “not actually reasoning” or “fundamentally incapable of producing something new.”

Reasonable people can disagree about whether Shumer is overly alarmist in response to AI progress or whether recent progress represents true exponential improvement which inevitably results in “AGI”. Personally, I don’t anticipate that LLMs will break the conventional paradigm of technological progress where new tools make people more productive rather than replacing them outright.

But to disparage his description of recent advances by claiming that AI can’t actually think is like quibbling about whether a car with a 350 horse-power engine can actually gallop like 350 horses. If you’ve never seen a car before, this might seem like a worthwhile topic of discussion. If you’ve driven down the highway at 70mph, however, you understand that it’s so beside the point that it’s frankly not worth discussing.

The only reasonable conclusion I can draw about this form of criticism is that these AI critics have not driven down the highway. They have not used Claude Code or OpenAI Codex themselves and are unaware of what they’re capable of. I too would be skeptical of Shumer’s claims if I hadn’t used the tools he writes about!

So rather than argue with these critics in the abstract or accuse them of being irresponsible for weighing in on an important subject without having approached it with enough curiosity to actually use the tools they opine on, I will just show them.

Here are three concrete tasks I’ve accomplished with AI tools in the past month that have changed the way I work.

AI wrote me a financial report that I couldn’t have written myself

My startup, Version Story, sells software to law firms. While modeling our finances this past week, my cofounder Kevin needed to understand the marginal cost of expanding one of our existing accounts with new users.

This is a complex, multi-variable problem. Many of our Amazon Web Services (AWS) costs are fixed and amortize with scale. Some are step-function costs that amortize until hitting a critical inflection point, at which point we need to scale up. Many are variable and impossible to calculate bottom-up so we can understand “one redline costs us X in AWS spend.”

I did not know how to approach this problem. So I asked Claude Code to help me write a script that could do it for me.

I gave it read access to an Amazon Web Services tool to fetch our billing data from the past quarter, and access to the Google BigQuery tool to read from our raw analytics data.

First, it analyzed all of our spend categories and quickly identified the fixed costs. For each variable cost category, it ran a linear regression analysis on-the-fly to correlate our spend to usage increases across the actions like file uploads, comparing documents, etc. It then wrote out its calculated cost/action estimates in a JSON file (a file used for storing data) that the script would use.

The structure of this file looked like the following:

Cost per file upload:

• Total cost: $N

• Breakdown:

  • Cost for AWS Service 1: $X

    • Notes: “Each file upload triggers Service 1 five times. Given the unit costs of the service…”

  • Cost for AWS Service 2: $Y

  • Cost for AWS Service 3: $Z

It broke down the cost of each of our key actions by estimating its cost across different AWS services. For each service, it describes how it arrived at this figure so that future Claude Code sessions could recalculate the figure if our infrastructure changes.

Claude Code used Google BigQuery data to script usage patterns for a customer over the past three months. It models a distribution of their usage data to project expected usage for the next 100 users, then projects expansion costs using the calculated cost assumptions from the file above.

The report includes a summary of our costs and margin based on the customer’s previous usage, with a granular analysis of per-user cost.

I don’t know how I’d have performed this analysis a year ago. My results would have certainly lacked the granularity and precision of this report. What would have taken most of a day, Claude Code completed in about an hour.

AI automated the worst part of my job

Every time we close a new deal with a large law firm, we need to fill out a compliance form. These forms ask about our security posture, certifications, data-access policies, etc.

The forms aren’t hard. We maintain good security practices and are SOC-II compliant. They’re just remarkably tedious. Every form asks similar questions with slight variations. Each one takes hours of digging through precedent forms, looking for similar questions, copying and rewording answers to fit, or starting from scratch when you can’t find a good match. We used to hire contractors to fill out these forms.

With Claude Code, my cofounder built a system to automate them.

The core idea is a “knowledge base” — a single file that serves as our source of truth for every security question we’ve ever been asked. Each entry contains a canonical version of the question, our official answer, and references to the specific compliance frameworks and vendor forms where that question appears.

The system works in three phases. First, Claude Code extracts every question from a completed questionnaire, capturing the exact structure of the form including question text, answer options, field identifiers. Second, it maps each question against the knowledge base to find equivalent questions we’ve already answered. Third, it fills in the new form automatically, color-coding each answer by confidence: green for direct knowledge base matches, yellow for answers carried over from similar previous questions, and red for questions that need manual review.

The first questionnaire we ran through the system took real effort. We had to build the knowledge base from scratch, confirm the mappings, and review every answer. But the second form we received had about 80% overlap with questions we’d already answered. By the third, we were close to 90%.

Each hour we spend answering one vendor’s questions now makes every future questionnaire faster. A task that used to take several hours of tedious copying, pasting, and rewording across old forms and policy documents is now mostly automated. We review the flagged items, make a few edits, and submit.

AI built me a custom tool I’d pay $100/month for

I spend a lot of time solving engineering problems related to Microsoft Word files. Our platform produces “redlines,” a type of Word file that shows the changes made to a document.

Docx, Word’s file format, is difficult to work with. It’s poorly documented and minor discrepancies in its underlying structure can cause a file to fail to open entirely.

Solving these problems is hard. It requires surgically changing minor details in the underlying structure of the document until you identify the cause.

Existing tooling to solve problems like this is limited.

My workflow looked like this: unzip the docx to extract its raw XML, open the files in my code editor, make changes, rezip it, test if it opens in Word, and repeat. All while keeping track of each hypothesis in separate files and reminding myself not to overwrite the original.

With Google AI Studio (a platform for agentic AI coding like Claude Code), I built a tool customized to my exact workflow. It opens docx files in the format I need, lets me make changes and quickly test if they solve the problem, tracks every modification I’ve attempted with version control, and has built-in diffing to compare document structures across files.

It would have taken months to build something like this without AI. If it was a product on the market, I’d have easily paid $50-$100/month for it a year ago.

But instead, I built it in a little over an hour without looking at a single line of code.

Automated coding is a very big deal

Some people are skeptical that AI will have much of an impact outside of coding. Despite the dubious implication that automated coding will only affect the software engineering profession, I deliberately chose examples that could apply to other professions.

The outputs of these exercises pertain to software startups, but the contours of the problems are general. Analyze data from multiple sources to create a report. Find precedent questionnaires to fill out a compliance form. Build a tool for a workflow that the market doesn’t have a solution for.

Many, many roles in the economy deal with problems like these. And that’s before you consider the impact on coding itself, which is already enormous.

Coding projects that would have taken days a year ago now take hours. With the latest models, I can often one-shot a full feature end-to-end in a single prompt. If we have a bug, Claude Code can usually fix it with just the error logs. I’ve worked through many tasks in recent months that sat on the backlog for years because they weren’t quite worth the time. Now they hardly take any time at all.

One of our engineers, Zak, has historically been skeptical of AI-coding. Before the tools had matured (i.e. four months ago), he usually felt that it took more effort to baby-sit the AI than to just write the code himself.

Yesterday, he was working through a particularly thorny problem in our document rendering system. After mentioning on a call that it would require a significant deep-dive to solve, he messaged this to the team.

A year ago, I daydreamed about what our team could accomplish with five more engineers. Now it’s difficult to imagine what we’d even have them work on.

But is it intelligent?

Now look, if you want to debate whether Claude Code doing my work for me in a fraction of the time satisfies your capital-T, True definition of “intelligence”, by all means, go for it. No true Scotsman, right?

If you don’t think all this AI stuff is that impressive, you’re entitled to that opinion. Although if the automation of coding in only a few years, the poster child of what has been the most important skill in the digital age, doesn’t impress you, I’d love to know what does.

But when considering whether these tools have the power to be economically transformational, debates like these are beside the point. The tools work. Now. In a real tangible sense that eludes philosophical pontification.

This is the tip of the iceberg. Diffusing new technology through the economy takes a while, and I still know software engineers who don’t use Claude Code. As evidenced by recent debates, even pundits purporting to speak with authority on AI haven’t used these tools!

In time, however, that will change and professionals throughout the economy will have access to capabilities that will make their heads spin. In light of that, I believe it is worthwhile to spread the message that, yes, AI actually is quite a big deal. People should pay attention to and experiment with AI instead of writing it off as vaporware.

I know critics will respond by accusing me of being an insider shilling VC propaganda. “See! He just wants you to use AI!” For the record, I am not affiliated with or invested in any AI company, nor is my startup Version Story an “AI” company. I have no financial stake in your AI-skepticism. I have simply experienced first-hand what AI is capable of.

But the good news is you don’t need to trust me! You don’t need to trust the skeptics either. You can try it yourself.

It’s not that hard. Set aside 30 minutes and find a decent YouTube tutorial to learn how to use the terminal and Claude Code. Build that app idea that you and your college roommate talked about but never built because you didn’t know how to code. Take a stab at automating that tedious task at your job that you hate so much.

You can just do it. No one’s stopping you. And when it works, I think you’ll begin to see what all the hype is about.

When I attended the Legal Tech Mafia breakfast last week, vibe-coding lawyers were undeniably the main topic of conversation. Despite the moderator’s best efforts to guide us elsewhere, the conversation kept circling back to a spirited debate: Is vibe-coding fundamentally limited — insecure and unreliable, useful for prototypes but too risky for real-world deployment? Or does it represent something more significant? Could it be a genuine shift in how legal software gets built, and perhaps the future of legal tech itself?

As a professional software engineer with 10 years of industry experience, I feel confident claiming that building software with AI is not simply a neat trick for building prototypes, but a true paradigm shift in how software is built. AI coding tools are already shipping production-grade code across the industry despite being brand new.

But aren’t vibe-coded apps brittle and prone to failure? Don’t they break when you push at the edges? How could lawyers ever trust them?

The answer to these questions depends on when you ask. In January of 2026, the answer is yes. Lawyers should not trust apps they vibe-code with their clients’ confidential information unless they have the technical expertise to deploy their tools securely. But if you’re asking one year from now, or in two years, the answer may be very different.

The scale of this shift is so significant, it should call into question every assumption we have about the way software is developed. If we study technological revolutions of similar magnitude from history, we should expect to live in a very different world soon, with new infrastructure and new competencies expected from professionals.

Here’s what the future of the vibe-coding lawyer looks like.

AI is revolutionizing software development

If you had asked me a year ago if I predicted AI would write nearly all of my code by the end of 2025, I’d have told you no way. I wasn’t an AI skeptic — in fact, I would spend hours a day in the Claude chatbot working through problems. I’d already tried AI coding tools like Cursor, and they just weren’t that good. The amount of time it would take me to correct Cursor’s mistakes was more than the amount of time it’d have taken me to write the code myself.

Then Claude Code was released in March 2025 and it changed everything. The first time I saw it autonomously traverse multiple codebases to build a full-stack feature end-to-end without making a mistake, I realized that this was a moment of significance akin to the original release of ChatGPT.

But despite its power, in those very early days of agentic AI coding, there was much debate among coders of whether these tools could ship production-grade software. It still made mistakes. Not everyone knew how to use it well. We still needed a couple more model releases before it could consistently ship high-quality code.

Now, only 10 months later, the conversation is different. The consensus among coders is overwhelmingly that AI coding is the future and that there’s no going back. AI is even improving the code quality of those most skilled in using it. In my case, Claude Code can often diagnose the root cause of a bug much faster than I can, making our codebase more reliable over time.

Practically every new feature or bug fix I ship is now written with Claude Code. Anthropic’s new wildly popular “Cowork” was built completely with Claude Code. Even Linus Torvalds, the famed engineer whose work is regarded as a paragon of rigor and quality among coders, is vibe-coding.

In the words of ChatGPT, “that’s not an incremental improvement. That’s a paradigm shift.”

These examples should call into question the supposition that AI is only capable of building flimsy, insecure prototypes.

The difference between a software engineer building software with AI and a lawyer doing it is that the software engineer has a suite of processes and infrastructure in place that allow them to build confidence in what they’ve built before it’s deployed. Code review, QA testing, deployment pipelines with automated unit tests and security checks, production monitoring, rollback infrastructure, etc. all allow a software engineer to build confidence in what they’ve built before deploying it to production.

The reason why coders have these systems and lawyers don’t is that lawyers have never needed them in the past. But as AI enables more and more lawyers to build their own tools, this is changing.

So can we imagine the legal profession adopting a set of practices that would enable lawyers to reliably and securely build their own tools? I believe we can.

Let’s walk through what secure vibe-coding infrastructure for lawyers could look like in practice.

A lawyer’s job in 2030

You’re an associate lawyer at a law firm in 2030. You’re reviewing a Limited Partnership Agreement for an investor client and need to populate your firm’s standard comments table, a structured summary of the agreement’s key terms. You’ve been using your Legal AI provider’s chatbot to extract the provisions, but it’s laborious to copy and paste the text output back into the table cell-by-cell.

You visit your firm’s tech dashboard and ask if there’s a tool that can automatically extract the key terms and populate the table directly. The answer comes back: no such tool exists.

So you decide to build it yourself.

You click a button that says “build tool.” This opens an interface that allows you to write a prompt to build your application. You describe your problem and the AI agent starts building it.

The agent builds your prototype in a sandboxed testing environment. All of its predefined integrations are mocked-out so that you can immediately begin testing your tool’s functionality as if it’s connected to the real thing.

You test your tool on a set of sample documents. It’s not populating the comments table with quite the right information, so you iterate a few times with the agent until it works precisely.

Everything is working as you want it to. You run automated security checks against your tool.

You submit your tool for approval. You describe what it does, who needs access to it, and which matters you need to use it with.

The IT team receives your request and reviews it. They review the tool’s code, the infrastructure components you need access to, the networking permissions it requires, etc. When they approve your tool, a member of the IT team is assigned to be its owner.

After IT approval, your tool is automatically deployed to an isolated container within your firm’s whitelist-restricted subnet. This means it can only communicate with IP addresses explicitly approved by the IT team.

The IT team has allocated a degradation budget of 5 failures for your tool. This means if it fails more than 3 times, it’s automatically taken offline. If the tool ever encounters any kind of issue, a task is automatically assigned to the tool’s owner within the IT team.

Now that your tool is live, the practice innovation team has dashboards to monitor its usage. If it’s popular, they know it’s worth continuing to support and to promote within the firm. If no one uses it, they might choose to discontinue support for the tool.

Over the coming months, your tool becomes very popular amongst associates in the Private Funds team. To reward you and incentivize others to build innovative tools, your firm gives you a bonus.

Legal AI providers aren’t ambitious enough

Consider how this problem would be solved under the current model, where law firms pay legal AI providers small fortunes to build workflows for them.

After you discover the problem, you ask your practice innovation team if you have access to a product to solve it. You don’t, so your practice innovation team makes a feature request to your legal AI provider.

If your legal AI provider decides it’s worth their time, they will add it to their next quarter’s roadmap when one of their employees will vibe-code a solution instead of you. When they eventually deploy the tool (which you didn’t get to test during the development process), the matter you needed the tool for is long over.

Meanwhile your IT team has limited visibility into the development process. They don’t control which teams have access to the tool. They don’t control the network configurations of the container that it runs in. The analytics that the AI provider provides grants them limited, if any, visibility into the tool’s usage within the firm.

Skeptics of AI-coding are concerned that lawyers building their own tools would be insecure. But which of the two development models sounds more secure? The one that gives law firms more control over their tooling, network, and infrastructure or less?

Software development is the new literacy

Prior to the invention of the printing press, literacy was a skill practiced only by specialists and elites. Once the printing press made the written word abundant, literacy eventually became universal.

Prior to the invention of personal computers, typing was delegated to secretaries, who usually had gone to typing school. As computers began to mediate professional work and emails demanded real-time responses, professionals needed to learn to type for themselves.

Prior to the invention of LLMs, software development was practiced only by coders with years of academic training and professional experience. AI coding tools are shattering that constraint.

When technological breakthroughs expand people’s capabilities dramatically, the skills that define professional competence shift. Given how dramatically AI has transformed software development over the past 10 months, I anticipate professional software engineers like myself will no longer be gatekeepers to the development of software in the future.

Instead, individual employees of all types of firms, including law firms, will be empowered to build their own solution when they come across a problem.

This change is already underway. More and more lawyers are building their own tools with AI. I’m a member of a group chat of these lawyers who call themselves “legal quants”, started by Jamie Tso. Every day, the ~50 lawyers in the chat post hundreds of messages sharing the tools they’ve built, the techniques they use to build them, and which open-source libraries are best for legal workflows. These lawyers are true hackers, in the Grahamian sense of the word.

These Legal Quants are paving the frontier of legal tech. One that frees lawyers from being trapped by inadequate tooling. One that empowers them to solve their own problems with agency, and no longer feel beholden to legal tech vendors that don’t understand them. The future of legal tech won’t be built by those vendors. The future of legal tech will be built by lawyers.

As the founder of a five-year-old legal tech startup with a product trusted by lawyers across the industry, I’ve developed this belief:

Venture capital-backed AI startups don’t build differentiated products because it’s not part of their strategy.

Subscribe now

Venture capitalists and lawyers have conflicting incentives

Venture capitalists (VCs) make money by placing high-risk bets across many startups, expecting that one or two will reach $10B+ valuations. Those winners “return the fund,” covering all the losses from failed investments while generating substantial profits.

The VC business model has capped downside and uncapped upside. At worst, a fund runs out of money, but an early bet on the next Google could return tens or hundreds of billions.

Law firms, on the other hand, have capped upside and uncapped downside. A law firm could close a $50B merger and their total compensation tops out at a negotiated fee. Their downside risk, on the other hand, is unlimited. Sending out the wrong version of a contract for signatures can expose their client to tens or hundreds of millions of dollars of liability. Lawyers are in the business of reducing risk, not taking it.

Additionally, VCs have a short-term incentive to demonstrate quick portfolio gains to their own investors, the limited partners who invest in VC funds. If a VC invests in a startup at a $20M valuation, they want that startup to raise again in 18 months at an $80M valuation so they can use that 4x markup to raise their next fund.

VCs didn’t like legal tech until LLMs

These mismatched incentives have historically made legal tech a bad fit for venture capital. Due to their risk profile, lawyers need to have complete confidence in a product before they adopt it. The product must work reliably, handling every idiosyncratic Microsoft Word formatting requirement across 1000+ page documents, maintain perfect information security practices, and have social proof from other big-name law firms.

Attempts by legal tech companies to play the VC game have historically ended poorly. As a consequence, legal tech developed a negative reputation amongst VCs. When my startup Version Story went through Y Combinator in 2021, a prominent VC advised the legal tech companies in our batch to pivot to a different industry.

The AI gold rush introduced the “Distribution > Product” game to legal tech

This changed when ChatGPT hit the world in fall of 2022. Despite its limited utility at the time, the conventional wisdom among VCs was that AI would automate the practice of law. It was a matter of time before LLMs would do work once done by lawyers. One VC told me, “If you aren’t pitching a plan to automate lawyers, you’re not an AI company.”

But in the early days of ChatGPT, LLMs weren’t yet useful to lawyers. They weren’t smart enough, they hallucinated too much, and the context windows were too small for legal documents. VCs observed the models were rapidly improving, however, and their Twitter feeds offered frequent reminders artificial general intelligence was on the way. GPT-4 couldn’t automate legal reasoning, but GPT-7 might.

An idea emerged that finally made the legal market palatable to VCs. Whichever startup captured the most market share by the time AI became capable of replacing lawyers would usher in the legal AI revolution — transforming a $1T legal services industry and defining how law is practiced with AI at the helm.

And with that idea, a new set of startups entered the scene seeking to capitalize on a once-in-a-generation opportunity.

How to scale distribution with an undifferentiated product

The conventional wisdom in the startup world is to build a great product and let distribution follow naturally. YCombinator’s motto is “Build Something People Want” and their entire startup curriculum is oriented around that idea.

But becoming the industry leader before AI is capable of high-quality legal reasoning requires capturing distribution before the product is useful. A friend of mine who founded a legal AI startup works from the office of his startup’s VC backer. Written atop the whiteboard on their wall are the words “Distribution > Product”.

Here’s how to capture distribution without a differentiated product:

Step 1) Sell fear, not solutions

Legal AI startups want lawyers to fear AI. They want them to believe that the AI revolution threatens their livelihood. Some of their marketing strategies are oriented around it. A video on the homepage of a leading AI company begins with the line:

“Being up to date is not that difficult. But becoming obsolete is really easy.”

Recall that lawyers are incentivized to eliminate risk. If they believe there’s a chance AI could disrupt the legal industry, that’s a risk to be managed. From the law firm’s perspective, a legal AI subscription is a strategy to minimize risk. If an AI revolution is coming, the firms best equipped to manage the transition will be the ones that have already integrated with the leading legal AI provider.

Step 2) Charge exorbitant prices

Because the AI companies sell insurance for disruption, they command far higher prices than traditional legal tech products. This creates a high top-line revenue figure to show VCs, allowing them to raise more money and further cement their position as the industry leader. As their status grows, they win more customers, increase their pricing power and ability to raise more money.

Why would a firm pay high prices for a leading legal AI provider when many other startups provide similar offerings at lower prices? Because the leading AI provider mitigates the most risk.1 This could be a pragmatic strategy from the law-firm’s perspective. If AI disrupts the legal industry, subscribing to the industry-standard legal AI vendor guarantees that you will be in the same boat as your competitors. Law firms don’t know which of the other boats will sink and which will pull ahead, and law firms aren’t in the business of making bets.

Step 3) Bet on OpenAI improving their models

Legal AI startups do not build AI. Research labs like OpenAI, Anthropic, Google DeepMind build AI. These labs pioneer AI research and release large language models (LLMs) for consumers to use via chatbots and companies to integrate with via APIs. Legal AI startups build products on top of these models.2

The products that legal AI startups build on top of the models are of secondary importance for many of their strategies. In the initial phase of the AI era, many of these companies found they could showcase the foundation model’s improvements, and thereby foster the impression that they were innovating.

Will “distribution > product” work in legal? Probably not for much longer.

If recent discussions in r/legaltech are a bellwether, however, this strategy might be near the end of its life.

When asked what their product can do that ChatGPT can’t in a recent AMA, a legal AI founder replied that their product could:

Extract data from +10.000s documents

Create workflows that redline contracts according to firm-specific playbooks

Draft contracts while keeping formatting in Word

Leverage precedent and internal knowledge basis as context

etc.

Later that same week, a lawyer used AI to create his own Word add-in. Another used Gemini studio to vibe-code a tool for bulk document analysis. “Workflows” built on top of AI offer less of a technological moat when a lawyer without an engineering background can use AI-coding tools to build them in an evening. As communities like this grow, more lawyers and law firms will discover they can access the power of AI models directly and cut out the middlemen, thereby saving considerable amounts of money.

If these trends continue, we will likely see a different type of strategy win in legal tech. To differentiate themselves in the age of AI, products must solve hard technical problems that can’t be vibe-coded. Building great products that lawyers love on a strong technical foundation seems like a more durable strategy.

This is why we’ve spent years at Version Story building critical document processing infrastructure to solve legal version control. It’s why we manually worked through thousands of edge cases to ensure that our document comparison and merge technology works across every possible permutation of Microsoft Word formatting options. And it’s why we’re excited for a future where AI puts more power in lawyers’ hands while the companies they partner with deliver value that AI alone can’t.

Sign up for Version Story

Why is it easier for tech people to build machines that emulate human intelligence than it is for them to build software for lawyers that delivers value? As a software engineer who has spent the past five years working in legal tech, I have observed several patterns in products that miss the mark and in my own thinking that I believe explain the disconnect between lawyers and legal tech vendors.

My conclusion is that coders misunderstand legal workflows and that their misunderstanding is upstream of many mistakes in legal tech.

Of all the mistakes this misunderstanding produces, one stands above the rest—the desire to replace Microsoft Word.

Microsoft Word can never be replaced. OpenAI could build superintelligence surpassing human cognition in every conceivable dimension, rendering all human labor obsolete, and Microsoft Word will survive. Future contracts defining the land rights to distant galaxies will undoubtedly be drafted in Microsoft Word.

Microsoft Word is immortal.

Why?

Legal systems around the world run on it. Microsoft Word is the only word processor on the market that meets lawyer’s technical requirements. Furthermore, its file format, docx, is the network protocol that underpins all legal agreements in society. Replacing Microsoft Word is untenable and attempts to do so deeply misunderstand the role that it plays in lawyers’ workflows.

The origin of this misunderstanding can be traced to a common myth shared by coders — “The Fall of Legal Tech.”

Subscribe now

Legal tech’s original sin

Throughout history, ancient cultures across the world developed myths about the creation and fall of mankind that mirror one another. So too do coders, drawing from the collective unconscious of the coder hive-mind, invent the myth of “The Fall of Legal Tech”. They mistakenly conclude that Microsoft Word is legal tech’s original sin and only its replacement will lead lawyers to salvation.

They have a variety of ideas of what form its successor will take. Some imagine it’s Google Docs. Others believe it will be their product’s proprietary rich text editor. The coders most committed to the ideals of technical elegance, however, propose that Markdown, a computer language for encoding formatted text, shall take its place.

Markdown is ubiquitous amongst coders. It allows them to encode document formatting in “plaintext”. Special characters encode its text so that applications can render it with visual formatting. For example, to indicate that text should be italicized, Markdown wraps it in asterisks. E.g. *This text will be italic* -> this text will be italic.

Below is an example of a simple Markdown document with its written form on the left and its rendered form on the right.

Why do coders want lawyers to use Markdown instead of Microsoft Word? Because Markdown is compatible with git, the version control system that structures their workflow. If lawyers could use git-like version control, so many problems in the legal workflow could be solved. It’s why we’ve spent years building such a system for lawyers. Let’s get into why Markdown is not legal tech’s savior.

Sign up for Version Story

Formatting

Markdown doesn’t work because of formatting. “But Markdown supports formatting!” the coder cries. That is, in fact, its whole point — the raison d’etre of Markdown is to encode formatting in text. Isn’t that enough?

Well yes, Markdown supports certain formatting. It supports bold, italics, numbered lists, ordered lists, headings, tables, etc. But what happens when a lawyer wants to style their headings in “small caps”, as my lawyer cofounder Kevin insists? Okay, perhaps we can add that formatting option to Markdown as well. But what happens when a law firm needs their documents to use multi-level decimal clause numbering like in the below screenshot?

Or how about when we need to specify the precise width of a column in a table that differs from the width of the other columns or split a particular cell to contain additional rows that other cells don’t?

Sure, we could theoretically encode that rule too and all other formatting rules until we’ve accounted for all of the formatting possibilities that lawyers actively use. By that point, however, we will have effectively recreated Microsoft Word but in a format that is significantly more challenging to use.

“But style doesn’t matter!”

Surely, many coders who have read up until this point are thinking the following objection: why do lawyers need all of those extra formatting options? The styling properties of lists don’t matter – all that matters is the information they convey.

Herein lies a cultural difference between the fields of coding and lawyering. For coders, visual aesthetics don’t matter. For lawyers, they are a technical requirement. While this difference may seem arbitrary on the surface, it is downstream of a critical technical difference between the two fields. Machines interpret the work of coders. Human institutions interpret the work of lawyers.

Concretely, visual presentation doesn’t matter for code beyond basic legibility because a machine ultimately executes the code. Courts interpret legal contracts, by contrast, and courts often have specific formatting guidelines that Markdown and other non-Word alternatives do not satisfy.

For example: federal appellate courts require all “briefs, appendices, and other papers” to adhere to the following formatting conventions:

• 14-point proportional typeface is mandatory, and Markdown cannot specify font size or font family.

• Double-spacing for all text, with narrow exceptions for block quotes and headings. Markdown has no concept of line-spacing rules.

• Precise margin requirements (at least one-inch on all sides) and 8.5×11-inch page size, which Markdown cannot express.

• Roman-numeral and Arabic page-numbering schemes, footers, and separate formatting for cover pages, none of which Markdown can natively encode.

Additionally, a well-formatted document is a symbol of a lawyer’s professionalism. Courts aren’t the only readers of legal documents. Clients, counterparties, colleagues, all read a lawyer’s documents as well. The style of their work product reflects the lawyer’s professionalism — the medium is the message.

Docx is a protocol, not a filetype

Beyond styling considerations, another structural consideration of the legal workflow prevents Microsoft Word’s defenestration — the legal system is decentralized.

If a coder wants to adopt a new file format for their internal documentation or new programming language, they can rewrite the relevant parts of their codebase. They are able to do so by virtue of having autonomy over the system they operate. While this becomes more complex in an engineering organization, the principle remains that the organization has the necessary autonomy to change its systems.

In the legal world, a lawyer cannot simply choose to adopt a new file format. This is because all existing legal precedent is in the old format. Docx encodes virtually every outstanding legal commitment for every person and corporation in our society. A lawyer could choose to adopt a new file format, but the system will break when they need to redline it against precedent.

Additionally, every colleague, counterparty, outside-counsel, and client a lawyer ever works with uses docx. To introduce a new format into this ecosystem would introduce friction into every single interaction. If a lawyer sends a contract in Markdown, the counterparty cannot redline it. If they send a link to a proprietary cloud editor, the client cannot file it in their internal document management system. In the legal industry, asking a client to learn a new tool to accommodate your workflow is a non-starter.

An appropriate technical analogy for docx is a network protocol. A coder cannot just decide to stop serving their web application over HTTP. Doing so would disconnect their application from the web and render it useless. The same goes for lawyers vis-a-vis docx. Docx is a protocol for defining legal commitments across a decentralized network of legal entities. Opting out of that system is not viable if the lawyer wants to stay in business.

This dynamic explains why legal tech products fail when they force lawyers to use a document editor outside of Microsoft Word. They attempt to introduce a walled-garden platform in an industry that runs on an open protocol. When a tech product requires both sides of a transaction to be on the same platform to collaborate effectively, it breaks the protocol. Until a startup can convince the entire global legal market to switch software simultaneously, .docx remains the only viable packet for transferring legal data.

How to innovate in legal tech

Accepting Microsoft Word’s primacy in the legal workflow is not technological defeatism. Progress shall continue! But impactful innovation in legal tech requires contending with Microsoft Word. Moreover, it requires cultivating a deep understanding of the practice of law beyond a surface-level recognition of the similarities between coders and lawyers.

At Version Story, this understanding originates from our lawyer/coder CEO, Kevin O’Connell. His experience in both fields has given us a unique vantage point in the industry, allowing us to understand the legal workflow as it exists while imagining what it can become. That vantage point has been critical in building a version control and redlining product that lawyers love.

Sign up for Version Story

If more coders and technologists learn the way lawyers actually work, we can expect a future with innovative legal technology that truly adds value. Not revolutions, not ChatGPT wrappers promising to remove lawyering from the practice of law, but meaningful step-changes that help lawyers to spend more time exercising legal judgment and less time wrangling documents.

Legal tech never fell. It doesn’t need full-stop salvation. It needs good products built by people who understand lawyers.

Last year, I attended a friend's wedding in my home state of Michigan. At the wedding, I spoke with an engineer named John who worked for an auto parts manufacturer. As we made small talk and discussed our work, I described how I was building a git-like version control system for documents.

This caught his attention. John leaned in and told me about a disaster that had just cost his company millions.

His firm had landed a contract with one of the big-three Detroit auto companies to design an engine part. After the initial prototypes, the client requested modifications. Simple enough — John and a colleague split the work. Both downloaded the latest CAD file from their cloud system and got to work on their respective changes.

When they finished, each uploaded their version. A few minor revisions later, the part went into production. Ten thousand units rolled off the line and shipped out.

Then the client called. Where were the modifications they'd requested?

John was baffled. He knew he'd implemented those changes. He could remember doing it. But when they investigated, the truth emerged: his colleague had saved his version after John, unknowingly erasing every change John had made. Neither engineer had any idea until those 10,000 incorrect parts were already in customers' hands.

The production line had to run again. Millions of dollars, gone—all because their version control system couldn't handle two people working on the same file.

When I published my essay “On Building Git for Lawyers” last fall, several people pushed back. "Don't document management systems and SharePoint already have version control? Aren't you building something that already exists?"

(Another common question—"Why don't lawyers just use Google Docs?"—deserves its own discussion, which I covered in my previous essay.)

John's multi-million dollar disaster illustrates why these systems are inadequate. They use linear version control — a paradigm software developers abandoned in 1986. The modern standard, Git, uses concurrent version control instead. And that changes everything.

Here's how we fix it — and why the transformation is inevitable.

Subscribe now

Alice and Bob collaborate

Standard Linear Version Control

Alice and Bob are roommates who share a digital grocery list. Their system creates a new version every time someone saves—V1 becomes V2, V2 becomes V3, forming a straight line. This is linear version control.

They both check the list:

Alice opens V1 and adds butter and eggs.

At the same time, Bob has V1 open and adds apples.

Alice saves first—creating V2 with her butter and eggs. Bob saves next—creating V3 with his apples.

The problem: V3 doesn't have Alice's butter and eggs. Bob's save completely overwrote her changes. She added butter to the list, but it vanished when Bob saved his version.

This is a race condition—the same type of problem that cost John's engineering firm millions. Two people editing one file, and changes disappearing without anyone realizing.

Fortunately, there are ways to prevent this. The solution is called a "concurrency mechanism," and there are two approaches: pessimistic (taking turns) and optimistic (working simultaneously). Let me show you how each one works.

Locking Linear Version Control

The first version control systems solved this with a straightforward approach: only one person could edit at a time.

Bell Labs introduced this in 1972 with SCCS (Source Code Control System). The concept is like checking out a library book — while you have it, no one else can modify it.

Here's how Alice and Bob's grocery list would work:

• Alice checks out V1 to add her items

• Bob tries to edit but sees it's checked out — he must wait

• Alice adds butter, removes bread, and checks in V2

• Bob can now check out V2, add apples, and check in V3

V3 contains all the changes from both collaborators. The race condition is prevented.

The downside is clear: Bob had to wait for Alice to finish. In professional settings with urgent deadlines, this bottleneck becomes a serious limitation.

Concurrent Version Control

But what if Alice and Bob need to make changes simultaneously? This is where concurrent version control comes in.

Software engineers developed several systems over the years—RCS in 1982, CVS in 1986, Subversion in 2000, and finally Git in 2005. These systems assume most edits won't conflict and let everyone work at once.

Here's how it works with Git:

• Alice checks out V1

• Bob also checks out V1

• Alice adds her items and checks in V2

• Bob adds his items, but before creating V3, Git requires him to "merge" Alice's changes from V2 into Bob's working copy

• When Bob checks in V3, it contains both sets of changes

No waiting. No lost work. Both collaborators can work simultaneously, and the system handles the coordination.

Legal Version Control

Now let us return to the objections that people raised to my previous essay.

What are the options that lawyers currently have at their disposal?

Option 1 — Standard linear version control

Most document storage systems use standard linear version control. As we've seen, this creates a fundamental problem: race conditions.

When two lawyers download the same contract, make different edits, and save their versions back to the system, whoever saves last erases the other's work. There's no warning, no conflict detection—changes simply vanish.

This creates constant uncertainty. Did your colleague's save overwrite your redlines? Is the "final" version in the document management system actually missing critical edits? When millions of dollars depend on contract language, this ambiguity is more than an inconvenience—it's a liability.

Option 2 — Locking linear version control

Some systems like SharePoint address the race condition problem by adding locks. Users "check out" documents for editing, and colleagues must wait until they're "checked in" before making changes.

But locking creates its own problem: bottlenecks. When it's 11pm and a deal needs to close by morning, you can't wait for someone to finish their changes before starting yours. The legal profession operates on parallel timelines—multiple specialists often need to review the same document simultaneously.

So what actually happens? Lawyers have developed an elaborate workaround.

One person checks out the document from the system, then emails copies to all the specialists who need to review it. Each specialist marks up their copy independently. Then comes the painful part: someone (usually a junior associate) sits with multiple redlined versions open, manually copying changes from each document into a master version. Only after this manual merge process does the document get checked back in.

This isn't efficient collaboration. It's a workaround for a broken system.

Don’t pave the cow path

Legend has it that in the early days of Boston’s urban development, city planners noticed the paths that cows created from walking over them repeatedly and paved them. Rather than designing a logical street grid, they created the notoriously convoluted set of roads that now make up Boston’s historic districts.

The legal profession has been forced down a similar path. Without tools that support simultaneous editing, firms have had to develop creative solutions: detailed naming conventions to track versions, careful coordination protocols, and the manual merge process I described above. These practices have become so standard that it's easy to forget they exist solely to work around technological limitations.

But these shouldn't be permanent features of legal practice. They're detours around a problem that concurrent version control solves entirely.

Option 3 — Concurrent Version Control

Concurrent version control allows lawyers to make changes at the same time without fear of overwriting each other’s changes.

Multiple lawyers can work on the same document simultaneously without overwrites or bottlenecks.

Here's how it works:

• Each lawyer edits their own copy of the document independently

• When ready, they merge their changes back into the main version

  

• The system automatically combines non-conflicting edits

• For conflicting changes (when two people edit the same paragraph), the system flags the conflict and lets a lawyer decide which version to keep

• Every edit is tracked—you can see exactly who changed what and when.

No more manual merging. No more waiting for check-ins. No more anxiety about lost changes.

This is the system software developers have used for decades. The time has come for lawyers to enjoy the same benefits.

The Future of Legal Version Control

When software engineering adopted concurrent version control, it didn't just change how developers saved files—it transformed the entire profession.

Git and similar systems eliminated bottlenecks and enabled truly parallel workflows. Developers could work on separate features without blocking each other or fearing overwrites. This technological shift reshaped how software teams organized themselves. Small, autonomous teams could tackle different parts of complex systems simultaneously. New methodologies like Agile and DevOps emerged, built on the foundation of rapid iteration and parallel development. The tools didn't just support the work—they fundamentally changed how the work got done.

Law faces a similar transformation.

First, the immediate benefits: no more elaborate workarounds. No more arcane naming conventions like "Contract_v3_FINAL_JB_edits_CLEAN.docx". No more policies about who can check out documents when. The system handles the complexity, letting lawyers focus on the law.

But the deeper changes will reshape legal practice itself. When teams can truly collaborate in parallel, new workflows become possible. Perhaps we'll see legal methodologies that mirror Agile—rapid iterations on contract language, parallel specialist reviews that merge seamlessly, faster deal velocity without sacrificing quality.

And concurrent version control opens doors for AI workflows that linear systems can't support—but that's a topic for another essay.

The tools are changing. The profession will follow.

Sign up for Version Story

In the essay, I explored the problems that arise when lawyers collaborate on the same document. In the below example from the essay, you can see a screen recording of an actual lawyer copying-and-pasting changes from their colleague’s draft into a shared draft.

Overwhelmingly, the response to my essay was positive! Many people across industries empathized with the problems we’re solving. One response stood out, however. Can’t lawyers just use Google Docs?

If you’ve read the title of this essay, you already know my response.

Google Docs does not work for lawyers.

The inefficiencies of legal collaboration are not a consequence of lawyers being unwilling to adopt the best technology — it is because the needs of their workflow require a fundamentally different technology solution. In this essay, I’ll explain why Google Docs fails to meet the needs of lawyers due to its all-or-nothing adoption model, lack of commit atomicity, and inadequate knowledge management capabilities.

Your job, as a lawyer

Imagine that you’re a lawyer working on an M&A deal at a law firm. Your firm represents the seller in the deal, and the buyer and their counsel (“counterparty”) just emailed you a new version of the terms of sale (a stock purchase agreement) with important changes.

These changes represent the counterparty’s move in a negotiation — seeking terms favorable to the buyer, often at your client’s expense. To do your job well, you need to review every proposed change, advising your client on whether to accept, reject, or modify the terms.

First, you read the counterparty’s changes and assess their potential impact. Which of the modified terms are materially important to your client, and which are low-stakes? Are the terms they’re proposing acceptable to your client’s stated priorities? Are there any legal risks in the new language?

You then advise your client on how to respond, proposing a plan for the next draft: your client signs off.

Next, your firm drafts a response to the counterparty according to the plan that you and your client agreed to. If the changes require input from specialists like tax or intellectual property experts, multiple colleagues will contribute to this response in their own versions of the document. This process looks something like this:

Upon receiving all changes made by specialists, you manually merge them into a single, consolidated new draft (as illustrated in the gif in this essay’s intro). You send this to your team for review before sending it to the counterparty.

Along the way, you, your team, and the client create many versions of the document. After the counterparty emailed you their latest changes, you saved a copy of it and added comments to share with your client. Your client downloaded that copy, responded to your comments, and sent it back to you. You sent this version to your colleagues who each sent you back a different version with each of their changes. You merge all of these into a new version, which is reviewed, commented on, and amended — creating more versions at each step of the way. Finally, you send your response to the counterparty on the final draft.

When they respond, the process starts all over again.

With this process in mind, let’s consider how Google Docs would fit into the picture.

All-or-nothing adoption

Google Docs only works when everyone uses it. If one person on the team makes their changes in Microsoft Word instead, the system breaks: there is no way to incorporate those changes without manually copying and pasting them in.

This constraint makes Google Docs unusable for legal collaboration. A law firm would never work directly with a counterparty on a shared Google Doc. Beyond the logistical headache of too many collaborators holding the pen, the drafting process exposes the strategy that both firms undertake. Their documents contain comments by lawyers and the client discussing the client’s priorities, what they’re willing to concede on, what they’re not willing to concede on, etc. Confidentiality in the drafting process is paramount.

Even within a single firm, getting all lawyers to adopt Google Docs instead of Microsoft Word is untenable. Most lawyers strongly prefer Word for a variety of reasons, including,

• Formatting options that Google Docs does not support (My cofounder, Kevin, a lawyer, refuses to put a contract in Google Docs if for no other reason than its lack of support for the “small caps” feature).

• A suite of custom Word Add-Ins that their workflows depend on.

• More granular options for defining clause numbering conventions.

Finally, many lawyers do not want to share their drafts until they’re polished. They don’t want their colleagues or clients to see the sausage getting made. Lawyers need the freedom to work through multiple iterations. They will try writing certain language in one provision, then take a step back to review how it fits in with the agreement as a whole, spot an issue, and zoom back in to make further changes. Throughout this process they don’t want senior partners breathing down their neck and prematurely critiquing half-formed thoughts.

Despite these reasons, let’s suppose all lawyers adopted Google Docs. Even then, it would fail to meet the needs of legal collaboration. This is due to a fundamental flaw with the Google Docs collaboration model.

Commit Atomicity

“Commit atomicity” is the principle that changes should be applied all at once or not at all. It’s a term that’s most commonly used by coders, but applies to any project with multiple collaborators.

Imagine I’m building a feature for Version Story that allows users to add tags to their documents. To deliver this feature, I have to change the user interface, the backend logic, and the database. For the tagging feature to work and to make sure I don’t break other features, I have to apply these changes all together. Furthermore, when my colleagues review these changes, I want them to be reviewed together as a cohesive set. They should also be reviewed separately from any changes my colleagues may have made to the same code, at the same time.

Thankfully, I can use Git to collaborate with my colleagues! I can put all of my changes in a single commit to be reviewed as a pull request. If my colleagues made changes to the codebase since I started working on mine, Git will guide me through merging them with mine.

Like coders, lawyers need to package their changes in cohesive sets.

Consider an example. The original draft has a provision that the agreement will end after one year. A lawyer modifies this provision to instead renew automatically at the end of each year. He adds another provision that either party can stop the automatic renewal by giving notice thirty days before the end of the year. If his colleague accepted the first change without reviewing the second, they would end up with an agreement that renews indefinitely with no way to stop it.

Furthermore, each set of approvals needs to be pinned to particular versions of the contract. If the tax specialist “signs off” on the contract after the M&A associate integrated the tax specialist’s changes to the main document, their approval only applies to that version of the document. If some of the tax specialist’s work is overwritten by subsequent changes made by other colleagues, their approval will not apply to the newer version of the contract. Pinning approval to particular versions mitigates risk for the collaborators reviewing the document.1

Despite its inefficiencies, the current redlining process embodies commit atomicity. The redline is the atomic statement of the lawyer’s changes. Redlines are reviewed independently from other redlines. When lawyers approve a redline, they know they’re only approving that redline and not future changes introduced by other lawyers.

Google Docs does not support atomic changes. By design, all collaborators hold the pen at the same time. While this makes it simple for people to make simultaneous edits to a document, it is not well-suited for legal drafting where atomicity is essential.

Knowledge Management

Lastly, Google Docs doesn’t preserve a comprehensive record of its history. While it offers a “version history” feature which shows a stream of all changes made at various time intervals, it’s challenging to understand what each of those changes represents (again underscoring the need for atomic commits).

Beyond the challenges of understanding what changed, it’s even more challenging to understand why those changes occurred in the first place.

Comments are essential in the legal workflow. They are how lawyers deliver feedback on changes proposed to documents. While Google Docs allows users to leave comments, its lack of commit atomicity means that comments aren’t associated with any particular version of a document. Once comments are resolved, you can view a history of them, but they won’t be associated with the changes they produced in the document.

This is not acceptable for lawyers who need to maintain a full record of what changed and why. If a partner on a deal asks a junior associate why a material term was changed, the junior associate needs to be able to reference the version and comment history to answer that question. Google Docs would not allow them to do so.

Conclusion

Google Docs is a great product for many types of collaborative writing and was a major milestone in the history of document collaboration. But for lawyers, the need for atomic changes and comprehensive record-keeping makes Google Docs unsuitable.

The system that truly solves the inefficiencies faced by lawyers will:

• Avoid all-or-nothing adoption by supporting partial participation.

• Enable users to make and review changes atomically.

• Preserve a complete history of how and why a document evolved over time.

At Version Story, we’re building that system. If you’d like to try it, click here and register for a free trial.

Sign up for a Version Story free trial!

This is an important question. The legal system is the essential bedrock upon which all else in society is built. The protection of civil rights, peaceful conflict resolution, access to due process, enforceable contracts — all these depend on a well functioning legal system.

The professionals who operate this system are equipped with inadequate tooling. Absent git-like version control, they rely on inefficient and error-prone manual “version control” processing.

In many cases, manual version control processes (e.g. git diff, merge, and rebase but by hand) take more than an hour of lawyer time per contract version while resulting in errors!

Note: this problem is not specific to the law. Finance professionals, academic researchers, legislators, among many other professionals, encounter similar version control issues. We are currently focused on law because of our domain expertise and because the problem is particularly pronounced in the law.

How do lawyers currently work?

As many have observed, lawyers face the same fundamental set of problems that coders do when collaborating. They have multiple collaborators contributing changes to a project concurrently. They need to receive approval from their colleagues prior to committing their changes. When a colleague commits new changes, they must update their current work to account for them.

Absent a concurrent version control system like git, lawyers rely on a process called "redlining" to solve these problems. A "redline" is the equivalent of a diff in git. It is a document showing the insertions and deletions between two versions of a document.

Redlining in practice

Unlike git, redlining leaves many of these problems unsolved. The following is an example of the basic steps of redlining a stock purchase agreement in the big-law context. Different practices of law might have different variations of the following process, but most follow similar general principles. 

In this example, our law firm represents the buyer in an M&A deal. The seller’s counsel just sent the first draft of an agreement, V1. To turn the second draft of the agreement, V2, the firm needs input from specialists on the tax team, the IP team, and the employment team.

1. Kicking off this process, an M&A partner instructs a junior associate lawyer to circulate V1 to the three specialist teams to receive their redlines. Upon receiving these redlines, the M&A associate should reconcile the changes and submit those changes as the new version on their document management system.
   

2. M&A lawyer emails specialist teams asking for their contributions to the agreement.
   

3. The specialist teams each modify V1 of the agreement with their respective changes. They send the modified documents to the M&A lawyer.
   
   Note: I’m simplifying the process a bit. The specialist’s team undergoes its own redlining process between the partner and associates on the team before returning a draft to M&A.
   

4. M&A lawyer redlines the specialist version to the original via a redlining product. Associate saves that redline to their local file system as well as the "clean" version that was sent by the specialist.

   

5. M&A lawyer manually merges the three specialists’ drafts. They do this by opening a copy of V1 of the contract in Microsoft Word on the left side of their screen. On the right side of their screen, they open one of the specialist’s redlines. Change-by-change, they modify the new document to reflect the changes in the redline. Upon adding all of the changes, the associate opens the next specialist redline and repeats the process. They continue this until all changes are integrated into the new document. This document is V2 of the agreement.

Below is a screen recording of an actual lawyer merging specialist changes into an agreement. It took them over an hour to do what our system did in under a minute. This process resulted in three mistakes.

6. Associate redlines the consolidated V2 against V1, and sends V2 along with the redline to the M&A partner. They also save V2 to their document management system, which serves as the source of truth for committed versions of the contract. 

The above process has several issues — the most obvious of which is that it's tremendously inefficient. It can take an associate lawyer several hours to integrate changes of a 100+ page contract such as a stock purchase agreement. Equally important, however, is that it’s error prone. If two specialists introduce conflicting changes, there is no way for the specialist to know without manually reading the redlines side-by-side. It's a huge problem if an associate incorrectly reconciles a merge conflict,  especially if they overwrite the changes made by a more senior colleague since those changes could become permanent legal obligations worth millions of dollars.

Why don't lawyers use git?

As any coder knows, git is designed to solve exactly the sorts of problems that the lawyer is tasked with above. When I tell coders about Version Story, they often ask me, "why don't lawyers just use git?"

While git is an excellent tool for coding, there are two reasons why it will never see adoption amongst legal professionals.

1. Docx. Every lawyer uses Microsoft Word. They're trained with it early in their career and regularly take advantage of idiosyncratic formatting features. Every legal contract and precedent created in the past 25 years currently is in docx (or its predecessor doc). The information underpinning the entire US legal system (and every other legal system) is in docx. Docx is as much the standard for legal drafting as JavaScript is for client-side web programming.

   

   Git works with plain text files, not docx files. While it is technically possible for lawyers to draft in a git-compatible markdown language, the legal industry departing from the docx standard is about as likely as web browsers discontinuing support for JavaScript. It's not going to happen. (Note: you should be deeply skeptical of any startup that claims they intend to replace Microsoft Word or docx in a lawyer's workflow).
   

2. UI/UX. I started coding when I was 14, have a four year degree in computer science, and have worked professionally as a software engineer for over 7 years. It wasn't until I was several years into my career that I achieved mastery with git. It has a notoriously steep learning curve and is a complete non-starter for non-technical professionals.
   
   Lawyers have high standards. A simple and intuitive user interface is essential for gaining widespread adoption within the industry.

Why hasn't anyone done this yet?

Solving this problem requires both an understanding of git and its capabilities as well as the intricacies of the legal drafting and redlining process. The set of people capable of solving it is limited to those who have both worked professionally as lawyers and also are proficient coders.

My co-founder Kevin is such a person. Prior to founding Version Story, he worked both as an M&A lawyer at Simpson Thacher and as a software engineer at LinkedIn. I can confidently say I would not be able to build a product fit to the needs of lawyers without his first-hand experience guiding our design.

Over the years, several startups have attempted to solve this problem. None of them have had domain experience in the legal field. Because of that, they are unaware of the two constraints necessary to break into legal workflows — docx and UX. To sidestep the immense technical challenges of handling docx, they build in-browser text editors thinking they can get lawyers to draft in their application instead of in Microsoft Word. In their UX, they use terminology like “pull”, “push”, “rebase”,  and “HEAD” forgetting how inscrutable this terminology is to the uninitiated.

Any product that seeks to bring the functionality of git to a mass audience must handle docx and mustn’t be afraid to rethink the user experience from the ground up.

Our solution

Building a solution to this problem was hard. The technical problems of comparing and rendering docx files and the UX problem of making git-like functionality intuitive required a substantial amount of creativity, determination, and patience on both parts. Beyond that, establishing credibility in the legal industry such that top law firms could entrust us with their confidential documents presented its own set of challenges. Thankfully we had the benefit of ignorance prior to embarking on these schleps.

Technical problems

When we started Version Story, we intended to leverage third party APIs for our document processing while focusing our energy on solving the UX challenges of reimagining git. Docx has been the standard file format for word processing since 2007 — surely there should be reliable APIs for comparing them and converting them to html and pdf.

We were wrong and, believe me, we tried not to be. While APIs exist which purport to do what we need them to, they are nowhere near adequate for legal use cases. They would work fine in demos with simple test documents, but as soon as an actual lawyer attempted to compare a 500+ page prospectus with complex tables, custom formatting, and embedded images, they would fail. Not even Microsoft Word's internal compare tool is adequate for such cases. We had to build our own custom comparison engine.

Comparing plain text is a solved problem. Since 1986, Myers Diff has been the standard algorithm for text comparison. There are plenty of helpful online resources for learning the algorithm.

Comparing documents is not a solved problem. Docx is an open file format which implements the OpenXml specification of XML. Under the hood, a docx file is a zipped set of XML documents. OpenXML is similar enough to html to be legible to those who have written html but with far fewer SDKs for interfacing with it. If you imagine how you would represent things like formatting, tables, links, etc. with HTML, that's essentially how it's represented in OpenXML.

A document comparison system requires,

• Decomposing the document into well-designed data structures.

• Comparing text that can be arbitrarily nested in any set of different containers such as tables, text boxes, and shapes.

• Defining an edit script format that can express both textual changes and structural changes (modifying formatting, changing table dimensions, etc). 

• Using that edit script to rebuild the document while pulling in the correct formatting from both the original and modified documents.

Additionally, several elements of this system required novel algorithm designs. Unlike comparing plain text, there is no standard algorithm for comparing tables. How do we know which rows from the original document match with which rows of the modified? The same goes for columns. Furthermore, how can we determine if a row or column has been modified or if it's been wholly inserted or deleted? How do we know if we're even comparing the correct tables against each other in the first place?

Beyond the elegant world of theory and algorithms, we had to work through the long tail of edge cases. Docx is an enormous file standard with countless features you’ve never heard of. After building the initial version of our system, it took debugging hundreds of edge cases to get it to a point where it’s consistently reliable. Since the files we compare are generated outside of our system, it was impossible to anticipate all of the edge cases in advance. The only way to do so is to work through them when they arise in production.

Finally, supporting such a system presents some thorny system-level problems. Comparing a 1000+ page document (not uncommon in the legal industry) can require 30+ minutes of execution time and 20+ gb of memory. Building robust support for these documents while not causing timeouts in the various parts of the system awaiting the completion of these operations was challenging. In hindsight, however, this has been an advantage for us because documents like these crash incumbent redline products which can only run on Windows laptops.

The product

Replacing git’s technical language with a visual one was our critical unlock to making git-like version control accessible to non-coders. Intuitive visual actions allow users to perform the core operations of git without requiring them to memorize any confusing commands or vocabulary.

The following illustrates the stock purchase agreement process described above within the context of Version Story:

1. M&A lawyer adds V1 of the agreement to Version Story. The version is represented by a tile on the canvas.

2. M&A lawyer invites specialist colleagues to Version Story.

3. Specialist lawyers upload their changes. They generate a redline by drawing a line from V1 to their changes.

4. M&A lawyer merges these changes into a consolidated redline. They download a track changes version of this redline and resolve conflicts in Microsoft Word.

Our product does not yet comprehensively demonstrate the full functionality of git. We still have work to do to accomplish our full vision! What we’ve achieved, however, is a critical step in the direction of moving non-coders to a git-like version control system. We have validated our core hypothesis of representing git functionality with a visual canvas and now have lawyers performing git-like functions they never had access to before.

Does it work?

The following is a set of unsolicited comments from our users:

Why does this all matter?

Legal documents aren't just text on a page – they're the operating system of society. When lawyers draft and revise contracts, regulations, and legislation, they're writing the rules that govern how our world works. The stakes couldn't be higher:

• A missed change in a merger agreement could cost clients millions of dollars

• An overlooked revision in a regulatory filing could expose companies to legal liability

• Conflicting changes in contract terms could lead to years of litigation

• The inability to trace how legal language evolved can hamper future interpretation

In a 2022 article of Money Stuff titled “Brightline redline”, Matt Levine illustrates an example of these stakes, describing how Certares and Knighthead found themselves in litigation with Morgan Stanley and Brightline over a $25,000,000 credit agreement where the two sides couldn't even agree on which version was signed. "If there is a dispute about what the contract says," Levine explains, "you have to go back through the email chain to pick out which attachment everyone thought they were signing off on." The dispute centered on critical language about loan prepayments worth millions of dollars – language that one side claims was never agreed to.

The next generation of legal collaboration will not be plagued by issues like these. It will be faster, better, safer, and easier with a concurrent version control system like Version Story.

What comes next

We've kept our heads down the past four years relentlessly building a solution to this problem and credibility in the legal industry. We now have a differentiated product that users love and sell to top legal teams like those of Dentons, Addleshaw Goddard, Mishcon de Reya, Barings, and Pantera Capital.

Over the coming months, we will launch to the public. In the meantime if you’d like to try Version Story for yourself, feel free to email me and I’ll add you to our whitelist! jordan@versionstory.com