In the last year or so, a quiet thing has happened inside law practice. Practicing attorneys — not vendor engineers, not law-firm innovation labs, not in-house product teams — have started shipping their own software.
We don’t mean attorneys filing JIRA tickets through their firm’s IT department, or sitting on a vendor advisory board. We mean lawyers opening a code editor on a Saturday morning, describing a problem to an AI assistant, and a few hours later having a working tool that solves a real piece of their practice. A litigation-finance partner builds a party-and-docket tracker because the off-the-shelf options don’t match how he underwrites. A practitioner who follows the Supreme Court closely builds his own calendar because the existing ones leave out the parts he cares about. A former product executive builds an AI system to scan agency outputs for patterns that shouldn’t be there. None of these people work at a software vendor. They are not building products to sell. They are building tools because they need them, and the cost of building them — measured in time, in money, in technical knowledge — has dropped to something a working professional can absorb on a weekend. That cost-curve change is the story. It is the difference between a trend and a curiosity.
The cost of building tools — measured in time, in money, in technical knowledge — has dropped to something a working professional can absorb on a weekend.
The Argument We're Not Having
It has become fashionable, in certain corners of the legal-technology market, to argue that AI is good for the engineers who build legal software and bad for the lawyers who use it. The reasoning runs like this: code has a tight feedback loop — compilers, tests, deterministic outputs, immediate failure when you get it wrong — and AI thrives in that environment. Legal work, by contrast, is judged by humans, often months later, with subtle distinctions (holding versus dicta, persuasion versus authority) that AI gets wrong in ways no lawyer ever would. Therefore: AI for our engineers, caution for your practice.
There is something right about this argument, and we want to say so plainly. AI-driven legal research — the case-finding, brief-drafting, holding-summarizing kind — really is hard, and the failure modes are real. Hallucinated citations, confidently misread holdings, dicta cited as precedent: these are not theoretical problems. Anyone telling lawyers that the legal-research AI is solved is selling something. We agree the caution is warranted.
But the argument quietly does something else. It treats AI use by lawyers as if it meant AI for legal research. That equation made sense two years ago, when those were the only AI tools most lawyers had encountered. It is no longer accurate. The lawyers in this series are not using AI to find cases or draft briefs. They are using it to write code — to build small, focused tools that automate the operational and analytical edges of their work. That is exactly the domain the same argument concedes AI is good at. The compiler that disciplines the vendor’s engineers is the same compiler that disciplines the attorney-builder’s weekend project.
The distinction matters because the prescriptions are different. “Be careful with AI legal research” is good advice. “Be careful with AI” — full stop — is a different sentence, and it misses something worth celebrating: the same advances making engineers more productive are drawing non-technical professionals — lawyers among them — much more deeply into the work itself, giving them practical means to realize ideas that used to wait on someone else’s roadmap. That is the change this series is documenting.
What's Actually Happening
The user-as-builder shift is not specific to law. Designers ship apps without engineers. Marketers stand up landing pages without web teams. Operations leads automate around their CRM without IT. The reason it took longer to reach legal is not that lawyers are less capable than designers — it is that legal practice’s risk profile is unusually high. The cost of getting something wrong is higher; the regulatory environment is denser; the data you’d want a tool to touch is more sensitive. Those reasons remain. They are why the tools featured in this series are mostly running on synthetic or public-record data, on personal laptops, with the writer’s own honest acknowledgment of where they would not yet trust their own work.
But the shift is happening anyway, because the underlying change — the cost of turning an idea into working software — is too large to be held back by industry caution alone. A senior attorney who used to need a six-week vendor contract to test a hypothesis can now test it on a Sunday afternoon. That is not a small change. It changes who gets to ask product questions, what kinds of questions get asked, and how quickly the answers come back.
The interesting question for those of us who build software for lawyers is what role we play once that is true. The honest answer, we think, is: we should make the lawyer-builder’s path easier, not harder. Where the lawyer-built tool is the right answer for the problem, the vendor’s job is to provide the boring infrastructure underneath — reliable data, hardened APIs, identity, security, audit trails, scale — so the lawyer-builder doesn’t have to reinvent any of it. Where the lawyer-built tool runs into the wall it eventually runs into — the security review, the multi-tenant requirement, the regulator’s audit, the malpractice carrier’s questions — the vendor’s job is to be the obvious next step rather than the obstacle.
We don’t think the user/builder line is fully gone, and we don’t think every problem is the right problem for an attorney to solve in code. We think the line has moved, and we think the people doing the moving deserve to be heard from in their own voices.
About This Series
Lawyers Who Code is a small number of first-person essays by practicing attorneys who have built their own tools. Each writer is telling their own story — what they built, why, what surprised them, and where their tool runs out of road. PacerPro’s job is to publish, edit, and frame. We don’t put words in the writers’ mouths, and we don’t ask them to comment on the legal-tech market. The work speaks for itself.
If you read all of these essays end-to-end, you will notice something the writers don’t have to say out loud: the people doing this work are not waiting for permission. They are not waiting for a vendor’s roadmap. They are not waiting for a managed service to ship the feature they need. They are building. The only honest response to that, from a company in our position, is to take it seriously — to publish what they have to say, learn from where their tools succeed and where they buckle, and make sure that when the work outgrows the laptop, there is a real grown-up version of the infrastructure they need waiting.
That’s what this series is for.
