There is a running joke in software circles that developers hate writing documentation. Ask a developer to build a feature and they will dive headfirst into the code. Ask them to document it afterwards and it will never get done. This is not a character flaw so much as a reflection of how IT people are wired — they were drawn to the field because they like solving logical, deterministic problems, not because they enjoy crafting precise prose.
With the rise of LLMs and vibe coding tools like Cursor, Claude Code and GitHub Copilot, this matters more than it used to.
Prompting Is a Language Skill
A lot has been written about prompt engineering as though it were some arcane technical discipline requiring knowledge of tokenisation and model internals. In practice, the most important skill is far more mundane: the ability to describe what you want precisely and unambiguously.
This is not a skill that most IT curricula develop. Computer science degrees teach algorithms, data structures, discrete mathematics and operating systems. There is little emphasis on written communication. The stereotype of the developer who communicates exclusively in terse Slack messages and Stack Overflow answers exists for a reason.
Lawyers, by contrast, spend years being trained to write with precision. Every word in a contract, a pleading or a legal opinion is deliberate. Ambiguity is the enemy. A poorly drafted clause can expose a client to liability or render an entire agreement unenforceable. Law students learn early on that "the court may order costs" and "the court shall order costs" are not interchangeable, even though a layperson might treat them as synonymous. This instinct for precision translates surprisingly well to prompting.
What Good Prompting Actually Looks Like
Consider asking an AI model to build a simple web form that accepts user submissions and sends an email notification. An IT person might write:
Build a contact form that emails me when someone submits it.
A lawyer might write something closer to:
Build a contact form with three fields: name (text, required), email (valid email format, required) and message (textarea, required, maximum 500 characters). On submission, validate all fields before submitting for processing. The server should send an email to admin@example.com with the subject "New Contact Form Submission" containing all three field values. Return a message on success, and a response with a specific error message if validation fails.
The second prompt will produce something usable on the first attempt. The first will produce something that requires three or four rounds of back-and-forth to pin down the missing details.
The IT person is not being lazy. They simply filled in the gaps mentally, the way they would when reading a requirements document. The lawyer left nothing to inference, because leaving things to inference is professional malpractice in their field.
The Documentation Paradox
There is a certain irony here. The people who are most resistant to writing documentation are the ones building the tools that require good documentation to use effectively. Developers have spent decades arguing that code should be self-documenting, that clean code is its own explanation. This philosophy is fine when the reader is another developer. It breaks down entirely when the reader is a language model being asked to generate new code from scratch.
Vibe coding is, at its core, a documentation exercise. You are writing a specification, and the AI is implementing it. The quality of the output is bounded by the quality of the input. A developer who cannot write a clear specification will get mediocre results and blame the model.
Lawyers Are Already Comfortable With This Workflow
There is another dimension to this. Lawyers are accustomed to working iteratively with a text — drafting, reviewing, redlining and refining. This maps naturally onto the prompt-refine loop that effective AI usage requires. They are also used to specifying not just what they want but what they do not want, which is equally important when prompting. Exclusion clauses in contracts and negative constraints in prompts serve the same function.
IT folks, on the other hand, often treat the first output as a near-final draft that needs to be debugged rather than a starting point to be refined through better specification. This is the wrong mental model.
Caveats
This is not to say that lawyers will outperform developers on every AI-assisted task. Debugging, architecture decisions and understanding whether a generated output is actually correct still require technical knowledge. A lawyer who vibe-codes an authentication system without understanding session management or SQL injection is going to produce something that works superficially and fails catastrophically in production.
The more realistic picture is that the tasks where lawyers have an edge are the ones that are specification-heavy and relatively self-contained — building internal tools, automating document workflows, generating boilerplate code for well-understood problems. For anything involving non-trivial system design or security considerations, technical knowledge remains essential.
Conclusion
The assumption that software development will always be the exclusive domain of people with technical backgrounds is being tested. Vibe coding has made it possible for non-technical people to build real things, and it turns out that the skills which determine success in this new environment are not the ones we would have predicted five years ago. The ability to write precisely and anticipate ambiguity matters more than knowing what a binary tree is. Lawyers, whatever their other shortcomings, have been training for this their entire careers.