Should Lawyers Learn To Code? If You Have A Good Use Case, Yes

Should lawyers learn to code? The question that has launched a thousand conversations at legal tech events, with the answer usually being: no. But, maybe something has changed now with the arrival of a more focused approach and some real use cases for those potential coding skills.

Cue Firelex, a document automation company from the same stable that has given us Wall Street Docs and AI-driven contract review and negotiation platform Scissero.

Investigating a truck accident is a search for the truth. Reliable auto accidents lawyers can collect and preserve evidence of truck driver and trucking company negligence which cause truck crashes. When a loved one was in an accident leading to death, contact an experienced wrongful death attorney for a case review. Filing a wrongful death suit is like filing a personal injury claim, except the injured victim is not available to file the claim. The victim’s immediate family will be the ones seeking damages.

Firelex provides truck accident lawyers with two main things: templates of standard commercial legal documents – nothing especially new there; and – a platform that allows for relatively straightforward coding to create your own bespoke automated contract templates. And arguably that may not be totally new either (see below re. what do we even mean by ‘coding’ *). But, their approach is very much on you taking control of the process yourself, right down to the coding, rather than needing a third party to create your templates for you.

How does it work? Check out the video below for starters, but, here are the key steps:

  • If you can’t find the template you need in the Firelex library, you can create a new one.
  • Using their simplified coding language that’s based on JavaScript, you are guided through the steps to build a ‘form’ (which then helps other users to then fill in the documents you’ve automated), using ‘code snippets’.
  • You can lay out the fields for populating the template in a variety of ways to make it easy for users to complete their documents.
  • You can add a header, a boilerplate, headings and paragraphs; and retrieve data from the form submission for dynamic content.

You could say it’s a sort of DIY HTML-style approach to document automation, where you use Firelex to create an online interface using their simplified coding language. The interface you create and structure can have boxes and menus that help later users of the template to quickly complete the document you’ve designed.

What this does is allow lawyers to build their own self-service automated template documents without needing to get someone else to do it for you. Once made the automated document works like many others.

Is this of any use?

Well, if you accept that document automation is useful in terms of efficiency gains and that self-service interfaces are a benefit especially for more routine documents, then the answer has to be: yes.

Is the coding bit complex?

Artificial Lawyer has seen a demo and it looked like with the level of coding needed, that if you really wanted to learn it, then you probably could get the basics quite quickly without any prior knowledge. This is because the range of things you’re likely do with it are quite narrow and highly structured, so it’s not like learning everything possible, just the few bits you need, and that – in theory – should make it ‘easy to learn’.

Does this change the response to the old adage ‘should lawyers learn to code?’

Yes and no. Should…or must…lawyers learn to code because they now work in a world of more software tools..? Nope. Of course not. You don’t need to know how to code all the software you use in your life.

But should lawyers who actively want to create their own bespoke templates in this way learn to code? Now, that’s a different proposition. And the answer has to be: if there’s actual value in you doing it yourself, so you get the template you want in rapid time and don’t need to outsource it to consultants or your already busy tech team….then it seems like a good idea.

Does this mean all lawyers need to learn to code now…? Nope. Little has changed there. It’s still going to be a very niche thing, namely for those lawyers who fancy being able to do this coding work themselves. And that is never going to be everyone. It might just be three or four lawyers in each firm, or one person in an inhouse legal team. But, this would still be quite a sizeable population when spread across the entire legal market.

If learning how to do this sounds interesting, the company behind the platform, Firelex, is holding what it’s calling a hackathon later this year to help people to learn how to use its system.

From September 1 to September 30, their coding experts will come to your offices once a week for training and to answer your questions.

Then, all participants in the hackathon will be invited to an event in London in October, where they will present their projects to a jury of lawyers and coders, who will pick the Firelex lawyer of the year.

If you’d like to know more, you can check it out here: https://firelex.com/hackathon2019/

And here’s a short video on how the system works.

[ * ‘coding’ – the term itself is used very broadly in the legal world. Do we mean setting up very basic commands in contract automation systems, of which there are now many on the market? Do we mean creating the interface for an automated template, as in this case with a modified version of JavaScript? Do we mean the coding of computable self-executing clauses in smart contracts using systems such as the software provided by the Accord Project, such as Ergo and Cicero, and the software provided by other smart contract platforms? Or do we mean full-on software creation where someone is designing and building an entire application in code, as opposed to very small segments of it?

The reality is that with the general way we talk about ‘coding’, the term refers to all of the above. It’s become a kind of shorthand to mean ‘anything that is not natural language’.  It feels like we may need to differentiate things now, especially given the proliferation in ‘coding’ models and approaches, from very basic, to super complex. For now, it looks like we are stuck with the umbrella term, but AL would be interested to hear if anyone has a user-friendly taxonomy that can divide up the various uses. ]

7 Comments

  1. Over 20 years ago I used Microsoft Word to automate processes.

    It did not have the bells and whistles of commercial products but addressed only the current needs of the service.

    Colleagues learnt to love tech.

  2. Hello Richard,

    With Juridoc (coming in the next few days), lawyers will not have to learn how to code at all to automate documents. And it will not take hours but minutes to do it in our platform. Stay tuned ! 🙂

    • I think the question isn’t so much whether lawyers HAVE to code, but whether they get a chance to do so. It’s 2019, we all live with technology, we love it, and it’s here to stay. Coding isn’t the scary beast it once was. It’s empowering and it’s fun – like driving a car or riding an escooter.

  3. I agree with Maxime. The coding can be automated for both new templates and legacy documents. My company works with Legal AI engines, feeding them native Microsoft Word documents. Our first contract came to us quite by accident, because the existing PDF-OCR method of converting these complex documents to AI ready text was fraught with errors. And we do excellent PDF, even for the most complex and lengthy documents.

    The thing is, once we understood the Legal AI problem with complex MS Word documents, we knew the most accurate route was to separate document content from styles, vector label the content text creating “ranges”, feed this into the AI engine, and then merge the results back into the original native document. All in real time.

    Since our core competency is that of browser-based viewing and collaborative editing of complex native MS Word documents, the AI engine can be treated as just another collaboration member; able to highlight, edit and comment.

    From a document perspective, the Legal AI industry looks to have three generations, and we are ready to work on the third level.

    For argument’s sake, we reference the three generations as:

    I. Static Reports based on PDF-OCR reading of complex native documents

    II. Real-time direct interaction “inside the document”, where the AI engine is editing and commenting while collaborating with lawyers and legal teams.

    III. Blockchain Smart Contracts and Documents

    Since we have “programmatic” control over all documents fed into the AI engine, we can insert blockchain code. What we need is to have the AI engine trained to identify the actionable components of a contract; the tags and triggers needed to initiate a new block. The AI engine passes the tags to our software as part of the collaborative editing process.

    Etherium has automated the process of initiating a blockchain / new blocks, using a simple scripting language called “Solidity”. It’s very JavaScripty looking 🙂 But perfect for automating this process at the application level.

    There are some questions about performance with Etherium Blockchains, but the idea is extraordinary. Technically, it’s possible to set up Etherium inspired blockchains within lightning fast Cloud centers from an Amazon or Google type player.

    The other thing I would like to point out is that this process is designed to deal with the billions of legacy native MS Word documents. They don’t have to be recreated. Just pushed into a whole new direction, while still continuing to service the legacy workflow they fuel.

    This document-centric perspective applies to Legal AI in one other way. As a platform, the great promise of the Internet has long been the integration of “communications, computation, and collaboration”.

    When you look into the components of that string, you will realize that for business, “computation” includes Data and Documents. The information that fuels every business is captured as data, documents, and collaborative-communicative methods.

    For an AI machine to be put to maximum use, it needs access to data, documents, and methods. Data is easy to manipulate, move and share. And it has long been the case that many applications are able to operate on the same data sets. (Not good news for Oracles Cloud Computing future).

    This is not the case with documents! All advanced and typographically rich productivity documents are “application specific”. They are locked into the application that created them. In most cases, MS Word.

    The documents are also rich with both data, human assessment, and knowledge. They are the corporate jewels. Especially if we are able to capture the human methods and collaborative interaction surrounding documents.

    We now know how to unlock these documents and feed this rich information set to AI engines. We also know how to enable an AI engine to interact within the document, and in direct collaboration with humans. It’s like having a legal spellchecker kind of nanny, watching and helping humans make decisions. Note that the AI engine will have a front row seat to learn from human methods.

    I have no idea how this will impact the Legal industry. My guess is that the engines get very smart feasting on all three information components: data, documents, and methods. And, I think the AI engines are going to fully control blockchain smart documents.

    Wow, what a world we live in!

    ~ge~

    • Gary I suggest that you try to dumb down your comments so that it makes sense and is readable by the average lawyer (I assumed that was the target audience). No doubt your post was full of great insights but it was lost on this simple lawyer.

      • Thanks Rob. You have identified that it is difficult for technology obsessed people to communicate. You perhaps have also answered the question at hand. My job in technology is to greatly multiply your expertise and efforts as a lawyer. Not through dialog. That is an integral part of your bailiwick. But through code. Software code.

Leave a Reply

Your email address will not be published.


*