Vibe coding is taking over. Here at DoltHub, we’re doing our best to embrace the change in the industry. The most impressive of our efforts (or, maybe more accurately, token spend) is DoltLite, a fully vibe coded SQLite fork that implements the Dolt storage engine to provide version control features.
From what I can tell, both from personal experience and the prevailing internet opinion, vibe coding doesn’t work so well for pure frontend development. This makes sense to me intuitively. Claude can’t actually see your screen in real time. Sure, you can point it to screenshots or use some extension to let it interact with the browser, but it lacks the human eye that can tell when a button is a bit off center or when a font is slightly too large. My experience thus far involved countless messages to the tune of “move that button a little farther up”, followed by a “no that was too far”, and then maybe a “that didn’t work. whatever you did caused all the page content to collapse on itself and overlap. i don’t even know what i’m looking at right now.” Needless to say, I was not the biggest fan.
Nevertheless, I wanted to experience the magic of write-only code, so I decided that, while building the new landing page for Dolt Workbench, I would do nothing but talk to Claude. I was able to build the entire thing in about two hours.
Background#
We wanted somewhere to point Dolt Workbench users for a quick product overview with download links, so we decided to build a landing page. This felt like a particularly good candidate for a fully vibe-coded frontend project for a couple reasons:
- It’s a static site. Just React and CSS.
- It has zero reliance on existing DoltHub code or infrastructure. I knew ahead of time the diff would be all green.
So, I opened up a terminal and did everything in my power to give Claude the best possible chance at being useful. I wired up the Figma MCP server and linked the Figma frame for the design I was targeting. I also pointed Claude at the code for the Doltgres landing page to use as a reference. This was my prompt:
I want you to build the landing page for Dolt Workbench. This will be an entirely new package that will live in the `ld` repository in a folder called 'workbench-web'. You should carefully study the `doltgres-web` package as a reference for project structure, styling, and other conventions. Here's a link to the figma frame containing the full design.
Results#
Five minutes later, Claude spat out a functional webpage that, to my surprise, actually looked pretty good. For reference, here’s the final version of the page that matches the design. This was the five minute version:
It successfully included all the necessary content and arranged everything correctly on screen. The components were of appropriate size and color, and there weren’t any huge issues with spacing. I was impressed. This was already kinda shippable. If I didn’t care about exactly matching the spec we designed for this page, I probably would have only spent a few more minutes fixing the glaring issues and then called it good. Unfortunately, I do care about matching the spec exactly.
This led me down a path I know all too well. Claude struggled quite a bit with the remainder of my follow-up requests. It floundered with the background color and could not seem to apply the gradient properly, getting the table alignment correct required extensive back-and-forth, and the page was basically entirely broken on mobile. This was surprising to me after it did so well with the initial scaffolding. Clearly, it was able to read the Figma properly and translate the design into code.
These issues were not, in my opinion, particularly hard to fix — often just a few lines of CSS here and there. I’m confident I could have fixed them myself faster than I was able to coerce Claude into doing so. I’m also confident I could not have produced that initial version in the five minutes it took Claude.
In total, the page took about two hours, but the time was distributed unevenly. If we measure the complexity of a task in terms of how long it would take a human to do it (which already feels like a somewhat archaic estimate), then probably 90% of the time I spent on this was allocated toward the final 10% of the work. If I was hand-crafting the code for the entire thing myself, I think it would’ve taken me about a day. So even in spite of the Claude-wrangling, I still saved time overall.
Conclusion#
I’m definitely more sold on vibe coding than I was before attempting this. For now, my plan for tasks like these is to go for the Claude one-shot to get me 80% of the way there, then revert back to my typical “trad-code-enhanced” workflow. There’s definitely still a gap somewhere in the frontend vibe code experience, but it’s clear to me now that the gap is narrowing. If you have any thoughts on the topic, come by our Discord and let us know.