Beyond vibe coding for the web

1. Introduction

As coding agents become integral to daily software development, whether you're a seasoned engineer or a new builder looking to launch your first app, how you build and what you build is fundamentally changing. When you start using coding agents, you typically start with "zero-shot" prompts—a single instruction that says in short, human language what you want. This runs into problems quickly:

• People-pleasing bias: Models often accept flawed constraints or premises, looking to complete your request as quickly as possible, and don't verify that what they are making actually does what you intended.
• Verification gap: Agents, even when they write tests, don't typically check their work to ensure that it works. Trying to use websites in a live browser surfaces hidden bugs, broken layout, and inaccessible controls.
• Technical debt: Because of how models are trained and work, the code they write leans towards old and outdated patterns, increasing technical debt that costs both more tokens and more human and machine time and effort to manage. Technical debt can even negatively affect your user experience.

The 4-step game plan

To help guide coding agents to produce better code that more closely aligns with your requirements, consider following a 4-step product development lifecycle:

1. Plan and design: Collaboratively write Product Requirements Documents (PRDs) with the agent and have them prototype and design the PRDs in-browser before starting production implementation, then draft architectural Design Docs (Specs) from your PRDs and designs before coding starts.
2. Code and build: Instruct your agents to build to your PRDs, designs, and Specs instead of a zero-shot prompt, and make it run another agent to check its work.
3. Rinse & repeat: Run through steps 1 and 2 again for each new feature you want to add.
4. Deploy: Ship to production.

This document guides you through how to use AI agents as active collaborative partners with practices meant to help you reduce technical debt and improve the output code quality. You use Antigravity paired with Modern Web Guidance and DevTools for Agents to build a casual word game and enhance it with AI capabilities. You then deploy it to Google Cloud using Firebase to share with your friends and family.

What you'll learn

• How to treat AI coding tasks as mini product development lifecycles.
• Why you should separate product requirements from architectural specifications.
• How to orchestrate multi-agent workflows to prototype directly in the browser and review your code.
• How to leverage third-party skills and tools to improve both your development and user experiences.
• How to deploy web applications directly to production using Firebase MCP.

Prerequisites

• A personal Google Account and Google Cloud or Firebase project (instructions in project setup)
• Some familiarity with HTML, CSS, and JavaScript.
• A web browser such as Chrome.
• Node.js installed (LTS recommended).

2. Project setup

Google account

If you don't already have a personal Google Account, you can create a Google Account.

Sign in to the Google Cloud console

Sign in to the Google Cloud Console using a personal Google Account.

Enable billing

Tip: If you set up billing using Google Cloud credits, you can skip to "Create a Firebase project".

To set up a personal billing account, go to enable billing in the Cloud Console.

Create a Firebase project

Tip: If you've set up a Google Cloud project as part of setting up Google Cloud credits, use that project to set up your Firebase project. If you do so, you don't need to connect your billing account because it's already connected.

1. Navigate to the Firebase Console and sign in with your personal Google Account.
2. Click Add project (or Create a project).
3. In the project creation wizard:
   • Enter a project name (such as, wordup-web-app), or reuse the Google Cloud project you set up during project setup.
4. Connect Billing Account
   • In the Firebase Console sidebar, locate the plan badge at the bottom (it says "Spark"). Click Upgrade.
   • Select the Pay as you go plan.
   • Select the Billing account you set up during the Project setup step.
   • Confirm the selection to attach your billing account to the project. (Firebase Hosting provides a generous free tier; completing this tutorial typically incurs $0).

Install tools

• Antigravity 2.0: The primary agentic coding harness you work with, paired with the latest Gemini Flash model for fast, frontier-level coding.
• Modern Web Guidance: Skill for coding agents to help them write modern CSS, HTML, and JavaScript. Install through Antigravity Settings > Customization > Build With Google Plugins > Modern Web Guidance.
• DevTools for agents: Enables agents to drive Chrome, inspect live DOM, test layout, and debug in runtime. Install through Antigravity Settings > Customization > Build With Google Plugins > Chrome DevTools and Antigravity Settings > Customization > Add MCP Servers > Chrome DevTools for agents.
• Firebase MCP server: For seamless project setup and one-prompt deployments. Install through Antigravity Settings > Customization > Build With Google Plugins > Firebase and Antigravity Settings > Customization > Add MCP Servers > Firebase.

3. Start with a plan

The common temptation in agentic coding is to submit a zero-shot prompt ("Build me a word game") and hope for the best. This almost always results in skipped edge cases, bloated codebases, and endless bug-fixing cycles.

Instead, treat each task as a mini product development lifecycle. Coding agents have research and reasoning tools that allow them to act as a collaborative partner to help you clarify your ideas before writing any code. The act of talking out your idea often helps you find and answer questions before they become problems—in software engineering this is called rubber duck debugging. You can use your coding agents as rubber ducks to plan out your projects and features.

You are building a casual word game. Prompt your agent to help you design the game you want.

I want to make a casual word guessing game. Go do deep research on those kinds
of games, then ask me questions to help me write a PRD for the game's features.

This is the basic shape of the prompt—remix it for your own needs. The key here is having it go do deep research and ask you questions based on that research to help you plan your work.

Start with this prompt because working with coding agents involves a lot of review. Breaking down a full implementation plan into smaller, focused pieces makes it much easier to review, lets you catch edge cases early, can bring in knowledge outside of the agent's training data and, most importantly, lets you take more breaks in between review.

• Separates "what" from "how": Defining the user experience and product scope in a formal Product Requirements Document (PRD) separates what you want to happen from how it's implemented, letting you focus on one aspect of product development at a time instead of everything all at once.
• Identifies edge cases early: An interactive Q&A session forces you to clarify your requirements before design or implementation begins.
• Active agent research: Because agent training is cut off at a certain date and information in it becomes highly summarized, pulling from live research can bring in new information that it would otherwise miss.

Tip: If you see your coding agent do something you like, or see it do something you don't like, you can add instructions to an AGENTS.md file in your project folder to correct, or reinforce, its behavior. Try adding the following to make sure that Antigravity uses its built-in question tool when asking you questions:

When I ask you to ask me questions, you are **REQUIRED** to use your `ask_question` tool to do so.

Exercise 1

Now it's your turn. Set up your project and build your PRD.

1. Add an instruction to your AGENTS.md file to tell it to save your output to docs/plans/{{YYYY-MM-DD}}-{{description}}.md.
2. Run the preceding research prompt, with whatever tweaks you'd like, to build out your PRD.
3. [Stretch Goal] Update your AGENTS.md file with things you find your agent doing that you don't like, and run your prompt again.

Tip: Antigravity 2.0 has a /grill-me command you can run specifically for doing this kind of exploration.

Best practice: Antigravity 2.0 has an "Artifact" tool that lets you comment line-by-line or highlight specific text and leave comments, just like Google Docs. You should leave comments inline instead of adding them to the prompt. Save the prompt for document-wide comments. Sending your prompt, even if it's an empty prompt, sends your comments and tells Antigravity to regenerate your document with your comments addressed.

Caution: Sometimes, even when you tell it to only write a PRD, it includes software design and architecture in your PRD. If it does so, leave a comment or prompt it to remove those items and focus only on user experience.

4. Design in the browser

Static UI design relies on mockups that often look stunning but can fail to account for edge cases, constraints, and actual user interactions. And much like code, asking an agent to "design" your site application results in designs that converge to a generic (often purple) design.

For web apps, you can use your agent's ability to control a web browser through DevTools for agents to design in the browser. Whether you're a designer working to bring better fidelity to your designs, a coder or builder looking to improve the UI and UX of your project, or the two working together, working in the actual medium you're building for produces better results.

Designing in the browser also gives you an opportunity to coordinate multiple agents working together to produce a single output. These subagents are agents with specific personas and goals that can be coordinated to produce better results than a single agent working on its own. With design, you can request that a visual design agent, a user experience agent, and an accessibility agent all work together to help you with your design, and have them show them to you directly in the browser.

Caution: Using subagents to complete tasks uses more tokens. While they can produce much higher quality results, understand that using them can have additional costs.

Start a panel of design agents to help you pick a design based on your PRD.

Using the PRD, start a panel of expert agents: one UX design, one web
accessibility, and one for visual design, and have them work together to design
3 different UI mockups and show them to me in-browser.

Tip: You can type @ in Antigravity's prompt area and start typing the name of a file to point Antigravity at the specific file you want it to look at.

Designing in the medium you're building for, in this case the web, instead of a static one lets you catch edge cases and constraints that are hard to manage otherwise and lets you get immediate visual feedback that is true-to-production.

Exercise 2

Now it's your turn. Design your project.

1. Run the preceding design prompt, with whatever tweaks you'd like, to build out your design. Include ideas for the different design directions you'd like to see (like modern, playful, realistic, and so on).
2. Choose a design you like and iterate on it with your agent.
3. Have your agent update your PRD to point to the agreed upon design.
4. Stretch goal: Run accessibility tests and responsive design tests for your chosen design, and tweak your design based on those audits.

Caution: Agents sometimes get overzealous and take this direction as approval to build out the whole application. Watch its thinking and if you see it doing more than you expect, stop it and prompt it to change its course.

5. Write a spec

With an approved PRD ("what to build") and a selected visual design ("what it looks like"), you now need technical alignment on architecture ("how to build it").

A technical design document or specification—spec for short—details file structures, state management, component interfaces, event pipelines, and dependencies. Creating a spec before writing code lets you catch misalignment and undesirable coding patterns early, before they turn into code that's harder to reason about and refactor.

Write a detailed technical design document on how to implement the game with
the chosen design.

Why you are doing this

• Architectural clarity: Defining the component hierarchy and state transition flow (such as, Idle → InGame → EvaluatingGuess → GameOver) prevents race conditions and brittle spaghetti code.
• Modern standards alignment: With Modern Web Guidance enabled, the agent references modern standards (for example, CSS @container queries, built-in
  elements for modals or help overlays, and modular ES modules) rather than pulling legacy heavy libraries.
• Staged reviews: Separating the functional PRD review from the technical design doc review lets you evaluate architecture independently from user experience.

Exercise 3

1. Instruct your AGENTS.md to save your output to the current folder:

   PRDs should _always_ be written to the current project's root in `docs/plans/{{YYYY-MM-DD}}-{{description}}.md` format
   

2. Run the design doc prompt and review it, ensuring it covers aspects like directory structure, event handling, and storage.
3. Stretch goal: Have it include Mermaid diagrams to explain state flow through the application, if it doesn't already include them.

6. Finally, build the app

With the PRD, UI mockup, and design doc established, it's time to build. These three items are the clear, unambiguous guidance agents need for what they should make.

Here's another good opportunity to use subagents. You can run them after the code is built to review how closely what was built stuck to your up-front designs, and another one to check the code quality of what was built.

Use the PRD, design doc, and mockup to implement the site, then send out 2
agents, one to check how closely you followed the requirements, and one to
review the code.

Why you are doing this

Spec-driven development with first-pass reviewers gives your agent clear, pre-vetted requirements to build from, and a fresh set of eyes to make sure they stuck to the plan before it gets to you, improving quality and fidelity.

• Vetted requirements: The agent doesn't need to guess at what you want; you've already reviewed everything but the implementation before any code's been written.
• Fresh set of eyes: A review agent spawned in a new context has zero confirmation bias from building the codebase out, making it effective at catching unhandled edge cases, missing implementation requirements, and other code or product details that were missed.

Exercise 4

1. Run the build prompt, pointing to the exact files you want it to review.
2. Watch the output as it runs. You see it reasoning through your requirements as it tries to build it out. If something looks like it's going off the rails, you can stop it and correct it.
3. Have it run your development server to see the final site and check its work.
4. Stretch goal: Run through this process again to add automated tests.
5. Stretch goal: Choose a specific framework or technology stack you want it to build the site in—with the PRD, mockup, and design doc separated, it should be straightforward to adapt to different ones.

7. Deploy to production

You have planned, designed, and coded. What's left? Deploying to production.

Deploy this site to my Firebase project [YOUR_PROJECT_ID] using Firebase
Hosting.

Caution: If this doesn't work, make sure you have Firebase MCP installed. You may also need to sign in the first time you run this.

Exercise 5

1. Run the deployment prompt substituting your project ID.
2. Copy the live hosting URL provided by the agent.
3. Open the live URL to verify it's deployed and working.
4. Stretch goal: Use DevTools for agents to run a Lighthouse audit of your production site, make adjustments to improve the Lighthouse score, and publish the updates.

8. [Optional] AI enhancements

Your word game is now fully functional using a static dictionary. To change the static dictionary into a dynamic word, you can instead prompt for one each time using a small, local language model from the Prompt API.

Caution: If you haven't already, make sure you have Modern Web Guidance installed to help you here.

Because this isn't available on all devices, you use progressive enhancement to check if the API and model are available. If they are, you use them; if not, you fall back to your static list.

Exercise 6

Put everything you've learned together into practice.

1. Work with your agent to write a PRD to use the Prompt API to generate a valid hidden word.
2. Design the download progress bar and AI integrating UI in-browser.
3. Write a spec for the implementation. (Hint: Run an agent to make sure it's used the correct API syntax here.)
4. Develop your new feature.
5. Deploy it to production.

9. Wrap-up

Congratulations. You have successfully built, refined, enhanced, and deployed a modern, accessible, and AI-forward web application using agentic coding best practices.

What you learned

• Product-driven agent workflows: How treating tasks as mini product lifecycles (PRD → Design → Spec → Build) reduces debt, review overhead, and back-and-forth friction.
• Multi-agent specialist panels: How running multiple AI subagents can help improve the quality and fidelity of your work.
• PRD vs. design doc: Why separating the functional scope (plan) from technical architecture (spec) is a more scalable and accurate process than zero-shot feature prompting.
• Seamless deployment: How to use MCP servers (like Firebase MCP) to streamline access to third-party systems, like deploying your site.