-
2010 onwards
Learning what the tools actually did
Large disclosure exercises were a core part of my early practice. At that scale, how you search, review, sample and visualise a collection determines how much work there is to do, as well as what you might miss. I was an early user of technology-assisted review and spent time understanding the methods behind the interface.
Within my teams, I was often the person who had explored the technology most closely. I clicked through the settings, tested the options and talked to the people supplying the software. I wanted to know how a review population had been selected, whether the method made sense and what would happen if we changed it.
On several occasions, I found that poorly conceived search terms had been applied in ways that brought unnecessarily large populations into review. Correcting the method could substantially reduce the work and the client’s bill. That was not always popular. It made the relationship between technical choices, legal work and cost very tangible.
-
ChatGPT’s first release onwards
A different kind of tool to investigate
I was fascinated by generative AI and became a heavy user from ChatGPT’s first release. I spent time testing how it responded to legal questions, where it lost track of an argument and how much I could improve the result through instructions and sustained interrogation.
I developed detailed protocols for sources, competing arguments and missing information. But the familiar questions remained: what had the system actually done, what had it left out, and how could I tell? Eventually, improving the instructions was no longer enough. I wanted to understand and change the process around the model.
-
Spring 2025
From copying code to making working software
I started by asking ChatGPT to generate code, then pasting it into files and trying to make the software run. I moved on to Cursor, Claude Code and Codex as I learned how to work directly with a codebase.
I did not arrive with a computer science background. I learned by deciding what I wanted a program to do, trying to build it, finding out why it failed and working through the underlying structure. Understanding the architecture became increasingly important: how the parts communicated, where information was stored and which component was responsible for a result.
Building also exposed shortcuts that were much harder to spot in a written answer. A model could quietly substitute dummy data for the facts it was meant to use, then announce that the task was finished. A working screen was not enough to tell me whether I had built the right thing.
23 September 2025: what coding taught me about supervision ↗
-
Second half of 2025
Learning from other people’s systems
As I shared more of this work, vendors and startups began to take an interest. I volunteered time to beta-test products because I wanted to learn: to see how other people approached the same problems, question their assumptions and understand the trade-offs they had made.
Legal experience gave me a way to test the products against the work they were intended to support. Building my own software helped me ask more specific technical questions. Each informed the other.
-
Alongside that work
Running the models myself
I experimented with local AI on a Raspberry Pi and began building custom retrieval systems. I later bought an EVO X2 with 128 GB of unified memory to run more demanding models locally.
Retrieval brought me back to questions I recognised from disclosure. How had the documents been divided up? Which passages did the search return? What did the ranking or the limit on results exclude? A model could accurately describe everything it had received and still miss the document that mattered.
Running the components myself made those choices visible. It also meant learning the less visible work of connecting services, managing resources and keeping a system running. I wanted to understand the plumbing and wiring well enough to inspect and change it.
-
My current practice
Engineering hygiene
As I became more capable of building software, I became more interested in the flaws in AI-assisted code. A demonstration can look convincing while the underlying system handles permissions badly, loses information or fails when someone uses it in an unexpected way.
I developed what I call my hygiene method: applying engineering principles to the way I direct, inspect and test AI-assisted work. That includes keeping responsibilities clear, testing known failure cases, examining how data crosses boundaries and checking what happens when a component fails. Security, integration and the demands of deployment within an organisation are central to that work.
I study the architecture and the implementation techniques. I want to understand why the system should behave as intended, and then test whether it does. That is ongoing work; generating code does not establish that it is robust or secure.
-
Frontier work · ongoing
A home server for local agents
The EVO now runs Linux as a headless AI server in my home. It provides the local model infrastructure for a team of custom agents I have built. The main project is Clint, whom I deployed in LegalQuants WhatsApp groups to interact with other participants and their agents. He now lives in Slack, working as my personal assistant and helping administer my games.
I have spent a great deal of time improving its memory, tool use and ability to research questions independently. I am also developing self-review and what I call “dreaming”: looking back through attributed records for unresolved questions, conflicts and connections worth investigating.
This is where I push the boundaries of my own work. I want an agent that can identify a useful next question, investigate it and help improve the system around it. The hard part is establishing whether it has learned something useful or simply produced a convincing explanation. Clint has gone through repeated trials and revisions, including approaches I have set aside when they failed.
The purpose is both practical and professional: an assistant that helps me run my projects, and direct experience I can draw on when advising clients about agents. It connects the technical questions about memory, evidence and permissions with the judgment needed to decide where these systems are useful. The same work informs my interest in tools that help people learn and navigate problems for themselves.
-
What comes next
More people able to build
For serious deployment, I still see a need for experienced engineers to advise, review and sign off. My expectation is that advanced users will soon be able to undertake much more of that work independently, even without a computer science background. That is a view about the direction of the technology, not a reason to skip the checks a system needs today.
The part that interests me most is what this could make possible for people who understand a problem but have never had the means to build a solution. It is why teaching has become part of my work, and why I want to do more in education and access to justice.
The record as it happened
The LinkedIn archive brings together posts about the experiments, setbacks, teaching and released tools. It starts in June 2025; the longer history above is my account of the work that led there.
Read the dated posts → · How I think now → · Legal experience →