July 2026

Build the app. Just check it first.

Last week I logged into a law firm's internal tool. It was a neat little daily capacity tracker. Staff marked themselves as free, flexible, committed or on leave, and everyone got a live picture of who could take new work. Useful, clean and solves a real problem.

I accessed the tool by Googling the law firm. No password. No sign-on. No permission, either. I was able to select a lawyer's name from the list and see their data, edit their capacity and submit as them. Anyone with the link was anyone on the list.

The tool is what happens when you supervise the idea but not the engineering.

Building software just got cheap. Spinning up your own tool stopped being a six-month project and became an afternoon. It means the lawyer who actually understands the workflow can finally build the thing that fixes it, instead of filing a feature request into the void.

But cheap-to-build is not the same as cheap-to-build-safely.

We as lawyers already know how to handle AI. You'd happily get a model to provide case summaries or draft submissions, but you wouldn't stand up in front of a judge and read them out without checking every line and confirming every authority. We've all now watched colleagues get torched for citing cases that never existed.

The discipline isn't "don't use AI", it's "supervise the output." AI is a freakishly capable junior: fast, tireless, never complains, and occasionally, confidently, completely wrong. You don't fire the junior. You check their work before it goes out the door.

This exact same discipline applies to the tools you build, not just the text the AI generates for you.

Take that dropdown login. To a lawyer it looks fine … you pick your name, your data loads, job done. To anyone who's built software, "the user just tells us who they are and we believe them" is the kind of thing you catch in the first five minutes. It's the equivalent of a fabricated citation: invisible if you don't know to look, obvious the moment someone does.

But two minutes in, I discovered a second issue, quieter and worse. The tool's back-end ran through a Microsoft Power Automate flow, and the signed URL that authorises it, signature token and all, was sitting right there in the page, readable by anyone who opens their browser's developer tools.

The signature is the key, and it's taped to the outside of the door. In principle, someone outside the firm could copy it and replay the flow. What that flow is allowed to do, I didn't test (since poking at it could touch live data or stray into unauthorised-access territory, and that's a line you check before you cross … not after) but "we don't know what it can reach" is not a comfortable sentence to write about a family-law firm's internal system, given what those firms hold.

None of this is a reason to stop. The fixes here are all solved problems — real authentication against the firm's existing Microsoft login, moving the sensitive call to the server so the key never reaches the browser, rotating the exposed URL, a five-minute check of what the flow can actually touch.

The distance between this tool and a safe one isn't money or ambition. It's discipline and a bit of expertise.

So: build the thing. Please build the thing!

The firms that win the next few years are the ones experimenting right now, not the ones who decided "AI is unsafe" or that "legal tech is dead". Just run your tools through the same instinct you already trust with everything else AI touches … "would I rely on this without checking it?" — and bring in someone who can read the code the way you read a contract.

July 2026

The Legal Tech Space

The conditions that make coding agents so powerful (i.e. instant feedback, obvious failures, high failure tolerance…) are precisely the ones the legal industry lacks. Law is discretionary. Outcomes are often contested rather than verifiable. The "right answer" depends on the jurisdiction, the presiding officer, and other extenuating circumstances that are not contained in the documents/material (the Judge not believing the evidence given by a party in the witness box). Confidentiality and privilege constraints limit how data can be used. Legal work demands near-total accuracy in a way most domains don't. A fabricated citation or misstated fact can be fatal to a case and expose the lawyer to sanctions, malpractice claims and/or disbarment.

However, while the application of law is discretionary and contested, the framework it runs on is highly standardised. Legislation, court rules, forms, and procedural steps are consistent across thousands of practitioners. It's this standardised scaffolding that overlaps with what coding agents handle well, and where the leverage opportunities sit. These examples include:

High volume, document heavy and pattern based work

Large portions of legal practice (disclosure review, document summarisation, contract analysis) are essentially extraction, classification, and synthesis across documents. These are the legal equivalent of the repetitive, pattern-rich problems that coding agents handle well … The same asset categories surface across every financial disclosure. The same event types recur across every parenting matter chronology.

Language, translation and communicating ideas

As per the above, the transformer's native strength is translation. Law, at its core, is a constant translation exercise. Translating a client's account of what happened into pleaded facts. Translating legislation, contracts, and court orders into plain English a client can actually follow. Translating a 40-page judgment into a one-page client advice. The same model that converts Python to JavaScript can convert a rambling client narrative into a structured chronology, or a legal argument.

Procedural and structural conventions

Forms follow the same structural patterns matter after matter. Legislation, court rules, pre-action procedures, disclosure obligations, pleading requirements, evidentiary standards, sentencing principles, statutory tests, these are not bespoke to each matter, they are the same framework applied to different facts. This is the legal equivalent of the well-documented conventions that coding agents thrive on, the rules are public, the templates are stable, and the same drafting problems are being solved across thousands of practitioners every day.

Research and verified retrieval

The right architecture is not "ask the LLM what the law says", it is retrieval over a verified database (AustLII, the legislations, the firm's own precedents etc.). The model then synthesises and connects rather than recalls. The verification step against a real database is the legal equivalent of the build-test-review loop. A cited case either exists or it doesn't. A section either says what the model claims or it doesn't. This restores the feedback loop that pure-LLM legal research lacks, and turns hallucinated authorities from invisible failures into obvious ones.

Engineering the practice

Each of these four leverage points presupposes that the underlying material (i.e. the precedents, the templates, the firm's data base and knowledge) is structured enough for AI to operate on. Most firms aren't there yet and this is where the legal industry has the most catching up to do … and the biggest opportunity.

Software's "engineering of engineering" did not happen by accident, it was a deliberate decades-long effort to standardise tooling, processes, and conventions across firms, and to build the shared ecosystem of skills, rules, and tools that let coding agents "stand on the shoulders of giants". Legal practice remains stubbornly idiosyncratic. Every lawyer and firm has bespoke templates, preferred precedents, and their own matter management workflows.

The firms that will benefit most from AI are the ones that invest now in standardising their own internal processes, building structured precedent libraries and codifying their house style into machine-readable instructions (a legal equivalent of Agents.md). Done at industry scale, this is also how the legal industry eventually builds the equivalent of an open source … a shared corpus of skills, prompts, and tooling that turns the profession's collective experience into infrastructure every practitioner can build on. Until that happens, every firm is rebuilding the wheel, and paying full price for AI tools that don't know how their legal work actually gets done.