THE DEVELOPMENT JOURNEY

Vibe Coding &
The AI Stack

How I built a production-grade UX tool using collaborative AI agents and next-generation models.

1. The Philosophy: Vibe Coding

I didn’t just write this project. I curated it. I used a method called Vibe Coding, where the developer acts as the visionary and AI agents act as the execution team. Instead of getting stuck in repetitive boilerplate, I focused on the “vibe.” This means putting all my energy into the user experience, the aesthetic flow, and the logic, while directing AI tools to build the foundation.

In this setup, my role shifted from typing syntax to shaping intent. I defined how the interaction should feel. I focused on the snap of a button, the timing of a loading state, and the warmth of the copy. I let the AI handle the vocabulary of the code while I provided the vision.

The end of blank-page paralysis: One of the best parts of this workflow is that I never get stuck staring at a empty screen. I can prompt an agent with a high-level goal and see a working prototype in seconds. This lets me skip the setup phase and go straight to refining the details. That is where the real value is created.

Velocity as a creative force: Speed matters because it keeps your momentum alive. When you can test an idea 30 seconds after you think of it, you take more risks. I iterated on the UI dozens of times in a single session. That is impossible with traditional manual coding.

The curator’s eye: When AI generates the code, the human becomes the ultimate quality control. I reviewed every function and tweaked every margin to make sure the soul of the application stayed consistent. Technical empathy became my primary skill. I had to understand why a model chose a specific pattern and guide it toward a better one.

2. The Orchestration Stack

To bring this vision to life, we utilized a powerful suite of agentic tools:

• Google Antigravity: The primary agentic intelligence that managed the project context, planned tasks, and executed complex file operations.
• GitHub: Used not just for version control, but as a synchronization point for our feature-branch workflow (e.g., `feature/real-time-status`).
• Cursor: The IDE that bridged the gap between human intent and machine code, allowing for inline AI edits and seamless debugging.

3. The Intelligence Engine: A Tale of Models

The “brain” you choose for an app is just as important as the code itself. My journey wasn’t a straight line. I tested different models to find the right balance of intelligence, speed, and cost.

The Paradox of Choice: When I began, the market was flooded with options. Should I optimize for the highest benchmark scores? The largest context window? The lowest token cost? I realized that different phases of development required different “cognitive profiles.”

Phase 1: The Architects (High-Reasoning Models)
For the heavy lifting, I needed models that could think like a senior engineer. I used Gemini 3 Pro and Claude Sonnet 4.5.

These models acted as our Senior Architects. When I needed to design core logic or handle complex errors, design the `GeminiService` class, handling complex dependency injection and error states, we didn’t need speed; we needed correctness. We used them to:

• Break down usability rules into system prompts.
• Map out how data moves from a raw URL into a structured report.
• Debug complex logic within the Google Places API.

However, “Architects” are expensive and thoughtful. They take their time. A single request could take 15-20 seconds to process a full analysis. In a chat interface, that’s acceptable. In a live consumer web app, it feels like an eternity.

Phase 2: The Runtime Engine (Gemini 1.5 Flash)
As I moved from architecture to production, the constraints changed. I needed a model that could read a massive amount of HTML context (large context window), understand the nuance of UX design (reasoning), and return a result before the user got bored (latency).

Enter Google Gemini 1.5 Flash.

Gemini 1.5 Flash cut our analysis time by 60%. This made real-time updates possible. Instead of looking at a loading spinner, the user sees the analysis happening step-by-step. Because Flash can “see” an entire website at once, the feedback it gives is much more accurate.

Flash represents a paradigm shift in our engine design. It is optimized for high-frequency, low-latency tasks without sacrificing the massive context window required to “see” an entire webpage at once.

• The Speed Factor: Flash cut our analysis time by nearly 60%. This allowed me to implement the “Real-Time” status updates, where the user sees the analysis happening step-by-step, rather than staring at a static spinner.
• The Context Advantage: Heuristic evaluation requires holistic understanding. You can’t judge a navigation bar in isolation; you need to know where it leads. Gemini 1.5 Flash’s massive context window allowed us to feed it the entire DOM structure, CSS classes, and even meta-data in a single shot, ensuring the evaluation was context-aware.
• Cost Efficiency: By moving to Flash, I reduced the cost-per-analysis significantly, making the tool viable as a free utility for the community.

The Pivot: The transition wasn’t just a config change. I had to “retrain” my prompts. High-reasoning models can infer intent from vague instructions; faster models need explicit, structured guidance. I spent a few days refining my prompt engineering, moving from conversational requests to strict, step-by-step algorithmic instructions that Flash could execute with robotic consistency.

The result is a hybrid monster: The architecture of a genius, executed by a sprinter.

4. Building for Resilience

The biggest trap in AI-assisted development is the “Happy Path.” It is easy to build a demo that works when everything is perfect. It is much harder to build a production tool that survives the chaos of the real web. This phase of the journey was about moving from a cool prototype to a resilient service ecosystem.

The invisible UX of stability
Most people think UX is just about what you see on the screen. I believe UX includes the things you never want the user to notice. If the app crashes because an API is slow, that is a design failure. To prevent this, I focused on these technical pillars:

• Performance Truth: Google PageSpeed Insights API
  AI is great at guessing, but it is terrible at measuring. I moved away from AI-estimated performance and integrated the Google PageSpeed Insights API. Now, my reports include real performance data fetched directly from Google.
  
  → Real-time Metrics: The “PageSpeed Health” section now reflects actual lab data: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and the Speed Index.
  → AI Context: Because Gemini now “sees” this real data, its executive summaries and UX recommendations are surgically accurate. It no longer hallucinates performance issues; it diagnoses them.
  → Graceful Fallback: If the PageSpeed API is slow or hits a limit, the system automatically falls back to the previous method. This ensures the user always gets a report, no matter what happens in the background.
• Managing the 429: The ROI of Patience
  High-performance models have strict rate limits. When you have multiple users hitting the engine at once, you run into the dreaded “429 Too Many Requests” error. I worked with the agents to implement an exponential backoff strategy. This means the app doesn’t just give up. It waits, calculates the best time to try again, and ensures the user session stays alive. This transforms a potential frustration into a seamless, reliable experience.
• Environment Sync: The Local-to-Live Loop
  One of the hardest parts of this build was managing the gap between my local machine and the live server. I faced persistent DNS issues, specifically the “Name Not Resolved” error, which can kill a development cycle. I established a custom development loop to ensure that every change made in the IDE was instantly reflected in a mirrored production environment. This eliminated the “it works on my machine” excuse and allowed for real-world testing from day one.
• Data Integrity and the Scraper’s Dilemma
  A UX audit is only as good as the data it analyzes. The web is messy. Websites have broken HTML, weird CSS classes, and hidden metadata. I had to engineer a pipeline that scrapes a DOM, cleans the “noise,” and tokenizes only what matters for the AI to understand the intent of the design. This required surgical precision in how we handle the Google Places API and various PHP quirks that usually trip up automated tools.

5. The Human-Agent Feedback Loop

Throughout this process, I treated the AI agents as senior consultants. When I hit a wall with a server configuration, I didn’t just ask for code. I asked for an audit of the architecture. We went back and forth on the best way to structure the data flow to minimize latency.

This isn’t just about making the code work. It is about making the code maintainable. By documenting every “why” behind the technical choices, I ensured that this tool isn’t just a flash in the pan. It is a scalable foundation that can grow as the models get smarter.

6. The Final Verdict: My Personal Operating System

The result of this journey is more than just a tool. It is the validation of a system that I am officially implementing into my own professional workflow. Vibe Coding is not a replacement for deep engineering. It is my method for improving my own work and scaling my capacity as a designer and consultant.

The Ethics and Limits of the Vibe

I am fully aware of the boundaries of this methodology. I am not here to replace developers or claim that agent-scaffolded code is a substitute for the deep expertise of a lead engineer.

• Privacy Standards: I am hyper-aware of the data and privacy limits of working with LLMs.
• Deployment Safety: I know that the code generated through Vibe Coding is for my internal acceleration. It is code that may not always be safe to deploy into the wild without rigorous human auditing.
• The Purpose: This is about my personal-professional ROI. It is a cost-effective way for me to validate ideas, build internal tools, and sharpen my strategic focus without getting bogged down in the manual labor of syntax.

By combining Vibe Coding with rigorous engineering, I’ve proven that AI doesn’t replace the designer. It amplifies my ability to solve complex, high-stakes problems at scale. This is my new baseline. I am no longer just designing for screens. I am architecting the future of my own human-machine collaboration.