Many friends and colleagues in the legal technology world have been telling me I need to start vibe coding. My answer is that in vibe coding, you are intentionally surrendering the control plane. That is not a tradeoff I am willing to make.

Let me explain why that is a principle, not a preference, and why it matters especially for lawyers.

By “control plane,” I mean the part of the system that sets constraints, enforces them, and makes compliance verifiable, not just promised. It is the governing layer that answers the hard questions. What is the rule? What enforces it? How do we know it happened?

I have written recently about control drift. This is the pattern where an AI system gradually reasserts its own defaults even after you have set explicit constraints. The system says it will behave a certain way. Then it does not. Then it assures you it will not happen again. Then it does. Here is what that looks like in practice. You specify a clear constraint, such as not storing client-sensitive text or not altering certain structures. Then the system pushes past it in small ways that are easy to miss until they matter.

Lawyers already know the relevant principle. Assurances are not controls. In compliance, risk, and governance work, we do not rely on promises when mechanisms are available. That same discipline now needs to apply to AI workflows.

To be clear, vibe coding is a breakthrough for certain “Jobs to be Done.” It is brilliant for prototyping, internal hackathons, and design-thinking events where the goal is to visualize a “what if” scenario. However, I am wary of pushing it much further into production. The reason comes down to the math.

Vibe coding is signing the contract and writing the terms yourself in a language you do not speak, then asking the person who wrote it to tell you if it’s fair.

Lawyers famously say they went to law school because they didn’t want to do math. But this is the moment where doing the math first is the only way to go. Large Language Models are, at their core, engines of probability and prediction. They are designed to guess the most likely next token, not to adhere to a rigid logical proof. When you vibe code, you are essentially asking a probability engine to build a deterministic tool. Without a control plane, you have no way to ensure that the 0.1% edge case—the one that triggers a data leak or a missed deadline—is not lurking in the code.

The common rebuttal is that we use “black box” tools like Microsoft Word or Lexis every day. But there is a massive professional distinction at play. When you use a vetted SaaS product, you are a consumer relying on a vendor’s multi-million dollar engineering control plane. When you vibe code a tool, you have moved from consumer to architect. You are no longer just using a tool. You are building the firm’s infrastructure.

Now, a lawyer does not necessarily need to be a Python expert to maintain a control plane. You don’t always have to read the code to verify the work. You can use functional testing by running 1,000 samples through a script to see if the outputs match a known-good standard. That is a valid control. But vibe coding usually skips this step. It relies on the “vibe” of a single successful run.

Worse, some suggest letting the AI write its own “verification artifacts” by prompting the model to write the test suite for the code it just generated. This is the ultimate trap. If you can’t read the code and you can’t read the tests, you haven’t built a control plane. You have just moved the “vibe” one layer up. You are asking the fox to design the security system for the hen house and then hand you a report saying all is well.

The lawyer who cannot verify the output independently has no control plane at all. They are not surrendering governance. They never had it. This is not just a workflow mismatch. It is a professional responsibility question in waiting.

Consider the irony. A lawyer would never advise a client to sign a contract they could not read. Vibe coding is signing the contract and writing the terms yourself in a language you do not speak, then asking the person who wrote it to tell you if it’s fair.

Vibe coding gets hired to build functional software fast when deep comprehension of the output is not required. That is a legitimate job for a prototype. It is just not a lawyer’s job when the output carries professional weight. The lawyer’s job is to provide defensible certainty.

Here is the falsifiable version of my position. If a vibe-coded workflow could demonstrate stable compliance with explicit constraints across extended sessions by producing independent verification artifacts like automated test suites or rigorous functional audits that the lawyer actually understands, I would reconsider.

Until then, the control plane question is the right first question. For lawyers, it may also be the professional responsibility question.

[Originally posted on DennisKennedy.Blog (https://www.denniskennedy.com/blog/)]

DennisKennedy.com is the home of the Kennedy Idea Propulsion Laboratory

Like this post? Buy me a coffee

DennisKennedy.Blog is part of the LexBlog network.