You Don’t Have to Vibe Code. You Have to Understand It.

There’s a concept in meditation practice that I keep coming back to lately. When you tell a meditation teacher that you’re too busy to meditate, they don’t let you off the hook. They tell you that’s exactly when you need it most — and that you should probably sit for twenty minutes instead of ten.

I think about that a lot as an operator navigating a world where AI is now a permanent colleague.

The pressure to adapt is constant. The tools are evolving faster than most of us can absorb them. And the instinct, especially for leaders who are carrying the weight of daily operations, is to defer. I’ll dig into that once things slow down. I’ll get up to speed next quarter. But that’s the same logic as skipping meditation on the days you need it most. The gap doesn’t close on its own.

The Before Picture: The Tool Sprawl Problem Nobody Talks About

To understand why this matters, it helps to see what “tool sprawl” actually looks like in practice.

At Xponent21, our SEO strategists were routinely moving between eight or more platforms to execute on a single client engagement — Asana for project management, Google Drive for documentation, SE Ranking and Screaming Frog for technical audits, Cognizo for AI citation tracking, Google Search Console and Google Analytics for performance data, AirOps for AI-assisted content operations, and the client’s content management system on top of that. Each tool does something the others don’t. Each tool has its own login, its own UX, its own way of storing and displaying information. Context-switching that many times across a single workflow isn’t just inefficient — it quietly degrades the quality of the thinking.

That’s the operating reality for most mid-market teams right now.

The question a lot of business leaders are starting to ask — and the one we’ve been actively working through — is whether that model still makes sense. Third-party SaaS is not going away, but the calculus has changed. Purpose-built internal tools are now within reach for companies that aren’t Google or Salesforce. The cost to build has dropped dramatically. The specificity you can get from a tool designed exactly for your workflows, your data, your team — without the overhead of features you’ll never use, without the privacy and security exposure of sensitive client data sitting on a vendor’s servers — is increasingly hard to ignore.

We made the decision to build. And that decision came with a learning curve I didn’t fully anticipate.

What Two Days in an AI Builder Actually Taught Me

I want to be direct about something: I have a strong technology background. SaaS, workflow automation, systems architecture — these aren’t foreign concepts to me. I am not someone who gets intimidated by new tools.

And I still felt the friction.

I decided to spend two days working directly in Lovable, one of the leading AI-assisted app-building platforms. I had no goal of becoming a vibe coder or developer, but I couldn’t do my job effectively without understanding the build environment. You can’t make good operational decisions about something you don’t understand. You can’t give meaningful input on strategy, resourcing, or direction if you’re working entirely from secondhand descriptions.

What I found was genuinely different from anything I’d encountered before. Vibe coding — the practice of building functional software by describing what you want in natural language, with AI generating and iterating on the actual code — isn’t just a faster version of traditional development. It’s a different kind of collaboration. It’s more intuitive in some ways and more disorienting in others.

But here’s what mattered: by the end of the first day, I had something useful to contribute.

We’re building a suite of apps — a cohesive, interconnected set of tools designed to support specific parts of our service delivery and operations. The instinct in any build process is to take things one at a time: build App A, then build App B, and treat each as its own project. But I saw quickly that we were going to recreate the same foundational infrastructure — user authentication, access controls, feedback and roadmap features — for every single app. This redundancy burns compute, creates inconsistency, and compounds maintenance burden over time.

My recommendation was to establish a shared base build first: a common foundation with single sign-on, unified access across all provisioned apps, and a shared Product Roadmap feature where team members can submit bugs or suggestions to inform our development sprints. Instead of building nine separate environments that happen to look similar, we build one coherent platform that scales.

That was a first-day contribution. Not from someone who’d been deep in the codebase for months — from someone who understood operations and took two days to get close enough to the work to see what was actually needed.

That’s the point.

Your Hesitancy Is Rational. It’s Also a Problem.

I’m going to be honest about something that I think most leaders in my position aren’t saying out loud.

Someone I work closely with — someone I’d describe as genuinely one of the most AI-forward operators I know — is currently executing on a personal challenge of building 52 apps this year. He’s the founder of one of the leading AI nonprofits in the country. He is, by any measure, all in. And even working that close to that level of momentum, I felt hesitancy.

Not because I don’t understand the stakes, nor because I’m resistant to change. Because I’m an operator. And operators are load-bearing. When you’re running daily operations, managing client relationships, overseeing a team, making financial decisions — the cost of slowing down to learn something new is visible and immediate. The cost of not learning it is diffuse and delayed. That asymmetry is why hesitancy is rational, even for people who know better.

But rational doesn’t mean right.

Here’s what I’d offer to other operators who are sitting with that same tension: your hesitancy isn’t a character flaw. It’s a signal. The discomfort you feel is proportional to how significant the shift actually is. If this were a minor upgrade to an existing workflow, you wouldn’t feel it at all.

And if you’re feeling it — your people almost certainly are too. With less context about where things are headed. With less agency over what comes next. With more direct anxiety about what the shifting landscape means for their roles.

What Leaders Owe Their Teams Right Now

This is where I think the Chief Work Officer lens matters.

The CWO role — which I’ve been building out and writing about for years now — sits at the intersection of people, process, and technology. It’s a role that treats the design of work itself — the workflows, the tooling, the team structures, the capabilities being developed — as a strategic function.

Right now, that function is more important than it’s ever been.

Because the decisions being made in the next 12 to 24 months about how your organization uses AI — what you build, what you buy, what you automate, what you protect, how you bring your team along — aren’t operational decisions. They’re cultural ones. They will define what your organization is capable of, and they will either build or erode trust with your workforce depending on how they’re handled.

Modeling the learning matters more than modeling the mastery. Your team doesn’t need to see you with all the answers. They need to see you willing to sit with uncertainty, take a few days, do the work of understanding — and come back with something useful. That’s what stability actually looks like in a period of rapid change. Certainty isn’t the point. What your team needs is demonstrated willingness to move through the unknown and bring people with you.

The question isn’t whether to prepare your people for roles that don’t fully exist yet. That’s already your job. The question is whether you’re doing your own version of the work — or waiting for a slower moment that isn’t coming.

The Smallest Investment With the Biggest Return

I came away from my time in Lovable with a clearer picture of what’s actually possible, what the real constraints are, and where the leverage points exist in how we build. I also came away with more credibility with my team — the kind that comes from firsthand understanding rather than secondhand descriptions.

For mid-market operators thinking about whether to build internal tools, move off legacy SaaS stacks, or explore what agentic workflows could do for your operations: the barrier to understanding is lower than you think. You don’t have to become a builder. You have to get close enough to lead.

Take the two days. Sit for twenty minutes instead of ten.

The gap doesn’t close on its own.