AI-assisted coding has made a new category of builder visible.
Lawyers are building intake tools, timeline generators, contract-review surfaces, demand-letter workflows, and research helpers. Legal operators are building dashboards. Firm administrators are building automations. Legal-aid teams are experimenting with triage and routing support. Non-engineers are shipping software because the distance between idea and working surface has collapsed.
The shift is real, and it moves the professional floor from theory to production.
The software may have been produced by a model. The obligation is still owned by the person or organization that deploys it.
The surface is not the system
Software has not become easy. Producing a working surface has become much easier.
That distinction changes the risk profile. A working surface can collect data, route users, draft documents, trigger workflows, make recommendations, store records, send emails, and shape what a user believes about a legal situation. It can do all of that before anyone has built the system underneath well enough to support the consequences.
The builder sees the working surface.
The user experiences the system.
Those are not the same thing.
What Heppner actually adds
United States v. Heppner is useful here because it points at system boundaries, not because it is a generic anti-AI case.
The lesson is not "never use AI." Professional obligations do not disappear because the tool is convenient, consumer-grade, or capable of producing polished output. Confidentiality, review, control, and judgment still have to be enforceable in the architecture around the tool.
The same logic applies to AI-assisted software in legal work.
If a lawyer ships a tool that collects client facts, the lawyer cannot answer a confidentiality failure by saying the code came from an AI assistant. If a firm deploys an intake workflow that mishandles a limitation-sensitive matter, the firm cannot answer the failure by pointing to the model that generated the form logic. If a legal-aid organization uses a routing tool that sends users to the wrong next step, the organization still has to account for how that workflow was designed, reviewed, monitored, and corrected.
The origin of the code does not absorb the obligation.
The deploying organization owns the system.
The cases will not look like demos
The first high-signal failures will probably not look like a dramatic AI mistake in a demo.
They will look like normal software failures in consequential settings.
A tool stores more data than the builder realized. Logs retain sensitive facts. Access survives after a contractor leaves. A routing rule looks reasonable in the happy path but fails under a common exception. A public form collects facts that create an urgent deadline but no one is alerted. A generated workflow has no owner for updates when the underlying law changes.
None of those failures require the model to behave mysteriously.
They require only the ordinary gap between a working surface and an operating system.
The gap existed before AI-assisted coding. AI makes it easier to create the surface before the organization notices the system cost.
The professional floor
For AI-built legal software, the floor is not "the app works."
The floor includes:
- data minimization
- confidentiality and privilege protection
- access control and revocation
- retention and deletion rules
- source grounding where legal information appears
- review before external legal effect
- escalation paths for high-risk facts
- monitoring for failure patterns
- ownership for maintenance and updates
- incident response when the tool fails
Non-engineers can meet that floor.
Engineers can fail it.
Credential is not the standard. Adequacy to consequences is the standard.
Lawyers are exposed in a specific way
Lawyers building with AI are not wrong to build.
They are exposed because legal already has an enforced professional responsibility framework. Technology competence, confidentiality, supervision, candor, malpractice exposure, and client communication already apply to legal work. AI-assisted software does not move the work outside that framework.
The exposure is sharper when the tool touches live matters, client facts, or external-facing output.
An internal note-organizer has one risk profile. A public intake tool has another. A drafting assistant whose output cannot leave the firm without lawyer review has one risk profile. A tool that sends a demand letter, generates a filing, or routes a user away from human help has another.
The deployment context controls the floor.
Many first-time builders miss that part. The same code can be a useful internal assistant in one setting and an unsafe legal product in another.
The legal-aid version
Legal-aid and access-to-justice tools need their own attention because good intentions can obscure system risk.
A free public tool is not automatically safer because it is free. A clinic routing workflow is not automatically safer because it points users toward help. A self-help document tool is not automatically safer because the user cannot afford counsel.
The floor still applies.
If the tool provides legal information, the sources need to be visible and maintained. If the tool routes users, the routing logic needs to account for jurisdiction, eligibility, urgency, and handoff. If the tool touches deadlines, the escalation path needs to be explicit. If the tool decides that self-help is appropriate, someone has to define when self-help is not appropriate.
Access-to-justice software is still software.
Legal-help software is still legal infrastructure.
Build with the floor in view
Do not stop building.
Stop treating the demo as the product.
A lawyer who builds a useful intake helper should keep going. A legal-aid team that prototypes a routing workflow should keep learning. A firm administrator who automates internal follow-up should not wait for a vendor if the workflow can be improved safely.
But the move from "I built this" to "people rely on this" is the move where the floor appears.
Before that move, the builder should know where the data goes, who can access it, how it is deleted, what sources support legal content, what happens when the tool is wrong, who reviews output before legal effect, who owns updates, and who responds when something breaks.
Those are not enterprise-only questions.
They are production questions.
Where the line is
AI-assisted building expands who can make software.
It does not erase the obligations attached to deploying software into legal work.
The line is not between lawyers and engineers. It is not between coders and non-coders. It is not between traditional software and AI-built software.
The line is between tools whose architecture matches their consequences and tools whose surface outruns their system.
The first category should be built.
The second category will create the signal cases.