Somebody at your company built an Excel file years ago, and the whole business still runs on it. It works, mostly. One accidental formula edit and your numbers are wrong. Half your team quietly keeps a private copy because nobody fully trusts the shared one.
Every company has this spreadsheet. When we described it at session 3 of AI for Operators, nobody in the room asked "what spreadsheet?" They started naming theirs.
It never gets replaced because replacing it sounds like a software project. Budget, a vendor, requirements meetings, a quarter of somebody's attention. Against all that, the haunted spreadsheet survives another year.
So we replaced one live, on screen, without a human writing a line of code.
From describing a thing to creating a thing
The first two sessions were about getting better answers out of Claude: a prompting framework in session 1, a persistent workspace in session 2. Session 3 crossed a different line. Instead of asking Claude to describe something, we asked it to build the thing itself.
We took a project profitability spreadsheet, inputs on one tab and fragile math scattered across the rest, and asked Claude Code to turn it into a calculator. A few minutes later it was running in the browser. Clean inputs, live results, nothing to install, nothing to break with a stray keystroke. People call this vibe coding: you describe what you want in plain English, the AI writes the code, and you never look at the code at all.
Then we pushed it. One prompt: show two projects side by side so we can compare them.
It did it. And a few parts of the calculator got wonky in the process. Layout and behavior that had been working fine got bent when the new view landed. We asked Claude to fix it, it did, and the demo moved on. Nobody in the room seemed bothered.
File that moment away. It was the most important thing that happened in the session, and I'll come back to it.
A standard operating procedure, written for Claude instead of a person
The second half of the session was skills, and the fastest way to understand a skill is exactly that: an SOP written for Claude instead of for a person.
Every operator knows the problem this solves. Your best analyst gets different results than the new hire, because the real procedure lives in her head. You can document it in a wiki nobody reads. Or you can write it once as a skill and have Claude run the same steps, in the same order, with the same checks, no matter who asks.
We took the weekly ops report we built in session 2 and converted it into a skill live. Same output, whoever runs it.
Someone asked the question I'd want to ask: what happens when a skill gets something wrong? That turns out to be the best part. You fix the procedure, not the person. Edit the file once, and everyone runs the corrected version from then on. Try that with tribal knowledge.
The napkin math
The ROI here doesn't need a vendor slide. Ten people saving four hours a week is roughly $200K a year in recovered capacity. Run the same math on your own headcount and your own loaded costs. The number moves, the conclusion doesn't.
And that's before the thing that's harder to price: decisions made on numbers everyone actually trusts.
The it-works trap
Now, back to the wonky calculator.
When we added the side-by-side view and pieces of the working tool bent out of shape, that wasn't a glitch in the demo. That was the demo. Every change to a vibe-coded tool can quietly break something that already worked, and since nobody is reading the code, running tests, or reviewing changes, you find out when the numbers are wrong.
Read that again slowly. It's the same disease the untrusted spreadsheet had. Rebuild it with no discipline and you haven't fixed anything. You've given the old problem a nicer interface.
So here's the line I draw, after watching a lot of these projects up close.
Internal tools with very small scopes: go. A calculator, a single report, a utility that does one job for you or your team. If it gets wonky, you ask for a fix, or you throw it away and rebuild it after lunch.
Tools that are going to be iterated on and used by other people: no. Iteration is exactly where vibe coding bites, as our own demo showed within one prompt. And other users means other people inheriting breakage they can't see and didn't cause. At that point you're not making a tool anymore. You're making a product, and products need real engineering: tests, review, someone accountable for the code. (That's the work we do all day. Same AI underneath, a lot more rigor on top.)
Someone in the Q&A asked whether Claude's code is any good. For a small, scoped internal tool: plenty good, and fast in a way that still surprises me. But "is the code good" is the wrong question for anything bigger. The right question is "what happens to this thing on change number forty."
Your homework stands
Pick the spreadsheet. You know which one; you pictured it the moment you started reading. Keep the scope small, rebuild it with Claude this week, and see how it feels to use a version nobody can silently break with a formula edit.
Then count how many private copies disappear.
Mike is Co-Founder of The Gnar Company, a Boston-based software development agency where he leads project delivery for clients like Whoop, Kolide (acquired by 1Password), LevelUp (acquired by GrubHub), Qeepsake (feaured on Shark Tank), and AARP. With over a decade of experience building impactful software solutions for startups, SMBs, and enterprise clients, Mike brings an unconventional perspective having transitioned from professional lacrosse to software engineering, applying an athlete's mindset of obsessive preparation and relentless iteration to every project. As AI reshapes software development, Mike has become a leading practitioner of agentic development, leveraging the latest AI-assisted practices to deliver high-quality, production-ready code in a fraction of the time traditionally required.
