Hi! I’m Laura, a Legal Engineer at Flank. I build agents and supervise them, making sure that we’re putting as much trust in them as they’ve actually earned.
There isn’t really a conventional route into Legal AI, and my career path is no exception. I’m not a qualified solicitor, I don’t have a law degree, and I’ve never worked as an engineer. What I do have is a background in translation, which has turned out to matter more than I expected.
In my previous article, I wrote about the human side of working with AI agents - how we supervise them and decide how much trust they've earned. This time, I’m looking at what happens when the people building those agents and the people working with them speak slightly different languages.
After completing a French degree in Paris, I headed back home to Newcastle to study a master’s in Professional Translation. That’s where I was first introduced to law, through a module offered by Newcastle Law School called “Key Concepts in Corporate and Commercial Law”. I learnt how to translate not only across languages, but across legal systems, and I surprised myself with how much I enjoyed it. In 2020, I landed my first job as a Legal Consultant, where my employer took a chance on someone with limited legal experience to help with French legal translation in contracts. Then, after working my way up in contract management at a tech company, I found my way to Flank.
As I moved into legal AI, there was one thing I had to figure out for myself: how to explain those key legal concepts clearly to our product engineering team (ProdEng) here at Flank.
Me and my brilliant manager, Lorna, who leads our Legal AI Alignment team at Flank. We’re remote-first, so photos with the whole team are rare, but I’m sure I’ll have one with our fantastic ProdEng team soon.
When legal detail gets lost in translation
Those of us in law are trained to cover every angle, and “it depends” is practically our catchphrase. But engineers need something specific enough to build or fix. Same feedback, two different needs.
Ali Chaudry, Senior Legal Engineer at Simmons & Simmons, worded it perfectly:
“Lawyers and technologists often approach problems from entirely different perspectives. Technologists are trained to think about scalability, architecture and long-term robustness. Lawyers are trained to think about risk, deadlines, client needs and practical outcomes.”
Source: The rise of the Legal Engineer: bridging law, technology & innovation
I learnt this the hard way. Our team was asked by ProdEng to review an agent’s outputs and check the quality of its third-party contract reviews. I built a huge Google sheet covering every test result: how long the agent took to respond, what it had done well, what it had got wrong, and chunks of clauses copied in from the agreements. I thought I was being helpful by including as much detail as possible.
It had the opposite effect. Not only did the sheet take almost 3 hours of my working day to create, but it could take just as long for ProdEng to digest. It was very much an “I ain’t reading all that” moment. When we switched to jumping on a call and screensharing, the feedback from the team was that this was the best way to do it, because they could see the problems for themselves without wading through a boatload of information.
Being thorough isn’t the same as being useful
Looking back, my Google sheet wasn’t wrong. It was accurate, detailed and exhaustive. But it was the wrong shape: too much content to read through and too convoluted to be of any use.
Our VP of Product explained why far better than I could:
What stands out to me is the cost we never counted. Huge spreadsheets take so much time and effort to put together on the legal side, then take hours to unpack on the engineering side. It didn’t even matter if my results were super positive and flagged no bugs. I’d spent all that time being ‘helpful’, and the feedback was still hard to digest.
What helps instead is small, rapid feedback loops. I’ll admit, I found this way of working uncomfortable at first, because to me more detail meant more diligence on my part. But I quickly learned that feedback is only useful if it reaches someone while they can still act on it, and in an amount they can take in.
One low-effort tactic to adopt tomorrow
When you have feedback to share, send a short note and a screenshot straight away. Don’t waste time compiling all of your brain dumps into one giant file.
A template you can start using:
“Current behaviour: the agent didn’t flag that there is no indemnity provision.
Expected behaviour: the agent should have flagged there is no indemnity provision, and drafted a new clause.”
And the sooner your feedback lands, the more likely someone can fix it while the context is still fresh.
This works for two reasons. It’s quick for you to write and quick for ProdEng to read. It also tells them what kind of problem they’re looking at. Putting “expected” next to “current” often shows whether something is broken or simply missing. In our indemnity example, the playbook might never have told the agent what to do when the clause was absent, so there would be nothing to fix in the agent’s behaviour, only an instruction to add to the playbook.
Learning to speak both languages
Legal teams don’t need to learn how to build the technology themselves, but they do need to understand enough about how it works to communicate what they need. And the same goes in the other direction. Engineers don’t need to become lawyers, but they need enough context to understand why a legal requirement matters.
What I’d been practising since university wasn’t law or code, it was translation: working out what the person in front of me needs and sharing it in a shape they can use. So if you’re reading this wondering whether you belong in legal AI without the “right” background, you might already have the skill that matters.
