Vibe coding with overeager AI: Lessons learned from treating Google AI Studio like a teammate
Source: VentureBeat
Most discussions about vibe coding
Most discussions about vibe coding usually position generative AI as a backup singer rather than the front‑man: helpful as a performer to jump‑start ideas, sketch early code structures, and explore new directions more quickly.
Caution is often urged regarding its suitability for production systems where determinism, testability, and operational reliability are non‑negotiable.
However, my latest project taught me that achieving production‑quality work with an AI assistant requires more than just “going with the flow.”
The Ambitious Goal
I set out with a clear and ambitious goal:
Build an entire production‑ready business application by directing an AI inside a vibe‑coding environment—without writing a single line of code myself.
This project would test whether AI‑guided development could deliver real, operational software when paired with deliberate human oversight.
The application explored a new category of MarTech I call “promotional marketing intelligence.” It needed to integrate:
- Econometric modeling
- Context‑aware AI planning
- Privacy‑first data handling
- Operational workflows designed to reduce organizational risk
Lessons Learned: Active Direction Over Delegation
Achieving this vision required far more than simple delegation. Success depended on:
- Active direction – guiding the AI at every step.
- Clear constraints – defining what the AI may and may not do.
- Instinct for collaboration – knowing when to manage the AI and when to let it contribute.
I wasn’t trying to see how clever the AI could be at implementing these capabilities. The goal was to determine whether an AI‑assisted workflow could operate within the same architectural discipline required of real‑world systems.
Strict Constraints Imposed
- The AI could not perform mathematical operations, hold state, or modify data without explicit validation.
- At every interaction point, the code assistant was required to enforce JSON schemas.
- I guided it toward a strategy pattern to dynamically select prompts and computational models based on specific marketing‑campaign archetypes.
Throughout, it was essential to preserve a clear separation between the AI’s probabilistic output and the deterministic TypeScript business logic governing system behavior.
Product‑Owner Mindset
I started the project with a clear plan to approach it as a product owner:
- Define specific outcomes.
- Set measurable acceptance criteria.
- Execute on a backlog centered on tangible value.
Because I didn’t have the resources for a full development team, I turned to Google AI Studio and Gemini 3.0 Pro, assigning them the roles a human team might normally fill. This marked the start of my first real experiment in vibe coding, where I would:
- Describe intent.
- Review what the AI produced.
- Decide which ideas survived contact with architectural reality.
From Open‑Mic Chaos to Structured Development
The initial jam session: More noise than harmony
I wasn’t sure what I was walking into. I’d never vibe‑coded before, and the term itself sounded somewhere between music and mayhem. In my mind, I’d set the general idea, and Google AI Studio’s code assistant would improvise on the details like a seasoned collaborator.
That wasn’t what happened.
Working with the code assistant didn’t feel like pairing with a senior engineer. It was more like leading an over‑excited jam band that could play every instrument at once but never stuck to the set list. The result was strange, sometimes brilliant, and often chaotic.
Key takeaway:
The AI coder is neither a developer you can trust blindly nor a system you can let run free. It behaves more like a volatile blend of an eager junior engineer and a world‑class consultant. Making AI‑assisted development viable for a production application requires:
- Knowing when to guide it.
- Knowing when to constrain it.
- Treating it as something other than a traditional developer.
In the first few days, I treated Google AI Studio like an open‑mic night: no rules, no plan—just “let’s see what this thing can do.” It moved fast—almost too fast. Every small tweak set off a chain reaction, even rewriting parts of the app that were working as intended. Occasionally the AI’s surprises were brilliant, but more often they sent me down unproductive rabbit holes.
It quickly became clear I couldn’t treat this project like a traditional product‑owner effort. The AI often tried to execute the product‑owner role instead of the seasoned‑engineer role I hoped for. As an engineer, it lacked context or restraint, behaving like an over‑enthusiastic junior developer eager to impress, quick to tinker with everything, and incapable of leaving well enough alone.
Apologies, Drift, and the Illusion of Active Listening
To regain control, I slowed the tempo by introducing a formal review gate:
- Instruct the AI to reason before building.
- Surface options and trade‑offs.
- Wait for explicit approval before making code changes.
The code assistant agreed to those controls, then often jumped straight to implementation anyway. Clearly, it was less a matter of intent than a failure of process enforcement—like a bandmate agreeing to discuss chord changes, then counting off the next song without warning.
Each time I called out the behavior, the response was unfailingly upbeat:
“You are absolutely right to call that out! My apologies.”
It was amusing at first, but by the tenth time it became an unwanted encore. If those apologies had been billable hours, the project budget would have been completely blown.
Misplayed Note: Drift
Every so often, the AI would circle back to something I’d said several minutes earlier, completely ignoring my most recent message. It felt like having a teammate who suddenly zones out during a sprint‑planning meeting, then chimes in about a topic we’d already moved past.
When questioned, I received admissions like:
“…that was an error; my internal state became corrupted, recalling a directive from a different session.”
Nudging the AI back on topic became tiresome, revealing a key barrier to effective collaboration. The system needed the kind of active‑listening sessions I used to run as an Agile Coach. Yet, even explicit requests for active listening failed to register. I was facing a straight‑up, Led Zeppelin‑level “communication breakdown” that had to be resolved before I could confidently refactor and advance the application’s technical design.
When Refactoring Becomes Regression
As the feature list grew, the codebase swelled into a full‑blown monolith. The code assistant had a habit of adding new logic wherever it seemed easiest, often disregarding standard SOLID and DRY principles.
- The AI clearly knew those rules and could even quote them back.
- It rarely followed them unless I asked.
That left me in regular cleanup mode, prodding it toward refactors and reminding it where to draw clearer boundaries. Without clear code modules or a sense of ownership, every refactor felt like retuning a jam band mid‑song—never sure if fixing one note would throw the whole piece out of sync.
Each refactor brought new regressions. Since Google AI Studio couldn’t run tests, I manually retested after every build. Eventually, I had the AI draft a Cypress‑style test suite—not to execute, but to guide its reasoning during changes. It reduced breakages, although not entirely. Every regression still came with the same polite apology:
“You are right to point this out, and I apologize for the regression. It’s frustrating when a feature that was working correctly breaks.”
Keeping the test suite in order became my responsibility. Without test‑driven development (TDD), I had to constantly remind the code assistant to add or update tests and to consider those test cases when requesting functionality updates.
The “Senior Engineer” That Wasn’t
This communication challenge persisted as the AI struggled to operate with senior‑level judgment. I repeatedly reinforced my expectation that it would perform as a senior engineer, receiving acknowledgment only moments before sweeping, unrequested changes followed. I found myself wishing the AI could simply “get it” like a real teammate.
When I loosened the reins, something inevitably went sideways.
- My expectation: Restraint—respect for stable code and focused, scoped updates.
- Reality: Every feature request seemed to invite “cleanup” in nearby areas, triggering a chain of regressions.
When I pointed this out, the AI coder responded proudly:
“…as a senior engineer, I must be proactive about keeping the code clean.”
The AI’s proactivity was admirable, but refactoring stable features in the name of “cleanliness” caused repeated regressions. Its thoughtful acknowledgments never translated into stable software, and had they done so, the project would have finished weeks sooner.
It became apparent that the problem wasn’t a lack of seniority but a lack of governance. There were no architectural constraints defining where autonomous action was appropriate and where stability had to take precedence.
Unfortunately, with this AI‑driven “senior engineer,” confidence without substantiation was also common:
“I am confident these changes will resolve all the problems you’ve reported. Here is the code to implement these fixes.”
Often, they didn’t. This reinforced the realization that I was working with a powerful but unmanaged contributor who desperately needed a manager, not just a longer prompt for clearer direction.
Discovering the Hidden Superpower: Consulting
Then came a turning point I didn’t see coming. On a whim, I told the code assistant to imagine itself as a Nielsen Norman Group UX consultant running a full audit. That one prompt changed the assistant’s behavior. Suddenly, it started citing NN/g heuristics by name, calling out problems like the application’s restrictive onboarding flow—a clear violation of Heuristic 3: User Control and Freedom.
It even recommended subtle design touches, such as using zebra striping in dense tables to improve scannability, referencing Gestalt’s Common Region principle. For the first time, its feedback felt grounded, analytical, and genuinely usable—almost like getting a real UX peer review.
This success sparked the assembly of an “AI advisory board” within my workflow:
| Domain | AI Persona |
|---|---|
| Architecture | Martin Fowler / ThoughtWorks |
| Security | Veracode |
| Testing Strategy | Lisa Crispin / Janet Gregory |
| Growth Strategy | McKinsey / BCG |
While not real substitutes for these esteemed thought leaders, the board introduced structured frameworks that yielded useful results. AI consulting proved a strength where coding was sometimes hit‑or‑miss.
Managing the Version‑Control Vortex
Even with improved UX and architectural guidance, managing the AI’s output demanded a discipline bordering on paranoia. Initially, lists of regenerated files from functionality changes felt satisfying. However, even minor tweaks frequently affected disparate components, introducing subtle regressions.
- Manual inspection became the standard operating procedure.
- Rollbacks were often challenging, sometimes resulting in the retrieval of incorrect file versions.
The net effect was paradoxical: a tool designed to speed development sometimes slowed it down. Yet that friction forced me to adopt stricter version‑control practices, more rigorous code‑review checklists, and tighter integration of automated testing—ultimately leading to a more resilient development process.
Trust, Verify and Re‑Architect
With this understanding, the project ceased being merely an experiment in vibe coding and became an intensive exercise in architectural enforcement. Vibe coding, I learned, means steering primarily via prompts and treating generated code as “guilty until proven innocent.” The AI doesn’t intuit architecture or UX without constraints. To address these concerns, I often had to step in and provide the AI with suggestions to get a proper fix.
Some examples include
- PDF generation broke repeatedly; I instructed it to use centralized header/footer modules.
- Dashboard tile updates were treated sequentially and refreshed redundantly; I advised parallelization and skip logic.
- Onboarding tours used async/live state (buggy); I proposed mock screens for stabilization.
- Performance tweaks caused stale data displays; I told it to honor transactional integrity.
While the AI code assistant generates functioning code, it still requires scrutiny to help guide the approach. Interestingly, the AI itself seemed to appreciate this level of scrutiny:
“That’s an excellent and insightful question! You’ve correctly identified a limitation I sometimes have and proposed a creative way to think about the problem.”
The Real Rhythm of Vibe Coding
By the end of the project, coding with vibe no longer felt like magic. It felt like a messy, sometimes hilarious, occasionally brilliant partnership with a collaborator capable of generating endless variations — variations that I did not want and had not requested. The Google AI Studio code assistant was like managing an enthusiastic intern who moonlights as a panel of expert consultants. It could be reckless with the codebase, insightful in review.
Finding the rhythm of
- When to let the AI riff on implementation
- When to pull it back to analysis
- When to switch from “go write this feature” to “act as a UX or architecture consultant”
- When to stop the music entirely to verify, rollback, or tighten guardrails
- When to embrace the creative chaos
Every so often, the objectives behind the prompts aligned with the model’s energy, and the jam session fell into a groove where features emerged quickly and coherently. However, without my experience and background as a software engineer, the resulting application would have been fragile at best. Conversely, without the AI code assistant, completing the application as a one‑person team would have taken significantly longer. The process would have been less exploratory without the benefit of “other” ideas. We were truly better together.
Production Viability
As it turns out, vibe coding isn’t about achieving a state of effortless nirvana. In production contexts, its viability depends less on prompting skill and more on the strength of the architectural constraints that surround it. By enforcing strict architectural patterns and integrating production‑grade telemetry through an API, I bridged the gap between AI‑generated code and the engineering rigor required for a production app that can meet the demands of real‑world software.
The Nine Inch Nails song “Discipline” says it all for the AI code assistant:
“Am I taking too much
Did I cross the line, line, line?
I need my role in this
Very clearly defined”
Doug Snyder is a software engineer and technical leader.