Is Claude Code reliable for law firms?
A practical guide for legal operations teams: what Claude Code does brilliantly, where its reliability breaks down for back-office work, and how to think about automating the firm without getting burned.
AI has arrived in the law firm, and it's no longer just about drafting. Operations and administrative teams, the people who run intake, filing, billing, and the inbox, are being asked whether tools like Claude Code can take repetitive work off their plate. It's a fair question, and the honest answer has two halves.
Claude Code is genuinely impressive. For research, drafting, summarizing, and technical tasks where a person reviews the result, it's a real productivity boost. But "reliable enough for a person to lean on" and "reliable enough to run your operations unattended" are different bars. This guide is written for the second one, and for the ops professional who wants to use AI well without putting the firm at risk.
Where law firms are trying to use Claude Code in operations
Before the frustrations, it helps to name the work. Most firms aren't trying to get Claude Code to practice law, they're trying to get back the hours their teams spend on repeatable, system-to-system tasks. The common candidates:
- New-matter and client intake. Reading intake forms, running conflicts, opening the matter, and setting up the document workspace.
- Document filing and naming. Profiling, naming, and filing documents and email into iManage or NetDocuments by the firm's conventions.
- Time and billing prep. Assembling prebills, chasing missing time, and reconciling against the practice-management system.
- Inbox triage. Sorting a shared inbox, new matters, client questions, court notices, and routing each to the right place.
- Deadlines and docketing. Pulling dates out of emails and orders and getting them onto the right calendar.
The reliability frustrations ops teams run into with Claude Code
If you've piloted Claude Code on this kind of work, the following will feel familiar. None of them mean you're using it wrong, they're properties of the tool. Here's each one, and what's actually going on.
Claude Code isn't following your instructions
You give clear, numbered instructions and it honors most of them, then quietly drops one. That's because instructions are a prompt the model interprets and weighs against everything else in context, not a rule it's bound to execute. The longer and more detailed your instructions, the more likely a step gets dropped.
Claude Code keeps changing the format
The same task comes back formatted differently each time, a date as 2026-06-10 on one run and June 10, 2026 on the next, columns in a new order, a file named a new way. The model regenerates the output rather than filling a fixed template, so naming and structure drift even when the content is right. For a firm with a strict filing convention, that drift is a real problem.
Claude Code gives inconsistent results
Run the same task twice and you can get two different answers. This is inherent to how a large language model works: it generates the most likely output rather than executing a fixed procedure, and small differences in context nudge the result. Inconsistency is fine when you're exploring; it's a blocker when the work has to come out the same way every time.
Claude Code produces different output every time
Closely related: even when the answer is correct, its shape changes, wording, ordering, structure. Anything downstream that expects a fixed shape (a spreadsheet, a filing system, a report template) breaks when the shape moves.
Claude Code won't follow your rules
You write the rules down, in the prompt, in a rules file, and it still goes off-script. A rules file is context the model reads and weighs, not an enforcement layer. When two rules seem to conflict, or a rule conflicts with the task, the model silently picks, and you don't get to control how.
Claude Code makes mistakes
It generates plausible output, and plausible isn't the same as correct. Most of the time it's right; occasionally it's confidently wrong in a way that's easy to miss, and nothing flags the difference. On client-facing or filed work, those misses ship unless a person checks every run.
Claude Code hallucinations
Sometimes the most plausible-looking output is invented, a citation, a docket number, a party name that reads as normal but isn't real. Hallucinations can be reduced but not guaranteed away, which is exactly why hallucination-sensitive legal work shouldn't depend on a model generating the answer on every run.
Why this happens: Claude Code is non-deterministic by design
Every frustration above traces back to one root cause. Claude Code is built on a large language model, and language models are non-deterministic: they generate output by predicting what's most likely, sampling from a range of possibilities. The same input can produce different output on different runs. That's not a defect, it's the property that makes them creative, flexible, and good at language.
It's also why they're a strength for drafting and analysis and a liability for unattended operations. A person reviewing each result absorbs the variability. An automation running hundreds of times a week with no one watching cannot, and in a regulated environment, "mostly right" is not a standard you can attest to. The reliability problem isn't a prompt you haven't found yet; it's structural.
| Claude Code | Caddi | |
|---|---|---|
| What runs in production | A model generates fresh output on every run | Deterministic code, generated once at setup |
| Same input, same output? | Not guaranteed, output can vary run to run | Yes, identical inputs yield identical results |
| Following your rules | Instructions are a prompt the model may reinterpret | Rules are compiled into the workflow, not re-read each time |
| Auditability | Hard to prove what happened or why | Full run-by-run audit trail (SOC 2) |
| Who maintains it | You re-prompt and babysit it | Built and maintained for you |
Is Claude Code too complicated for a non-technical ops team?
There's a second, quieter barrier. Claude Code is a developer tool: it lives in a terminal, expects you to write and refine prompts, and leaves you to maintain whatever you build. For an engineer that's natural; for the paralegal, billing coordinator, or operations manager who actually runs the workflow, it's a steep climb.
That matters because the people closest to the work are usually the ones who can't build for it, so the automation either never happens or lands on one overloaded technical person. The goal for most ops teams isn't to become prompt engineers; it's to stop doing repetitive work. A tool that requires the former to get the latter is a hard sell.
Can you trust Claude Code with client and matter data?
For a law firm the bar isn't just "is the model secure", it's whether you can scope and control access, prove exactly what happened with a client's data on every run, and get the same handling every time. Prompt-driven, run-to-run-variable execution is hard to audit and hard to constrain, which is the opposite of what your malpractice carrier and your clients expect.
The danger is rarely a dramatic breach. It's the quiet failure: a hallucinated value in a record, inconsistent handling that surfaces in an audit, or credentials embedded in an ad-hoc script that no one can fully account for. Those are the failures that draw findings and erode client trust, so the operating model has to make them structurally hard.
Why firms give up, and how to split the work instead
This is why so many firms prototype something promising in Claude Code and then quietly abandon it. The demo works; production doesn't. Connecting the DMS, the practice-management system, and the inbox is real engineering, reliability takes constant prompt-tuning, and every tool change breaks something the firm then has to fix. Giving up isn't a failure of effort, it's asking one tool to do two different jobs.
The fix is to split the work. Caddi Discover finds and ranks the repetitive work across the firm's systems, with evidence, so you know what is worth automating and which tool should run it. The high-volume, high-accuracy work (intake, filing, billing prep, triage) runs in Caddi. Caddi uses AI once, at setup, to understand a workflow you demonstrate over a screen share, the way you'd train a new hire, then runs it as deterministic code over real connections: the same inputs produce the same outputs every time, every run is audit-logged, and genuine exceptions are routed to a person. No terminal, no prompts to maintain, and Caddi keeps the automation working as your tools change. The individual, judgment-heavy work, where Claude shines, is exported to Claude as a skill.
Caddi Govern then monitors every Caddi run, and the skills Caddi hands to Claude report each decision and API call back to it, in one firm-wide view. Leadership sees what should be automated, what is automated and where, and what is still manual, instead of going team to team months after a rollout with surveys nobody fully trusts.
Connect iManage to Caddi
Allow1Sign in to your tools
One click each for iManage, Microsoft Outlook and Aderant. No API keys.
Automate law firm operations.
ScreenshareType it2Show or tell it
Screenshare the job, or type it in chat. Change it any time.
- Running
14 done1 for review
3Watch it run
Caddi does the work and flags anything unsure for review.
Keep reading
- Caddi vs. Claude
- Caddi for law firms
- Client intake automation
- Automate matter intake
- Caddi Govern: monitor Caddi and the work it hands to Claude and Copilot
- How Caddi works
See deterministic automation in action
Caddi builds reliable automations from a screen recording and runs them across 150+ tools as deterministic code. Explore real workflows for law firms and RIAs & financial advisors, or book a demo to see your own workflow built live.
Caddi
See how Caddi AI Agents can run your firm's high-volume work the same way every time and monitor the work in Caddi and the work it hands Claude
Frequently asked questions
Is Claude Code reliable enough for law firm operations?
For supervised work like research and drafting, yes. For unattended, rule-bound back-office workflows it's limited by non-determinism, the same input can yield different output run to run, so it's hard to run without a person checking every result.
Why does Claude Code give inconsistent results?
Because it's a large language model that generates output probabilistically rather than executing a fixed procedure. The same task can produce different results on different runs.
Why won't Claude Code follow my firm's rules or naming conventions?
Rules and conventions in a prompt or rules file are guidance the model weighs, not an enforcement layer it must obey. They improve the odds but don't guarantee compliance, especially with many rules or long context.
Can I trust Claude Code with client and matter data?
For unattended work the concerns are auditability, scoped access, and consistent handling, areas where prompt-driven execution is weak. Deterministic automation with scoped access and a full audit trail (like Caddi, which is SOC 2 attested) is a stronger fit for client data.
Do I need to be technical to use Claude Code?
Effectively, yes, it's a developer tool driven from a terminal with prompts and maintenance. Non-technical ops teams typically get more from a done-for-you platform like Caddi, where you demonstrate the workflow and it's built and maintained for you.
Should a law firm use Claude Code or Caddi for back-office automation?
Both, for different work. Caddi Discover finds and ranks the firm's repetitive work, with evidence. High-volume, high-accuracy workflows run in Caddi as deterministic code across your DMS, practice-management system, and inbox, identical every run, audit-logged, and maintained for you. Individual, judgment-heavy work can be exported to Claude as a skill. Caddi Govern monitors every Caddi run and the work exported to Claude, which reports each decision and API call back, in one firm-wide view.