The Self-Build Paradox: What Vibe Coders Actually Know (And What We're Still Learning)

My last piece on Matt Shumer’s article generated some heat. Good, that was the point.

I have been accused of overselling and naïveté. Of being a lawyer who thinks he can code. All fair criticisms, delivered with the kind of directness I actively invited. But let me be absolutely clear: I am not retracting a single word, nor am I apologizing. I was offering a vision of the future, and we need to look at the reality of what is happening right now.

Let's look at Collate, the proof of concept tool I outlined in that post. It is a fully local, desktop-based application. Crucially, it contains absolutely zero AI integration within the software itself. It is simply a highly useful, deterministic utility built to solve a specific mechanical problem. My point was that even in its imperfect condition, it would still have saved me time, if used properly and rigorously checked. None of these tools should take away that key lawyer role, but they can still simplify our workflows.

If a practitioner with no coding background can architect and deploy a genuinely useful, secure desktop app in 90 minutes today, what will be possible in six months?

The Honest Premise

Nobody in the Legal Quants community believes they are building production-grade, enterprise-deployable software in an afternoon, or a week. What we are building are highly sophisticated proofs of concept, constructed with something the legal technology industry has chronically lacked at the design stage: practitioner perspective.

That distinction matters enormously. The history of legaltech is littered with elegant solutions to problems lawyers don't have, and clumsy workarounds for problems lawyers do. The functionality gap, the distance between what a tool does and what a practitioner actually needs it to do, is where most legaltech investment quietly goes to die.

We build because we are tired of waiting for someone else to solve problems we understand better than they do.

Three Pillars, One Honest Assessment

Every technology product—however it's delivered, whatever its ambitions—can be evaluated against three core tenets: functionality, reliability, and security. Let me be direct about where we stand on each.

1.  Functionality: This is where practitioners have an inherent advantage. Years of using inadequate tools creates a forensic understanding of what is actually needed. When I build something that does exactly what I want it to do, that is not beginner's luck; it is domain expertise finding an outlet. Frontier LLMs have made that expertise architecturally relevant. This is where vibe coders are strongest, and frankly, where we embarrass the competition.

2. Reliability: This is a process, not a destination. Testing, iteration, dogfooding, and edge case analysis are not mysteries. What the market hasn't fully absorbed is how dramatically LLMs have compressed the cost of building test suites. An AI that writes code can also write the tests for that code and flag failure modes at a speed that would have required a dedicated QA team eighteen months ago. The legal industry has barely registered this capability.

3.  Security: This is where we must be most rigorous—and most honest.

The Security Conversation Nobody Is Having Loudly Enough

Here is the uncomfortable truth: the legaltech industry has the same security vulnerabilities as self-built tools. The difference is that enterprise vendors have PR budgets and NDAs, while independent builders have LinkedIn posts. That asymmetry distorts the perception of risk, not its reality.

Let's name some security vulnerabilities plainly.

  • Prompt Injection Attacks: The most immediate risk for any AI-powered legal tool. Hidden instructions in white text, tiny fonts, or embedded PDF content can silently redirect an AI's behavior. A contract review tool processing counterparty documents is a prompt injection surface.

  • Classic Web Vulnerabilities: SQL injection, cross-site scripting, and insecure API key management are decades-old attack vectors that reappear constantly, even in well-funded vendor products. Building fast doesn't cause these; building without deliberate security review does.

  • Supply Chain Attacks: Vibe-coded applications rely on open-source libraries. A compromised dependency can propagate silently. Anyone deploying self-built tools without dependency auditing is trusting a chain they haven't inspected.

None of this is unique to us. Every vendor deploying a SaaS contract analysis platform faces versions of these same risks. The question is not whether you are exposed, but whether you have thought deliberately about it. We have.

On the 90-Minute Claim

A clarification, since several commentators seized on it with the enthusiasm of counsel spotting a concession.

I was not suggesting that production-ready legal applications routinely emerge fully formed in ninety minutes. I was describing the compression of the conception-to-prototype cycle to a timeframe that was simply impossible eighteen months ago. The gap between "I have an idea" and "I have something I can test" has collapsed.

Most good software ideas die in the distance between imagination and demonstration. When that distance disappears, the constraint shifts from technical execution to quality of thinking.

The path from prototype to deployable, secure application still requires rigor. We know that. But the ability to rapidly validate whether an idea is worth pursuing is genuinely transformative. We aren't claiming to have crossed the finish line; we are saying the starting line has moved dramatically closer to it.

What We Actually Want

Legal Quants is an elite network of over eighty lawyers across seventeen jurisdictions. We are practitioners who have decided that waiting for the tech industry to understand our problems is an inefficient strategy.

What we want is an honest conversation with every sector that intersects with what we do: law firms, vendors, developers, and regulators. Not a conversation that uncritically celebrates AI, and not one that reflexively dismisses it. We need a conversation that grapples with the actual capability frontier and the methodology required to close the gap between where we are and where we need to be.

The legal world is uncomfortable with uncertainty. Those instincts, appropriately directed, make us better builders than our critics expect.

We build imperfect things. We know they are imperfect. We document what we learn, we share it, and we iterate. In the current state of the technology, that is not a weakness. It is the methodology.

AnonLQ is a pseudonymous contributor from within the Legal Quants network. Views expressed are personal and do not represent the positions of any firm or institution.