Jamie Tso Interview: Vibe-Coding Your Own Legal AI Tools

If you’ve been on social media then you will have probably seen posts by Clifford Chance senior associate Jamie Tso, who on his own has built – or in today’s parlance vibe-coded – a range of sophisticated legal AI tools that aim to do what major companies are providing. Here, Artificial Lawyer interviews Hong Kong-based Tso (see Linkedin bio), and asks him some of the big questions. This includes the key one: is this approach a viable alternative for major law firms to buying legal tech tools? And also: why not start your own legal tech company?

How did you get into legal tech and building your own applications?

I first got into legal tech as a trainee. About five years ago, when I was in the investment funds seat, a big part of my day-to-day was mapping retail fund prospectuses against the content requirements in Appendix C of the Unit Trusts Code. After doing that repeatedly, I started wondering whether I could build a small tool to automate at least part of that mapping.

So I experimented with training small language models using publicly available materials, and I hired engineers on Upwork to help. I was playing around with TensorFlow, PyTorch, and BERT, things like mapping entities (e.g. investment objectives against risk factors etc). Honestly, it didn’t go very far at the time: it was technically hard, and I didn’t yet have the right tooling or enough support to make it production-ready.

I became much more serious when I started building internally at Clifford Chance. The firm, through its Microsoft subscription, enabled no-code automation tools like Copilot Studio and Power Automate, so associates could build AI-enabled workflows. From what I’ve seen, not many firms give lawyers that kind of ‘playground’, so I was genuinely grateful for it. I got obsessed and started building not just for myself but for colleagues.

Pretty quickly, partners and associates from different offices started sending automation requests every other day, and I got a real taste of taking something from 0 to 1. Some of the document-processing tools I built ended up going viral internally and were ultimately adopted by the firm, which was a great experience. The best part was collaborating with colleagues globally and shipping real things that actually got used.

After that, I ran into the limits of no-code, and I wanted to go deeper: what’s actually state-of-the-art for the hardest problems lawyers face, and what does the industry really need? So I started teaching myself to code on weekends and late nights, and I began posting on LinkedIn mostly to share what I was learning and to connect with others building in the space.

What you have made is really impressive, why not start your own legal tech company? Or join one of the major legal AI companies?

I’m mostly driven by solving real problems and building things people love. I want my career decisions to be an extension of that – not the other way around. If there comes a point where starting a company or joining a major legal AI team gives me the most leverage to build and ship the best solutions, I’d consider it.

Is it realistic for most law firms to rely on tools you’ve built, or build similar tools, instead of buying legal AI platforms? Isn’t it easier to just buy a platform that 1,000 lawyers can use?

Traditionally, the argument for buying is totally fair: software needs maintenance, security, support, and it has to scale. But I think the economics are shifting.

As LLMs get better at coding, and coding agents get more capable, the cost of building high-quality, maintainable internal tools is dropping fast. In practice, a lot of the “first draft” code even for professional developers is already AI-generated.

That pushes us toward a world with more just-in-time, disposable software, tools built to solve a specific pain point for a specific workflow, then replaced or disposed when the workflow changes. In that world, long-term maintenance matters less.

The same goes for scalability. Lawyers don’t all work the same way – teams and practice groups have their own habits and workflows – so many internal tools don’t actually need to scale to 1,000 people globally. They just need to work well for the users who need them.

On security and privacy: there are already strong patterns for this – automated scanning, dependency checks, and secure deployment processes. Tools like Semgrep and Houngdog help, and I expect ‘vibe coding’ platforms will keep baking more of this in at the platform level. Security doesn’t go away, but it becomes more standardized and solved at scale.

Of course, there will always be use cases and features that are common and foundational. Even if 1,000 lawyers “vibe code” 1,000 different solutions, a lot of the underlying building blocks will be the same.

That’s why, as features across legal AI products start to converge, I think it’s important to have open-source equivalents so that:

• New entrants don’t have to keep rebuilding the same baseline capabilities and can focus on genuinely differentiated innovation.
• Law firms can adapt those open tools to their own workflows instead of paying multiple subscriptions for overlapping functionality – and they can audit, explain, and govern the code because it’s open.
• Clients ultimately benefit as shared infrastructure reduces duplication and lowers software costs, which can be passed through in cheaper and faster legal service.

Can law firms use what you’ve built ‘as is’? Can they just go to GitHub and start using it? And will you maintain it?

Yes – if an individual lawyer wants to run it locally on their own laptop, they can use it pretty much as-is. If a firm wants to deploy it at scale on day one, it usually needs a bit more engineering work around things like hosting, user management, security, and support – although none of that is conceptually difficult. That said, the repos I’ve open-sourced have already been forked 100+ times, so they’re clearly being used in different ways – from, I suppose, using the repo end-to-end to reusing individual modules or components as building blocks inside other internal tools or commercial products. Either way, it’s a good signal that people are getting practical value from them.

Once someone forks a repo and builds their own version, maintenance of that fork is on them. But if there’s clear demand – feature requests, recurring issues, or common use cases – I’m happy to keep iterating on the main repo and move it toward something more production-grade, with features closer to what you’d expect from commercial tools.

How do you see the future of legal AI developing: more firms building tools, or more buying the well-known platforms?

On the build side: yes, I expect more firms to build – especially for specialized workflows that only one team cares about, where vendors aren’t incentivized to build because the TAM is too small. On the buy side: I still don’t think we’ve seen the ‘Cursor for lawyers’ moment yet – the product that becomes an obvious, daily default for most lawyers. I think something like that will emerge, but it’s not fully there yet.

More broadly, I think more lawyers will start translating their know-how into agent-ready workflows – turning playbooks, checklists, negotiation patterns, and internal guidance into tools that AI can use more deliberately. You can already see early versions of this in the idea of ‘Skills’ for models like Claude to follow.

Looking further out, I think the biggest opportunity is in new demands and new markets – new modes of legal service that didn’t exist before. One idea I’ve been exploring is contract simulation: an app that “brings a contract to life” by spawning AI personas for each party and simulating how they’d argue a clause under different scenarios – so the contracting parties can see how the agreement behaves before something goes wrong, and fix vulnerabilities before they sign.

You can try out the apps here: Jamie’s Collection. That idea, something like ‘synthetic precedents’ – wasn’t really possible pre-AI. For novel, high-stakes deals with limited to no precedent, simulation could become a way to model risk. And it raises an interesting question: if vibe coding makes people focus on outcomes instead of code, do we move toward clients focusing on outcomes instead of clauses? In that world, the experience – how the contract plays out—becomes the real UI/UX of contracting, and that’s something AI uniquely enables. That’s something I am genuinely excited about and am exploring more.

Thanks Jamie and also thanks for all you do.