Start with your own pain, not the tool. Before you open any AI tool, look at your week and find the manual, repetitive work that eats your hours. Where do you click three times to do the same thing that does not need your legal judgment. Natalie called this a pain audit, and it gives you a real problem to solve instead of a blank screen. Starting from your constraints, whatever your team is allowed to use, keeps the first step manageable.

Treat prompting like onboarding a junior lawyer. The most useful reframe was thinking of a prompt as explaining a task to a new associate. You describe what you want and how you want it delivered. Kevin built a working indemnification visualizer from one paragraph-long prompt written exactly that way. The depth of your contract knowledge is what turns a generic output into a useful one, so put it in the prompt.

Your contract knowledge is the scarce resource now, not coding. The bar to building something has dropped, which means the advantage shifts to whoever knows what good looks like. Lawyers are translators by training, taking hard concepts and putting them in words people cannot argue about. The model now handles the translation into code. The part that is left is the part we are already good at.

Use Claude Cowork for a fast first-pass review. Cowork ships with a legal skill, and you can upload your own materials so the review reflects your standards instead of generic guidance. Kevin ran it on an open-source agreement and got flagged items and a redline with no customization. Treat the result as a starting point, not a finished review. It is closer to a capable junior than a senior reviewer.

Build tools and playbooks without writing code. Kevin pointed Claude Code at a folder of planning documents and got a working app in about two hours, writing and reviewing no code. He generated NDA playbooks the same way, using a model playbook and an agreement as inputs. These are little tools that save you time, not enterprise products, and that is exactly why they are worth building.

Annotate your playbooks so juniors do not misuse them. A bare list of past concessions handed to a junior lawyer is a trap, because they will accept bad terms simply because the terms appear in the playbook. Good playbooks need good-better-best annotations and some never agains. This holds whether or not AI generated the playbook, so build in the context before anyone relies on it.

Decide where you actually need AI and where you do not. In the indemnification tool, the AI does narrow parsing work rather than generating clauses, which keeps the output predictable. Where you have a clause library, use it directly instead of asking AI to generate language. Choosing what stays deterministic is part of designing a tool you can trust, and it also makes the output easier to defend later.

Match your privacy setup to your data. Confidentiality topped the audience poll on barriers, and the answer is that privacy is solvable at every level. A local model can run a tool with nothing leaving your computer. A paid subscription with training disabled covers most organizations. A dedicated cloud instance lets a team send privileged material through these tools, so pick the posture your work requires.

Review the output the way you review a junior's work. As the output improves it gets more dangerous in one way, because it states everything with confidence and hides the missed nuance that used to be obvious. Keep a human in the loop on every task. Kevin now puts the quality closer to a mid-level associate, which means more capable, not more trusted. You still sign your name to the work.

GitHub is more approachable than it looks. If a project tells you to go to GitHub and you usually bail, you can skip almost all of it. Open the Claude app, go to the code tab, and ask Claude to pull the code from the URL and get it running. A good repository includes a readme that Claude reads on its own. Open-source readmes also let anyone see how a tool was made and decide how much to trust it.