Building the BR Website Without Touching Code
Episode 1 of the vibe coding experiment
One year ago, we used to joke: "True AGI will be achieved the day LLMs understand CSS."
Despite what Milo thinks, we don't have frontend developers at Bot Resources. We've never really needed them. We build agentic systems for clients - the work is architecture, orchestration, integration. For POCs and POVs, we need functional UX, not pretty UI. Chainlit and similar libraries get us there.
For the last two years, we've relied on LLMs to handle the UI part. Especially CSS. The results... weren't good. I'm pretty sure a real frontend developer would get physically ill looking at our CSS files.
Our website reflected this. We used it to experiment with content generation - can we use agents to write about what we do? The answer was no. Our content is too disruptive. Most of it contradicts what's in LLM training data.
What's an agent? What's an agentic system? Why aren't data scientists the best fit to build them? Why is fine-tuning usually a bad idea? What are realistic use cases? These questions don't have correct answers in the training datasets.
As for the old website's UI? Let's just say it was made by GPT-4 Turbo. Beautiful, elegant, well thought out... or not.
But that was more than one year ago. In most industries, that means yesterday. In ours, it might as well be two centuries ago. During this period, we went from chatbots barely able to replace Google + Stack Overflow on simple bugs to agents that can semi-autonomously edit codebases to implement features. Time for a rebuild.
The Experiment
The coding agents we use every day are integrated in our IDE and command line tools. Great for backend dev. For frontend, it's clumsy.
Frontend development is like Russian nesting dolls - components inside components inside components. Multiple layers. Add the inner logic with different types of services and interfaces, and you get a large codebase where understanding which code handles a specific button's behavior requires reading through dozens of files.
Then there's the "pretty" part. For a coding agent to see the website, you have to screenshot it and paste it in chat. Far from ideal. And you still have to tell the agent which precise element to work on. Best way? Inspect the DOM elements, find the right one, tell the agent "the button <app-user-edit-button-admin-page> isn't working." Slow, tedious, painful.
We looked for tools specifically designed for this. We found lovable. We experimented. Can we use it to discuss UX/UI? Yes. Mock dashboard? Yes. Build something real? Yes. Right-click in the preview to tell the agent to change a button's color? Yes! Is it perfect? No. But it's a start.
Time for a new experiment. The question: should we use it for a client project or for ourselves? First option too risky. Second option - maybe, but on what? Then I realized the website content hadn't been updated since July 2024. So much had changed. We needed a new one.
The Ambition
People who know me understand that I'm a grounded, reasonable man without any ambition. I'm never going to try to make a project overly ambitious, especially if it's a small internal project. To give you an idea, when I was working on marketing data, I never decided to build a system that would redo the whole attribution logic of an adserver, except better.
So my specs for our small company website are reasonable. Trust me. Nothing fancy. We're a small company with not that many customers. No need to build elaborate tools for so few users. Let's sum up the specs:
- I don't like CMS.They're horrible. So instead my CMS will be lovable. We're entering a new age. Let's fully delegate to an agentic system the whole website. After all, nothing bad can happen, right? Right?
- I want a fully fleshed-out website, with lots of content.Even if we don't have time to write this content and nobody will ever read it. Let's do it anyway.
- I want a localized website.We're a French company, but somehow most of our sales are made abroad, so we need English and French. Oh, and one of our employees is going to Japan next year. Let's have a Japanese version too.
- I want a blog section.Localized too. New blogging logic: we write the content, and let Lovable find the illustrations and make it pretty. Translation will be a problem, but we'll build something for that later.
- It would be nice if viewers could post comments on the blog articles too.Comments are good. They flatter my ego. They might even entice me to do more content. But for that we need both a backend and moderation. For moderation, we could use automated moderation. I've never tried it, let's do it. Nothing to fear here, it's not like random viewers on the internet will try some prompt injection if they know the moderation is done by agents.
- I want a backend for prospects.Nothing fancy. A small agentic system with a qualification agent and a presales engineer able to analyze use cases would be nice.
- I want a backend for our clients.Basically everything provided to prospects but with added features. Contracts and invoices management. A PM agent would be nice too. Add timesheet management for time-based invoices, API fee and deliverable for project-based invoices.
- I want a full CRM for our sales.I don't like CMS but I also don't like CRM. Let's replace both.
- I want a backend for our employees.We currently have 4 employees. It's critical that they have agents with access to holiday schedules, pay leaves, and work contracts.
- And of course, this must be fully secured, maintainable, no LLM vendor-lock, SSO everywhere.
As you can all see, I have nothing but reasonable, grounded ambitions.
What Actually Happened (So Far)
I set one constraint: I don't touch the code. Not during development. Full vibe coding mode - instructions in, results out. For frontend, true vibe coding: I give general instructions, without providing the code architecture. For backend, I'm maniacally over-ambitious. I won't use lovable even if supposedly it can do it. Pure coding agent workflow. Strict instructions on architecture with clear separation of concerns. If I have the time, I'll do blog posts on how to do that and why.
Lovable generates React/Vite code, syncs with GitHub, makes one commit per change. I deploy to OVH via GitHub Actions. Authentication implemented - SPA using Entra and Google, will connect to backend via WebSocket with access token in the first message. That part was tricky. Everything else? Surprisingly smooth.
I write content in markdown. Paste it to the agent: "add this to the blog, make it look good." Preview appears. Adjust if needed.
When I wanted internationalization, I told it to create French and Japanese versions. Technical implementation worked on the second try - first attempt forgot a few elements, quick follow-up fixed it. Three-language site running.
The translations themselves are generic and lack company context. That makes sense - good translation needs domain knowledge and oversight. But the system works.
The site looks better than anything I could have built. Hours instead of weeks.
If you're reading this line it means that, at least partially, this project was successful. It's still early stage. Stay tuned for follow-up posts.