Whether you are just starting out or are not in a technical role at all, you likely already have the skills you need to build your own tools.
If you have ever thought “I’m not technical enough to build that,” this post is for you.
Let me introduce the team.
We are lawyers, program managers, and business professionals—not engineers.
A large part of our work is often repetitive, like reviewing the same kinds of contracts over and over or answering the same legal questions, and our prior guidance is frequently recycled.
These are problems AI could help solve, but we lacked confidence in how to build the right tools.
That is where GitHub Copilot CLI came in.
We asked for what we wanted in plain language, plugged into our repos, and saw real changes fast. “I could never code” turned into “I just built something,” and that habit spread on its own until every one of us was building something.
What follows are two real accounts of people who did exactly that.
Plus, watch the videos for two additional stories.
Why I built an internal drafting style guide The following is a first-person account from Ngandu Kasuku, Principal Product Counsel.
I’m a product attorney, but commercial work remains a sizable part of my practice.
Around March or April, I found myself buried in partnership deals involving data, infrastructure, and product integrations.
No two deals looked quite alike, so each new matter felt like starting over.
I started using Copilot CLI to manage the surge, which helped, but also had some problems.
Then, after seeing what others had built with Copilot, I realized I wasn’t thinking big enough.
Instead of using AI for one task at a time, I could build something around the way I work.
So, I created a contract drafting tool using Copilot CLI.
I called it terms-ai, which I admit isn’t the most original name.
I started by scaffolding the project and storing key documents in a repository.
This gave me one place to organize and version the instructions, drafting resources, and workflows that guide the AI.
That structure made the results more consistent and reduced the copying and pasting that had slowed me down when I was using a library of prompts.
One of the tool’s main features is an internal drafting style guide.
Since my days as a commercial lawyer, I’ve favored plain language.
I never understood why contracts needed words like “heretofore” and “therewith.” When I discovered that an entire legal drafting movement shared this view, I used its principles as the foundation for my style guide.
I also built a library of agreements I had already completed.
Now, when an existing partner sends over an addendum or a new agreement, the tool can draw on that earlier work.
These agreements remain in an approved, access-controlled internal environment.
The tool and its general workflow are open source.
The agreements and other sensitive information aren’t part of the open source repository.
Since I began using terms-ai, I’ve cut my review and drafting time roughly in half.
My provisions are more consistent across agreements, and the drafts reflect the plain style I prefer.
The tool still has a long way to go.
But the biggest lesson wasn’t that AI could help me draft faster.
It was that I could use AI to build a tool around my own judgment, experience, and way of working.
How I built legal workflows without writing traditional code The following is a first-person account from Jesse Geraci, Online Safety Counsel.
I started with a narrow problem.
We needed to analyze source code quickly and accurately to evaluate DMCA (Digital Millennium Copyright Act) notices.
The original project began as a set of GitHub Copilot instructions for recurring tasks like DMCA triage, comparing code, license checks, and circumvention review.
We wanted to turn the messy, one-off prompt work that everyone was doing independently into something repeat