The Circular Saw Problem

Your sales ops manager just built a tool. It pulls customer data from the CRM, reformats it overnight, and pushes updates to the ERP. She demoed it last week to a standing ovation. Management called it a "force multiplier." She shipped it to production on Friday.

Nobody asked how it authenticates. Nobody asked what happens when the CRM API returns an error. Nobody asked whether the third-party formatting service it calls has a data retention policy. Nobody asked — because the person who would have asked those questions wasn't in the room, and in a lot of companies right now, they're no longer in the building.

This is the pattern engineering managers are describing right now. One put it plainly this week: "We assume our team is using these tools well, but we can't actually demonstrate it." That was about his developers. The harder version of that problem is what happens when everyone else in the company starts building too.

The Circular Saw Is Real

Nobody's disputing that AI lowered the barrier to building software. It did. A determined non-engineer with a capable model can now produce working code for a specific, well-defined task faster than a junior developer could eighteen months ago. That's a genuine shift.

The part getting glossed over is what "working" means. A circular saw is a real tool. It cuts. When you hand one to someone who doesn't understand kickback, kerf, or the grain of the wood, you don't get a person who can't use it. You get a person who uses it confidently, right up until they don't.

Experienced engineers are noticing the after-effects. The pattern: a non-technical person built something that works on the surface. Users hit it. Things fall apart — slow queries, auth logic that's swiss cheese, error handling that catches everything and does nothing with it. The code passed a demo. It didn't pass production load.

But the ops manager's CRM tool is a different problem than a founder's AI-generated MVP. The MVP fails and you clean it up. The ops manager's tool fails inside your production environment, potentially with customer data, on systems you own, with consequences that don't stay in her lane.

The Org Chart Has No Load-Bearing Walls

What changed isn't just that non-engineers can write code. It's that the tools they're building connect to production systems — your APIs, your databases, your customer data. The circular saw isn't in the workshop. It's in the walls of the house.

When a developer ships to production, there's usually a chain: code review, security review, deployment pipeline, monitoring. That chain exists because someone understood why each link matters. When a non-technical person builds a "productivity tool" that hits the same APIs, that chain doesn't apply. Their tool isn't in the repo. It isn't reviewed. It lives in a folder on their desktop that syncs to a cloud drive.

The engineering team finds out when something goes wrong. By then, the tool has been running for three months.

This is what engineering managers are starting to call "the audit problem." Not whether they can see what their developers are doing with AI — it's whether they can see what everyone else is doing with AI. The governance question has expanded from "are our engineers using these tools with judgment" to "are all the people now building software using them with judgment?" For most organizations, the honest answer is that they have no way to know.

And the regulatory pressure is making that ignorance expensive. EU AI Act requirements, ISO 42001, enterprise vendor questionnaires — the conversation is shifting from "are you using AI" to "can you prove your team is using it responsibly." Most companies can't prove the first thing. They definitely can't prove the second.

You Can't Take the Saw Back

The reflex here is to lock things down — restrict API access, require engineering review for anything that touches production, mandate that all tools go through IT. These aren't wrong instincts, but if they're the whole response, they'll fail.

The tools are already out there. The people who built productivity solutions over the last eighteen months aren't going back to Excel pivot tables. Block them completely and you've traded an invisible risk for a visible revolt — and the resentful workaround they build next will be harder to see than the thing you shut down.

You have two paths. Lock everything down and watch people route around you. Or start with architecture: define the blast radius of different API surfaces. Some endpoints are fine for anyone to hit. Others touch customer PII, financial records, or downstream systems where a bad write can't be undone. The governance layer that matters is the one that distinguishes between those two categories — and makes it structurally difficult to touch the second without a review.

That's not a policy document. That's an architectural decision. It requires someone who understands both the technical implications and the organizational behavior well enough to design something that will actually get used rather than routed around.

The Role That Was Always Supposed to Own This

The gap here isn't a tools gap. Every company already has the tools to build API gateways, define scoped credentials, and create sandbox environments that non-technical builders can use safely. The gap is a judgment gap — someone needs to map the organization's building activity to its risk surface, and that person needs enough cross-functional authority to make architectural decisions that cross departmental lines.

That's a CTO problem. Not a "hire a full-time CTO immediately" problem — most organizations experiencing this don't need new headcount. They need someone with enough altitude to see the whole board: what's being built, what it's touching, where the load-bearing walls are, and how to create a perimeter that enables building rather than shutting it down.

The companies that will have the uncomfortable audit conversation aren't the ones that let non-technical people build. They're the ones that let it happen without anyone mapping the consequences.

If you're watching your organization hand out circular saws and wondering who owns the liability when someone cuts through a beam, that's worth a conversation before the wall comes down. Reach out to The Bushido Collective.