I keep meeting smart people who say the same thing: I could never build something useful at work. That sentence is almost always wrong. What they usually mean is that nobody ever gave them permission to try. The GitHub legal team spends most of its week on contracts and recurring questions, the kind of work that loops back on itself. Instead of asking engineering for help, several of them opened a terminal, ran prompts through Copilot CLI, and shipped internal utilities that the team now relies on. No degree required. No permission slip. Just typing and an afternoon of looking foolish in front of your peers.
What I want to pull apart is not the technology. It is the cultural mechanics. How does a team where nobody has a CS title end up writing and maintaining its own software? The answer turned out to be less about tooling and more about who got first dibs on the friction.
One lawyer, one weekend, one ugly repo
Ngandu Kasuku is a Principal Product Counsel at GitHub, and partnership deals kept stacking up through the spring. Each one combined data, infrastructure, and product terms in slightly new ways. The boilerplate was the same. The hours were the same. After a few weeks of running Copilot CLI task by task, she noticed something her colleagues were quietly shipping on the side. That shifted her framing.
She had been using AI the way most people use it: paste a paragraph, ask for a polish, paste it back. That is find-and-replace with extra steps. The workflow underneath never moved. Watching her colleagues, she saw a different shape: not a polish, but a wrapper around the whole job. So over a weekend she wrote a small project, called it terms-ai, and pushed it to a private repo. The name is unoriginal and she is fine with that.
What makes the project worth dissecting is not the code. It is the four pieces of plumbing she chose to wire up:
- A single repository for every drafting rule, reference document, and style preference, so the source of truth is one place instead of three Google Docs called
FINAL_v3_REAL - An internal archive of past approved agreements that the tool can scan when a new addendum arrives, so the new language mirrors what the team has already signed off on
- A plain-language style guide wrapped around every draft, because legal writing does not need to sound like a deed from 1820
- An access-controlled environment for the underlying agreements, because legal teams that pretend access control is optional learn quickly that it is not
The first three are obvious. The fourth is the one most people forget, and it is the one that decides whether security is on your side or against you.
The boring habits that made it spread
Once the first utility landed, the question was whether anyone else would build one. The answer came down to whether the first builder made the second builder feel invited. Three habits seemed to do most of the work.
First, the repos were ugly on purpose. A clean repo signals that someone polished it before showing the team. An ugly repo signals that someone shipped it before polishing. The second signal is the one you want, because it lowers the bar for everyone watching. Ngandu’s first version was a pile of markdown and prompts in a single folder. That was the point.
Second, the tools were scoped tight. Each utility handled one annoying job. Nobody tried to build a platform. Nobody tried to build a framework. Each person picked the friction that annoyed them personally and wrote the smallest thing that solved it. The cumulative effect was that the team owned a collection of small, sharp tools instead of one large, abandoned platform.
Third, the work happened in public inside the team. A Slack channel for tool demos. A weekly fifteen minute share. No all-hands announcements, no leadership memos. The visibility was enough that the next person saw what was possible without anyone having to pitch it.
If you are trying to seed the same dynamic on your own team, the recipe is simpler than you expect:
- Pick one task that annoys you personally, and ship the smallest possible tool that handles it
- Push to a repo, even if the repo is ugly and the README is two paragraphs
- Demo it in a team channel for ten minutes, with the repo link, no slides
- Let the next person copy the structure rather than your code
That last point matters more than it sounds. Copying the structure scales. Copying your code does not.
Where non-engineers get stuck, and how to unstick
Three things go wrong when people without engineering backgrounds start shipping internal tools. The same three things, every time. They are all solvable, but only if you spot them in advance.
The first is access control. If your tool can read sensitive documents, decide ahead of time where the data lives and who can run the tool. Do this before writing a single line of prompt logic, because retrofitting access control is miserable. Ngandu’s team spent a week on this conversation before writing any tooling, and it saved them months of cleanups later.
Quality drift is the second trap. AI output reads as confident, which makes it tempting to ship a draft straight to a counterparty. Resist that. Keep a human review step in the loop for anything that leaves the team, especially anything with legal or financial consequences. The tool is a draft generator, not an approver. The lawyers stay the approvers. That division is what keeps the output trustworthy.
The third is shadow IT. The moment the first tool lands, other people on the team will copy the pattern. That is the goal. It also means your team is now running software that nobody on the security or platform side has reviewed. Loop them in early, ideally before the first tool ships, so the review process is already in place when the second and third tools arrive.
None of those three problems require an engineer to solve. They require a conversation, a checklist, and a willingness to send a few boring emails.
Trade-offs
This path is not free. The first tool takes longer than you think. Writing a style guide is real work, not a one hour exercise. Getting security to bless a new repo is not a five minute email. Plan for two or three weeks the first time, plus another week for the inevitable review cycle that surfaces issues you did not anticipate. For a team that has never shipped its own tooling, that overhead feels heavy. It is not actually heavy. It is just front-loaded.
The upside compounds. The first tool feels like extra work. The second tool feels like a copy-paste of the first. The fifth tool feels almost free, because the repo layout, the access controls, and the review pattern are already in place. That compounding is the entire reason this approach is worth the awkward first month. A team that ships one tool a quarter is not meaningfully faster than a team that files tickets. A team that ships one tool a month for a year is unrecognizable by December.
In Ngandu’s case, the legal team traded a few weeks of first-build friction for hours saved on every partnership deal from then on. Your math will be different if your work is not contract-shaped. If your week involves any kind of repeated analysis, message drafting, or review cycle, the math probably still works in your favor.
Your next step, if you want to copy this
You do not need to build a contract tool. Pick the one piece of work that grinds your week down. Ask Copilot CLI to help you wrap that work in a small command-line utility. Keep the first version rough around the edges. Push it to a repo. Demo it to one person who has the same problem. That is the whole game in one paragraph.
Past me would have heard that the scary part is the build itself. It is not. The scary part is deciding that you are the person who is supposed to ship it. You are. The rest is just a long evening of typing and a Slack message with a repo link when you are done.
Original Source: How the GitHub legal team used Copilot CLI to streamline their workflows