All you need to do is ask

Anyone can be a legal engineer. All you need to do is ask.

That statement is deliberately provocative. Legal engineering is not easy, and asking one clever question does not suddenly make someone an engineer. But its point of entry is available to almost everyone.

You do not need to begin with a complete understanding of artificial intelligence, software architecture or even the legal process you hope to improve. You begin in the same way every good junior lawyer begins: by trying to understand something larger than you can currently see, attempting the work, discovering the limits of your understanding and asking better questions.

I did not recognise it at the time, but this was my first lesson in legal engineering: before you can improve, automate or delegate legal work, you need to see the system in which that work belongs.

‍

Things I had never seen before

When I started working as an M&A lawyer, I was asked to create things I had never seen before. I advised on parts of much larger systems without knowing the size and complexity of the whole. I dealt with mechanisms without understanding all their consequences. I communicated with people without always knowing precisely which role they fulfilled. I worked towards deadlines without yet understanding why those particular moments mattered. I handled amounts and risks whose actual impact I could barely comprehend.

And I explained things to people that had only recently been explained to me – the legal profession’s version of reading the instructions one page ahead of the person you are teaching.

This is an ordinary part of becoming a lawyer, but it did not feel ordinary while I was living through it. I often felt lost inside work that seemed too extensive and complex ever to grasp properly. An enormous structure functioned around me, while I could see only the component immediately in front of me.

Still, I kept trying.

My method was usually the same. I first attempted to solve the issue myself. I researched what I could, developed assumptions about how it worked and considered the risks and potential solutions. Eventually, I would reach a wall.

Then I would go to my supervising lawyer – my patroon, as we call it in the Dutch legal profession. That was Roald Subnel, who had the habit of discussing problems with me as though we were collaborators, even when we were obviously not equal in experience.

I tried not to bring him an empty question. I explained how I currently understood the problem, which assumptions I had made, where I thought the risks might lie and which possible solutions I could see. He would listen until I was finished. Then he would explain how he saw it.

Parts of his reasoning would overlap with mine. Other parts would expose a miscalculation, a missing connection or an entire dimension of the problem that I had failed to see. He could explain the full picture, but at first I absorbed only its foundations.

The rest of his explanation had nowhere to land yet.

‍

Understanding is recursive

Months later, we might discuss a similar issue. He could explain it in almost exactly the same way, yet I would suddenly understand something new. His explanation had not changed, but I had. The previous conversation had given me the foundation required to understand the next layer.

Every answer enabled a better question, and every better question made another part of the system visible. Years later, I would recognise the same recursive pattern in my work with AI: the quality of the collaboration depended not only on the answer, but on whether I understood enough to ask the next question and test what came back.

Sometimes, Roald did not know either. He would lean on experience and offer his best estimate – a provisional answer produced by trained intuition. I had to learn whether he was sharing a calibrated suspicion or a settled conclusion.

Gradually, my questions became sharper and my assumptions became more accurate. Our conversations became less like a one-directional transfer of knowledge and more like collaboration. Even when I added nothing new, explaining the issue to me could still be useful to him. Explanation forces thought into structure. A question can expose an assumption, require an intuition to be articulated or make a familiar problem visible from another angle.

The threshold was never equality of knowledge. It was understanding the discussion sufficiently to participate in it. Once you can understand an idea, test it and respond to it, you have earned a seat at the table where the reasoning takes place.

‍

When the structure appeared

After several years, something began to crystallise. A mental model of an M&A transaction had formed. Around it, the separate documents, deadlines, workstreams, roles, decisions and dependencies began to find their place.

I started seeing the fixed elements and the modules that changed from deal to deal. I understood why documents existed, which interests they served and why one apparently small change might affect several other parts of the transaction.

The edge cases stopped appearing random. I did not need to have encountered every possible variation before. Once I understood what an unfamiliar issue connected to and which function it needed to perform, I could reason from the system towards a solution.

For the first time, I could pull one thread and anticipate how the entire fabric of the transaction would shift. I no longer needed to have seen an issue before. If I understood its place in the pattern, I could begin to understand its nature and consequences.

My understanding of M&A seemed to enter a hockey-stick curve. Not because I had suddenly memorised all the answers, but because I had acquired a model through which I could interpret situations I had not seen before.

What people call professional intuition is, at least in part, structured experience that has become automatic.

‍

Then the structure dissolved again

When I became a legal engineer at Saga, I began creating use cases and a workflow map for M&A. I wanted to identify the general sequence of a transaction while accounting for the workstreams, modules, gateways and interdependencies that made every deal different.

With just under four years of experience, I could see the general path, but I knew my perspective was incomplete. Mapping it revealed that M&A was itself only one part of a much larger system of legal work. I knew the structure of a transaction, but not yet the structures around and beyond it.

I started designing prompts to automate parts of the workstream. Initially, a prompt appeared to be a relatively contained object: an instruction intended to produce an output. But serious prompt design immediately raised larger questions.

A good prompt required me to understand the use case it served; the use case required me to understand the underlying legal process; and supporting that process with AI required me to understand how models use instructions and context, retrieve information, produce answers and fail.

Which sources were authoritative? Where did flexibility help, and where were strict controls required? Which decisions had to remain human? How could an error be traced, and how could a correction improve the system rather than disappear after one interaction?

Again, I tried, asked, made mistakes, tested and spoke with experts and non-experts – but mostly, I asked AI to help me evaluate ideas and gain different perspectives. At times, I felt lost again – not because the structure I had learned was wrong, but because it had become one component of a larger system whose full shape I could not yet see.

I hit another wall. But hitting the wall was not a failure of the process. It was part of the process.

Until then, the ideas had existed in my mind as a cloud of charged particles – full of movement and energy, but without shape. Then a nucleus formed and the loose elements began to crystallise around it. What had been complexity became structure.

I started recognising patterns across prompts for different legal tasks. Apparently different use cases contained overlapping elements. Some things were fixed. Others had to be resolved from the matter, the organisation or the individual user.

The prompt itself began to look less like the product and more like the temporary executable expression of a much larger system. The whole machine we were working with had become a recognisable model in my mind.

I could work with this.

‍

A seat at the table

Only then did I understand that this was not merely the story of how I had become an M&A lawyer. It was also the method by which I was learning to collaborate with AI and design legal systems around it.

The analogy has a limit. AI is not an experienced supervising lawyer. It has no professional responsibility or dependable judgment of its own, and it can present a hallucination in the same fluent, confident register it uses when it is right. Its answers must be tested, challenged and validated.

But the discipline required from me is surprisingly familiar. I try something. I explain my understanding. I ask where my model is incomplete. I examine the answer, test it against reality and expertise, and return with a sharper question.

As with Roald, the threshold is not equality of knowledge. It is understanding the discussion sufficiently to participate in it: to inspect what the model produces, ask which assumptions and evidence support it, test its method and recognise which decisions remain mine.

Lawyers underestimate how well prepared they are for this. They already model and simulate complex, abstract situations. They anticipate consequences, work through exceptions and express intended outcomes with precision. The challenge is not acquiring an entirely foreign set of abilities. It is recognising those abilities as parts of a system and learning how to use AI within it.

That does not make every lawyer a legal engineer by default. Professional intuition is the raw material. Legal engineering begins when that intuition is translated into processes, criteria, handoffs, controls and feedback loops that can be inspected and improved.

The decisive shift occurs when you stop asking only for an answer and begin asking about the route to the answer.

What are we actually trying to accomplish? What must be true before we can begin? Which information is necessary, and which would merely create noise? What is authoritative, current, contested or missing? Which steps lead from the present situation to the desired one? Where might the process fail? What should the system do, and what must a human decide?

Those questions are the beginning of legal engineering.

My advice: try. Reach the wall. Work out exactly where your understanding stops.

Then ask.

Asking is not the whole of legal engineering. But beginning really is that simple.

All you need to do is ask. Then ask again – until the hidden system becomes visible enough to inspect, engineer, test and improve.

The next article in this series begins with one of the systems I had learned to see: the contract. It asks what sits beneath the document itself, and how lawyers design the mechanisms that turn one legal reality into another.

‍

‍