Dud for Some, Big for Others

Guest Author Justin Tung, Transactional Practice Innovation Lead at Jackson Walker LLP

I recently attended the 2026 AALL Annual conference where I had the privilege of attending sessions taught by some of the most knowledgeable and thoughtful individuals in the law librarian profession. Part of what makes conferences like this such a great facilitator for education and information is the ability to engage in discourse with individuals who have different perspectives and experiences. It is in that spirit that I want to respond to a piece by Stephen Embry on Above the Law, entitled “Vibe Coding For Lawyers: Next Big Thing Or Just A Big Dud?” where he gives his impressions of an AALL session I attended on vibe coding.

Embry’s perspective on the presenters and vibe coding is overall negative. While I have certainly spent my fair share of time turning my nose up at “mere” vibe coders, his reasons for doing so puzzled me. His perspective on vibe coding seems confined to the sort of cases where AI blows up and ends up in legal news outlets, such as Above the Law.

This sentiment is revealed in a few different ways. For instance, Embry writes that:

Vibe coding is what you can do when you find a solution to a problem that requires coding you have no clue how to write. So you ask the chatbot to write it for you. . . . That right away gives some pause: you’re asking a chatbot to do something you can’t do, know little about, and aren’t able to evaluate when done.

Embry seems to be saying that either you understand and can do something, in which case there is no value to vibe coding a solution, or that you have no knowledge or ability to do something, in which case the output is incomprehensible to you and is therefore useless. This perspective makes sense when chastising bad lawyers who work outside their practice area and get caught filing fake cases in court, but breaks down in many scenarios.

Firstly, there is tremendous value in vibe coding tools for tasks that someone already understands and can themselves do. The projects demonstrated in the session included a web app to teach students boolean terms & connectors and a downloader for government information. The speakers are fully able to do these things themselves, but shared how they found value in creating additional resources for them.

Secondly, the inability to understand a process doesn’t mean the inability to evaluate an outcome. Every day, people drive cars they could not build to work on a floor of a building they could not construct via a road system they could not design to type on a computer they could not program. We are comfortable with all these things because we do have frameworks for evaluating them, i.e. we can tell when they work. It is not clear to me that this ability suddenly disappears when talking about vibe coding.

If we create a Cartesian grid with understandability on one axis and verifiability on another, there are a lot of AI-related tasks that can fill each quadrant of the grid. There are genuinely instances where outputs are difficult to verify, such as checking an AI-generated transcript or deep research memo. But there are also a ton of tasks with low verification costs. In fact, there is a whole category of problems in mathematics, called NP-complete, that are very characteristically difficult to solve, but can be verified quickly (e.g. Sudoku, traveling salesman).

In the law library, someone may not know how to write headers for a GET request, but can easily tell when the appropriate files have been downloaded from a government source. They may not know how to walk through a base directory recursively and zip files, but they can tell when the zip files decompress into their originals. They may not know how to compare hashes of a court announcements page to flag changes, but they can tell when their system alerts them to new changes.

Despite this, Embry’s piece often points to this perceived lack of competence with a topic as a reason to defer to those he deems more appropriate. He often cites IT as the more proper and competent authority on doing these tasks:

And all three [presenters] were quick to point out that if you went beyond the very simple, you would need to get help from your IT department, the experts. Since lawyers in larger firms have these experts in house, going to them in the first place might save a lot of time and trouble.

Most of the work to create a robust vibe-coded tool needs to be left to IT anyway, so why waste time trying to do it yourself. So, the work-use case for vibe coding right now seems pretty low.

The argument here seems to be that vibe-coders, by dabbling in a domain in which they are completely inept, need the expertise of IT departments to complete tasks that are of any value. I find that this perspective misses the point. Vibe coding augments the abilities of the person using it so that they can effectively act in a domain they otherwise would not be able to. If someone has a thousand DOCX files to convert to PDF, vibe coding a simple script or bash command is relatively easy (and I daresay even reliable) with commercial LLMs. Vibe coding makes the user’s unfamiliarity with a scripting language no longer a barrier to them completing the task.

Another consideration is that while IT in law firms specialize in network systems and information security, they may not readily understand the needs of lawyers or law librarians. (This is not a slight at all, as lawyers and law librarians rarely understand much of the depth of IT’s domains either.) Vibe coding can offer anyone the ability to efficiently create tools and provide value in ways that they haven’t articulated or could not articulate to others.

At this, Embry raises the issue of security:

Another telling sign: all were adamant that work policies should directly preclude vibe coding efforts. Why? In the hands of those without substantial expertise and sophistication, system security could be compromised. And the very architecture of the system could be threatened. As in all the files might disappear.

Another fear: people may try to vibe code without understanding what it is doing. This is not like asking ChatGPT for restaurant recommendations. The whole idea of vibe coding is that you create systems that can and will take actions without direct human involvement or approval. Great. Let it run and threaten both security and operations unbeknownst to anyone.

At the session, I remember a joke the panel circulated about “rm -rf”. In Unix systems, “rm” is the command to remove, and “-rf” is a flag that tells the operating system to do this recursively (“r”) and to force (“f”) override protections without user confirmation. There have certainly been incidents where AI agents have irretrievably deleted user information or created security issues, but Embry’s fear that vibe coding will suddenly do this seems to conflate two things.

Writing code and running it are different stages. When the person is interacting with the AI it may run shell commands, and (however unlikely) it may even get very confused and try to run “rm -rf /”. However, most AI platforms are configured to ask for user approval to run commands like this. The companies who have been burned by AI likely changed their configurations to run without asking for permissions, which is entirely their responsibility.

Once the output of the vibe-coding is generated, there is basically no risk that it’ll do something like “rm -rf /” because although the AI wrote the code, it doesn’t continually make decisions about the behavior of the program. That’s the written code’s job. This is one of the points of using the AI to write code to do something rather than telling the AI to do it by itself. It’s not as if since a tool was vibe coded, it always has the mercurial nature of generative AI. It behaves as code does, which is largely deterministic.

Embry, however, additionally raises other security issues.

And of course, like all things AI, it can hallucinate and create libraries that enable hackers to gain access. Bottom line, said the panelists, don’t use it for anything related to work.

The attack vector of registering packages of names that are easily mistaken for legitimate packages is often called “slopsquatting” and is a legitimate concern. However, there are some pretty simple best practices for avoiding it. One is to stick to a language’s standard library. Another is to only import packages you know. Another is to check package repositories online before you import them. It’s also important to note that slopsquatting did not start with AI, and many organizations have internal repository environments where they can verify packages before allowing importation into user code. The panelists did not go into depth on these issues, but they did raise them so that attendees can be aware and avoid them.

I don’t directly remember that the panelists directly said not to use vibe coding for anything related to work, but I’d be surprised if they did. This was a session at a professional conference, where professionals were sharing use cases they found for vibe coding in their job roles.

Of course, there are other security issues with vibe coding, especially with apps that are exposed to the open web. Web security is a very important and expert domain. However, none of the speakers demonstrated nor advocated that attendees try these projects.

Embry ends with an interesting anecdote.

I ask ChatGPT to search every morning for legal tech news, emphasize the U.S. market, rank the stories by importance, and deliver the report to me every day by 8 a.m.

ChatGPT tells me that’s not vibe coding since I haven’t asked for any code to be created. But if I were to add to the list things like store the articles in a database or add a button that exports the report to Word, now I have asked the LLM to create a code and voila, I’m a vibe coder. Yippee.

While he certainly intended this to be humorous, he’s both quite close and also astonishingly far off. Vibe coding consists, nominally, of two parts. He’s got some vibes. This is an interesting project and use case. He just needs the coding part. If he asked ChatGPT to write him a news aggregator/ranker app, then yes, he would be vibe coding since it has, you know, code.

—

This piece by Embry was interesting in some ways and confusing in others. It reflects an idea of organizational task delegation and domain boundary maintenance that I don’t think is reflective of the majority of law libraries or firms. But as fractionalized as Embry’s view on organizations seems to be, his view on technology is quixotically monolithic. His analysis would consider asking AI to make a scraper for state laws as potentially dangerous as asking AI to build a web app to hold client social security numbers.

In my view, the point of sessions like this one is to showcase innovative and novel problem solving by peers in the profession. That means that by definition, the demonstrations are going to present problems and solutions that step outside of established practices. The invitation to attendees is to consider the presentation and rethink their preconceptions. While it’s natural to be horrified when news breaks about AI misuse landing a startup or a lawyer in trouble, this session provided a deeper and more nuanced view of vibe coding and its use in professional legal settings.