Your Legal Team Ships Software Now. Are You Ready?

This is the first story in Machine Learnings, a series offering an inside look at Cyera’s AI rollout and our learnings along the way.

One of our lawyers started building tools with Claude Code to work through contracts, patent submissions, trademark conflicts, and managing the patent portfolio. When he walked me through what he’d built, he could explain why he’d built it and what it was doing for him. It sped up negotiations, helped him understand company obligations with customers, and ultimately gave him time back. 

He was excited. That’s pretty common when someone finally gives building a try. He also had a business case for what he was doing.

I’m not a lawyer, so I’m taking his assessment of the legal work at face value. But he’s good at his job, and he was stretched. Hiring another lawyer would take time, and another lawyer might not even be the right answer for the particular work he needed to get through. Here was something that let him scale his efforts and unlocked new capabilities. If it makes him happier at work and gives him more capacity, it seems like a smart investment.

His tools worked for him. Sharing what he’d built with the rest of the legal team was where he got stuck.

It Works on My Machine

AI can do amazing things. Writing software is one of them.

And here’s your engineers’ dirty little secret: code was messy before AI. Gasp.

If the argument is “you can’t do this because you’re not an engineer,” we should probably have a look at the collective code engineers have been writing.

There’s a reason spaghetti code is a term. There are probably entire parts of your company’s codebase that people actively avoid touching because the person who wrote them left, and figuring out how they work and what depends on them is a whole job. 

Now people with deep domain expertise can build scripts and tools themselves. Some previously would’ve had to purchase a product to get anything close to what they needed. They can finally make the thing they have in mind, without needing to know the framework developers use to build, test, and support it.

And while vibe-coding your own version of a $50K-a-year product is appealing, building it is only part of the cost. Once you include running it, testing it, maintaining it, and securing it the total cost of ownership can be a lot higher.

As an organization, you have to make a decision: do you ban all the builders or do you give them a path?

Give Everyone a Path

The lawyer never learned deployment or the many other skillsets and tools engineers take for granted; why would he? He doesn’t understand the “it works on my machine” meme. He can get Claude to build something, but there are still questions about identity, authentication, authorization, and testing. 

Some of his tools run code Claude wrote. He needs to understand what he’s asking each part to do and how to check that it works.

But his domain expertise is still incredibly valuable. He knows what takes too long and what he never has time to get around to. He knows what type of legal work is fine for vibey outputs from Claude and what requires deterministic outputs and repeatability. Expecting attorneys or other non-technical employees to learn the software development life cycle is unrealistic. That doesn’t mean their contributions are any less valuable.

Graduating an agent from an individual user to something the team relies on is new territory for everyone. The questions about ROI and token efficiency can be endless. But if your team has to wait until there’s an agreed-on defensive ROI number, we create a chicken-egg problem. Reliance should be the trigger, not revenue. Once a team is reliant on a new agent, it’s time to take it seriously. Getting a tool to that place can be a long path.

Here’s how I approach it:

It starts with access. If you’re aligning the company around a particular desktop agent, make it available to everyone. Then give them time to use it and resources to go to when they get stuck. That’s what we did when we rolled out Claude.

And space to experiment. I’m also starting to realize how often we assume people have already had a chance to learn these tools. Plenty haven’t had the time to try them or haven’t worked somewhere that gave them access. With every new batch of employees, you have to be prepared to start from zero. Someone can have decades of experience in their field and be completely new to this.

Some of the education has to come from trying things, running into problems, and figuring out why they happened. That’s how you start to understand why the next idea might work better with a different approach.

Then a way to share what they’ve built. That path needs to go somewhere. For this lawyer, that means getting a useful tool off his laptop and into the hands of the rest of legal. Who does he go to for help? Where can it run? Who helps him with QA before other people depend on it? Who will help keep it working?

A platform for internal sharing can solve a lot of these problems. We launched our own tool for that called Cyera Pages, and anyone connected to our VPN can access these pages. Claude artifacts or similar vendor-provided resources are another great option here. It’s an example of how teamwork between non-technical and technical teams gives users a safe path to share their creations without the risk of accidentally posting internal information publicly.

With lightweight validation. Imagine a patent checker costs $160 in tokens every time it runs. Is the ROI there? If it saves a lawyer several hours of work, likely yes.

I’d still want to give him an exercise: break down what the tool is actually doing. Which parts need AI? Which parts could be ordinary software? What is getting sent to the model, and how often? What happens if you change one of those steps?

He might discover that most of the work can run as ordinary software, with AI needed for a smaller part. He might find that the cost is justified. Either way, he starts to understand the system he built. That gives him something he can use when he builds the next idea, hopefully faster and better.

These are all things your organization should be figuring out now. If the answer is that the lawyer has to figure all of it out himself or follow the same deployment cycle an engineer would, you’re submitting a lot of projects to an early death.

The Redlines Are Still Yours

There also needs to be a clear understanding of responsibility. When I say you’re on the hook for what you create, think about the work this lawyer is doing. Two businesses are entering into an agreement. The company is still responsible for that agreement whether the redlines were done by hand or with help from AI (not to mention norms and etiquette to follow as attorneys increasingly deal with documents full of AI-generated redlines).

Using a tool to make the job easier doesn’t change that responsibility.

There’s something interesting about our expectations here, too. We know a human isn’t going to be right 100% of the time. With AI, many expect it to be right every single time — without exception. When it isn’t, we torch it.

That expectation may be reasonable. But if that’s the assumption, there’s a different problem to solve.

Before other people depend on a tool, you need to talk about what it has to get right and how you’re going to check that. Which results need someone to review them? How will you know something has gone wrong? What happens then?

The lawyer understands what a bad result means for his work. The AI engineers who are helping him refine the tools need that context. He needs their help understanding how the system can fail and what can be done about it. Having that conversation is part of getting comfortable with the risk.

So, Are You Ready?

You need to rethink the software processes your engineering or IT team already uses to suit a totally different audience. You now have to work out how someone who has never before needed to know even the basics of software development can build stable, cost-effective tools and distribute them. More people are going to arrive with useful things and questions. Helping them is key to AI starting to have a real, meaningful business impact.

So if someone tells me their company is ready for these builders, I want to know:

• What was the moment that made you take them seriously?
• What are you providing in the way of education and tooling, including for people who are starting from zero?
• What happens when someone builds something useful and wants the rest of their team to use it?
• How did you get comfortable with the risk of other people depending on what they’ve built?

We launched Machine Learnings to help answer those questions and learn from each other along the way. My goal is that sharing our own challenges and breakthroughs can help solve your problems and keep you from making the same mistakes we did. Today, about 90% of our 1,800 employees use AI every week, but there’s always more work ahead. Stay tuned.