What I learned vibe coding my portfolio in 4 days, and how the playbook has evolved across a dozen projects since.
In September 2025, I vibe coded my portfolio in four days. Seven months and more than a dozen projects later — web apps, data science work, automation pipelines, AI agents — the playbook has evolved a lot. This is everything I’d tell past-me, condensed into one post.
How it started: the 4-day portfolio
I started with a Wix resume template as inspiration and asked the LLM questions as I went. The iterative approach worked, but I only realized what I actually wanted to build after several rounds of implementation.
Two things slowed me down. First, my software engineer friends took one look and said: “this looks like a resume — you might as well not build one.” They sent me a few minimalist portfolio references, and I spent another day rebuilding the homepage. Second, I’d picked the wrong tech stack. Adding new content meant editing JSON files, and once I wanted markdown for blog posts, my vanilla HTML/CSS setup couldn’t handle it gracefully — every new post triggered layout bugs. I migrated to Astro for native markdown support, file-based routing, and static generation.
Both rebuilds were avoidable. The lesson wasn’t “plan more” — it was that I didn’t yet know the right questions to ask.
What the portfolio taught me
A few things landed hard the first time:
AI can’t give you taste. AI builds what you ask for. If you base your design on a resume template, you’ll get a resume. Define your taste, references, and purpose before you start, because the cost of rebuilding is real.
Tools matter more than prompts. I started with Claude, hit rate limits, switched to Codex (ChatGPT Plus), and the real jump came when I moved from terminal prompting to the Codex plugin in VS Code. Pasting reference images, scrolling conversation history, iterating on code — all of it got dramatically faster.
Specificity is a feature. Codex converts UI screenshots to functional code at ~80% accuracy, and you can paste website URLs as references. But the bigger unlock was learning to talk to it precisely. “Move the experience-description into the first column of the grid” works. “Move it to the left side of the box” doesn’t.
Plan before agent. Define requirements in planning mode before letting the model implement in agent mode. Skipping this step is the single fastest way to generate rework.
Production code needs explicit asks. LLMs build like enthusiastic juniors — functional but not production-grade. They don’t include CSS variables, mobile responsiveness, README files, reusable components, or sensible file organization unless you ask. So ask, every time.
Purpose determines stack. A portfolio with markdown blog posts needs a different stack than a static brochure or a content-heavy site with a CMS. How often you’ll update and how you’ll author content drives the framework choice. Get that wrong and you’ll migrate.
What’s changed since
A dozen projects later, two things from the original list have evolved enough to call out separately.
Sequence beats questions
The Sep 2025 me had a list of “questions to ask before building.” That was right but incomplete. The actual lesson is that vibe coding works brick by brick, in this order:
- Idealization — key features + user flow. Don’t touch code yet.
- UI/UX frontend — build the screens before the logic.
- Features that link to the frontend — wire backend behavior into screens that already exist.
- Test the features — does it actually work end-to-end?
- Security + final checks on the frontend — auth, permissions, edge cases.
- Deployment — monorepo or separate repos? Where to host? The earlier you decide, the less restructuring later.
When I skip the order, the project gets messy fast — things stop working and I spend longer debugging than I did building.
The right tools beat raw prompting
Sep 2025 me was prompting LLMs from scratch for design and fighting the output every step. Now I lean on:
- Claude design tools for components and layouts
- Stitch for UI scaffolding
- Frontend designer skills with pre-loaded design conventions
- Playwright MCP for UI/UX checking — the model can actually see what it built and iterate without me being the screenshot pipeline
The output is cleaner, more consistent, and I argue with the model less. The tool you reach for matters more than the prompt you write.
What still needs work
Writing better code and designing better architecture. I can ship a v1 of anything in a weekend, but my code tends to be functional rather than clean.
The build sequence is figured out. Code quality and architecture aren’t — that’s what I’m working on next. Happy building.