The two skills software has always needed

Every piece of working software is the product of two skills. One is the technical work — knowing the syntax, the libraries, the deployment plumbing. The other is specification — knowing precisely what the thing should do, who uses it, what happens when something goes wrong, and which edge cases will eat you alive. These are very different skills, and historically the same person rarely had both.

AI has not eliminated the technical work, but it has compressed it dramatically. What used to take a competent engineer six weeks now takes a competent engineer six hours, and what used to require a competent engineer at all now often does not. The bottleneck has shifted entirely to specification — to knowing exactly what should be built. That's the skill lawyers have spent their entire careers training.

What you already do that engineers struggle with

  • You take an ambiguous client situation and produce a precise written description of who, what, when, and what could go wrong.
  • You identify edge cases that haven't happened yet — the cases the contract has to cover even though the parties don't think they will.
  • You think in terms of obligations and consequences: if X then Y, but only when Z, except in the case of W.
  • You read other people's specifications (statutes, contracts, regulations) and find the holes.
  • You know the difference between what the client says they want and what they actually need.

Every one of those is, almost word-for-word, what a good software specification looks like. "If a user submits the form and a required field is missing, surface a specific error and don't lose what they've already typed." "When two matters share a party name but different addresses, flag for human review." These are if-then-but-when sentences. You write them in your sleep.

What you don't actually need to learn

  • How to write code. Genuinely. The AI writes the code. Your job is to describe what it should do, then check whether it did.
  • Specific languages, frameworks, or stacks. The names — React, Next.js, Tailwind — are background scenery. You will see them and you will not need to know what they do.
  • Server administration, deployment configuration, or any of the operational plumbing. Modern hosting platforms make this a one-click affair, and tools like BuildLegal handle it for you entirely.

What you do need to develop

  • Comfort with iteration. The first version of any tool will be wrong, in small but important ways. The skill is in noticing the wrongness and describing the fix precisely. You already do this with draft contracts.
  • Healthy skepticism about AI output. AI lies confidently. Your professional instinct to verify citations, double-check dates, and not trust an unsourced claim is exactly the right instinct here too.
  • A working mental model of what software looks like under the hood. Not how to write it — how it's shaped. Browser, server, database. Six articles in this Learn section covers the lot.

The asymmetry, in one sentence

An engineer who wants to learn family law has to spend three years in school, two years on the bar, and a decade in practice. A family lawyer who wants to learn enough to build their own software has to read a few thousand words and have an afternoon's worth of conversations with an AI.

The asymmetry is doing work for you, not against you. Use it.