Responsible Agentic Development: Vibe Coding vs. Agent Teams

Written by Jen Oppenheimer | Jul 21, 2026

In just minutes, AI can produce software that looks 90% done. The question for engineering teams is what lives inside the other 10%. This is where the database, the tests, the security model, and everything else a business depends on tend to hide.

That gap was the subject of Episode 64 of the Scaling Tech Podcast: Responsible Agentic Development: Building Fast Without Losing Control, where host Arin Sime sat down with Andrea Phillips, a Senior Web Developer here at AgilityFeat, and with our subsidiary, WebRTC.ventures. Andrea has been part of our team since 2012, working as a nearshore software developer from Costa Rica across real-time video applications, multi-tenant SaaS platforms, and compliance-sensitive products. She is also one of our earliest and most disciplined adopters of agentic development. In the podcast, she demonstrated her full workflow live, running a spec-driven agent team head to head against a vibe-coded build of the same application.

This post recaps the highlights. The episode itself is worth the hour for any team adopting AI agents.

Vibe coding and its limits

Andrea drew the line between vibe coding and responsible agentic development early in the conversation. Vibe coding, in her experience, mostly comes from non-technical builders.

“They just gave a prompt to an AI, and they come up with this beautiful design and semi-working applications, and they can wow everybody. But in reality, there are a lot of loopholes and security gaps behind them.”

Andrea was quick to note that there is genuine value in vibe coding: non-technical people can now build things that were out of reach two years ago. That is worth celebrating for demos, side projects, and personal tools. The problem is when a vibe-coded application gets treated as a production system. Responsible agentic development means bringing the full weight of engineering practice into the workflow: source control, database design, row-level security, proper testing, and deliberate architecture. As Arin put it, AI is about augmentation of engineering talent, not replacement.

Specs before prompts

The foundation of Andrea’s workflow is spec-driven development: a PRD that defines what is being built and for whom, a tech spec that defines the architecture, epics that group the work, and small, scoped tasks with acceptance criteria and a definition of done. Her one-line summary has become a mantra on our team:

“A prompt is a wish.”

Without a defined scope and outcome, you are hoping the AI builds what you wanted rather than knowing it will. She also shared a technique she picked up from a project building an agentic software delivery platform for our client Compounds.dev: before any code is written, ask an architect agent to simulate the implementation plan and surface friction points, a pre-mortem that costs one prompt now instead of a sprint later.

We have covered this method in depth before, so this recap stays brief. For the full workflow, see Hector Zelaya’s post on writing production-ready code with AI using spec-driven development.

The demo: one prompt, two very different applications

The centerpiece of the episode was a live experiment. Andrea gave the same prompt, a web-based World Cup trivia game, to two setups.

A single AI session with a one-paragraph prompt and no further structure (vibe-coded)
An orchestrated agent team running in Hive, a tool for managing multiple agents without juggling ten terminals.

The vibe-coded version finished fast. And, credit where due, it was fun. It asked good trivia questions, kept score, and looked decent. It was also a single index.html file. No database, no server, no persistence. Close the browser and your score is gone. Every user plays in isolation, so a leaderboard is impossible. And the answers sit in the JavaScript, readable by anyone who opens the source. Fine for practicing trivia at your desk. A liability the moment someone deploys it and invites the public in.

The agent team took longer and produced something categorically different: a client and server, a SQLite database with seeded questions, a test suite, input validation, and a leaderboard that persisted across sessions. During the build, the PM agent paused to ask Andrea about the stack and content requirements, and she answered as she would answer a colleague.

The takeaway Arin drew is the one every engineering leader should sit with: to a non-technical observer, both apps look “90% done”. The difference lives entirely behind the interface, which is exactly why organizations without engineering judgment in the loop keep mistaking demos for products.

A team of agents, not a chat window

Andrea runs distinct agent personas for the product manager, developers, and a code reviewer, each in its own session with fresh context. She gives them names and personalities, which sounds playful and serves a real purpose: it keeps roles cleanly separated. Her reasoning for the separation is an old engineering principle applied to new tooling: “You shouldn’t give a developer the responsibility to check its own work. It’s biased. It wrote it.” A reviewer agent with fresh context and the full project scope catches issues the builder cannot see.

There is enough in this part of her workflow to fill its own article. Watch this blog for a deeper look at orchestrating multi-agent teams. You can also read the WebRTC.ventures case study on a clinical role play simulator with six purpose-built Gemini-powered agents.

The warning shot: Meta’s Instagram outage

The episode also covered the counterexample. In late May, high-profile Instagram accounts were hijacked through an AI-built account recovery flow that skipped identity verification entirely, a failure compounded by a security team too depleted to catch it. Andrea’s reaction on the episode was blunt: the bug sat in production since February, so the promise that agents “fix things fast” never materialized. A full analysis of the incident and the practices that prevent it will be in a follow up post on human-in-the-loop AI development.

Andrea’s advice for engineering managers running agent teams

The back half of the episode turned practical. Five recommendations for engineering managers adopting agentic development:

Match the model to the role. Use stronger, more expensive models for thinking-heavy work like PRDs and task definition, and cheaper models for well-specified implementation. Token spend correlates with quality no better than lines of code ever did.
Automate only what you have done by hand. A process is ready for an agent “when you run it X amount of times and you know that the output is what you want.” Until then, you cannot recognize a bad output when you see one.
Run parallel agents like a real team. Small tasks, a visible board, and Git work trees so agents never step on each other’s changes.
Put security first, literally. Top of the prompt, then human exploratory testing, QA, and a security review before anything customer-facing ships. Limit what tools and permissions agents can touch.
Keep humans on the creative and architectural decisions. AI has syntax covered. Left to its own devices it drives toward the average application. “We have to use our heads to imagine what’s coming, what can be done to push the limits,” Andrea said. “AI is not going to do it.”

Work with a team that builds this way

At AgilityFeat, this is how our senior engineers work by default. Our BuilderPods pair small senior teams like Andrea’s with AI-native workflows, delivering agentic speed inside the engineering discipline that makes software production-ready. We also offer nearshore staff augmentation and standalone projects. Contact us today.

About the author

Jen Oppenheimer

Since joining our ranks as Chief of Staff in 2020, Jen has played a crucial role in driving communication and alignment across our diverse organization, ensuring that time, information, and decision-making processes are as effective as possible. Additionally, she directs our marketing and oversees much of the day-to-day operations, ensuring that all departments work cohesively towards our common goals.