DEV Community: Igor Kan

The Legal Profession's Best-Kept Secret: Why Git Belongs in Every Law Firm

Igor Kan — Sat, 21 Mar 2026 05:25:54 +0000

You've sent it. Everyone has.

An email with a subject line that reads something like: "Merger Agreement — FINAL_v4_revised_JT_edits_ACTUALLYFINAL.docx"

And somewhere in that chain of files is a version that went to the client by mistake. Or a clause that got quietly removed and nobody noticed. Or a dispute — weeks later, in a meeting nobody wanted to be in — about who changed what and when.

This is not a technology problem. It's a documentation problem. And it has a solution that software engineers figured out decades ago. It's called Git, and it's quietly changing how governments write laws, how legal teams manage contracts, and how the most forward-thinking firms in the world handle document history.

This article is for anyone in the legal world — lawyers, paralegals, legal ops professionals, law students — who has never heard of Git, or has heard the name and assumed it wasn't for them. By the end, you'll understand exactly what it does, why it matters for legal work specifically, and how it's already being used at the level of national and municipal law.

Part One: What Is Git? (Without the Jargon)

Let's start from the very beginning.

Git is a system that tracks every change ever made to a document — who made it, when, and why.

That's the core of it. Everything else is detail.

Imagine you're drafting a contract. Every time you save a version, Git takes a snapshot. Not just of what the document looks like now, but of exactly what changed since the last snapshot — every word added, every word deleted, every clause rewritten. It stores all of this in a neat timeline, and it never throws any of it away.

Now imagine you have three colleagues also working on the same document. Git tracks all of their changes separately. It can show you a side-by-side comparison of any two versions. It can show you who changed a specific clause on a specific date. And if a change was a mistake, you can go back — not to "yesterday's version" saved somewhere in your email, but to any specific moment in the document's history, with one command.

Here are the key terms you'll see throughout this article, explained in plain English:

Git Glossary for Non-Developers

Repository (or "repo"): The project folder. Not just the files, but the entire history of every change ever made to them. Think of it as a filing cabinet that never forgets anything.

Commit: A saved snapshot. Each time you commit, you're saying: "I'm done with this set of changes. Lock them in." You also write a short message explaining what you did — like a mandatory comment next to a redline. Example commit message: "Removed arbitration clause per client instruction on 14 March call."

Branch: A parallel version of the document. You can create a branch to explore a different direction — say, draft the contract with a different indemnity structure — without touching the main version. If the branch works out, you merge it in. If it doesn't, you delete it. Nothing is lost, nothing is broken.

Merge: Combining two branches back into one. Git is smart enough to do this automatically in most cases — and in cases where two people changed the same clause differently, it flags the conflict and asks you to resolve it manually.

Diff: Short for "difference." A diff shows you exactly what changed between two versions, line by line. Added text in green, removed text in red. This is Git's version of tracked changes in Word — except it works across every file, every version, forever.

Pull Request (or PR): A formal proposal to merge one set of changes into another. In a legal context, think of it as a junior associate submitting a draft for a partner's review. The partner can see every change, leave comments on specific lines, request revisions, and approve or reject — all in one place.

git blame: A command (the name sounds harsh, but it's standard) that shows, for every line of a document, who wrote it and when. In a legal context, this is an audit trail at the line level.

GitHub / GitLab: Websites that host Git repositories and add a visual interface on top. Git itself is the system; GitHub is a popular place to use it with a web browser rather than a command line.

Part Two: The Problem Git Was Built to Solve — and Why Law Has the Same Problem

Git was invented in 2005 by Linus Torvalds, the creator of Linux, to manage something extraordinarily complex: millions of lines of code being edited simultaneously by thousands of developers around the world.

The legal profession faces a structurally identical problem.

Large contracts can run to hundreds of pages. Multiple parties redline the same document over weeks or months. Clauses are added, removed, reworded, restored. Different versions circulate between firms, clients, opposing counsel, and regulators — sometimes simultaneously. And at any moment, someone might need to answer the question: "What was in version seven? And who approved the change from version seven to version eight?"

Right now, most law firms answer that question by digging through email chains. Some use document management systems (DMS) like iManage or NetDocuments, which offer basic version tracking — better than email, but still a long way from what Git provides. The difference is intent and precision: a DMS tells you that a document was saved as a new version at 3pm on Tuesday. Git tells you exactly which words changed, which words were deleted, who made each change, and what note they left explaining why.

That distinction matters enormously in legal work, where the why behind a clause change can be as legally significant as the change itself.

Part Three: What Git Actually Looks Like in a Legal Context

Let's make this concrete with a scenario.

Scenario: The M&A Contract

A mid-sized law firm is handling a merger. The acquisition agreement is 180 pages. Three partners, two associates, and outside counsel for the other party are all making changes over six weeks.

Without Git, the workflow looks something like this: the document circulates by email. Each person saves a new copy with their name and a date in the filename. After two weeks, there are fourteen versions in a shared folder. Someone overwrites the wrong file. A clause added in version six mysteriously disappears in version nine. Nobody is sure when it happened or why. The client asks for a change history. The associate spends three hours reconstructing it from email timestamps and hoping they haven't missed anything.

With Git, every change is committed with a message. The history looks like this:

March 3  |  J. Thompson  |  "Added force majeure clause per client call 3/3"
March 5  |  S. Patel     |  "Revised indemnification cap — reduced to $2M per opposing counsel"
March 7  |  J. Thompson  |  "Removed arbitration clause — client preference, confirmed in writing"
March 10 |  R. Chen      |  "Added governing law clause — New York jurisdiction agreed"

Each of those entries is a permanent, timestamped, attributed record. Click any one of them and you see a precise diff — every word that was added or removed, shown side by side with what was there before. The entire six-week history of the document is reconstructable in seconds.

If someone asks: "When did the indemnification cap change, and who authorised it?" — the answer is one click away.

Scenario: The Contract Dispute

Two parties end up in litigation over the terms of a supply agreement. The dispute centres on whether a limitation of liability clause was present in the version that was agreed upon, or was added afterward.

A law firm using Git can produce a complete, timestamped audit trail: when the clause was added, by whom, with what commit message. It's the equivalent of a notarised log of every document event. This kind of traceability is increasingly valuable in disputes, and some courts are beginning to expect it.

As one legal technology expert put it: "In a real estate M&A dispute, a firm can avoid liability by producing a version history that shows exact approval timestamps. That audit trail is their first line of defence in court."

Scenario: The Policy Document

A large financial institution needs to update its internal compliance policy whenever regulation changes. The policy is 60 pages. Different departments own different sections. Currently, a new Word document is emailed around every quarter with tracked changes turned on — and then someone always accepts all changes before sending it on, losing the revision history.

With Git, each department works on their section in a branch. Changes are reviewed via pull requests before being merged. The compliance officer has a complete history of every policy change going back years — who changed what, when, and what note they left. When regulators audit, the firm can demonstrate exactly how policies evolved in response to specific regulatory changes.

Part Four: Governments Already Do This — And the Results Are Striking

Here is where the story becomes genuinely surprising.

Legal professionals often assume Git is a developer tool that would need to be "translated" for law. But some governments have already made that translation — and the results show both the enormous potential and the real limitations.

Washington D.C.: The City That Put Its Law on GitHub

In 2018, the District of Columbia did something unprecedented: it made GitHub the official, authoritative source for D.C.'s legal code.

A civic hacker named Joshua Tauberer found a typo in the District of Columbia's legal code and corrected it using GitHub, highlighting the groundbreaking way the District manages its legal code. The District publishes the law on GitHub as an authoritative source — it is where the DC Council stores the digital versions of enacted laws, and this source feeds directly into the Council's DC Code website.

The practical effects were immediate and meaningful. With the District's previous codification contractor, updates to the DC Code were published three times a year, with a five-to-seven month delay in seeing the latest laws. The Open Law Library has shortened the publication process to about a week after a law is enacted.

That is not a marginal improvement. It means citizens, lawyers, and courts are working with law that is weeks old instead of months old. The transparency gain is equally significant: anyone in the world can see exactly what changed in D.C.'s legal code, when, and in what version.

The U.S. Congress: The Comparative Print Project

At the federal level, the U.S. House of Representatives has been working on what it calls the Comparative Print Project — an effort to bring version control to federal legislation.

The U.S. Law Revision Counsel compiles the U.S. Code through careful analysis of new laws. Since 2011, the LRC has been using and publishing the results of this analysis in XML format, making it feasible to automatically match the "before" to the "after" text and produce a redlined version showing the changes in context.

The project addresses a problem that most people don't realise exists: for many laws, particularly those that were recently changed, there is no current official version and no way to see a precise history of amendments over time. In the Canadian House of Commons, a lack of version control led to embarrassing headlines when the Senate debated the wrong version of a government bill — for the second time in less than three months.

The goal of the Comparative Print Project is to create what Git provides automatically for every software project: a legally relevant diff — the ability to see exactly how a new bill changes existing law, before it passes.

New Zealand and the "Better Rules" Movement

Further afield, New Zealand has been a pioneer in what it calls the "Better Rules" approach — a methodology for drafting legislation that is machine-readable, unambiguous, and collaboratively developed by teams of policy experts, lawyers, and technologists.

The approach represents a fundamental shift in how governments draft rules, bringing multi-disciplinary teams together to look at what's proposed in a Bill or Amendment, virtually model and test the draft rules using real data and likely scenarios, to ensure the rules are implementable and more likely to achieve the intended outcome.

This is not just about Git specifically — it's about adopting the principles of version-controlled, collaboratively-drafted, machine-readable documents. The OECD selected this approach from over 500 public sector innovation case studies for its Global Trends Report.

The Honest Limitation: Git Wasn't Built for Law

It's worth being clear about something: Git is not a perfect fit for legal documents out of the box. It was built for code — plain text files that follow predictable structures. Legal documents, with their complex formatting, cross-references, page and line numbers, and jurisdiction-specific drafting conventions, don't map cleanly onto Git's assumptions.

Git is designed specifically for the software development process. The legislative process has a quite different set of requirements and traditions which must be met. It simply isn't possible to bend and distort the legislative process to fit the model prescribed by Git.

What this means practically is that the concepts of Git — version history, commits, branches, diffs, pull requests — are the valuable thing, not necessarily Git the exact tool. The future of legal document management will likely involve software built on Git's principles but designed specifically for legal workflows: tools that understand redlining conventions, can handle Word and PDF formats, and integrate with existing legal technology stacks.

Some of that software already exists. Tools like Ironclad, ContractSafe, and Hyperstart bring version-control thinking to contract management. The legal document management platforms used by major firms — iManage, NetDocuments — are adding increasingly Git-like features. The direction of travel is clear.

Part Five: How to Actually Start Using Git's Thinking in a Law Firm Today

You don't need to install Git on day one to start applying its principles. Here is a practical roadmap, from simplest to most advanced.

Level 1: Adopt the Commit Message Habit

The most immediately valuable thing Git brings to legal work is the discipline of explaining every change.

Start by making it a firm policy that every time a document is sent with changes, the email must include a brief note describing exactly what changed and why. This isn't Git — it's just good practice. But it's the same habit that makes Git's commit log so powerful.

Example: instead of "Please see attached revised agreement," write: "Revised Section 4.2 — removed liquidated damages clause per opposing counsel's objection on 15 March call. Added right of termination for convenience at client's request."

That note, attached to every revision, turns your email chain into something resembling a commit log. It takes thirty seconds and creates a paper trail that could be invaluable months later.

Level 2: Use a Document Management System with Proper Version Control

If your firm is still managing documents through a shared drive or email attachments, the first step is a proper DMS. Systems like iManage, NetDocuments, or Clio all offer version tracking, access controls, and audit trails. After 20+ years in legal technology, version control is on the short list of things a law firm's document system absolutely must do well.

This is not the same as Git, but it puts in place the infrastructure — centralised storage, version history, attribution — that Git formalises.

Level 3: Use Contract Lifecycle Management (CLM) Software

For firms that handle high volumes of contracts, CLM platforms like Ironclad, Hyperstart, or Icertis bring Git-like thinking directly to legal workflows: structured approval workflows, complete version history, automated audit trails, and clause-level tracking.

When legal teams get version control right, the payoff is huge. You can prove who made what changes, when they were made, and whether they were approved. Every edit is logged, every comment saved, and access is role-based. You avoid costly he-said-she-said disputes.

Level 4: Explore Git Directly for Plain-Text Legal Work

For legal professionals who work with policy documents, regulatory submissions, or internal guidelines — documents that don't require complex Word formatting — using Git directly is increasingly viable.

Plain text documents (including Markdown, a simple formatting language) work beautifully with Git. A compliance team that manages its policy documents as plain text files in a Git repository gets the full benefit: line-by-line history, branching for draft alternatives, pull requests for review, and a permanent audit trail.

This is not for everyone. But for legal operations teams, in-house counsel, or legal technology professionals, it's worth exploring. GitHub provides free accounts and extensive documentation. A few hours of setup creates infrastructure that pays dividends for years.

Part Six: The Bigger Picture

There is a version of the future where the opacity of legal documents — who added that clause, when this term was agreed, what the original draft looked like — becomes a relic of an older way of working.

What if you could fire up git blame and see who is responsible for writing each individual line of a bill? Think of how easy it would be to track those responsible, especially if the actual writer was tracked, and not just the bill's official sponsor.

That vision applies as much to a corporate acquisition agreement as to a piece of legislation. Legal documents are, at their core, a record of decisions made by human beings over time. Version control doesn't change the substance of those decisions. It just makes the record honest.

The legal profession has long prided itself on precision — on the exact meaning of words, on the careful drafting of clauses, on the documented intent behind every contractual provision. Git is simply a technology that makes that precision verifiable. Every change, every decision, every iteration: provably recorded, forever.

The question isn't whether version control belongs in legal work. It clearly does. The question is how long it takes the profession to fully recognise something that software engineers worked out decades ago — and that Washington D.C. has already proved works.

TL;DR

Git is a system that tracks every change to a document: who made it, when, and why
In legal terms: it's a permanent, timestamped audit trail for every draft, revision, and decision in a document's history
The problem it solves: the FINAL_v4_ACTUALLYFINAL.docx email chain, missing revision history, and undocumentable clause changes
Key concepts: repository (project folder), commit (saved snapshot + explanation), branch (parallel draft), diff (what changed), pull request (formal review), git blame (who wrote each line)
Real-world legal use: Washington D.C. uses GitHub as the official source for its legal code; the U.S. House of Representatives' Comparative Print Project applies version control to federal legislation; New Zealand's "Better Rules" programme uses similar principles for drafting law
For law firms today: start with commit message discipline, invest in a proper DMS or CLM platform, and for plain-text documents, consider using Git directly
The honest limitation: Git was built for code, not legal documents — but its principles are invaluable, and legal-specific tools are catching up fast

If this sparked a question or a "we actually tried something like this" story, share it in the comments. The legal technology conversation is just getting interesting.

The "Just Run It" Problem: Why AI + Bash Is Everyone's Business Now

Igor Kan — Sat, 21 Mar 2026 05:22:36 +0000

There's a moment that's becoming increasingly common.

Someone opens up an AI tool — Claude, ChatGPT, Cursor, or any number of others — types a request like "set up my project" or "clean up these files" or "automate this task", and the AI responds with something like:

rm -rf ~/Documents/old-project

The person doesn't know what that means. But the AI said it, so they copy it, paste it into their terminal, and hit Enter.

Their Documents folder is now gone. Permanently.

This is not a hypothetical. It happens. And as AI agents become more powerful — capable of running commands on your computer without you even typing them — the stakes are getting higher. Fast.

This article is for anyone who uses AI tools and has ever thought "I'll just let it handle it." You don't need to know how to code. But you do need to understand what's happening under the hood — because right now, that gap in understanding is where things go wrong.

First: What Is Bash, and Why Does AI Care About It?

Bash is the language of the terminal — the black (or white) command-line window you've probably seen developers use and assumed was only for them.

Think of your computer's visual interface — the icons, folders, drag-and-drop — as the "polite" version of your computer. Bash is the direct version. Instead of clicking File → Delete, you type a command. Instead of dragging a folder somewhere, you write an instruction.

It's powerful because it's direct. You can do in one line what would take ten clicks. You can automate tasks that would take hours of manual work. You can control things the visual interface doesn't even expose.

And here's the thing: AI agents love bash.

When an AI agent "does something" on your computer — creates a file, moves data, runs a script, installs software — it's almost always using bash commands behind the scenes. The friendly chat interface is just a wrapper. The actual work happens in the terminal.

Which means the AI is, in many cases, typing on your behalf. And unlike you, it doesn't hesitate.

Why Bash Is Becoming an AI Skill (Not Just a Developer Skill)

Five years ago, if someone said "you should learn bash," they meant developers and sysadmins. It was a niche skill for people who lived in terminals.

That's no longer true.

AI tools have quietly put bash into the hands of everyone — not by teaching people to write it, but by writing it for them. When you ask Claude to "organize your downloads folder" or ask an AI coding assistant to "set up your environment," the AI figures out the bash commands and runs them.

This is genuinely useful. It's also genuinely risky if you have no idea what's being run.

Here's why this matters for non-developers specifically:

Writers using AI to manage manuscripts, rename files, or automate backups are increasingly working with tools that run terminal commands.

Lawyers and researchers using AI to process documents, sort files, or batch-rename folders are in the same position.

Small business owners using AI to automate invoicing, move files between folders, or set up simple workflows — same thing.

Anyone using AI agents — tools that don't just answer questions but actually do things on your computer or in your accounts — needs a basic mental model of what's happening.

You don't need to write bash. But you need to know when an AI is running it on your behalf, and what questions to ask before you let it.

The Three Ways This Goes Wrong

1. The Irreversible Command

Some bash commands cannot be undone. The most infamous:

rm -rf

This deletes files permanently. No Trash. No recycle bin. No recovery. Just gone.

An AI agent that has permission to run commands on your system can run this. If it misunderstands your request — or if you misunderstood what you were asking it to do — the results can be catastrophic.

A real-world example: someone asks an AI to "clean up the temp files in my project." The AI interprets this broadly, runs a deletion command, and removes files that weren't temp files at all. The person didn't know to check. The AI didn't ask for confirmation. The files are gone.

The lesson: Before any AI runs a deletion, moving, or overwriting command, you should know what it's touching. "Delete these files" should always come with a list of exactly which files, reviewed by you first.

2. The Runaway Script

Bash can do things in loops. One command can run a thousand times. An AI agent that's tasked with "processing all the files in this folder" might write a script that touches every single file on your hard drive if the scope isn't clearly defined.

This is less about malice and more about ambiguity. AI agents are optimistic interpreters. They try to do what you asked. If you weren't specific, they fill in the gaps — and their gaps and your gaps might not match.

The lesson: Scope matters. "Do this to my files" is very different from "do this to the files in this specific folder." Always be explicit about what the AI has access to.

3. The Permissions Creep

When you install software or run certain scripts, bash sometimes asks for elevated permissions — essentially the ability to do anything on your computer, including things that affect system files, other users, or security settings.

An AI agent that prompts you for your password is asking for those elevated permissions. Once granted, it can do far more than you likely intended.

The lesson: If an AI tool asks for your system password, stop and ask why. Understand what it needs elevated access for before you give it.

So Should You Let AI Run Bash Commands Unsupervised?

The honest answer: not yet, and not without guardrails.

That's not a reason to avoid these tools. It's a reason to use them thoughtfully.

Here's a practical framework for thinking about it:

Low risk — generally fine to let AI handle it

Reading files and summarizing them
Creating new files in a specific location you've defined
Renaming files according to a pattern you've reviewed
Running commands where the worst case is easy to reverse

Medium risk — review before running

Moving large numbers of files
Installing software
Making changes to configuration files
Anything that touches multiple folders

High risk — always confirm, always review

Anything involving deletion
Anything requiring your password
Anything that touches system files or settings
Anything you don't understand and can't verify

The key question to ask is: "If this goes wrong, can I undo it?" If the answer is no, you should understand exactly what's being run before it runs.

The Guardrails That Actually Help

You don't need to become a bash expert. But a few habits go a long way:

Ask the AI to explain before it executes. Most good AI tools will tell you what they're about to do if you ask. "Tell me what commands you're going to run and why before you run them" is a completely reasonable thing to say to an AI agent.

Ask for a dry run. Many bash commands have a "preview" mode that shows you what would happen without actually doing it. You can ask the AI to show you the dry run first.

Work in a test folder. When trying something new, create a folder with copies of your files and let the AI work there first. That way, the worst case is losing a copy, not the original.

Read the command, even if you don't understand all of it. You don't need to be fluent in bash to notice red flags. If you see rm, that's deletion. If you see a path you don't recognize, ask what it is. If something looks broad — like /* which means "everything" — ask for clarification.

Use AI tools that show their work. The best AI agent interfaces make visible what commands are being run, in real time. Prefer tools that don't hide this from you.

The Bigger Picture

AI agents are becoming genuinely capable. In the next few years, it won't be unusual for an AI to manage files, run automations, interact with your email, and execute complex multi-step workflows — all from a single instruction you gave it in plain English.

This is mostly a good thing. The productivity gains are real. The reduction in tedious work is real.

But there's a version of this where people hand over more and more control to systems they don't understand, and occasionally something goes very wrong — not because the AI is malicious, but because the human didn't know what questions to ask.

The goal isn't to make everyone a bash programmer. The goal is to close the understanding gap just enough that you can be an informed participant in what your AI tools are doing on your behalf.

Bash is no longer just a developer skill. It's becoming AI literacy. And AI literacy is becoming — quietly, quickly — something everyone needs.

The One Thing to Remember

If an AI agent is about to do something on your computer and you don't understand what it's doing: ask it to explain, in plain English, exactly what will happen and whether it can be undone.

That one habit will save you more times than you know.

Found this useful? Share it with someone who uses AI tools but hasn't thought about what's happening under the hood. They'll thank you later.