eva // weekly legal tech digest
← Digest·substack·Law What's Next

The Tools Lawyers (Might) Build For Themselves

From no-code and low-code to vibe-coding: lawyers drinking directly from the AI firehose

January 13, 20262000 wordsoriginal ↗

Topics

Article

# The Tools Lawyers (Might) Build For Themselves > From no-code and low-code to vibe-coding: lawyers drinking directly from the AI firehose [Read on Substack](https://lawwhatsnext.substack.com/p/the-tools-lawyers-might-build-for) · 2026-01-13 · Law What's Next --- Until fairly recently, the idea of lawyers building their own software tended to mean no-code or low-code platforms. Tools that allowed motivated individuals or legal ops teams to stitch together workflows, automate processes, or move information from one place to another. Compared to buying an off-the-shelf product that only did part of the job, or waiting months for bespoke development, this felt like real progress for lawyers who wanted to build for themselves, as Tom and I discussed at CLOC EMEA around twelve months ago. Large language models soon began to appear at the edges of this world. Copilots made interfaces easier to navigate. Some teams bolted AI onto the start or end of workflows to handle natural language inputs or outputs. But for most non-techy lawyers, GenAI was still something you used, not something you built with. That has changed. A new class of building tools What is emerging now is not just easier automation, but a new layer of building altogether. Lawyers and other domain experts are beginning to use AI-powered development environments that translate natural language directly into working code. These tools sit somewhere between a chatbot and a traditional development environment, allowing users to describe what they want and then iteratively refine what gets built. This goes well beyond asking an AI for tips or snippets. With these tools, people are creating small apps, workflows, and features, and from within that same environment, they can test them, adjust them, and in some cases deploy them for real use. At Law://WhatsNext, we’ve featured some impressive early builders in the legal space: Jamie Tso and Anson Lai have both showcased some of their builds, and Jamie has shared more recently via the Artificial Lawyer. No doubt more to follow here in the coming weeks. The noise, and what matters underneath it As with most things AI, these developments have brought a familiar wave of hype. Claims that software development is dead. That vendors are obsolete. That everything will soon be free. These reactions are predictable and mostly unhelpful. A more grounded way to look at what is happening is this: AI-powered coding is becoming part of how software gets built. Not just by lawyers and domain experts experimenting at the edges, but by professional software teams as well. It is already being used to prototype faster, explore ideas, generate boilerplate and documentation, and compress parts of the development cycle. That matters. The traditional cycle times involved in developing software may be significantly compressed. Not eliminated. Not trivialised. But shortened in practical ways that affect speed, cost, and iteration. A lawyer with a problem can now explore a solution directly. They can sketch out how something should work, test it, and refine it before involving anyone else. When they do bring in technical help, they can arrive with a working prototype rather than an abstract description. That alone can reduce friction, misunderstanding, and wasted effort. At the same time, there is a fairly strong consensus across the software community about the current limits of what this approach can deliver on its own. What AI-assisted building gets you today is not a full substitute for the other components of shipping software that people will pay for and rely on in an enterprise setting. Architecture still matters. Security still matters. Design decisions, data models, error handling, performance, maintainability, and long-term support still matter. Those elements do not disappear simply because code can be generated quickly. Without them, you tend to get collections of features rather than coherent, reliable systems. That is why, for legal tech products and enterprise software more broadly, AI-powered coding is best understood as an accelerator rather than a replacement. It changes how work gets done, who can participate earlier, and how fast teams can move. But it does not remove the need for trained developers, structured engineering practice, and human judgment when the goal is to ship production software at scale. Ted Theodoropoulos, CEO of Infodash and host of the fantastic Legal Innovation Spotlight podcast, wrote about this topic well here. That framing is compelling if the question you are trying to answer is how to build better legal tech products. But it assumes that “shipping software” is always the right lens. That the thing being built needs to scale, to be robust, to be sold, and to survive long-term use by people who did not build it. It is worth asking whether that is always what lawyers are trying to do. When “real software” is the wrong yardstick A large amount of legal work flies under the radar of enterprise-grade software. Much of it is highly contextual, shaped by individual judgment, and embedded in personal ways of working that resist standardisation. In those cases, the goal is not to create a product. It is to remove friction from the work itself. Seen through that lens, AI-powered building tools look different. Not as a way to compete with legal tech vendors, but as a way for lawyers to create small, practical tools that sit close to their own workflows. Tools that support how the work is actually done, rather than how a generalised system assumes it should be done. Measured against the standards of enterprise software, these tools will almost always fall short. They are not designed for scale, long-term maintainability, or broad deployment. But that is the wrong yardstick. Once you stop expecting them to behave like products, their usefulness becomes much easier to see. Tools built close to the work Many lawyers who start building alongside their day job are not trying to build technology in any formal sense. They are trying to smooth out the rough edges of their own work. These are people embedded in day-to-day legal practice. They understand their workflows intimately because they live inside them. They know which steps feel repetitive, which checks are instinctive, and where time is lost in small but persistent ways. AI-powered building tools make it possible to act on that understanding directly. A narrowly focused solution can be spun up in a short period of time, adjusted as the work changes, and used by the individual who built it or by a small group of colleagues. There is no need for a business case, a roadmap, or a procurement process. The results are often messy by traditional standards. The tools may be inelegant. They may break at the edges. They are not systems of record. But they work. And they work precisely because they are built by the people who use them. What these tools look like in practice Most of these tools are small. They do one thing, or a handful of closely related things. They encode how a particular lawyer thinks about a task rather than how a generic user might approach it. They might automate a drafting sequence that follows a personal logic. Or apply a series of checks that an experienced practitioner runs instinctively. Or transform information into a format that makes sense to one team, in one context. They can be built on top of approved AI models, using sensible security guardrails and inexpensive API access. They can live inside familiar environments. They are easy to change because the person changing them is also the person feeling the friction. Their limitations are acceptable. They are not designed to scale. They are not designed to be shared widely. They are designed to be useful. Alignment beats polish One reason these tools resonate is that a surprising amount of legal work is poorly served by formal legal tech. In recent AI studies, professional users report getting more day-to-day value from a simple AI assistant, such as a twenty-dollar-a-month ChatGPT subscription, than from far more expensive, carefully designed domain-specific systems. Not because those systems are bad, but because the assistant is always there. It adapts. It responds to how the lawyer works rather than forcing the lawyer to adapt to it. The lawyer can pick it up and put it down at their discretion. AI-powered building tools extend that model by adding a second layer. Lawyers can continue to rely on a general-purpose assistant for exploration, drafting, and thinking out loud, while also building a small collection of highly focused tools that execute repetitive tasks and actions in the style they prefer. Those tools would not replace judgment. They would encode it. They’d reflect how an individual lawyer approaches their work, the steps they habitually take, and the transformations they apply without thinking. At that point, the value is not sophistication or scale. It is alignment. The tool works because it mirrors the practitioner who built it. A quiet shift in expectations These vibe-coded tools are unlikely to exist in the general marketplace in any straightforward way. More generalised versions can, and often do, exist, but by definition, they are designed for broader audiences and lose much of the precision that makes these tools valuable in the first place. The strength of these tools is not that they address a category of users, but that they meet the needs of one user extremely well. That has an interesting side effect. Lawyers who rely on highly focused, self-built tools are likely to be less inclined to go to market at all, at least for a time. As long as their needs remain narrow and manageable, there is little incentive to replace something that works with a more generic alternative. The shift tends to happen only when a genuine threshold is reached. When scale and consistency start to matter. When a tool needs to be shared across a team or business. When workflows become more complex. When maintenance, reliability, or support outweigh speed and flexibility. At that point, more traditional software begins to make sense again. But by then, the buyer is likely to have changed. Lawyers who have spent time working with highly tailored, home-spun tools will arrive at the market with sharper, and sometimes unrealistic, expectations. They will be more attuned to where software fits their way of working and where it does not. They will be quicker to push for configuration, customisation, and development that reflects how they actually operate. These vibe-coded tools do not create competitors in the usual sense to established legal tech. But they may quietly remove some buyers for a period of time, and then reintroduce them later as a more demanding audience than before. A moving target It is important to be explicit that this is a snapshot in time, in early 2026. AI capabilities are still evolving, and it is not clear where the ceiling lies. No-code and low-code platforms may become more powerful by incorporating stronger AI-driven scaffolding and governance. Community-driven efforts may emerge, with shared tools that users can adapt by plugging in their own models. Traditional tech providers may benefit from compressed timelines and faster feature delivery to capture more of the need in the marketplace. Some of today’s excitement may fade as maintenance costs and operational realities assert themselves. The ground is still shifting. Why lawyers should pay attention For individual lawyers, particularly those doing the work day in and day out, there is a real opportunity here. Being close to the practice puts you in the best possible position to spot small points of friction, repetitive steps, or workarounds that never quite make it onto a roadmap. The ability to build even modest, personal tools in response to those moments may become a valuable skill. Not because everyone needs to become a developer, but because it allows practitioners to shape their own working environment in practical ways. This is not about replacing software teams or bypassing governance. It is about learning what becomes possible when the distance between problem and solution becomes very small. The most interesting impact of AI in legal tech may not be what gets sold. It may be what quietly gets built, used, and refined without ever entering the market at all. Thanks for reading Law://WhatsNext! Subscribe for free to receive new posts and support our work.