A vibe coding guide for lawyers
Why the skill that keeps a contract from being litigated is the same skill that keeps code from breaking, by Jake Jones.
Everyone keeps asking whether lawyers should learn to code. I’ve spent the last eight years building software with lawyers.
The answer is more interesting than you think.
This is the honest version… what vibe coding actually is, where it goes wrong, and why lawyers are better equipped for it than almost anyone.
What happened on a Sunday evening
I built a self-updating, self-executing kanban board tool for myself a few weeks ago, on a Sunday evening, in less than an hour. The data persisted across sessions. The styling matched the rest of my workspace. An agent triages my Slack, email, and calls, and any relevant “to dos” it adds to the board. Another agent does the work, if it doesn’t need me in the loop. I now use it every day. I cannot tell you, in any meaningful detail, what the code does. Oh, and I’m editing this article on a vibe coded CMS.
I described what I wanted in a few paragraphs across a few iterations and an agent built it. I ran the result. It worked. I asked for some more fine changes. It made them. By the time I closed the laptop, I had a tool that did exactly what I had been trying to make myself do across multiple, expensive apps for the better part of a year.
I cannot tell you, in any meaningful detail, what the code does.
This is familiar to some of you. To many others, you’ve heard of it, but you’ve not yet dipped your toe in. The name for this is vibe coding, a term coined last year by Andrej Karpathy in a tweet that has since accumulated several million views. The defining move, as he described it, is that you stop reading what the model produces. You see, you say, you run, you copy and paste. The code grows past your immediate comprehension, but it works, and that is enough. The code becomes a black box, and actually... I don’t hate that.
But here, I want to think through what this means for lawyers, partly because I have watched a lot of lawyers ask the question already, and partly because the honest answer is a lot more interesting than “you should learn to code” (because, hot take, you definitely should not).
⚡ The reading step is the part that disappears
There is a version of using AI to help with code that is not vibe coding. It is the version most engineers have settled into. A developer asks a model to draft a function. They read it carefully, edit it, run the tests, and ship. The model is a faster pair of hands; the skill of reading the code is preserved. Simon Willison, one of the more careful voices in this space, has said that if you have reviewed and understood every line, you are not vibe coding, you are using an LLM as a typing assistant. He is right about this, and the distinction matters.
Vibe coding is the version where the reading step is gone. You describe what you want. The agent writes the file, the test, the dependency, the config. You judge the result by what it does, not by what it says. If it behaves the way you described, you keep it. If not, you describe the gap and let it try again. You can spend a whole evening like this and end up with a working tool whose source code you have never seriously opened.
Using AI to help you code is (i) boring and (ii) serves an entirely different purpose to vibe coding.
The reason this matters to people who are not engineers is that the bottleneck has moved. The hard part is no longer the writing. The hard part is the description. And lawyers, of all the professions I have worked alongside, are unusually well-equipped for the description.
The core claim: The bottleneck has moved from authorship to specification. Lawyers have spent their careers writing specifications precise enough that they cannot be misread, because they know what happens when they are. That craft, more than any technical skill, is what vibe coding requires.
Why specification is already your job
When you draft a contract, you are not really writing prose. You are writing a small set of behavioural rules that some future party (a counterparty, a counterparty’s counsel, a judge, a regulator) will execute by reading. Every clause is a function. Every defined term is a variable. Every “notwithstanding the foregoing” is an exception handler. You have spent your career trying to write specifications precise enough that they cannot be misread, because you know what happens when they are.
An agent doing vibe coding will read your description the same way a court reads your contract. If you have been vague, you will get something vague back. If you have left a term undefined, the agent will define it for you, often badly. If you have specified what you want but not what you do not want, the negative cases will come back wrong. The skills that keep a contract from being litigated are the same skills that keep a piece of code from breaking on its first real input.
The lawyers I have watched do well at this are not the most technical. They are the ones who can hold a problem in their head with discipline. They notice when a description contains an implicit “obviously”. They ask, before they send a request to the agent, what the agent is most likely to misunderstand. They draft like they would draft a clause, which is to say, with the worst-case reader in mind.
You already have most of this skill. What you do not yet have is a tool that lets you point it at something other than a document.
You already have most of this skill. What you do not yet have is a tool that lets you point it at something other than a document.
The gap between "I built a thing for myself" and "I built a thing other people rely on" is what the webinar covers. Join us Wed 3 June.
🔒 Four traps worth naming
There are four ways I have watched lawyers get vibe coding wrong (and I have done all four of these myself). They are worth naming because they tend to be rather hard to spot.
The first is mistaking running code for working code. The agent will produce something that compiles, accepts input, and returns output. None of that means it is correct. A contract that has been signed has not been read by the people who will eventually need to enforce it; a tool that has been run once has not been tested against the inputs that will eventually break it. The right posture is the one you would take with a draft from a smart associate with strong written English and limited subject-matter knowledge: assume it is plausible, assume it is wrong somewhere, and look for that somewhere before you let anyone else rely on it.
The second is confidentiality bleed. Most of the agents you might use to vibe code something send the text you give them to a model provider’s servers. Some of those providers train on the input and some do not. Some have zero-retention agreements and some do not. If you paste a client contract into a general-purpose chat in order to ask for a summary tool, you may have just done something your firm’s information security policy does not permit. The remedy is dull (read the agent’s privacy posture before you use it, prefer enterprise-tier tools with zero data retention, never paste anything you would not paste into an email to a competitor) but the discipline does matter because failure here is usually silent.
The third is the gap between a prototype and a production system. The kanban board I built on a Sunday is fine because the only person it can disappoint is me. A clause-extraction tool you built on a Sunday and then quietly rolled out to your commercial team is not fine, because now it can disappoint someone who matters. The line you have to hold is the one between “I built a thing for myself” and “I built a thing that other people now rely on”. The second category brings with it a set of standards (testing, monitoring, version control, escalation paths) that the first does not. The mistake is to assume that because the same person built both, the same level of care applies.
The fourth is the maintenance tax. Vibe-coded software is software. It rots. Dependencies break, model behaviours shift between versions, the world your tool was built for is not the world it now sits in. The pattern I keep watching is the lawyer who builds a tool in a burst of enthusiasm, uses it for a month, watches it slowly stop working, and quietly stops opening it. The honest move, before you build, is to ask whether you will return to this thing in six months. If the answer is no, build it anyway, but build it small. It’s easy to build a ton of stuff. It’s a lot harder to care about those apps in six months or two years.
It’s easy to build a ton of stuff. It’s a lot harder to care about those apps in six months or two years.
🌱 What to build first
The best place to start is something private. Something that has exactly one user, and that user is you. Karpathy’s original framing was that this style of building is best suited to what he called throwaway weekend projects... and he was right, in the sense that the constraints of a weekend project are the constraints that vibe coding is genuinely good at.
A meeting-prep tool that pulls the last three emails with a person into a single page before a call. A small utility that takes a redline you have just received and gives you a one-paragraph summary in your own voice, not the model’s. A clause library you might actually use, instead of the SharePoint folder you do not. The personal kanban board. None of these will win an award, and all of them will be slightly bad in ways only you will notice. That is the point. You are practising the description skill on a problem where the cost of getting it wrong is one wasted afternoon.
The things not to start with are the obvious ones: anything that touches client data, anything that touches the matter management system, anything that anyone other than you might come to depend on. There is a version of vibe coding that will eventually be safe to do all of those things; it is largely the version we build, day to day, at Flank. But it is not the version you do on your first try. Build small. Build private. Build something you can throw away without losing anything that mattered.
The craft has not changed
I do not think every lawyer is going to become a programmer. I think something more interesting is happening, which is that the gap between describing what you want and getting it built is collapsing across the whole of professional work.
For most of the last fifty years, software has been a thing other people made for you. Lawyers have lived with this constraint quietly. The document management system is what IT bought. The contract review tool is what procurement signed. The workflow you have to follow is the one the vendor designed. Vibe coding does not solve this entirely, and it does not turn a GC’s office into an engineering team. But it does mean that some of the things you have been waiting for somebody else to build, you can now build yourself, on the weekend, in the form that actually fits the work you do.
The deeper point is that lawyers have spent their careers in the gap between what people want and what the document says. That gap is exactly the gap that vibe coding lives in. The skill that makes you good at one is the skill that will make you good at the other. The tool has changed; the craft has not.
What you describe is what gets built. That, more than anything else, is the thing worth internalising. Describe carefully.
✳️