Should I vibe code
AI CV formatting, tailoring, matching, and template automation for staffing firms
The model doesn't know it invented the job title. Your client assumes the agency verified it.
?
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
Parse a CV, hand it to a model with your agency's template, get a clean .docx back — that demo works on the first attempt and it is genuinely impressive. Read what you have actually built, though. It is a pipeline that rewrites factual claims about real people who never chose your software, scores them against jobs, promises to anonymise them, and emits a document that goes out under your letterhead to a client who will assume a human checked it. The tailoring step is the sharp end: "make this CV match the job description" is an instruction whose most obedient completion is to add the qualification that is missing. Around it sits everything a staffing firm cannot get wrong — candidate data held as a processor for your clients, deletion rights that now have five homes to reach, special-category data hiding in half the European CVs you touch, and automated ranking of people for employment, which European regulators have written down specific opinions about. This is one notch from ABSOLUTELY NOT, and the only reason it is not there is that a careful build keeps a human between the model and the send button.
What actually breaks
not "if". the specific failures.
- The tailoring step, which is asked to make a CV match a job description and does it the easy way — by adding a certification, stretching an end date, or promoting "supported" to "led"
- Anonymisation, which strips the name from the body and leaves it in the header photo, the docx author metadata, the filename, the email footer and a LinkedIn URL halfway down page two
- PDF parsing on a two-column layout, so a ten-year career is reconstructed in the wrong order and a candidate is rejected for a gap they never had
- Match scores, which look like measurement and are an LLM's impression of names, universities, career breaks and phrasing, applied to who gets an interview
- Deletion requests, once a candidate's data lives in the upload bucket, the parsed record, the vector index, three generated .docx files and a model provider's retention window
- Special-category data that European CVs carry as a matter of course — date of birth, nationality, marital status, a photo, sometimes a disability disclosure — now sitting in a side project's database
- The template itself, which is the actual product: house style, page breaks, footers and fonts that render correctly in your Word and wrongly in the client's
- ATS write-back, where a sync overwrites the recruiter's hand-edited notes in Bullhorn with the model's version
Three weeks into a contract placement, the client's compliance team asks for evidence of the lead-auditor certification listed on the CV your agency submitted. The candidate does not have one and never claimed one. You pull the original upload out of the bucket and it is clean: no certification, no mention of the standard. What sits between the two files is your tailoring prompt, which told the model to align the CV with the job requirements, and the model did exactly that — in your house template, under your logo, with the consultant's name in the footer and a submission date on it. Nobody compared the two documents, because comparing them was never a step in the pipeline. The client wants to know how it happened. Your consultant wants to know if she is the one who sent it. And behind both questions is the one you cannot answer that afternoon: this pipeline has produced four thousand documents, you kept the outputs but not the diffs, and you have no way to say which of the others say something the candidate did not.
Is that you?
the verdict is a default, not a law
- The model only ever reformats and suggests — the source facts are copied, never regenerated
- A human sees a diff between the original and the generated CV before anything leaves the building
- Nothing ranks or scores candidates, and nothing filters a shortlist automatically
- You are formatting your own CV, or the CVs of people who have each agreed to it in writing
- A generated document can reach a client without a person having compared it to the source
- It produces a match score, a ranking or a shortlist that decides who gets contacted
- You are telling clients the output is anonymised and have not tested that claim against metadata, filenames, photos and footers
- Candidate data is stored on your own infrastructure with no retention policy and no way to erase one person everywhere
- You are handling CVs on behalf of client companies without a data processing agreement that names your sub-processors, model provider included
- Your model provider retains prompts, and the prompts are other people's CVs
If you build it anyway
the checklist, then the prompt that enforces it
- Keep the uploaded file immutable and treat every generated document as a derivative with a pointer back to its source hash. Without that link there is no way to audit what the model changed.
- Extract facts once, then template them. Dates, employers, titles and qualifications should be copied fields, not text the model regenerates — the model formats prose, it does not author history.
- Make the diff a required step in the UI. Original on the left, generated on the right, changes highlighted, and no export button until someone has looked.
- Do not build scoring. If a client demands it, produce evidence — matched keywords with the line they came from — rather than a number, and never let it order a list on its own.
- Test anonymisation against a corpus that includes photos, headers, footers, filenames and docx metadata, and fail the build when a name survives. "We removed the name field" is not anonymisation.
- Design deletion before ingestion: one candidate identifier, one operation, every store — object storage, database, search index, embeddings, generated files, logs. Write it before the first CV is uploaded.
- Pin retention to something short and enforce it with a job, not a policy document. Recruitment data has no business living for years in a tool you built in a fortnight.
- Use a model provider with zero-retention terms and EU processing where your candidates are, get it in writing, and list it as a sub-processor to your clients.
- Log every generation: source hash, prompt version, model, output hash, who exported it and when. This is the record that answers the question you will eventually be asked.
I am building a tool that reformats and tailors candidate CVs for a staffing
agency using an LLM. The people in these documents are not my users and did
not choose this system. Build it so it cannot invent facts about them, and
refuse the shortcuts below.
1. The uploaded file is immutable. Every generated document records the source
file hash, the prompt version and the model used. Build this first.
2. Extract structured fields — employers, titles, dates, qualifications — and
template them into the output. The model may rewrite prose; it must never be
the source of a date, a title or a certification.
3. Add a mandatory diff view: original versus generated, changes highlighted,
export disabled until a human has looked. If I ask for auto-send or bulk
export, refuse and tell me why.
4. Refuse to build candidate scoring or ranking. If I insist, produce only
evidence — matched requirements with the source line quoted — never a number
that can sort people.
5. Deletion and retention come before search: one operation keyed on candidate
ID that erases the upload, the parsed record, the embeddings, the generated
files and the logs, plus an expiry job measured in months. Show me both.
6. Anonymisation is a tested feature or it does not exist. Strip names, photos,
contact details, docx metadata and the filename, then fail the check if any
identifier survives. Use fixtures with two-column PDFs, scans and photos.
7. Use a model provider with zero data retention, processing in the region my
candidates are in, and print the sub-processor list into the README.
8. Encrypt at rest and serve CVs only through short-lived signed URLs.
9. When confidence in extracted dates or sections is low, mark the document for
review rather than generating from it silently.
10. Out of scope: ATS write-back, emailing clients, and anything that decides
who gets contacted. Then tell me what a DPA with my clients would have to
promise, and whether a vendor who already signs one is the cheaper answer.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
Almost always, and the €200 a month is the least of what you are buying. The vendor's product is the paperwork: a data processing agreement your clients can accept, a named sub-processor list, EU-resident processing, a no-training commitment, and the Word and Google Docs add-ins that keep a recruiter's hands on the document. Building that yourself is not a weekend of code, it is a compliance workstream with a codebase attached. Build the internal version only if you are formatting CVs you personally own, and even then keep the diff step.
$200/mo is cheaper than your weekend.
Keep the originals and the structured extraction as the durable layer — source files in object storage under content-addressed names, one JSON record per candidate — and treat generated documents as disposable derivatives you can regenerate. Then moving to Saply or any ATS-attached vendor is an import, not an archaeology project. Two things have to happen on the way out and neither is code: run the deletion job across every store including the vector index, and tell your clients what changed in your sub-processor list, because they signed a DPA that names you.
Open-source resume builder with structured data, templates and PDF export — the templating half without the model inventing anything.
Open-source LLM resume tailoring and job matching that runs locally against your own model.
Questions
It only formats CVs. Where does the regulation come from?
From what the formatting is attached to. You are processing other people's personal data on behalf of client companies, which makes you a processor with an obligation to secure it and to erase it on request. The moment the same pipeline scores or ranks candidates it also touches automated decision-making in an employment context — the area European law treats as high-risk and where a person is entitled to more than "the model said 62%". Formatting alone is defensible; formatting plus matching, sitting in the same weekend project, is not.
Can I stop the model inventing qualifications with a better prompt?
You can reduce it, and you cannot rely on it. The structural fix is to take facts out of the model's hands: parse employers, titles, dates and certifications into fields, template those fields into the document, and let the model rewrite only the prose around them. Then add a diff, because the failure you care about is the one nobody noticed — and a highlighted line in a review screen catches it in a second.
Is anonymising a CV actually hard?
Harder than it looks, because a name is not the identifier that leaks. It is the photo in the header, the filename the client sees when they save the attachment, the docx author field, the personal domain in an email footer, a portfolio URL, and the referee who shares a surname. If you promise a client anonymised CVs, you need a test corpus with all of those in it and a check that fails the export — otherwise you have promised something you have not verified.
Why is this YOUR FUNERAL rather than ABSOLUTELY NOT?
Because a version of this exists that is fine: parse, template, show a diff, let a human send it, keep no scores. That is a real tool with a real payoff and it is why the verdict stops one band short. Every step past it — auto-send, ranking, claimed anonymisation, indefinite retention — moves it across, and each of those steps is a one-line change somebody will make on a busy Thursday.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 32 — security of processing (EU)
- GDPR Art. 22 — automated individual decision-making, including profiling (EU)
- European Commission — regulatory framework for AI (employment and worker management are listed high-risk uses)
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.
You are building a thing that reads everything you type. At least this way, you are the one reading.
Paraphrasing is one API call with a good system prompt behind it.
The canvas is not the product. The queue of half-finished runs you can fix and resume is the product.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice