When will legal vibe like code?

# When will legal vibe like code? > What legal needs to build before AI agents can dance like they do in code [Read on Substack](https://lawwhatsnext.substack.com/p/when-will-legal-vibe-like-code) · 2026-02-03 · Law What's Next --- The following article was published by our friend Chris Bridges through LinkedIn on January 29, 2026, and with his permission we are sharing this super insightful and enjoyable reflection piece with you. We caught up with Chris and Matt Pollins earlier this week to discuss this and their new collaboration: vibecode.law; and that conversation will be published across our Law://WhatsNext channels (next week) on the 11 February 2026. Putting the prototype v production debate aside, AI coding tools offer an incredible productivity boost compared to what we have in legal. I’m not necessarily talking “vibecoding” here, despite the title, and despite my closing line (go on, keep reading)! I am talking about how prevalent it has become for senior software engineers to be supercharged by tools like Claude Code, Cursor or OpenCode. They are quickly becoming part of every software engineer’s business as usual, and the difference they make is huge. Understandably, people are asking “if it’s possible for software engineering, it must be possible for legal?”. As both an engineer and a lawyer, I think that is a half-truth. So in this article, I try to compare them directly. Clearly, that comparison is strained at points. That is somewhat my point. It is a tough comparison to make, given the radically different status quo between the fields. That said, it is a useful exercise in thinking “what needs to happen in legal to move things in a similar direction”. Grab a coffee, and if you are familiar with the idea of work that requires agency, and what is therefore “in scope” of agentic tools, skip the next section. Scope – legal work that requires agency In this article, I’m talking about work that is by its nature “bespoke” — work that takes a high degree of agency to carry out. This is what AI coding tools do: they share agency with their human co-pilot. I’m not talking about “off the shelf” work. I am not getting into what should be off the shelf, or whether you even need a lawyer or software engineer at all when you could just “vibe” something yourself. Those are minefields for a different day. Example: Inside scope Think corporate structuring and tax advice for a well-funded founder. The right solution is highly dependent on their circumstances and their investors’ goals. Even if the end solution is relatively standard, the path there isn’t a straight line. Or think about advising on a contractual web for a novel operating model. What you’re doing isn’t novel, but how you’re doing it is. You need to design inter-dependent contractual relationships that manage legal risk while actually working for the business. What these have in common is the number of people, opinions and moving parts — even if no single element is completely novel. Whether human or AI, the outcome requires judgement, planning, and probably some empathy for how everyone involved is going to feel about it. In software terms, these are your features — the things unique to what you’re building, where a lot goes into design even if implementation is then relatively straightforward. Example: Outside scope Think website terms of use. They’re more or less the same across websites, and what differentiation exists based on what the website offers can be handled by old-school deterministic document automation. Or reviewing supply agreements from household-name suppliers. You’re not negotiating bespoke terms — you have a few showstoppers you’ll push on, but otherwise you sign what’s in front of you. The important point: you aren’t “building” anything here. You don’t need flexibility. There’s a standardised process, probably tech-led with a human pulled in as needed. In software terms, that’s a library, a package, or off-the-shelf horizontal SaaS. An engineer might use an AI agent to integrate with it, but not to build it. With scope defined, let’s look at what makes AI coding tools work so well — and why those ingredients are harder to find in legal. So what makes software engineering different? So you’ve identified work that requires agency. Now what is it about software engineering that makes AI such a good co-pilot? Watching Claude Code, OpenCode and other tools like them work is fascinating. If you have an engineering team in your business, do yourself a favour and ask them to show you how they work with them, and to explain what it is doing as it does it. It is like watching a carefully choreographed dance – until you see it fall over – when it gets even more impressive as it picks itself back up, corrects its mistake and moves on. LLMs have lots of agency, but they are not very deterministic. Their lack of determinism is what makes it possible to even be having a conversation about helping with bespoke work. It is what gives them their agency. But that agency and lack of determinism needs to have guardrails in order to build the trust and autonomy needed for serious productivity gains – whether in law or code. AI coding tools leverage the software engineering ecosystem that existed long before AI to make them more deterministic. The next few sub-sections go through what those building blocks are, with a comparison of what the equivalent might be in legal. Conventions & standards Professional software engineers work to strong conventions – so much so that they often become published standards. They have existed since the dawn of computing, and have only become stronger and more opinionated. Most of those standards are public. Bigger organisations might have their own flavours, but they still exist, and many later go on to become the first version of an industry standard. Why develop these? Because it makes it easier for different engineers to pick up when moving between teams or organisations. The code follows familiar patterns, and is easier to read. Surprise surprise, that is also why codebases that follow standards will perform better with AI. It can read and understand what is already there better. This isn’t a law firm style guide on fonts and the type of numbering to use. It is the equivalent to a set of tightly defined rules of the right way and a wrong way to write a sentence. This is the equivalent of law firms, in-house legal teams and others agreeing on the “right” way to write each clause or type of clause. That is a lot more challenging to do in the adversarial world of legal – which is probably why we haven’t seen much of it yet. Knowledge Software engineers often measure other software on the quality of its documentation. The strongest ecosystems, languages and frameworks document every detail about how they work, their limitations and common pitfalls. Like conventions, they are also often strongly opinionated. There is a shared understanding of the optimum way of doing things, and the less optimum way. Where there are gaps, software engineers have relied on communities like SourceForge to crowd-source solutions. If you have had an issue – its likely someone else has too. Not to mention git – the way software engineers version their code. Github alone has billions of lines of public code, along with code reviews that link “why” to each change. You guessed it – that’s all incredible training knowledge for LLMs. So good, that I’ve seen multiple instances of the author of the software sharing experiences of LLMs suggesting features or solutions they long forgot existed… I’d hazard a guess that if you put together all of the public and private legal knowledge (Practical Law, Lexis PSL, etc.) – it’d far still be less useful than the corpus of software engineering knowledge available. Not least due to lack of common belief on the “right” way. As with convention, this is somewhat made more difficult by the adversarial nature of legal – with the “right” answer depending on what side of the deal or advice you are on. Oh, and this all needs to be in a format that is easy for an LLM to follow. We better work on our readability scores (me included, he says, as he skims back over this long article)… Linting In the software ecosystem, “linters” are tools that parse code and either (a) fix it; or (b) flag that it needs fixing. They are usually doing this against conventions, standards and knowledge. However, they are doing that in a highly deterministic way – not using AI as you’d know it. These typically work by a combination of pattern matching and by boiling what is written down to its “computational equivalent” or something near it – i.e. how a computer would understand the instruction. This enforces convention, standards and architectural knowledge, and as every compliance lawyer will know, a policy is only as good as how you monitor it and enforce it! AI coding tools can run these linters after making changes, ensuring they are always contributing back “compliant” code. Sadly, this is much harder to do in legal. We tend to deal in words, which do not have as easy a computational equivalent. That said, that may change. The nearest I can think of that we currently have is tools like Definely – which look over your documents for common errors or inconsistencies. A good step in the right direction. Testing and certainty of input and outcome This, for me, is a big one – the ultimate deterministic backstop. Software engineers typically write tests for their code. Fundamentally a test: defines some input data; performs an action within the codebase; and tests the effect of that input data – e.g. the errors it returns, what shows on screen, or what data does or not stay the same behind the scenes. They’ll re-run these frequently whilst coding to spot “regressions”. I always used to write my tests after writing the feature. However, with AI coding agents, it is the first thing I will check. If tests already existed, I’ll check it hasn’t changed them or that it has changed them the right way. If tests did not already exist, I’ll check what it has tested and whether I’d expect the same output with the given input. What I am doing here is checking if it is aiming for the right outcome. If you get your tests right, you are able to give AI agents so much more autonomy. They’ll run those tests after making changes, check if they have broken anything, and then fix them. That means the software engineer only needs to intervene if it’s going in the wrong direction. For the same reasons as linting – this is tough in legal. You cannot “run” words in a deterministic way like you can code. Hell, there is often no black and white outcome to aim for! If someone is trying to solve this challenge in legal, I’d sure love to know about it. The end-game All of the above sounds like hard work, and it is. Both at a macro level building the ecosystem to make it possible, and then being disciplined to follow it. Ultimately one of the big differences between legal and software engineering is the end game. A huge proportion of legal work is project based. Each project is a onetime thing (or at least is seen that way), not something you iterate on for the foreseeable future. In software engineering, the opposite is true. If all goes well, your codebase will still be running and being worked on in 10-years’ time (even if it has gone through evolutions). This makes the ROI of investing in determinism much higher. Even if it were possible, are you going to invest in building a test suite for legal work that you will only run once? The answer here is probably building re-usable legal solutions in verticals. For instance, building an AI coding agent like experience for executing a corporate transaction (or part of one). That way, you can start to build conventions, standards, knowledge, linters and test suites (or whatever their equivalents become in legal!) in a re-usable way between client transactions. Some commonality I’ve used a lot of words talking about the differences between legal and software engineering, but there is one huge similarity which will not go away anytime soon. And it is something that – perhaps ironically – vibecoding tools can help with. That is the human side of our work. Lawyers often complain about not being able to get clear instructions out of their client. It is one of the biggest causes of scope overruns and broken expectations in the industry – regardless of where fault lies. The same is true in software engineering. Trying to understand what it is that your client needs, and how they want it achieved. Failure to do so properly leads to at best delay, or at worst a failed project or product. Vibecoding tools are a genuinely awesome tool for breaking down those communication barriers. They allow a domain expert to get closer to product, massively increasing the chances of the product & engineering team building the right thing first time. They might just help us build a future where legal can be more like software engineering. Follow Chris Conclusion I’m bullish on AI in legal, but realistic about the groundwork still needed. Whilst you might argue that ultimately everything will be vibe-able, change is a progression. We won’t get there by trying to jump all the way from A to Z. Legal will need to put in the miles that engineering has – albeit AI and learning from software engineering may accelerate the process. Thankfully vibecoding tools give us a fantastic opportunity to break down communication barriers, prototype rapidly, and bring legal domain knowledge closer to the engineering team. That is mostly certainly a good thing, that we should all celebrate, whether or not vibecoded apps are production worthy. Thanks for reading Law://WhatsNext! Subscribe for free to receive new posts and support our work.