The Vibe Coding Earthquake: What Happens When Non-Engineers Ship to Prod

Last few weeks, we went through an earthquake at illumi.

I’ve been working in AI since 2016, but this is one of the first times I’ve felt a solid, hands-on shift. I moved past just chatting with AI and started building actual agent Skills for myself.

Skills? They are specific abilities or capabilities that an AI agent has been designed or trained to perform. (and they don’t just GENERATE, they can EXECUTE)

I was never overly excited about RAG or MCP. They are powerful, but they require deep technical preparation to work well. Skills are different: you can start small, build today, and see immediate execution.

At first, I started to apply skills on marketing tasks, building a mini “content engine” with multiple skills - researching, analysing, writing, image generation, and publishing: which made the process vastly easier.

But the real turning point hit when I realized I could just “vibe code” features in my head directly on top of our production codebase when I created a “product feature planner“ skills myself.

I built a working demo, tested it, and proudly submitted a PR to hand it over to engineering.

It took our engineers several stressful days to clean up and refactor my AI-generated code. I almost felt like I destroyed them. We ended up having a very honest talk about what needs to change in how we work and how to properly embrace this wave of AI-assisted development.

The productivity win of building a functional demo inside the product (instead of drawing Figma mockups and writing specs) is undeniable. But it made one reality starkly clear:

A strong code foundation and clean architecture are everything if you want creativity to flow on top of it.

Documentation, guardrails, code standards, and best practices don’t just matter: they compound. Without them, “move fast” turns into “create debt fast.”

To solve this, our engineers created several specific skills for my agent (and we reviewed them together). These skills ensure the agent respects our coding standards and clearly frames the specific areas of the codebase it is allowed to touch.

After two weeks of trial and error with these new guardrails, the results have been massive:

• We’ve merged almost 10 pull requests (from me!!).

• I successfully updated UI which I’ve wanted to change for a long time.

• I now have 5+ branches about new features that’s coming

More importantly, I feel genuinely liberated! I’m no longer hesitant to tackle a “too tough” request. I can try it myself, demo quickly, and iterate with the team until it’s right.

Despite the excitement and sense of achievement, it hasn’t been completely smooth. You know what the most painful bottleneck for me is? It’s managing Git branches. I almost cried a few nights trying to untangle version control, and I felt so stupid.

This experience forced a critical question: How do teams actually work together with AI? How do they manage the required context, documentations, rules that would frame their agents?

AI is incredibly capable, but real work involves real people, real systems, and real constraints. How do we get meaningful AI assistance without slowing each other down or killing execution?

This is actively making us rethink the value of illumi. What if I could come back to illumi to plan features and vibe code the demo without directly touching the “sacred” engineering environment, yet remain close enough to the codebase to be immediately useful?

We are working hard to make illumi to be the answer to this question. Stay tuned!