Vibe-Coding Legal AI: Jamie Tso on Build vs Buy, Security, and What's Next
Clifford Chance senior associate Jamie Tso has been quietly building sophisticated legal AI apps on his own. His approach - vibe-coding: fast, focused, and practical - challenges the assumption that firms must buy everything off-the-shelf.
Here's the core question for legal leaders: Is building your own AI a viable alternative to buying? And if so, where do you start without creating a support headache?
From trainee pain points to internal adoption
Tso's journey started with a repetitive task: mapping retail fund prospectuses to Appendix C of the Unit Trusts Code. Early experiments with TensorFlow, PyTorch, and BERT showed promise but weren't production-ready without the right tooling and support.
Things shifted when firmwide access to no-code tools like Microsoft Copilot Studio and Power Automate gave him a playground. He built document-processing workflows that spread internally, took requests from teams globally, and shipped tools colleagues actually used.
Why he hasn't launched a startup (yet)
He's motivated by solving real problems and shipping useful tools. If building a company or joining a major AI team gives him more leverage to do that, he'll consider it. Until then, he's shipping, learning, and sharing.
Can firms build instead of buy?
The ground is shifting. As LLMs write more of the "first draft" code and coding agents improve, the cost of building high-quality internal tools drops. That nudges teams toward just-in-time software: build for a specific workflow, replace it when the workflow changes, and avoid long maintenance cycles.
Not every tool needs to scale to 1,000 users. Many practice groups have their own habits, so a smaller, well-fitted tool can deliver more value than a one-size-fits-all platform.
On security and privacy, strong patterns already exist: automated scanning, dependency checks, and controlled deployment pipelines. For example, code scanning with tools like Semgrep helps standardize risk checks so builders can move faster without cutting corners.
Build vs buy: a quick decision checklist
- Build when the workflow is specialized, the user group is small to medium, and you need tight iteration loops with direct feedback from lawyers.
- Build when data sensitivity or integration with internal systems makes vendor onboarding slow or complex.
- Buy when the capability is foundational (used widely across the firm), requires 24/7 support, or must meet strict audit and certification expectations out of the box.
- Buy when change management and training at scale are the primary hurdles and a proven product shortens that path.
Why open-source building blocks matter
As legal AI products converge on similar features, open-source equivalents help everyone. New builders don't have to rebuild the basics, and firms can adapt tools to their workflows, audit the code, and avoid overlapping subscriptions. Clients benefit as shared infrastructure lowers costs and speeds up delivery.
Can firms use Tso's tools today?
Individual lawyers can run them locally as-is. A firmwide rollout usually needs hosting, user management, security gates, and support - none of which are conceptually difficult, just necessary for scale.
His open-source repos have been forked over a hundred times. Teams are using them end-to-end or as components inside other tools. If demand is clear - recurring use cases, feature requests - he continues to iterate the main repo toward production-grade stability.
What's next for legal AI
Expect more in-house building for niche workflows vendors won't prioritize. Also expect a general-purpose "daily driver" for lawyers to emerge - the default interface people open every morning. It's not fully here yet.
More lawyers will translate know-how into agent-ready workflows: playbooks, checklists, negotiation patterns, and internal guidance that AI can execute consistently. That shift favors deliberate, repeatable processes over ad hoc knowledge in people's heads.
Tso's frontier bet: contract simulation. Spawn AI personas for each party, stress-test clauses across scenarios, and expose weak points before signing. Think "synthetic precedents" for novel, high-stakes deals where past data is thin. The focus moves from drafting clauses to engineering outcomes - the real UI becomes how the contract behaves.
How to get started without breaking things
- Pick one painful workflow with clear boundaries and measurable outcomes (hours saved, fewer handoffs, error reduction).
- Prototype fast with no-code where possible; ship to 3-5 power users and iterate weekly.
- Lock down security early: code scanning, dependency checks, data scoping, and access controls (add a tool like Semgrep to your pipeline).
- Decide build vs buy with the checklist above, not by defaulting to either path.
- Convert playbooks into structured prompts, guardrails, and decision trees so agents can follow your firm's way of working.
- Track outcomes and retire tools that no longer fit - disposable software beats bloated shelfware.
Upskill your team
If your practice is moving from talk to implementation, structured upskilling helps lawyers turn playbooks into working automations. See practical options by role here: AI courses by job.
Bottom line: vibe-coding won't replace every platform, but it gives legal teams a new lever - build small, ship fast, and focus on workflows that actually move the needle.
Your membership also unlocks:
