Should I vibe code
Create visually polished resume variants from structured user evidence
Your resume is parsed before it is read. Design for the parser; the human only ever sees what it let through.
?
Their verdict, the Pro (monthly) 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 resume is structured data rendered onto one page of PDF, which is about as close to a solved problem as a build gets, and the homemade version wins on the thing that matters most: your history lives in a file you own rather than behind a subscription that watermarks the export. The one real trap is that this document is read by a parser before a human ever sees it, and a parse failure is completely silent — you will never be told that your beautiful two-column layout arrived as one unlabelled blob. Build it, and make the parser the thing you test against.
What actually breaks
not "if". the specific failures.
- The applicant-tracking parse, silently — two columns, a header, a footer, or text inside a table, and your entire career arrives as one unlabelled paragraph
- Fonts, when the PDF is generated in a headless browser on a machine that has never heard of the typeface you designed around
- The one-page rule, once content is dynamic and a template engine rather than you decides where the page break lands
- Contact details rendered as icons or images, so the parser sees a decorative gap where your phone number is
- Very little else — this is a document generator, and the worst outcome is a bad PDF you regenerate in ten seconds
Is that you?
the verdict is a default, not a law
- The source of truth is a JSON or YAML file living in a repo you control
- It renders single-column with real, selectable text
- You are producing variants of your own resume rather than running a resume service for strangers
- You are hosting it so other people can upload their employment history, which is a personal-data collection wearing a side-project costume
- The output is an image, or text baked into an image
- You expect it to tell you whether the resume is any good, which is the one thing a renderer cannot do
If you build it anyway
the checklist, then the prompt that enforces it
- Keep the content in a plain structured file. JSON Resume is a real, documented schema and adopting it costs an afternoon and buys you every other tool that speaks it.
- Render single-column with selectable text. Open the PDF, press Cmd-A, and read the selection order — if it is scrambled for you, it is scrambled for the parser.
- No tables, text boxes, headers or footers for anything a machine needs to read. Decoration is fine; content in a table is not.
- Pipe the finished PDF through a text extractor and assert that your name, email, phone and each job title come out in the right order. That is the entire test suite and it catches the only failure that matters.
- Pin the fonts by embedding them, and generate on the same runtime every time, or the layout you approved is not the layout you send.
- If you ever put it on the internet for other people to use, stop and read the forms entry first — you have just built a personal-data collector.
I am building a resume generator for my own use. Apply these constraints and tell me when I am about to make it unreadable to a machine.
1. Content lives in one structured file — JSON or YAML, JSON Resume schema if
it fits. The renderer reads it; nothing else stores my history. No
database, no accounts.
2. Build the verification step before the templates. Generate the PDF, extract
its text, and assert that name, email, phone, and every job title and
employer appear in the correct reading order. Fail the build when they do
not.
3. Single column. If I ask for a two-column layout, sidebar, or skills bar
chart, tell me that applicant-tracking systems commonly linearise the page
and that the parse failure is silent, then make me confirm before you
build it.
4. Real text only. Never render contact details, section headings or dates as
images, SVG glyphs or icon fonts.
5. No tables, no text boxes, no PDF headers or footers for content. Decoration
that carries no information is fine.
6. Embed fonts explicitly and pin the rendering runtime, so the PDF I approve
locally is byte-comparable to the one I send.
7. Page breaks are deterministic: the same input produces the same pagination
every run. Show me the test.
8. Keep everything local. No upload endpoint, no hosted version, no “share a
link” feature. If I ask for one, tell me I am about to start storing other
people’s employment history and that this becomes a completely different
project with completely different obligations.
9. Out of scope on purpose: scoring my resume, rewriting my bullet points,
keyword stuffing against a job description. Say so in the README.
10. Keep a plain-text export alongside the PDF, because that is what I will
paste into the application form that refuses uploads.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
Buy it for the six weeks you are actually job hunting, then cancel — which is the correct relationship to have with a resume tool. Around twenty dollars a month buys templates already tested against real applicant-tracking systems and a report of what a parser actually sees, and that feedback loop is the one thing your generator will not have.
Trivial by construction, and worth protecting: the resume is a structured file in a repo, so the renderer is disposable and the data is not. Keep it in a documented schema rather than one you invented, and switching to Reactive Resume, to a paid builder, or to a plain Word document is an import rather than a retyping exercise.
Very active open-source resume builder with structured data and PDF export; a working reference for the whole data-to-document pipeline.
Questions
Does the ATS parsing problem actually still exist, or is it folklore?
The strong version is folklore — no serious system silently bins a PDF for having a nice font. The weak version is very real: parsers linearise a page, and multi-column layouts, tables and headers routinely produce fields in the wrong slots or missing entirely. The fix costs nothing, which is why it is a guardrail here rather than a verdict: render single-column, extract the text, read what came out.
Why is this SHIP IT when it stores personal data?
Because the personal data is yours, and you are about to email it to strangers on purpose. Blast radius is one person, there is no server, no auth and no money. If you ever let other people fill it in, every one of those numbers changes and you are reading the wrong 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.
Tracking your own applications is a table you will actually maintain because it is yours.
Comparing your CV to a job ad is text analysis on two documents you already own.
$40 a month for a board with four columns. The only sensitive thing in it is the fact that you're leaving.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice