Career Development and Wellness: Planning on AI: “So How Do I Build My Own?”

When attorneys and planners imagine their ideal AI tool, they are not imagining a smarter search engine. They are imagining something closer to a very capable associate who has read every document their firm has ever produced, has internalized their drafting preferences, understands the client base, and can actually help build things rather than just retrieve information.

The technical concept that makes something like that possible is called RAG, which stands for Retrieval-Augmented Generation. Strip away the jargon, and it means the AI is allowed to read your materials before it answers.

A generic chatbot responds based on what it was trained on, which was built from the internet and whatever datasets the developers assembled months or years ago. A RAG system responds based on your documents. Your templates. Your state-specific provisions. Your internal memos.

Think of the difference between asking one associate a question about GRATs and asking another associate who has spent the last year reading every GRAT your firm has ever drafted. That second person is not just smart, but also is contextual. She knows how your partners think. She knows which boilerplate your firm actually uses, rather than what the forms books suggest. That is what people want.

The gap between what attorneys want and what exists has been frustrating for a simple reason: building a genuine RAG system, one that ingests your firm’s documents, understands the relationships between them, and surfaces the right information at the right moment, requires software development. Until very recently, there was no path to that for a solo practitioner or small firm without either a significant technology budget or access to a large institution’s IT department.

Some of the major firms and financial institutions have built internal AI tools. But most of those are more accurately described as enhanced search functions. They can tell you where a document lives or provide a summary of its contents, but are not working alongside you.

Third-party legal tech vendors have not filled this gap in a comprehensive way. Most vendors in the legal AI space are focused on delivering their own curated document libraries and standardized workflows, which makes sense as a business model. Custom integration working, ingesting a specific firm’s documents, learning their internal processes, and maintaining a system tailored to one practice is time-intensive and does not scale well. Even when vendors undertake that kind of project, the relationship is typically transactional rather than ongoing. As priorities shift and staff turnover, custom systems can drift without consistent maintenance. This isn’t a criticism of vendors. It is just a recognition that their economic incentives do not naturally align with building and maintaining truly personalized systems for individual practices.

The result has been a kind of structural inequality. The tools that would actually reflect how your practice works have been available only to firms with resources that most attorneys will never have.

Most of the AI tools attorneys have tried so far are conversational. You ask. It answers. You paste into a document. You get a summary. The interaction begins and ends in a single exchange.

An agent is given an objective and permission to act. Instead of: “Summarize this trust.” It becomes: “Analyze this client situation. Identify the planning issues. Pull the relevant clauses from our preferred templates. Flag the state-specific provisions that need attention. Draft a preliminary strategy memo. Then show me what you did and why.”

This isn’t a better search engine; it’s participation in the actual workflow. The agent is not waiting to be asked each question in sequence. It is moving through a process on its own and checking back in at meaningful decision points.

Consider a probate practice handling a steady volume of estate administrations. An AI-assisted workflow today can extract key information from a will, death certificate, and financial statements in minutes, identifying beneficiaries, fiduciaries, dispositive provisions, and potential issues before the first client meeting. In a real estate practice, AI tools can triage hundreds of leases or purchase agreements, flagging nonstandard indemnification clauses, assignment restrictions, or environmental provisions almost instantly. These are not hypothetical capabilities. They are incremental efficiencies available now, and they compound when integrated into daily workflow rather than used as occasional experiments.

We are not fully there yet in terms of what is available off the shelf for law firms. But the infrastructure to build something like it has gotten dramatically more accessible. That’s where Claude Code comes in.

Claude Code is a product from Anthropic, the company behind the Claude family of AI models. On the surface, it is a tool that lets software developers write, test, and debug code through a natural language interface.

Developers have responded strongly to it, not just because it helps with individual lines of code. Claude Code understands entire projects. It can reason through a problem across a whole codebase, refactor systems, and help build functioning applications, not just autocomplete snippets. Developers who might have spent two weeks building a working RAG pipeline, testing it, debugging the retrieval logic, and deploying something usable can now work through a comparable project in a fraction of that time.

That matters for the legal industry for a specific reason. The bottleneck has never been imagination. Attorneys and planners who use these talks as a forum to describe what they wish they had are not short on vision. The bottleneck has been implementation. Building the tool has required technical skills that most practitioners simply do not have and are not going to acquire through a weekend of reading.

What Claude Code does is compress the distance between having a clear idea of what you want and being able to build it. It does not eliminate the distance. There is still real learning involved. But the ceiling for what a determined non-programmer can accomplish has moved.

Solo estate planners with no development background, a clear sense of what their practices need, and a genuine willingness to experiment are now working in a different environment than they were 18 months ago.

To make this concrete, here is a rough version of how this could work for a small estate planning practice. This is not a technical blueprint. It is an illustration of what the process actually looks like when someone without a development background decides to try.

First, start with your core materials. Templates you actually use. Internal checklists. State-specific addenda. Memos you have written explaining how you approach particular planning scenarios, like why you prefer one trust structure over another for a closely held business owner, or how you think about generation-skipping allocations for a particular family profile. These do not need to be organized perfectly. They need to exist somewhere accessible and be specific enough to reflect how you actually work, not just generic forms you downloaded somewhere.

Second, use Claude Code to build a simple RAG pipeline. In practice, this means building a system that reads your documents, breaks them into indexed sections, and retrieves the relevant sections when you describe a client situation. You describe what you want in plain language. Claude Code helps you build it, explains what each piece does, and helps you debug when something is not working. You are directing the process more than executing it. That is a different relationship with software development than most attorneys have ever had access to.

Third, create a structured intake prompt. This is essentially a template for how you describe new client situations to the system: asset mix, family structure, planning goals, state of domicile, relevant tax considerations, and any existing documents or prior planning. The more thoughtfully you design this prompt, the more useful the output. This is actually where your expertise as a planner matters most. You already know what questions drive the analysis. You are just writing them down in a way the system can use.

When a new client situation comes in, you run it through the intake prompt. The system pulls from your document library and produces a draft issue list, a preliminary strategy memo, and a base document built from your templates. Not a finished work product. A first draft that reflects your approach rather than a vendor’s generic workflow.

Then you review it. You correct what it got wrong. You note where the retrieval missed something important, and you figure out why. You refine the prompt. Over several iterations, the system becomes a more accurate reflection of how you think about planning problems.

The first version of this will not be impressive. It will feel rough, and it will make mistakes you would not make. That is not a reason to stop. Every associate you have ever trained made mistakes in the first month. The difference is that this system does not bill hours while it is learning.

The larger question the legal industry will need to reckon with is not whether AI can assist with estate planning or contract drafting. That question has already been answered. The question is who gets to decide what the AI knows about how planning should actually work. Right now, that defaults to whoever builds the tools that get widely adopted. The vendors moving into this space are making choices, whether intentionally or not, about which planning approaches get encoded, which documents become templates, and which workflows get treated as standard. Practitioners who are building their own systems, however imperfect, are participating in that answer. Practitioners who are waiting for a vendor to solve it are ceding that ground.

That matters more in estate planning than in most practice areas, because estate planning is inherently personal and contextual, resisting standardization. The value a good planner adds is not in knowing what a GRAT is. It is in knowing which clients should use one, how to structure it given a particular family dynamic, and how to explain it in a way that a specific client will actually understand and be comfortable with. None of that lives in a generic document library. It lives in the accumulated judgment of the practitioner. The question this moment is asking is whether that judgment gets captured somewhere useful.

For more information see Ross Burch “Career Development and Wellness: Planning on AI: “So How Do I Build My Own?” American Bar Association, May 1, 2026.