The portfolio you are reading was written mostly by typing English at a terminal. I did almost no manual coding for the first two days. The result was good enough to ship and bad enough in specific places that it is worth writing the honest version down.
I opened a blank Next.js 14 app, opened Claude Code in the same folder, and started describing the site I wanted. Header, hero, blog index, project case studies, contact form. I gave it the typography I liked and the page structure I had sketched on paper. Then I let it write.
Over a weekend, the site went from empty to roughly forty components and twenty pages. I reviewed diffs, asked for changes in plain English, and rarely opened a file myself unless something was clearly off.
The boring parts were great. Layout scaffolding, Tailwind class composition, accessible nav structure, schema.org JSON-LD blocks, MDX-ish data files. Things that have a thousand examples in its training set arrived clean on the first attempt.
It was also good at being told to be consistent. Once I picked a card component pattern, asking it to apply the same pattern to a new section worked the first time, every time. That alone saved hours.
Three categories of lies, in increasing order of how much pain they caused.
First, it invented props that did not exist on libraries it was using. The code compiled because TypeScript inference filled in any, the runtime worked because the unused prop was simply ignored, and I only noticed weeks later when I tried to actually use the feature.
Second, it confidently produced breadcrumb arrays with one item on three pages, then told me the component was working. The component was working. The data I had let it generate was not.
Third, and worst, it duplicated logic. The same date formatter exists in four files. The same color token is defined twice. None of this is broken, but all of it is the kind of rot a senior engineer would catch in code review and a vibe coder will miss until the codebase is too big to refactor cheaply.
After the weekend, I added a single rule to my workflow. Before asking for new code, ask Claude to read the existing files and tell me where the new logic should live. Roughly half the duplication problem disappeared immediately.
The other half got better when I started ending prompts with a short verification step. Not "build X" but "build X, then run the type check, then list every other file you touched and why."
Start with the data model, not the components. The components are the easy part. The shape of a BlogPost or a Project is the part you will regret if a model invents it for you in a single shot.
Write a one-page house style before the first prompt. Spacing scale, color tokens, typography ramp, naming conventions. Five minutes of constraints up front saves a refactor pass at the end.
And keep a running list of every assumption the model makes that you did not verify. Most of them are fine. The ones that are not will be the bugs in production.
For a personal site, yes. For anything anyone else depends on, only with the same review process you would apply to a junior engineer who is fast, confident, and occasionally wrong about things they will never admit to.
The honest answer is that vibe coding is not a replacement for understanding the stack. It is a force multiplier for people who already understand it and a trap for people who do not.