Vibe Coding for Lawyers: What Lawyers Are Building, What Breaks and How to Start Safely

In April 2025 an immigration lawyer typed a question into ChatGPT that most of his profession would be embarrassed to admit: “How do I open a terminal?” By February 2026 Kevin J. Andrews had a solo practice and a SaaS platform, after roughly 500 hours with Claude, and could still write, “I still haven’t written a line of code.” His description of the working relationship is the best one-line definition of vibe coding for lawyers I have read: “I think of myself as a really dumb Steve Jobs, and the AI is a really smart, but incredibly naive, Steve Wozniak” (Andrews on Medium).

Two things are true at once: lawyers are building working tools without engineering training, and some of those tools are, in one r/legaltech sceptic’s words, “primarily single user softwares” made “for LinkedIn love”.

What vibe coding is, and why it suits lawyers

Vibe coding is describing what you want in plain English to an AI coding tool and letting it write the code, run it, read the error and fix it, while you test the result.

Why it suits lawyers is a point Jamie Tso, a Clifford Chance senior associate, made in the ABA’s IP newsletter: “by asking the AI to build a tool rather than answer a question, the result becomes deterministic, significantly reducing the error rate” (ABA). Ask a chatbot whether every date in a contract falls on a business day and you get a plausible answer that may be wrong. Ask it to build a script that checks the dates and you get a program that gives the same answer every time and can be tested against documents where you know the truth. The model’s unreliability is confined to the building; the running is ordinary software.

Who is doing it: Tso, LegalQuants, Linklaters, vibecode.law

Tso started as a trainee in 2020, built internal tools with Copilot Studio and Power Automate that “went viral internally”, then taught himself to code; his open-source repositories have been forked more than 100 times, and he predicts “just-in-time, disposable software” (Artificial Lawyer). His LegalQuants tools include a law-review verifier, a clause bank, a terms-update checker, chronologies and local-rules dashboards; a LegalQuant hackathon produced 20 working apps in one week.

At Linklaters, managing associate James Phoenix built an Excel plugin, driven by the firm’s in-house chatbot, that scans and fixes time-recording issues; it is used firm-wide. vibecode.law launched as an open platform for sharing such tools; one example, DocUnlock, cleans heavily marked-up documents for reuse (nonbillable.co.uk). Andrew Thompson of Orbital argued in Bloomberg Law that firms which ban this “lose twice: once by missing feedback in the form of product intelligence from their lawyers, and again when they can’t tell what technology to build from what to buy.”

Good first projects: internal, deterministic, low-risk

The pattern: one user, one job, inputs you control, an answer you can check.

The risks: CodeRabbit’s numbers and the Version Story warning

CodeRabbit’s December 2025 study of 470 open-source pull requests, 320 of them AI co-authored, found the AI-assisted ones carried about 1.7 times as many issues (10.83 against 6.45 per pull request), 1.4 to 1.7 times as many critical or major findings, 75% more logic errors and up to 2.74 times as many security vulnerabilities (CodeRabbit). Agiloft adds “slop squatting”, where a model invents a package name that an attacker then registers, and lawyers hosting tools on personal cloud accounts outside IT’s view.

Jordan Domash, an engineer writing in Version Story, put the rule bluntly: “Lawyers should not trust apps they vibe-code with their clients’ confidential information unless they have the technical expertise to deploy their tools securely” (Version Story). His 2030 workflow is the checklist to aim at: a sandbox, automated security checks, IT approval, an isolated container, a “degradation budget” that takes a tool offline after repeated failures.

Client data and hosting: the line not to cross

A home-built tool that sends text to a model’s API is a vendor without a contract, a DPA or a no-training clause; on a personal cloud account it is also shadow IT. ABA Formal Opinion 512 requires you to evaluate the risk of disclosure before client information goes into any tool. After United States v. Heppner (S.D.N.Y., February 2026), where a defendant’s exchanges with consumer Claude were held to be protected by neither privilege nor work product, “it was just a script” is not an answer.

Three positions are defensible. Build and test on synthetic or anonymised documents, always. Run on real client data only inside the firm’s environment, after applying the vendor due-diligence checklist to your own creation. Or keep the whole pipeline on one machine: a local model through Ollama (Llama 3.1 8B runs on a 16 GB laptop) means nothing leaves the room, at the price of weaker models that still invent citations; see local LLMs for lawyers.

Claude Code, Cursor, Lovable, Replit: the tool ladder

Two cautions on Claude Code. It ships with Claude Pro, Max and Team Premium ($100 a month billed annually, $125 monthly), but on the consumer plans your sessions train Anthropic’s models unless you switch that off; Team and Enterprise do not train by default. And the open-source Claude for Legal plugins drew the LinkedIn verdict that they are “more engineer than lawyer friendly at the moment”. The plans are in Claude for lawyers; the lower rung is worked through in no-code automation for a small law firm.

Write a plain-English specification I can paste into Power Automate's "Describe it to design it" or a Zapier description: when a potential client submits the website form, post a summary to the "Potential Clients" channel in Teams tagging [name] to run a conflict check, send the enquirer a holding email from <template>, and create a task due in two business days. Do not create a client record until the conflict check is marked clear.
Then list every service the enquiry passes through and what each stores, the failure cases (duplicate contact, missing email, spam), and any step where the enquiry could be visible outside the firm.

Maintenance: who fixes it in a year

Noah Waisberg’s rebuttal to the Claude-native enthusiasts applies to every home-built tool: “what you’re building starts to look a lot like software… except without the QA, the versioning, the user feedback loops, or the ability to survive someone leaving the firm” (Zuva). The minimum discipline, adapted from Tom Martin’s small-firm research habit (a fixed non-billable block each month, one-workflow experiments against a baseline, and a written note of what you learned): a README that says what the tool does and how to test it, and a set of known inputs with known outputs you re-run after any change. A tool with no owner, no test set and no README is disposable software; Tso’s phrase is a compliment only if you actually dispose of it.

When to hand it to a developer

Hand it over when someone other than you relies on it; when it needs logins; when it reads or writes to the document or practice management system (the MCP route, which iManage and NetDocuments now support, is a procurement decision, not a weekend); when it touches client data outside your own machine; or when a failure would be visible to a client or a court. Your prototype then becomes the specification, Thompson’s “product intelligence”, worth more to IT than a feature request written from memory.

A first weekend project

1. Pick the annoyance. Weekly, with a right answer, on documents you can fake; the pre-send bracket checker is a good default.
2. Interview before building. Have the tool ask questions first; Andrews asked for “IKEA-style instructions”.
3. Build on synthetic documents, one of which should fail.
4. Test against ten known answers. Every disagreement is a bug or a lesson.
5. Ask where the data goes (second prompt below) before the first real document.
6. Write the README and the kill switch.

Build me a small tool I can run on my own computer. Input: a .docx file. Output: every square-bracket placeholder ([CLIENT], [cite], [TBD]), highlighted passage, comment and unaccepted tracked change still in the document, with paragraph numbers, and a one-line PASS or FAIL.
Constraints: run offline, send nothing over the network, never modify the input file, handle a 200-page document.
Before writing code, ask me up to five questions about my documents. Explain each step as if I have never used a terminal. When done, generate three test documents, one that should fail, and show the expected output for each.

Here is the code for a tool I built with AI: <code>. Explain to me, as a lawyer with no technical training: (1) every place data goes in, is stored or leaves my computer, including logs, temporary files and network calls; (2) every third-party service, library or API it uses and what that party could see; (3) what happens if a document contains malicious content; (4) what breaks if the model or a library changes; (5) the three riskiest lines.
Do not reassure me. If you are not certain what a line does, say so. Then list the changes needed so the tool never sends data off this machine.

Andrews’ closing advice is the right note: “The single most important capability we human users need to preserve is a radical sense of intellectual humility.” The tool that says “Done!” has tested nothing; you have. That is why AI Lab for Lawyers stays in the browser and writes no code: the platforms-and-agents session works through what an agent does with a folder of anonymised documents, and the confidentiality questions get asked out loud before anything runs.

Where to go next: the skills this page depends on are mapped in the AI skills lawyers need; the agents your tools will call are in what is an AI agent for lawyers; the rest of the cluster is in the careers and future hub.