Stop 'Vibe Coding.' Start Orchestrating: How I Built an Agentic Newsroom (Not a Wrapper)
Source: Dev.to
By Rizwanul Islam (Afraim) – Architect of Intelligent Futures | Founder @ Gaari & The Trail
They call it “Vibe Coding”—the idea that you can prompt‑engineer your way to a unicorn without understanding how a database schema works. It is a seductive lie. While vibe coding is great for building toys, it is catastrophic for building systems. I don’t build toys. I build architectures reliable enough to hold the weight of thousands of users.
When I architected The Trail (a high‑performance news aggregator) and Gaari (Bangladesh’s premium vehicle rental platform), I didn’t use AI to write the code for me. I used AI to execute the code I designed.
The “Vibe Coding” Trap
“Vibe Coding” relies on probability. You ask an LLM to “build a news app,” and it hallucinates a React component that looks pretty but fails under load. It removes the friction of syntax, but it also removes the friction of understanding.
When you build a system like Gaari, which handles:
- 110+ API endpoints
- Complex multi‑service booking flows
- Real‑time payment gateways (Stripe / Bkash)
you cannot “vibe” your way through race conditions in a database. You need unshakeable reliability.
The Shift
Stop treating AI as a “Magic 8‑Ball” that writes code.
Start treating AI as a junior developer that requires strict architectural constraints.
Case Study: Architecting “The Trail” as a Swarm
Most “AI News Apps” are just wrappers around the OpenAI API: user asks a question → bot answers. This is fragile and prone to hallucination.
For The Trail, I didn’t want a chatbot. I wanted a digital newsroom. I adopted the Agentic Swarm architecture. Instead of one prompt, the system is orchestrated into specialized agents:
- The Planner – scans the web for trending topics and defines the scope.
- The Researcher – pulls data from verified sources (no hallucinations allowed).
- The Writer – drafts the content based only on the Researcher’s data.
- The Critic (crucial) – reviews the draft against a quality rubric (SEO, readability, fact‑check). If the score is < 8/10, it rejects the draft and forces a rewrite.
The Code vs. The Orchestration
// Writer agent produces a draft
let draft = await writerAgent.write(plan, facts);
// The Orchestration Loop
if (review.score < 8) {
console.log(`Quality fail (${review.score}). Rewriting...`);
// trigger rewrite logic
}
return await publisherAgent.publish(draft);
The Stack: Next.js + Supabase (The Reliability Layer)
To support this agentic workflow, you need infrastructure that moves as fast as the AI but stays as secure as a bank. For both Gaari and The Trail, I standardized on the Next.js + Supabase stack.
Why Supabase?
Gaari’s architecture handles sensitive user data (bookings, payments). Even if an AI agent goes rogue or a frontend bug appears, the database physically refuses unauthorized queries. That is unshakeable reliability.
Why Next.js 14?
Next.js provides server‑side rendering, API routes, and edge‑runtime capabilities that align perfectly with real‑time AI orchestration and rapid iteration.
The “Founder Mode” Mindset
There is a viral debate about “Founder Mode”—the idea that leaders must know the details. As the architect of these systems, I don’t delegate the database schema. I don’t treat the API as a “black box.” I know every one of the 30+ tables in The Trail’s schema.
To be a 100× Engineer in 2026, you must pivot:
- From: Writing syntax (the AI can do this).
- To: Designing systems (the AI cannot do this).
Conclusion: Build the Engine, Don’t Just Paint the Car
My work with Gaari and The Trail proves that you don’t need a team of 50 to build enterprise‑grade software. You need a system mindset. Stop vibing and start orchestrating.
If you are building something that needs to scale, stop looking for “code snippets” and start looking at architecture patterns.
Discussion
Are you using AI to write code, or are you designing systems for AI to execute?