Your people are already building
Somewhere in your company, someone who isn’t an engineer has built something useful with an AI tool. An operations lead replaced a weekly spreadsheet ritual with a small app. An analyst built a dashboard the whole team now opens every morning. A product manager prototyped a customer feature in an afternoon.
That’s good news. The people closest to the work understand it best: the exceptions, the workarounds, what customers actually ask for. For years they had to explain all of that to an engineering team with a queue. Now they can build part of it themselves.
The worry is what happens next. Who reviews the code before it touches real customer data? Where does it run, and who has the passwords? What happens when the person who built it changes roles? Most companies only ask those questions after something goes wrong, then spend months untangling tools nobody fully understands.
There’s a better order: put an engineer in the loop from the start.
What I set up
The aim is to make building with AI tools safe enough that you can say yes more often. Your builders keep building. I give them a structure where mistakes get caught early and quietly.
- One shared place for the code. Every tool lives in a proper repository with history, not on someone’s laptop or in a personal account.
- Review on every change. Nothing reaches production without a second look from me or a trained reviewer on your team. Reviews are quick, specific and written to teach, not to gatekeep.
- Automated tests in the pipeline. Each change runs the tests before it can merge. Your builders learn to ask their AI tool for tests along with the feature.
- A staging copy. A safe place to try changes with realistic data before real users see them.
- Sensible permissions. Tools get the access they need and no more. Customer data, payment systems and anything regulated get extra care.
- Secrets handled properly. No passwords pasted into code or chat windows.
- A weekly review. Half an hour with your builders: what shipped, what nearly went wrong, and one thing to do better next week.
- Project instructions for the AI tools. A written file in each repo telling the assistant your conventions and red lines, so it starts from your standards instead of guessing.
Coaching, not policing
The fastest way to kill this kind of initiative is to make every builder feel like a suspect. I don’t approach it that way. Your people are doing something valuable, and most of what they need is a handful of habits that experienced engineers picked up over years:
- Describe the change before asking the AI tool to make it.
- Ask for tests, and read what they actually check.
- Keep changes small enough to review in ten minutes.
- Never let the tool touch production data directly.
- Notice when the tool is guessing, and stop.
Within a few weeks, most builders catch the common problems themselves and reviews get shorter. Over time some of them become good reviewers for each other, and the system needs less of me.
Documentation, so it outlasts any one person
Every tool ends up with a short written record: what it does, who owns it, where it runs, what data it touches and how to deploy or roll it back. The program as a whole gets a plain-language overview, runbooks for common tasks, decision notes on the rules and why they exist, performance numbers where they matter, and the AI-assistant instructions for each repo. When a builder changes roles, their tool doesn’t become a mystery. You own all of it, including the code, the accounts and the review process, and any future developer or freelancer can pick it up.
Where the experience comes from
I spent seven years as a senior engineer on a multi-tenant B2B SaaS product as it grew from about four million to thirteen million dollars in annual revenue, including running its production database. Reviewing other people’s changes to a system that customers depend on was a large part of that job. I also build and run a live product on my own with AI tools in my daily workflow, so I know where they shine and where they need a firm hand.
Take a business like this one
The business in this section is a composite of the kind of company I talk to, not a named client. The numbers are the shape of the problem, not a case study.
Picture a regional logistics company with two hundred staff and a four-person IT team that maintains the core systems. In the last six months, people in dispatch, billing and customer service have built about a dozen small tools with AI assistants: a route-exception tracker, a script that reconciles carrier invoices, a customer status page. Three of them are now part of daily operations. Nobody is sure where two of them run.
What I’d do for a company shaped like this:
- An inventory first. Find every tool, who built it, where it runs and what data it can reach. Write it down.
- Fix anything risky right away. A tool with a shared admin password, or one that can write to the billing system unsupervised, gets locked down first.
- Move the tools that matter into the shared setup: repo, tests, review, staging and proper deploys. Retire the ones nobody uses.
- Set the path for new tools, with a simple request form so IT knows what’s being built.
- Run the weekly review with the builders and train two people from IT as reviewers.
- Hand over the playbook so the IT team can run the whole thing.
The dispatch, billing and service teams keep building what they need, and the IT team stops worrying about what’s running in the dark.
What it costs
It starts with a fixed-price assessment: an inventory of what’s been built, a written risk review, and a recommended setup sized to your team. After that, the setup work is scoped and quoted, and the ongoing review is a monthly retainer you can reduce as your own reviewers take over. No per-seat licences.
What I need from you
A sponsor who wants this to succeed, access to whatever your builders have made so far, and an hour with each builder to see what they’re working on. Then a regular weekly slot, and the patience to let the habits form.