When considering adopting AI, legal teams often ask themselves whether they should buy a tool or build it in-house. We’ve seen the splashy stories: law firm Kirkland & Ellis, for example, is spending $500M USD to build its own AI tool. On the opposite extreme, former Latham & Watkins associate Will Chen has created MikeOSS, an open-source legal platform that claims to offer the same functionality as very well-known legal AI tools. Comments like this turn up regularly on the r/legaltech subreddit: “You can easily vibe code all of the functionality of [a major AI legal tech vendor] in a weekend. In fact, you can vibe code a better solution since you can customize it to your situation.”
So the question remains: with vibe coding tools, open-source projects, and general-purpose AI tools entering the legal market, should enterprises create their own AI tools in-house? Can you vibe code a legal AI tool that can do the work that in-house counsel needs it to do?
“You can absolutely vibe code a legal AI tool,” Didier Smith, Ivo’s Head of Engineering, says. “But whether that’s a good idea depends a great deal on who is doing the vibe coding.”
The reason, Didier points out, comes down to a software principle. “There's this rule in software called the 90/90 rule,” he notes. “Ninety percent of a software project takes 10% of the time. Then the last 10% takes the other 90% of the time. I believe that now, with AI vibe coding tools, it's actually closer to the 99.99 rule. You can get something that is 99% complete in a very short amount of time. But then that last 1% takes the other 99% of the time. It's that level of detail that makes the difference between software that normal people want to use and software that only tinkerers want to use.”
Why the last 1% takes so long
Didier notes that the best example of obsessing over this type of detail is the fate of FreeBSD, an open-source operating system that dates back to the original Unixes in the 1970s. “People have been tinkering away on FreeBSD in their spare time for about 50 years. And many people do run FreeBSD on their laptops. But they just don't know it, because Apple did the last 10%. macOS is, in fact, built on top of FreeBSD. Apple did all the bits that the guys tinkering in their spare time didn't want to do.”
The same principle applies to vibe-coded or open-source software. “People love to smash out these open-source projects when they're fired up,” Didier observes. “You go on the weekend and think: I want to build a legal AI tool, I want to build an operating system. And that first 99% is really satisfying because you just have your concept in your head and you bash it out and you've got something that sort of works. But then you run into the edge cases you didn't anticipate. The number and diversity of those edge cases determines how long you're going to be grinding away before you have something that's actually acceptable in practice.”
Didier elaborates on why the profession of law, in particular, has such a high number of edge cases. “One reason is purely technical,” he says. “Lawyers deal a lot with Word documents, and Word documents are an obscure, complex format. Lawyers care a lot about formatting—the numbers on their bullet points, the clause numbers—and those have legal implications. Getting a clause reference wrong can actually cause trouble down the line. So just editing a Microsoft Word document in a way that a lawyer would be happy with is surprisingly difficult. And then there's the legal substance itself. A lot of people think contracts are like code written in English, but that's not true. Code is designed to be unambiguous, whereas contracts are often designed to be ambiguous. Lawyers, when negotiating a contract, are under a dual tension. They have to protect their company from risk, but they also need to get the deal closed. So they'll deliberately put in ambiguous language that lets the deal move faster—language they can later fall back to arguing in court.”
The difference between lawyers and engineers
Didier points out the importance of domain expertise in both engineering and law. He notes that the two professions have different skill sets, which means lawyers are unlikely to enjoy using open-source or vibe-coded software. “The people who can orchestrate agents and vibe code Claude Code instances just tend not to be the same people who know the difference between a good redline and a bad redline. This is why we have companies with different people in them and different departments—so the people who are great at programming can focus on programming, and they can leverage the domain expertise of people who are great at law.”
That said, he points out, there is some crossover between people who enjoy vibe coding and people who are good at practicing law. And in those cases, it’s possible that creating these types of software projects might be a good solution to working more efficiently. “If you're a tinkerer and you like tinkering, and you don't mind when your software kind of breaks a little bit because you can fix it, and you enjoy that, then it probably is a good idea to tinker away and build your own legal AI setup. But your average lawyer won’t want to go through the grind that it takes to build something that works really well in a high-edge-case environment. And if it breaks, the lawyers aren't going to be the ones to fix it. They're just going to say it's broken. You're not going to get the lawyer open-source community submitting PRs to your GitHub,” he jokes.
Didier is clear that none of this is a criticism of the tinkerers themselves. If you enjoy building, you should build. The question that legal leaders should ask themselves is whether these types of tools will survive contact with a legal team under pressure that has neither the time nor the inclination to scrutinize their output or fix them when they break.
