Vibe-coded projects have a perception problem: say “the AI wrote it” and people hear “no skill involved”. The honest answer - you supplied the judgment, the agent supplied the typing - only lands if there’s evidence. The fix is not hiding the AI. It is showing your work the way engineers always have.

The five artifacts

1. The spec, published. Keep the brief that started the project - stack, constraints, definition of done - in docs/SPEC.md. It proves the project began as a decision, not a dice roll, and it doubles as the clearest feature list you can show.

2. A README of decisions, not descriptions. Anyone can read your code. What they can’t reconstruct is why: why this framework over that one, why this data model, what you rejected. Three or four short “why” sections beat ten paragraphs of API docs.

3. A decision log. The single most convincing artifact for vibe-coded work: a running list of moments where the agent proposed A and you chose B, with one line of reasoning each. “Agent suggested storing sessions in memory; moved to Redis because deploys restart containers.” Ten entries demonstrate more skill than any code tour - because judgment is the skill.

4. A two-minute demo. A live URL or a short screen recording showing the thing working. Reviewers believe what runs. Put it at the top of the README.

5. The verification trail. Tests, plus a short checklist of what you reviewed before shipping: diff review, security pass, edge cases considered. It answers the unasked question - “did anyone actually check this?” - with a yes they can inspect.

What reviewers actually look for

Recruiters and clients rarely audit your code line by line. They scan for three signals: can this person define a problem (spec), steer a solution (decision log, README), and vouch for the result (tests, demo)? Those three signals are exactly what the artifacts above produce - and they are all things the agent cannot do for you.

The one-repo layout

my-project/
├── README.md          ← demo first, then the "why" decisions
├── AGENTS.md          ← conventions: shows how you ran the project
├── docs/
│   ├── SPEC.md        ← the original brief
│   └── DECISIONS.md   ← agent proposed / I chose / why
└── ...                ← code + tests

None of this takes more than an hour if you capture it as you build instead of reconstructing it later. The habit pays twice: better documentation while you work, and a portfolio piece that argues for you when you’re not in the room.