My Experience Vibe Coding

Over the last few weeks, I’ve needed to build a new personal website. Although I’ve been skeptical about “vibe coding,” I decided to give it a try.

My conclusion from the exercise is that it works, sort of. I used Cursor, as it is the current market leader (and the closest to my current setup, though any tool will do). You can see the code commits made on the site’s GitHub repository page.

For seasoned engineers, vibe coding is good but not great. It excels at automating mundane tasks, such as writing unit tests, scaffolding code, and updating documentation. However, its real power shines for business users, designers, and non-coders, helping them rapidly prototype and iterate on ideas, possibly adapting experiences they see on other websites.

Old personal website on the left, my new site on the right.

So, what is “vibing” that code?

My first experience with the modern use of the term “vibe” or “vibing” was several years ago while watching “Bachelor in Paradise.” In that show, the term “vibing” between two contestants generally meant they were getting along and, ah-hem, fairly into each other.

In software development, “vibe coding” generally has the following characteristics:

• Flow State: The psychological concept describing a state of deep focus and immersion in an activity.
• Rapid Prototyping: A common practice in software development and design, emphasizing quick iteration and experimentation.
• Agile and Iterative Development: Methodologies that encourage adaptability, experimentation, and incremental improvement.
• Creative Coding: A movement where programming is used as a medium for creative expression, often seen in art and music tech communities.

How Did I Approach Vibe Coding My Website?

My “rules”:

1. Start simple, then add complexity iteratively
2. The goal was speed of development and the finished product, not code quality
3. I would only code if the tool went way, way off, sort of like using a GPS on a hiking trail — follow the path unless it leads you straight into a river
4. Commit working code as often as possible so that I can show you (my reader) the code it produced and how it evolved

Scope of the site:

• A personal site
• The sections of the site should be “About Me,” “My Resume,” and “Blog Posts”
• The content on the site should come from notes (my CV, Resume, LinkedIn profile, etc)
• The site’s code should include CI / CD practices

Milestones and Process:

Vibe Coding at 50K feet on my uConsole on the way back from visiting family in the Central Valey of California

1. Basic site with three sections
2. Styled site based on another website*
3. Local build and run in a container
4. Incorporated content into the site
5. Tweaked styling
6. Deployed the container to my hosting provider
7. Added Google Tag Manager

Along the way, I also added linting, containerization, automated testing, and some refactoring.

My Tools:

• My 2017 MacBook Pro 13" (dual-core Intel) and my ClockworkPi uConsole (Raspberry Pi CM4, Arm64)
• Cursor AI coding editor, my primary tool for vibe coding (though any alternative would do, I also use Github Copilot in VS Code)
• GitHub & GitHub Actions for code management, CI/CD
• ChatGPT for writing my “About Me” section and consolidating my resume
• Warp Terminal, an AI-powered terminal (mostly to debug local configuration issues)

So, how did it go? What did you learn?

It worked; my site is proof of that.

The main thing that worked well — I didn’t need to code ~90% of the time. It was surprisingly effective at incorporating another website’s code into my site. It updated the templates, HTML, and CSS to adopt the styles from the other site. It also quickly bootstrapped my Docker container, set up GitHub Actions, and kept my README accurate and up-to-date.

Cursor’s AI did run into issues (I’ve seen similar behavior with GitHub Copilot and Amazon Q Developer, as the buffer managing context becomes exhausted). Every so often, it would become confused about what I was asking it to do and would update unrelated parts of the project, resulting in bugs. Asking the tool to revert its suggested changes was a risky proposition because it didn’t always remember the changes it had made. Cursor’s back-end service would periodically crash, which would reset the tool’s context. A few times, I needed to fully revert via git and ask the tool to rescan the folder before making changes.

This latter part was problematic because my local environment is on a well-used laptop with a lot of crud. Cursor would periodically need reminding of that crud; if I forgot to point it out, the tool would go on a 15–20 minute vision quest trying to fix my machine when it didn’t need to. Warp occasionally does this, too.

Additionally, Cursor and its peers (Amazon Q Developer, GH Copilot, etc.) are not ideal coders; I’d place the code they produce somewhere in the middle, better than that of a recent graduate, but not as good as someone with 3 years of experience. The tools don’t get nuance and intent from the prompts. For example, trying to ingest a string that appears to be a list, but is just free text; tools detect commas and assume the text is a list. More than a few times, it took me more words to describe the change for it to get the update right than the amount of code that needed to be fixed.

A change I would like to see these tools make is to ask for more details, direction, and suggestions from the user if it’s not certain what is wanted. It’s the exact feedback I often give to my more junior reports: if you’re not sure, ask.

Would you do this again for a different project?

Yes.

The obvious use cases would be for experimental code, such as prototyping a user experience without a set visual design or developing a form for a wizard-like workflow before a clear design direction is established. Alternatively, vibe coding can be helpful when writing one-time-use code, where code quality or performance isn’t essential, but the output is. An example is a data transformer where the input, transform logic, and output logic are already documented, possibly following a Test-Driven Development (TDD) approach.

Alternatively, one could incorporate the use of principles of vibe coding into their workflow to keep developer documentation up to date, in an automated manner, utilizing Pull Requests or Merge Requests to monitor their agentic partner. Alternatively, generative coding tools could help with unit tests or keeping brittle ones up to date as you vibe-code refactors or create new features.