Should I vibe code
Build ATS-friendly resume variants from a verified evidence bank and export PDF
Ask a model for achievement bullets and it will invent the metric, because metrics are what good bullets have.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A CV is a small structured document rendered onto one page, and the homemade version wins the ownership argument outright: your history becomes a file you keep rather than an export you have to stay subscribed to retrieve. Two entries on this site already make that case for resume builders, so here is the part specific to Rezi. Rezi's pitch is generation — the AI writer will cheerfully produce "Reduced infrastructure spend 34% by migrating to Kubernetes" for someone who did not do that, because a model asked for achievement bullets will supply a metric, metrics being what good bullets contain. That document then goes out under your name, to people who will ask about the 34% in an interview and, at a certain class of employer, verify it. Nothing about this is dangerous to anyone else and the code is a Saturday. Build it — but build it evidence-first, with a bank of things you actually did and a generator that is only ever allowed to rephrase them.
What actually breaks
not "if". the specific failures.
- The generated numbers, which are the whole feature and the whole hazard — a fabricated percentage on a CV is grounds for withdrawing an offer, and it is in a document you already sent
- Version drift, once there are eleven tailored variants and you cannot remember which one the company you are interviewing with actually received
- PDF layout, endlessly: a bullet that reflows onto page two, a name that collides with the margin at a different font size, and text that copies out in the wrong order
- Parser output, which is what a recruiter's system sees first — columns, text boxes, header images and icon glyphs all survive visually and disappear on extraction
- Tailoring at volume, where forty variants generated against forty job ads slowly converge on whatever phrasing the model prefers, and every one of them sounds the same
- The export, if the resume lives only inside the tool: a rendered PDF is not your data, and the structured version behind it is the thing worth keeping
Is that you?
the verdict is a default, not a law
- The source of truth is a structured file of things you actually did, and the renderer is downstream of it
- Any generated line is a rephrasing of an entry in that file, shown next to the original before you accept it
- You export a plain-text or single-column PDF alongside the pretty one, and check what the plain version says
- You are letting a model write bullets from a job title alone, because what comes back is fiction with your name at the top
- You would send tailored variants without recording which company received which version
- The layout is two columns with sidebars and icons, and you never check how it extracts — that is the single most common way a good CV is never read by a human
- You are building it for other people's job searches, at which point a hallucinated metric becomes someone else's interview to survive
If you build it anyway
the checklist, then the prompt that enforces it
- Make the evidence bank the source of truth: role, dates, what you did, and the numbers you can actually stand behind. Everything downstream is a rendering of it.
- Constrain generation to rephrasing. A model may reword an entry it was given; it may never introduce a figure, a technology or a scope that is not already in the bank.
- Show the original and the rewrite side by side and require an explicit accept per line. Never bulk-apply.
- Flag every number in the output and make yourself confirm it against the evidence bank before export, because numbers are what interviewers follow up on.
- Keep a log of which variant went to which employer, with the date. It costs one table and it is the difference between a calm interview and a scramble.
- Export a single-column plain-text version every time and read it, because that is closer to what a parser hands the recruiter than your layout is.
- Store everything as JSON or YAML in version control. The PDF is an artefact; the structured history is the asset.
I am building a resume builder with AI assistance: an evidence bank of my real
experience, tailored variants per job, PDF export. The risk is fabrication, not
security. Build in this order and hold the line on invention.
1. Define the evidence bank first, as plain YAML or JSON I edit directly: role,
employer, dates, what I did, and a separate list of verified metrics with a
note on where each number came from. This file is the source of truth.
2. Build the renderer next, before any AI feature: structured file in, PDF out,
plus a single-column plain-text rendering every time so I can see what a
parser gets.
3. Only then add generation, constrained hard. The model may rephrase entries
it was given and may not introduce a number, technology, team size or scope
absent from the bank. Enforce it by passing only relevant entries as context
and by checking output for digits that do not appear in the input.
4. Every generated line appears beside the original with an explicit accept or
reject. No bulk apply, no silent rewriting of the bank.
5. If I ask you to make my experience sound more impressive, or to write
bullets from a job title alone, refuse and explain that a fabricated metric
can end an offer after it is signed.
6. Highlight every numeric claim in the final document and make me confirm each
against the bank before export.
7. Track variants: one record per application with employer, date and the exact
file sent — the rendered document, not just the parameters.
8. Keep everything local and in version control. No account, no upload of my
employment history.
9. Default to a single-column layout with real text: no icon fonts, no text in
images, no sidebars. If I ask for two columns, show me the extracted text
before I commit.
10. Out of scope, and say so: predicting interview outcomes, scraping job
boards, claiming compatibility with a named applicant tracking system.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
If you want the interview practice and the human review as well as the document, that is a bundle you are not going to reproduce, and the $149 lifetime tier is a smaller number than a weekend for most people reading this. For the resume itself, build it: your history in a file you control beats a subscription that holds the structured version hostage, and the constraint that matters most — never claim a number you cannot defend — is one only you can enforce anyway.
$29/mo is cheaper than your weekend.
The evidence bank is the asset and it is already a file, so there is nothing to escape from. Keep it in version control, render to PDF on demand, and every future tool — Rezi, Reactive Resume, RenderCV, a LaTeX template — takes a structured history as input. The trap this avoids is the one people hit with hosted builders: discovering that what they own is a watermarked PDF rather than the data behind it.
Active open-source resume builder with structured data and PDF export.
Renders a YAML CV into a typeset PDF, which is exactly the evidence-bank-to-document pipeline this entry argues for.
Questions
There are already resume-builder entries here. What is different about this one?
The others are about rendering — layout that a parser can read, and owning the structured version of your history. This one is about generation. Rezi's differentiator is the AI writer, and an AI writer pointed at a CV has one specific failure mode: it supplies the quantified achievement you did not have, because that is what the genre demands.
How do I actually stop a model inventing numbers?
Structurally, not by asking nicely. Pass it only the entries from your evidence bank, tell it to rephrase rather than compose, and then check the output for any digit that does not appear in the input. That check takes ten lines and catches nearly all of it.
Is this really irreversible enough to carry a risk tag?
A CV is a document you send to strangers who keep it. You can fix the file; you cannot fix the forty copies already sitting in inboxes and applicant tracking systems. That is a small blast radius but a genuinely one-way door, which is why the tag is there on an otherwise cheerful entry.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Your two-column layout looks great to a human and parses as one scrambled sentence to the system that screens you.
Your resume is parsed before it is read. Design for the parser; the human only ever sees what it let through.
You can ship the score by Sunday. You cannot ship a reason to believe it.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice