How to Deal with a "Vibe Coding" CEO (And Still Keep Everyone Happy)

As a CTO or Engineering Lead, you might find yourself in a unique position: your CEO is technical, they want to code, and they move fast. They are "vibe coding"—leveraging AI tools to generate massive chunks of functionality, prioritizing momentum and velocity over clean architecture or perfect syntax.

This can be terrifying. It can lead to "messy" PRs, architectural violations, and a pile of tech debt.

But you don't want to kill that energy. You want to harness it. Here is the playbook for managing a high-velocity, AI-reliant coding CEO without compromising your engineering standards.

1. The "Just Another Dev" Standard

The most critical rule is simple: No special treatment.

Despite the title, when they are in the codebase, they are an engineer. They must be held to the exact same standards as the rest of the team.

• Own Your Bugs: There is no "cleanup crew" for the CEO. If they ship a regression, they fix it. This enforces a natural feedback loop—if "vibe coding" leads to broken builds, they feel the pain of fixing it, which naturally encourages better habits.
• Review Rigor: Do not rubber-stamp PRs just because they come from the top. Call out architectural violations and naming inconsistencies. Use code reviews as a coaching opportunity, not just a gatekeeping step.

Real World Example: I don't let small inconsistencies slide just because of the title. Here is actual feedback I gave on a PR regarding naming conventions:

"I could approve this if you rename the name_asc and name_desc to secondary_searchable_text_asc [to match our schema standards]..."

2. The "Sandbox" Strategy

You cannot rely on willpower or "being careful" when someone is moving at AI-speed. You need systems that make it hard to ship bugs to production. The goal is to create a safe sandbox where the CEO can experiment without risking core stability.

The bottom line:
The CEO must be able to test their code locally, not just with unit tests, but functionally. Whether that’s manual testing or something like playwright, they need to be able to run the code locally, see that it works, and then open the PR.

• Mission Critical Separation: Ideally, core infrastructure and stability-critical paths should not be the primary playground for vibe coding.
• The Codebase as a Safety Net: A "safe" sandbox is built on the back of automated tooling. If your codebase has proper guardrails, the CEO can't accidentally break production with a syntax error or a loose type.
  • Strict Linting: This is your first line of defense. If the indentation is off or the types are loose, the build should fail. No exceptions.
  • Mandatory Testing: AI writes code fast; it should write tests fast too. If a PR doesn't include tests for new logic, it doesn't get merged.
  • Robust CI/CD: Your pipeline must be the ultimate arbiter. It should catch regression issues, environment mismatches, and build failures before they ever see a staging environment, let alone production.

These guardrails allow the CEO to "play" safely. They can move as fast as they want, and the system—not a person—will stop them if they color outside the lines. This shifts the dynamic from "the CTO is blocking me" to "the build failed," which is much better for morale.

Real World Example: It is crucial to catch architectural violations before they merge. Here is a real comment where I blocked a pattern that would have introduced technical debt:

"Need to update the collaboration_card web-api handler to not invoke repositories directly. Looks like a spot was missed when you updated it to not do that the first time."

3. The "Vibe" Reality

Understand that their goal is usually product velocity, not code perfection. They are optimizing for impact.

• Accept the Velocity: Don't be the "Department of No." Be the "Department of How." Find ways to let them ship features quickly while abstracting away the dangerous parts.
• Iterate: Accept that their code might be a "Version 0.5." It validates the idea. Once it's proven, it might need a refactor—and that's okay, as long as it was planned for.

Real World Example: Sometimes you have to push back on "quick fixes" that create long-term pain:

"If this isn't mission critical could we hold off on it until we get a static file storage thing set up? ... we're just adding tech debt with the avatar_data column"

Conclusion

Managing a coding CEO isn't about stopping them from coding. It's about building a padded room where they can do cool karate moves without breaking the furniture. By enforcing accountability and building automated guardrails, you turn a potential liability into a powerful engine for product growth.