Every so often, a project comes along that solves an immediate, tangible problem while also letting you test a completely new way of working. The Barca Image Generator Tool was one of those projects. Honestly, getting the opportunity to tackle challenges this way is one of my favorite perks of working here at Coveo Labs.
To put this project in context, you have to know about ‘Barca’. It’s our primary demo environment – a fictional company we use to showcase Coveo’s power by proving our integration capabilities across complex ecosystems. Simply put, for Barca to be believable, it needs to feel real, and a huge part of that realism comes from having a deep and visually rich product catalog.
The primary goal was to build the next generation of our product image generation workflow. Our first-generation tool, an innovative Midjourney-based script, proved that automation was possible. But as a v1, it was naturally built with a lot of hardcoded logic that became inefficient to manage at scale. The review process was a painful cycle of generating a full batch, manually checking hundreds of images, noting the bad ones in a separate list, and then re-running the entire script from scratch. We needed a smarter, more interactive, and more flexible solution.
Alongside this, I had a secondary, more experimental goal: to explore what I initially thought of as vibe coding. The idea was to let an AI model shape the initial structure and “vibe” of the application, which I would then refine with traditional, manual coding. As my first attempt at blending these two approaches, I chose Google’s AI Studio as the testbed to see just how effective AI-assisted development could be for building sophisticated internal tools.
This post is a deep dive into that journey – from initial research and AI-driven blueprints to the final, polished application that replaces our outdated script.

Step 1: The Foundation – Choosing the Right AI Brain
At the heart of the tool was a simple idea: take structured product data, use an LLM to generate a descriptive prompt, and then use a text-to-image model to create the image. Because the quality of the prompt and the images generated were the most important factors, my very first step was to research which language model would be the most reliable and cost-effective for the job.
I set up a comparison document to track the performance of Google’s Gemini models against GPT-4o. The evaluation focused on two key tasks:
- Prompt Generation: How well could each model take a raw JSON object of product data and write a rich, descriptive, and creative paragraph suitable for an image model?
- Image Rendering: How well did the generated images from our model capture the nuance of the prompts generated by each LLM?
Key Observations:
My research led to a very clear set of conclusions, which I summarized in the table below.
| Task | Gemini 2.5 Flash (Google) | GPT-4o (OpenAI) | Imagen (Google) |
| Prompt Generation (from CSV) | Excellent. Accurately interpreted the CSV data, identified key visual attributes for variants, and followed complex instructions precisely. Fast and cost-effective. | Good, but slow. The agent mode was overly detailed and required several rounds of fine-tuning to get the prompt right. | N/A |
| Image Rendering Quality | Fair. Images often looked more like artificial 3D renders, lacking convincing realism. | Very good. Produced highly realistic shots with natural textures and subtle, diffused lighting. | Excellent for ecommerce. Produced vibrant, clean, and commercially appealing images. The use of dramatic lighting and reflections made products “pop” and feel dynamic. |

This initial research led to a clear architectural choice that would guide the rest of the project. And with this foundational decision made, I had the confidence to move on to the next step: using these tools to build the application’s blueprint.
Step 2: The Blueprint – Prompting a Professional Software Requirements Specification (SRS)
Before writing a single line of code, I wanted a solid plan. Traditionally, this means writing a detailed SRS. In the spirit of my experiment, I decided to prompt for it.
I started by visualizing the entire workflow to better explain the concept to others. And in a perfectly meta moment for this project, I didn’t even draw it myself. After all, what’s the best way to visualize an AI workflow?
Have the AI sketch it out, of course.

I opened a session with Gemini 2.5 Pro and began a brainstorming conversation. Instead of just giving it a one-sentence command, I treated it like a technical partner. I started with the core concept of the tool, outlining the general workflow I had in mind.
My Initial Core Concept Prompt for the SRS:
Give me a detailed SRS for a lightweight tool to automatically create photorealistic product images for a product catalog. The general workflow is: - Input: The tool starts by reading product information from a standard spreadsheet (CSV file) or a JSON file. - Smart Filtering: It intelligently identifies which product variations actually look different (e.g., a part in 'red' vs. 'blue') to avoid creating redundant images for variations that look the same. - AI-Powered Generation: It uses a two-step AI process to create all the necessary images in a single, unattended batch job: First, a large language model reads the product's technical data and writes a rich, descriptive paragraph about it (a "prompt"). Use gemini 2.5 Flash. Second, a text-to-image model reads that description and generates a high-quality image of the product. Use Imagen. - Human Review: A developer uses a specialized, two-part web interface for quality control: The primary "Grouped Review Dashboard" displays parent products together with all their visual variants for fast, contextual review, allowing the user to approve entire product families at once or reject individual images. A separate "Rework Queue" provides a focused to-do list for fixing and regenerating only the rejected images. - Final Output: After the review is complete, a "Finalize" action processes the entire batch. It automatically saves all approved images with the correct product code (SKU) as the filename, discards the rejected ones, and creates a comprehensive log, making the entire set ready for upload to the product system.
The result was a comprehensive, professional SRS document that became the foundational “vibe” for the entire project. This AI-generated blueprint saved hours, if not days, of planning and gave me a clear roadmap to follow.
Step 3: The Spark – Scaffolding with AI Studio (“Vibe Coding” in Action)
This is where the magic happened. I took the SRS we just created and used it as the primary input for Google AI Studio’s app generation feature. I asked it to build the initial React application based on the requirements defined in the SRS.
What I got back was remarkable. It wasn’t a perfect, production-ready app, but it was a fully structured project with:
- A multi-step component layout for the 5-step workflow.
- Placeholder components for each major feature (the file uploader, the attribute editor, the review dashboard).
- Initial state management logic using React hooks.
- Boilerplate service files for parsing and AI calls.
Essentially, AI Studio built the skeleton of the entire application in minutes. It handled the tedious setup and generated all the necessary boilerplate code, giving me a functional foundation to build upon. This is the core of “vibe coding”: letting the AI translate your high-level plan into a tangible codebase, getting you 70% of the way there instantly.


Step 4: The Refinement – Where Traditional Coding Shines
AI provided the spark, but human expertise was needed to turn it into a fire. The scaffold from AI Studio was a fantastic starting point, but it required significant manual refinement to become the robust tool we have today. This is where my traditional coding skills came in.
My work focused on:
- Complex State Management: Fine-tuning the React state to handle the complex flow of data between steps, especially the status updates during the review and rework process.
- Polishing the UI/UX: While the AI laid out the components, I used my knowledge of our design system and user needs to refine the layout, add better visual feedback (like loading spinners and alerts), and ensure the workflow was truly intuitive.
- Robust Error Handling: Building out the logic to gracefully handle API failures on a per-item basis during the batch generation, ensuring one failed image doesn’t stop the entire job.
- Security: Implementing the secure backend for S3 uploads and ensuring the client-side Google API key was handled correctly via environment variables — a critical detail AI can’t manage on its own.
This hybrid approach felt incredibly powerful. The AI handled the breadth, and I provided the depth.

From Vibe Coding to Vibe Engineering: A New Methodology
This project was a resounding success, but my biggest takeaway wasn’t just the final tool – it was the evolution of the development process itself.
I started this journey with the goal of trying ‘Vibe Coding’ – letting an AI quickly generate the initial concept and code. And it excelled at that. The AI authored SRS and the initial React scaffold were the creative ‘vibe’ that got the project off the ground in record time.
But as a developer who cares about how code is built, I realized the initial ‘vibe’ is just the starting point. The real magic happened when engineering discipline was applied to that creative spark. The methodical model research, the iterative prompt refinement for the SRS, the manual addition of robust error handling and security, and the planning for a secure deployment — that wasn’t just vibe coding.
That was Vibe Engineering.
Vibe Engineering is a more complete methodology. It uses AI for what it does best: rapid ideation, brainstorming, and scaffolding. But it then layers on the irreplaceable value of human expertise: architectural rigor, user experience refinement, and security-conscious implementation. It’s a methodology that respects both the incredible creative power of AI and the essential discipline of professional software development.
Putting Vibe Engineering into Practice: Key Takeaways
So, how can you apply this methodology to your own projects? Here are the key takeaways from my experience:
- Start with Research: A small, upfront investment in comparing AI models for your specific use case pays huge dividends in quality and cost down the line.
- Use AI to Blueprint Your ‘Vibe’: Let an LLM co-author your initial SRS. It forces you to think through your requirements and gives you a professional blueprint to guide both the AI and your own work.
- Embrace AI as a Scaffolder: Think of AI Studio as the ultimate boilerplate generator. Use it to build the initial structure and save yourself from the tedious setup phase of a new project.
- Your Expertise is the Engineering Layer: The AI will get you most of the way there, but your skills in refining logic, polishing the user experience, and ensuring security are what turn a creative “vibe” into a production-ready application
The Barca Image Generator tool is now in a great state, and more importantly, we’ve validated a new, faster way to build the tools we need. This “vibe engineering” approach, blending high-level AI direction with focused human expertise, is something I’m excited to apply to future projects.

