James Cockburn

UK Solicitor · Builder of Legal AI Tools

I'm a practising litigator who builds AI tools for legal work. If you're paying for an AI "wrapper" over Claude or GPT, you should consider building it yourself—same capabilities, more control, and you actually understand what it's doing.

Vibe Coding

Building with AI, Not Learning to Code

The first thing you realise about these models is that they don't come with instructions. Those of us curious about what they can and can't do have to learn through trial and error. It's strangely the inverse of everyone's fear about AI replacing human thought—in the AI sphere itself, you have to take the journey into the unknown step by step.

That journey led me to vibe coding: AI-assisted development where you describe what you want in plain English, and the model proposes the implementation. You scope, steer, test, and iterate. I've built hundreds of tools this way—professional litigation software, home automation, games for my kids—without having learned to write a single line of code.

Many legal AI products are essentially UI layers over the same models you already have access to. If you're paying for a wrapper, you're paying for someone else's prompts and interface. The same capabilities are available to you directly—with more control and transparency about what's actually happening.

The Process

Start by scoping your idea in your normal AI provider—ChatGPT, Claude, Gemini. Describe what you want in plain English and ask what would be involved. If your idea is feasible (it almost always is), move to an IDE like Cursor where you can use an AI chat interface to build software from the ground up. Your job becomes reading the conversation and steering toward your goal, not writing syntax.

The real skill is document ingestion and context engineering—structuring what the model sees so it can reason effectively. This matters more than clever prompting. A well-architected context window beats a clever prompt every time.

The Discipline Problem

AI can break things faster than you can fix them. Without human oversight, models rapidly optimise the wrong thing. I've watched AI make rapid, impressive progress on a project—rewriting sections, adding features, refining structure—while gradually losing sight of why it was doing any of it. The end result looks smart, even impressive, but it's fundamentally broken.

In litigation, this manifests as elegant submissions that subtly drop your strongest point, briefs that confidently misstate the law, or analysis so elaborate it misses the crucial fact. Bad code usually fails visibly. Bad legal output can be fluent, plausible, and wrong.

The models simulate discipline without enforcing it. I've tested every major ChatGPT model over the past two years, alongside Claude, Gemini, and dozens of open-source alternatives. They follow custom protocols until they don't, then pretend they still are. Protocols can be taught and remembered. They can be performed. But none are verified against the model's own output. The model will quote your rules, apologise for breaches, simulate audit and recovery—then bypass everything on the next failure. This is performance, not enforcement.

The trick is to use AI like any other power tool: carefully, iteratively, always watching what it's actually doing. Make small changes. Step back. Reassess. Don't get pulled into the rabbit hole. Complexity feels impressive, but clarity wins cases.

Local AI

Privacy, Control, and the Limits of Context

Local AI is a different category from vibe coding—more advanced, focused on balancing privacy with model sophistication. The case for running models locally isn't ideological. It's risk management.

If your documents leave your environment, that's a different risk profile than local processing. For legal work involving sensitive client data, "no cloud" is often the cleanest route to defensible confidentiality. A controlled retrieval pipeline is easier to supervise than a general-purpose assistant that implicitly "knows everything". Self-built tools can be designed so uncertainty is obvious and source grounding is mandatory—vendor tools often fail silently.

What Becomes Possible

I've built a fully working local RAG system with unlimited document ingestion, summarisation, chronology extraction, and a query engine powered by large local LLMs. Totally offline, detailed and fully referenced responses on consumer hardware. I develop and deploy across both Linux and Windows—self-taught from first principles, not formal training. The architecture is fully swappable—different models for different tasks, some optimised for speed, others for reasoning depth.

This wouldn't have been possible even a few months ago for someone without traditional coding experience. The field moves that fast.

The Architectural Challenge

Local models are improving rapidly, but context remains limited on realistic hardware. This creates predictable failure modes: misattribution, over-confident synthesis, improvised reasoning from narrow windows. The answer isn't bigger models—it's architecture.

My systems operate at two levels: a case graph layer with stable, verified representations (party positions, issues, chronologies), and a raw chunk layer with the underlying sources. The goal is to prevent the model from inventing global understanding when it only has local visibility. Structured retrieval with mandatory source grounding, not open-ended generation.

The ideal system isn't one that "never hallucinates"—that's unrealistic. The ideal system prevents pure invention, makes uncertainty obvious, and allows rapid verification. In legal work, supervision is the point. The human remains essential.

Custom Protocols

A Year of Building AI Governance from Scratch

Standard prompting doesn't work for legal AI. You can tell a model to cite sources, verify authorities, and flag uncertainty—but it will simulate compliance rather than enforce it. After a year of daily testing across frontier models, I designed a complete protocol architecture from first principles: a three-layer system that forces structured behaviour where the model's default is performance.

These protocols are entirely self-designed and self-tested. No vendor templates, no borrowed frameworks. Every rule exists because I watched a model fail without it.

The Architecture

The system operates across three layers. Layer 1 (Governance Core) handles fundamental integrity: protocol conflicts, memory limits, hallucination containment, citation verification, and session state. Layer 2 (Global Operating Rules) governs daily operation: source hierarchy, authority acquisition, case handling, output structure, and mandatory verification triggers. Layer 3 (Domain Modules) contains jurisdiction-specific rules—currently UK civil procedure—with renumbering audits and conditional order handling.

Key Mechanisms

Hallucination containment freezes propagation of suspect claims. The model must replace with verified sources or mark content explicitly as unverified. If a prior step was influenced, it issues a correction note. Citation verification treats all new authorities as draft until verified against primary sources—statute sites, BAILII, official reports. Secondary sources are permanently marked.

Source hierarchy enforces primary over secondary: no quotes or doctrinal use without verified authority. The Interrogation Escalation Protocol triggers when I challenge any fact, law, or inference—the model must restate the proposition, show its evidence chain, verify against primary sources, and correct or mark as disputed.

Why This Matters

Off-the-shelf legal AI has no equivalent. Vendor tools promise accuracy but fail silently. My protocols make failure visible, force verification at defined points, and prevent the model from generating confident nonsense. The human remains in control—not because the model chooses to defer, but because the architecture requires it.

Legal Practice

Ongoing

LegalTech Advisory

International Consulting

Advising prospective founders, startups, scale-ups, and established legaltech providers on AI product development, risk architecture, and practical implementation challenges.

2020–Present

Senior Associate

Harcus Parker

Lead solicitor on civil fraud, competition litigation, and group actions. Successfully defended CICC's funding structure through CAT, Court of Appeal, and Supreme Court—ending a two-year challenge to litigation funding in collective proceedings.

2018–2020

Associate

King & Spalding

Internal investigations for UHNW individuals and multinationals.

2014–2017

Associate

Curtis, Mallet-Prevost

Lead English solicitor on £100m+ international arbitration and investor-state disputes.

2008–2014

Earlier Career

Joseph Hage Aaronson · Quinn Emanuel · Gibson Dunn · Trowers & Hamlins

Contentious insolvency, commercial disputes, investigations.

Recognition

"Exceptionally bright – a really good lawyer" — Legal 500, 2025

Lawyer in the NewsLaw Society Gazette, July 2025

Frequently Asked Questions

Do I need to learn to code to build AI tools?

No. AI-assisted development lets you describe what you want in plain English and steer the model toward implementation. The skill is in scoping, testing, and iterating—not writing syntax. That said, you need to understand what's happening well enough to catch when it goes wrong.

What's the difference between vibe coding and using local models?

Vibe coding is a method—AI-assisted development using any model, cloud or local. Local AI is about where processing happens: on your own hardware, with no data leaving your environment. You can vibe code with cloud APIs, or you can vibe code locally. They're complementary, not competing.

Why would I build instead of buying a legal AI tool?

Many commercial tools are UI layers over the same models you already have access to. Building yourself gives you control over the architecture, transparency about what's actually happening, and the ability to design for your specific workflows. It also forces you to understand the failure modes.

How do you prevent hallucinations in legal AI?

Architecture, not prompting. Structured retrieval with mandatory source grounding. Two-tier systems that separate verified representations from raw source material. Designing for uncertainty to be visible rather than hidden. And relentless human oversight—the model will never reliably verify its own output.

Is local AI sophisticated enough for real legal work?

Increasingly, yes. Context limits remain a constraint on consumer hardware, but architectural solutions—chunked retrieval, multi-model pipelines, structured summaries—can compensate. The tradeoff is privacy and control versus raw capability. For many use cases, that tradeoff favours local.

Contact

Whether it's a complex dispute, an AI project, or questions about building your own tools—I'm happy to talk.