Vibe Coding for People Who Can’t Code: A five-part series. Part V — Doing this at work
In Part I of the series, we talked about vibe coding basics, in Part II, about how to get setup, in Part III, the build, and in Part IV, testing. Today in Part V, the final installment here, we talk about vibe coding at work. As in, “Kids, don’t try this at work” (sort of).
What I tried
I had an idea for reengineering some major swaths of my company’s workflow and business process with a whole new system underneath it to match the changes AI has brought to getting work done in a software company (more on that in subsequent posts). So I started designing a system in a Claude Project, and the design part worked — which is itself evidence for Part I’s claim that the Project is where you think. Then I tried to build it, wiring it into our real systems. I got in trouble with our IT department, because I’d started putting webhooks into our Slack and reaching behind the firewall. I believe Shawn’s exact words were “Ok Matt, what kind of trouble are you getting into here?” And then we paused the whole project — because it was genuinely important for work, and it had gotten too complicated too quickly for me to carry alone.
Two lessons, both mine to own. I broke my own small-first rule: a corporate system is not a grocery list, and I’d have told anyone else not to start there. And IT was right. At home the only person I can hurt is me; at work I’d quietly become a security surface, and nobody had asked me to be one.
Why work is genuinely a different game
Four things change at once, and together they’re the whole reason that vibe-coding-versus-engineering line matters.
“You are the user” stops being true. The first rule of Part I doesn’t survive contact with an organization. You’re building for people whose judgment about the output isn’t yours, and who disagree with each other about what “right” even means.
The data isn’t yours. Company data has rules attached, and those rules exist whether or not you know them.
Someone will inherit it. A personal tool can die with your interest in it. A work tool that people depend on cannot — the moment colleagues rely on your weekend build, walking away from it stops being free.
There’s a real perimeter, with real reasons. The firewall isn’t bureaucracy. It’s the thing standing between your enthusiasm and a breach.
The unlock: build the safe place
Here’s the move that actually solved it. This is going to sound really meta, but Martin, our head of technical operations, vibe-coded a vibe-coding platform that lives behind our firewall. It’s a safe environment where people at work can build applications that connect into our internal systems, without any single person becoming the security problem I’d become.
Why it’s the genuinely novel move in the whole series: he didn’t route around IT, and he didn’t wait for permission. He applied the technique one level up and built the sanctioned place. It’s also the real answer to the responsibility line — this platform lets people vibe code responsibly at work, because the platform carries the quality-and-security burden that no individual amateur builder could personally promise.
The detail that matters most for anyone leading a company: Martin is far more technical than I am — not a full-time software engineer, but someone who’s been writing backend code for years. The person who solved the institutional problem had real depth, and used it to make the technique safe for people who don’t. That division of labor is the thing to point at.
The result: anyone in the company can now build small, useful applications against our own systems, safely. That is a categorically different capability from one CEO with a build tool and too much ambition.
What changed when a group took over
The system project came back, and it came back different. A group adopted it — including our heads of product and engineering — and we’re building it together now. The most instructive change: we lean far harder on off-the-shelf components wherever they exist. That’s Part III’s “rent what isn’t your product,” at organizational scale — more people didn’t mean more building, it meant more discipline about not building. And with the right people in the room, the questions I couldn’t answer alone get answered. The thing that was too complicated for one person turned out to be the right size for a group with the right skills.
If you run a company
Four things, stated plainly:
- The demand exists whether you sanction it or not. Your people have the same tools I do. Some of them are already building.
- Saying no produces shadow IT, not safety. I’m the proof — I’m the CEO and I did it anyway, and I wasn’t being reckless, I was being useful.
- The answer is a safe place plus a size limit. Somewhere sanctioned to build, and a clear norm that what gets built there stays small.
- The builders don’t have to be engineers. They do have to be trusted, and supervised by someone who owns the perimeter.
Closing the loop
Five parts, and the difficulty moved five times. The difficulty was never in the code. It was in deciding what was worth building. In not quitting during the boring setup. In specifying clearly and choosing what not to build. In noticing that something confident and well-formatted was quietly wrong. And finally in recognizing that the thing I could do alone at my kitchen table was not the thing I could do at my company — and that the fix wasn’t a better tool, it was a safer place and more people.
I love my three applications. I may build more, I may not. It’s possible they’ll all still be part of my life in 5 years, but that’s not a guarantee either. Bedrock could help fix what’s wrong with our country’s politics, or it may never get used again. But I’m so glad I learned how to do this work. It will make me a better CEO, and it’s keeping me sharp and current with AI. I hope this is a useful series for you if this is a journey you want to go on and don’t know where to – or are afraid to – start.
Martin Hempstock, Shawn Nussbaum, and Andrew Winston read all five parts in draft. Andrew co-wrote Part II, and his Context Coach is one of Part I’s examples; Martin is most of Part V, and the reason the hosting advice is as blunt as it is. Whatever’s still wrong in here is all me.