Moving Beyond "Vibe Coding"

About a year ago, I shared that I was stepping into the prompt engineering role here at Eliq. It’s been an incredible journey, and after spending the last 12 months deeply observing, testing, and understanding exactly what and how we need to change in our engineering teams, I am back to my original role, armed with a playbook that feels like discovering a gold mine.

I promise this isn't a humblebrag but if you're leading engineering teams or building software today, you'll want to read this.

By restructuring our internal processes around AI, we have boosted our efficiency big time. We are now 95% faster than we used to be.

Of course, there is no "final" or single solution when it comes to engineering with AI; every team will find their own unique rhythm. But sharing is caring, and I hope our success story can help you scale and improve your own teams.

I feel incredibly lucky and blessed to have been with Eliq for the past 7 years and counting. Eliq has always been an environment that welcomes new ideas, allowing me to run numerous experiments over the years. Some failed, some succeeded. This one? This is a massive success story.

We did it by pioneering what I call the OOPPSS Methodology. Here is how it works:

1. “Observation” & “Owning” the Product

This is arguably the most critical phase of modern software development. Without deep ownership, you fall into the trap of "Vibe Coding."

Let’s be honest: vibe coding is a one-way ticket to engineering hell.

If you want to build a feature or a piece of software using AI, you must know every single detail of it. You must own it entirely. You need to be able to explain exactly how that feature behaves in every edge case and scenario. You don't necessarily need to master the coding syntax, but you must master the programming logic. The time you spend on understanding and owning what you are building will save you hours and days in later stages.

2. “Phasing” & “Programming”

If you want to eliminate AI hallucinations, you have to break the project down into highly specific phases. You can only do this effectively if you’ve already mastered Step 1 (Ownership).

From a high-level view, phasing means assigning a separate AI agent to each specific part of the work.

 The Architect Agent: One main agent creates the general source material and guardrails for your project.

The Builder Agents: Dedicated agents build specific components in separate, isolated threads.

The smaller and more contained the context window for each phase, the lower the chance of hallucination. By leveraging the power of modern LLMs like Claude and Gemini 3.5 Flash, we experienced zero hallucinations. It resulted in a beautifully smooth, continuous development workflow.

3. “Staging” & “Shipping”

Testing what an AI generates is paramount, but we realized you can test the core logic before you even compile the application.

By introducing diverse test cases with mock data, we instructed a separate, dedicated AI agent thread to run through the generated code and validate it against our business logic.

Is this unit testing? Yes, but on steroids.

A crucial lesson we learned: While AI agents are incredibly eager to write unit tests based on the code they just generated, you must explicitly instruct them not to do that. True value comes from writing the unit tests without looking at the code.

By implementing this pre-testing staging phase, we were amazed to catch dozens of bugs before the application ever interacted with real backend data.

The Big Shifts: Killing the Bottlenecks

Through this process, we realized something radical: We stopped writing PRDs (Product Requirement Documents) and TFSs (Technical Functional Specifications).

They are old-school, time-consuming, and ultimately became the biggest bottlenecks in our pipeline.

However, replacing them with AI meant the volume of code generated and the number of Pull Requests submitted skyrocketed insanely. To handle this influx without crashing, we had to completely change how we view our software infrastructure.

The "City" Metaphor

Today, we look at our software infrastructure like a strictly zoned city:

 There are rigid, unyielding laws (AI Atomic Skills) governing where you are allowed to construct a building.

 There are strict rules regarding what the exterior of that building must look like. You aren't allowed to build a skyscraper in the middle of a traffic junction.

 We use an aggressive, highly strict "Code Reviewer AI Skill" to guard these city borders and ensure integration points are flawless.

But what happens inside the building? We pay zero attention to it.

Whether the interior design inside that micro-component is clean and modern, or a bit of a creative mess, it doesn't matter. As long as it has a net-zero footprint on the rest of the city, and as long as the external interface is beautiful and functions perfectly, the internal complexity becomes irrelevant.

Next Up: Scaling Beyond Engineering

Building this way has completely transformed how we deliver value at Eliq. It’s faster, it’s highly scalable, and it keeps our engineers focused on high-level logic and architecture rather than fighting boilerplate code.

But we aren't stopping at engineering.

We are now taking this framework company-wide, bringing our project managers and support teams and design teams into the fold. To kick this off, we are hosting an intensive 3-day AI workshop. Together, we will put the OOPPSS methodology into practice and build a brand-new feature from scratch; from zero to hero.

I will be publishing our progress and sharing exactly how it goes in a follow-up post, so stay tuned!

How is your team adapting to AI workflows? Are you still writing traditional PRDs, or are you experimenting with cross-functional AI frameworks?