Quick preface: this site is a simple blog and contact form. No sensitive data behind it. So everything that follows is calibrated to that kind of low stakes build. If you are shipping anything that handles real user data or payments, the bar is higher and the playbook is different.
I work in Cloud GTM. While I consider myself to be quite technically capable, and have a foundational understanding of HTML and JavaScript, I am not a software engineer. I have not written production code in my career. But over the last couple of weeks I designed, built, and shipped my own personal website end to end, using AI as the engineer and myself as the director.
The site is live. It has a custom contact form with spam protection, dark mode, a typography system I picked myself, and it deploys automatically the moment I push a change. The cost was dollars, the time was a few hours (though by the time you read this I bet I've tweaked it more). Five years ago, this would have taken me weeks to get into production with my current responsibilities.
What follows is what I actually learned doing it. The tools I used, the prompts that worked, the mistakes I made, and the workflow I would recommend if you want to try the same thing.
What "vibe coding" actually means
Let me name the term first because it sounds cooler than it is. Vibe coding is just building software by telling an AI what you want in plain English and reacting to what it gives back. You do not write the code. You describe the result. The AI writes it, runs it if needed, shows you, and waits for your reaction.
The skill is not knowing syntax. The skill is knowing what you want, being able to describe it clearly, and being willing to keep going when the first version is wrong.
That is the entire thing.
What I built
The site itself is small. One page, four sections (intro, blog list, about, contact). It has light and dark mode. The contact form gets posted to a serverless function with a captcha gate so I do not get drowned in bot mail. The whole thing is hosted free, on its own custom domain.
Stack, if you care:
- HTML, CSS, JavaScript (no framework)
- A serverless function for the contact form
- Cloudflare Turnstile for the captcha
- Azure Static Web Apps for hosting (Netlify and Vercel are equally good)
- GitHub for source control and automated deploys
If those words mean nothing to you, that is okay. You can hand the entire stack decision to your AI and it will pick a sensible default. In fact, tell it to always provide you a recommendation and why along with any questions it proposes.
The mental model: you are the director
The single biggest unlock when working with AI on a build like this is to stop thinking of yourself as a programmer who is bad at code. You are not coding. You are directing a coder.
The good news is that being a good director is something you already know how to do. You have probably explained a project to a contractor, told a designer what you wanted on a slide, or briefed someone you manage. It is the same job. You communicate intent, you review the result, you give feedback, and you iterate.
The bad news is that the AI will do exactly what you ask. If your brief is fuzzy, the result is fuzzy. The clearer your intent, the better the output. This is true at the macro level ("I want a personal site that feels like a serious tech professional, not a freelancer template") and at the micro level ("make this paragraph shorter and remove the closing platitude").
The tools I actually used
You can build a site like this with a surprisingly small toolset. Here is what I used.
Visual Studio Code with GitHub Copilot. This was the cockpit. VS Code is a free code editor. Copilot inside it can read your files, edit them for you, run commands, and explain what is happening. Describe a goal and Copilot makes the changes across files on its own.
A separate AI chat in another window. I also kept a second AI assistant open for higher level questions. Things like "what is the cleanest hosting option for a personal HTML site in 2026" or "summarize what this CSS file is doing." Some questions are better with a brain that is not currently knee deep in your code.
A local preview. A simple way to run your site on your own computer so you can see changes immediately. Python ships with a one line web server. So does Node. Your AI will set this up for you in thirty seconds if you ask.
Git and GitHub. Source control sounds intimidating. It is not. It is just a way to save snapshots of your project, share them, and roll back if you break something. Your AI will guide you through every command.
A hosting service that deploys automatically from GitHub. Candidly I used Azure Static Web Apps because as a MSFT employee, I get discounts and perks. It also doesn't hurt that Azure is one of the most reliable clouds out there. Netlify and Vercel are just as good and both have generous free tiers. The magic here is that every time you push a change to GitHub, the site updates automatically. You do not upload files. You do not configure servers.
That is the whole stack. Editor, AI, preview, source control, host. Nothing exotic.
The workflow
This is the part that took me the longest to get right, and it is the part I would tell anyone starting out.
The loop is: describe, preview, react, repeat.
You describe what you want in plain English. You look at the result. You react to it like a human, not like a code reviewer. You send the next instruction. Then again.
The mistake I made early was trying to plan the whole site in one giant prompt. It did not work. The AI took a hundred shots in the dark on style choices I had not actually made. The fix was to slow down and run the loop in small bites.
A real example. Early on I asked the AI to "build me five different style mockups of my personal site, masculine and modern, not corporate." Five mockups came back as standalone files I could open in a browser. I looked at them, picked the one that hit closest, and went back with "I like the typography on mockup four but the color palette on mockup five. Show me three variations that combine them." Three more came back. I picked one. Then I picked apart that one in pieces, paragraph by paragraph.
By the end I had something that looked like me, not like an AI template.
There were far more effective ways to attack this from a token preservation perspective, I'll be the first to admit it, again perks. Each build is a chance to harness the power though, you quickly become much more effective with better planning ahead (I did none), or more practice (this I have).
Prompts that actually worked
Generic prompts produce generic output. Specific prompts produce useful output. Here are patterns I came back to constantly.
Ask for variations before committing. Instead of "design my homepage," try "give me five different visual directions for my homepage. Make them genuinely different in tone, not just color swaps. I will pick one and we will iterate from there." This single move saved me hours.
Reference what you already like. "Make the typography feel more like Linear or Vercel than like a Medium blog post." The AI knows what those brands look like. Reference points carry more information than adjectives.
Be explicit about what you are not. "I am not going for a freelance creative portfolio look. I am a working professional in tech. Lean editorial, lean serious." This pruned a lot of bad directions before they happened.
Use sensory language for feedback. "This font feels feminine, I want something more bold and masculine." "This banner is too tall, it crowds the headline." Tell the AI what you feel, not just what is technically wrong. It will translate that to code choices.
Ask it to show its work in small steps. "Make this change, show me the result, and wait before doing anything else." Big batches of changes are hard to review. Small ones are easy.
Mistakes I made
I want to be honest about these because they were the most useful part of the build.
I chose a font early on that turned out to feel wrong for the persona I was going for. Specifically I picked a fancy serif with calligraphic italic flourishes. It looked elegant on its own but combined with the rest of the page it read more like a wedding invitation than a professional site. I ignored that feeling for two iterations because I had committed to it. The right move was to scrap it the first time it felt off.
Lesson: trust your gut on the first reaction. If something does not feel right, it does not get more right with more time invested. Tell the AI to throw it out and try again.
I let the AI run too long without preview. There was a moment where I asked for a series of changes, did not look at them for a few iterations, and ended up with a layout I did not want. Pulling that apart took longer than just stopping every change to look.
Lesson: previewing is not optional. The cost of looking at the result every time is zero. The cost of not looking is rework.
I let placeholder content stay too close to production. A stock image of someone who was not me almost made it onto the live site. Catch this stuff early. Search your project for placeholder text and stock assets before you ship.
Lesson: do a "what would a stranger see" pass before going live. Read the site like you have never been there.
I spent thirty minutes on a security tangent that turned out to be a non issue. Tooling will scare you with warnings sometimes. Slow down, ask the AI to explain the actual risk, and decide if you care. Often the real risk is much smaller than the warning makes it sound.
Lesson: not every warning is an emergency. Ask for the plain English version of the risk.
Going to production
Three things stand between a local prototype and a real site on the internet.
A domain. You can buy one in five minutes from any registrar. The standard pattern is firstnamelastname.com. If your name is taken, get creative with a middle initial, your discipline, or a "writes" or "builds" prefix.
A host. Pick a free tier from Azure Static Web Apps, Netlify, or Vercel. All three connect to GitHub and redeploy on every push. Setup is roughly ten minutes if you have never done it. Your AI will walk you through the screens.
DNS. This is the part that confuses everyone the first time. Once you have a domain and a host, you point your domain at the host using a few DNS records inside your registrar dashboard. The host will tell you exactly what records to add. Copy, paste, save. Wait fifteen minutes. Done.
For my contact form I added one more piece, a serverless function that takes the form submission and emails it to me. Hosts like Azure Static Web Apps, Netlify, and Vercel all include this in their free tier. The AI wrote the function in about three minutes once I described what I wanted.
I also added a Cloudflare captcha gate to keep bots out. This is free, takes about ten minutes to set up, and dropped my spam to zero. No doubt if my friends have read this far, that number is no longer 0.
The feedback loop is the whole game
If I had to compress everything I learned into one line, it would be this: the quality of your output is determined by how tight your feedback loop is.
A tight loop looks like: prompt, preview, react in one sentence, prompt again. Cycles of three to five minutes.
A loose loop looks like: prompt, walk away, come back later, look at twelve changes at once, write a long paragraph of feedback, get back a confused response, repeat.
The first one builds momentum. The second one kills it. Set up your environment so the loop is short. Have your editor open. Have your preview running. Have a way to take a screenshot. Have your AI ready to listen.
What I would tell someone starting
A few things I wish I had known on day one.
You do not need to learn to code to do this. You will pick up tiny amounts of vocabulary as you go and that is enough. The AI handles the rest.
Start with one small project, not a portfolio overhaul. Build a single page about yourself. That is enough to learn the workflow and produce something real.
Treat the AI like a junior engineer who is fast, capable, and a little overconfident. Review what it gives you. Push back when it feels wrong. Praise when it nails something and ask it to do more of that.
Build in public. Push your code to a public GitHub repository so people can see how a working site is structured. It is a free portfolio piece and a free learning resource for the next person doing what you are doing.
Get the boring stuff out of the way first. Buy the domain, set up the host, get a hello world page live before you spend time on design. Knowing your deploy pipeline works removes a lot of anxiety from the creative work.
Finally, ship before it is perfect. The version that exists on the internet is worth a thousand of the perfect version that lives only on your laptop. You can keep iterating once it is live.
Closing
The barrier to building real things on the internet has collapsed in the last two years. You do not need a bootcamp, a developer friend, or a six month commitment to learn enough to ship something useful and good looking. You need a couple of free tools, a willingness to describe what you want, and the patience to iterate.
If you have been thinking about putting up your own site, this is the easiest moment in history to do it. Go build something.
Views expressed are explicitly that of my own.