The Day My CEO Opened a Pull Request

Written by hacker92494927 | Published 2025/08/27
Tech Story Tags: ai | startup | code-generation | software-engineering | software-engineering-education | software-engineering-workflows | ai-ceo | ai-running-business

TLDRAt Vybe, you don't have to be a developer to open pull requests. From CEOs to engineers, see how AI coding is reshaping software production.via the TL;DR App

What happens when your non-tech CEO can open a PR? And what about your COO, head of marketing or sales? That’s not a thought experiment—it’s our daily reality. Thanks to vibe coding, we’ve built a workflow where non-developers can meaningfully contribute to the product. And no, it doesn’t break production.


Hi, my name is Paul.

I’ve been an engineer for over ten years, mostly as a full-stack developer in fast-moving startups. You won’t find any of the companies I’ve worked for, none of them still operate under the same name today—they’ve either been acquired, pivoted, or completely rebranded.

Today, I want to share a very concrete experience: how we use vibe coding to develop a production ready product. Not just demos or throwaway prototypes—real code that ends up in users’ hands.


From personal experiments to a real project

Before joining my current project, I had already explored “AI coding”: using Cursor, Copilot, Lovable, and many other tools.

I’ve actually built Super-me, an executive coach AI assistant, entirely on an AI optimized based project. I had designed a very structured folder architecture with DDD, unit tests, and custom prompts so the AI could understand my personal way of coding and generate clean, modular, maintainable code.

It worked well—but it was still a personal setup. I had full control over the generated code, and the features I would produce. The moment you work in a team, things change:

  • Different coding styles,
  • The need for shared practices,
  • And most importantly, production rigor: you can’t just “let AI code” without human control.


The setup at Vybe

Vybe is a startup where we’re building a generative AI that can create apps from simple prompts. I joined Quang Hoang and Fabien Devos as Founding Engineer to push the project toward production.

Our approach:

Everything goes through code review

That’s a classic, we’ve leveraged Github to protect our source code. Impossible to push on main, protected secrets, pull requests need to be validated, automated unit tests and security audit… Your source code will be at the mercy of anyone in your organization, it’s important to take time to protect it.

We read absolutely all the code that gets merged into the base. That’s non-negotiable: a tech engineer needs full awareness of what enters the codebase.

AI as a skeleton generator

When I start a new feature, I ask the AI to generate the first draft. Then I refactor, clean it up, and ensure quality.
AI doesn’t deliver the final code, it gives me a base to work from.

More than a time saver, it helps us understand how models generate code, acting as a manual eval. We are building an AI app that builds AI apps with an AI app after all.

Anyone can contribute

We connected Cursor to Slack, so even our CEO can request:
*“Make me a PR that sends an email to every new member invited into an organization.”
*Cursor generates the PR, GitHub automatically assigns me as the reviewer, and I apply my changes.

Out of a customer call, we allow our CS team to directly trigger the base of the new feature asked by our clients. We might not get to it right away, but the gap between starting from blank and taking over a PR is big. I can clean up a feature in a couple of minutes this way, and I’m sure it will make someone happy.

To be fair, I haven’t merged a single vibe coded PR as is so far. I’ve always had to jump in and clean up the sometimes aggressively wrong generated code. But it still gives us something concrete to iterate on. And sometimes, it surprises me with a clever idea I wouldn’t have thought of.


The balance: AI + human

The barrier between AI-generated code and production-ready code is still the engineer.
Review, testing, team discipline—that doesn’t go away.

But the speed boost is massive:

  • We ship features at record pace.
  • Ideas come from everywhere in the team—even from non-developers.
  • Quality remains high because the final filter is a team of experienced engineers.

I believe we’re moving toward a model where everyone in the company can contribute to the product, without risking production stability.


Conclusion

AI coding isn’t about “replacing developers”.
It’s a new collaboration tool that reduces friction, speeds up feature development, and opens the door to more contributions inside the company.

As long as review and quality stay in human hands, AI becomes a powerful ally to ship faster—without sacrificing production standards.



Written by hacker92494927 | Clean and factorized code provider.
Published by HackerNoon on 2025/08/27