The bottleneck was never the lawyers

Walk into any small or mid-sized firm and ask them what they wish their software did. You'll get an immediate, vivid answer. "I want intake to know about every conflict before I see the file." "I want my settlement spreadsheet to alert me when a statute date is 30 days out." "I want a document automation that actually understands which jurisdiction we're in." These aren't moonshots. They're a Tuesday afternoon's worth of work — for a software engineer who already knows your practice area.

But software engineers don't know your practice area. They never did. The legal tech market has been a 30-year exercise in engineers building the things engineers thought lawyers needed, charging $40k a seat for it, and being correct in a narrow corner of the field while missing every interesting opportunity in the rest. The bottleneck wasn't ambition or capital. It was translation.

What actually changed in 2024–2026

The thing that changed isn't "AI is smart now." The thing that changed is that an AI system can now read a precise English-language description of a piece of software and produce a working, reasonably structured implementation of it. Not perfectly — but close enough that a non-engineer who can describe what they want, clearly, can iterate to a real working tool in an afternoon.

This is a strange and specific superpower, and it doesn't matter for most professions. A surgeon's skill isn't "describe a surgery in detail." A pilot's isn't "describe a flight in detail." But a lawyer's job — actually, the core of a lawyer's job — is to take an ambiguous human problem and reduce it to a precise, structured, defensible written description. You already do this every day. It is the entire skill.

What this is not

It is not "replace your associates." It is not "have AI do the legal work." Anyone selling you that is either dangerous or selling you something other than what they're describing. The hallucination risk is real. The privilege risk is real. The unauthorized-practice risk is real. We have a whole section on those questions and you should read it.

What it is: building the small operational tools that don't justify a $40k vendor contract or a six-week engagement with a consulting shop. The intake form your firm has been using for nine years that doesn't ask the three questions you wish it asked. The matter-status dashboard you've been duct-taping out of Outlook calendar entries. The settlement-tracker spreadsheet that doesn't know what a statute of limitations is. These are tools you can have working, today, for the cost of a couple of subscription seats.

Why now and not in two years

Two reasons it's now and not later. First, the lawyers who start now will, in eighteen months, have built up a small portfolio of tools that have iterated through real client use. The lawyers who wait are going to walk into a market where their competitors have those tools and they don't. The compounding is asymmetric.

Second, the bar associations are catching up. ABA Model Rule 1.1's technology-competence comment has been adopted in roughly forty states. Several state bars have issued formal opinions on AI in the last eighteen months. The window where "I'm not technical" is a defensible answer is closing. "Reasonable competence in the benefits and risks of relevant technology" is a duty, not an aspiration.

What to do this week

  1. Pick the dumbest, most-repeated, most-annoying piece of paperwork in your practice. The one that wastes time on every single matter.
  2. Describe it out loud to a colleague who doesn't do your work. Force yourself to be precise about what fields it has, who fills it out, what happens to it next.
  3. Open the scoping conversation here, paste that description in, and see what comes back. The tool you talk to will ask you the questions a good engineer would have asked.
  4. If you don't like what it comes back with, refine. Building software used to mean six weeks; now it means an afternoon of conversation. Treat it that way.