Getting into Action Thanks to AI Vibe Coding

I'd been wanting to create my personal website for months, if I said years I wouldn't be lying. I had a clear idea, but every time I opened the editor, I faced the same barrier: the blank page. It's not that I don't know how to program, with thirty years of experience, but starting from scratch requires energy that was scarce for personal projects.

Everything changed when I started using Cursor. Instead of writing all the code, I wrote the main parts and it completed the rest. That shift in mindset was enough to break the barrier. This isn't a tutorial about "vibe coding" (there are already many of those), but an honest reflection on what I learned: that not writing code doesn't mean messy code, and that using AI requires more professional judgment, not less.

1. The Blank Page Problem

When starting a project from scratch, you have to make hundreds of decisions: What framework? What structure? What tools? Each decision seems important and can be "wrong." It's easy to get paralyzed, because we know what it means to want to change that decision later.

I'd been through this before. A previous site with Jekyll worked, but maintaining it was a burden. This time I wanted something simple, but "simple" is also a decision. Analysis paralysis is real, and after months years of doing nothing, I realized I needed a push to start. That push came with Cursor.

The blank page isn't a lack of ideas. It's an excess of options without a clear starting point.

2. AI Vibe Coding: Conversing Instead of Writing

Over time, Cursor changed my approach. Instead of "how do I write this?", I thought "how do I describe what I want?". I started by describing: "A static site, simple, with self-hosted Tailwind, dark mode based on system preferences."

Cursor generated code. I reviewed it, adjusted it, and kept describing. Each iteration brought me closer, and each one required decisions about what to ask for. I wasn't passive. I was directing the generation.

This process forced me to be clearer. When writing code, you can be vague. With AI, you have to be specific. And that improved the result: I ended up with a more coherent and thoughtful design.

Describing what you want requires more mental clarity than writing code. And that clarity is reflected in the result.

3. Not Writing Code Doesn't Mean Messy Code

There's a misconception: if I don't write code myself, it will be bad. My experience was different. Cursor's code wasn't perfect, but it was more consistent than what I would have written manually. When I asked for something specific, it applied consistent patterns.

The trick is in how you ask. "Make me a button" gives you a generic button. "Make me a button that follows the design system, with primary colors, hover states, and accessible" gives you something much better. But you have to know what to ask for, and that requires professional judgment.

The AI generated things I didn't need: Analytics scripts, irrelevant meta tags. I had to review and ask it to remove them. That review process is crucial. It's like code review, but of generated code. And it requires the same professional judgment.

Code quality doesn't depend on who writes it, but on who reviews and refines it.

4. Using AI for Deployment Too

Setting up deployment isn't something I do every day (sometimes months go by without doing it). I wanted Nginx with Docker and Kamal, but I didn't have as much experience with Nginx as with Kamal. Normally, this would mean hours reading documentation.

With Cursor, I described what I wanted: "Dockerfile with Nginx for static files, Kamal configuration, the site is already pre-generated." It generated everything and it worked on the first try. Then I refined details: environment variables, domain, security headers.

The AI also explained what each part did. That allowed me to learn while building. The deployment wasn't perfect because I had to adjust things, but the starting point was much better than starting from scratch.

AI can generate code that works, but understanding why it works is still your responsibility.

5. What Worked and What Didn't

What worked well: Fast and effective initial structure. Consistent styles applied automatically. Deployment configuration that worked on the first try. Fast iteration and changes in seconds.

What was harder: AI can't make architectural decisions. You have to know what you want beforehand, or you'll end up with a cheap copy of what's most popular on the internet. Sometimes it required several iterations to get exactly where I wanted. It didn't always remember previous decisions. Debugging was harder because I hadn't written the code myself.

The lesson: using AI doesn't eliminate the need for professional judgment. It just changes where you apply that judgment: while describing what you want and reviewing what the AI generated.

6. Conclusion: Professional Judgment Is Still Key

There's an idea that AI will replace developers. My experience suggests the opposite: it makes professional judgment more important. When you ask AI for something, you have to be specific and know what you want, but that requires professional judgment.

This very post was written with AI assistance. Not by AI, but with assistance. I had the ideas and experience. AI helped me structure them and find the words. That's powerful: I can keep the site updated without it being a huge burden.

The future isn't about replacing developers, but amplifying what they can do. Eliminating friction from repetitive tasks and allowing focus on what matters: solving real problems and applying professional judgment.

AI doesn't replace professional judgment. It makes it more visible and more important.