Building an AI Resume Rewriter That Refuses to Invent Achievements

Shaozhe Zhang — Tue, 14 Jul 2026 13:48:46 +0000

AI is very good at making a resume sound more polished. It is also very good at making an unsupported claim sound completely plausible.

That tension is what led me to build Zesume, an AI resume rewriter for students and early-career applicants targeting software engineering, quant, finance, and general roles.

The goal is deliberately narrower than “let AI write your resume.” Zesume starts with an existing resume, improves its structure and language, and tries to preserve a hard boundary:

Rewrite the evidence. Do not manufacture the evidence.

The core rewriter is available without creating an account, so you can try the workflow directly.

The problem with plausible improvements

Consider a source bullet like this:

Built a React dashboard for a university project.

There are many legitimate ways to improve it:

Developed a React dashboard that organized project data into reusable, interactive views.

But an AI model may be tempted to make the bullet look more impressive:

Developed a React dashboard used by 5,000 students, reducing reporting time by 40%.

The second version sounds stronger, but the user never supplied those numbers. On a resume, that is not a harmless creative flourish. It is a false claim the applicant may later have to defend in an interview.

This problem becomes especially visible for students. Their experience may be real and technically interesting, but it often lacks the clean metrics found in polished resume examples. A useful rewriting tool should help express the available evidence clearly instead of filling every gap with a synthetic percentage.

Treating the current resume as the source of truth

Zesume always treats the pasted or uploaded resume as its primary source. The rewriting instructions explicitly prohibit adding unsupported:

employers, roles, and internships;
degrees, grades, awards, and rankings;
technologies, datasets, and financial instruments;
percentages, revenue, user counts, latency improvements, and model metrics.

If a useful metric is missing, the preferred behavior is to report it as missing information rather than insert a number.

A simplified version of the instruction looks like this:

Core rule: Rewrite, do not invent.

Preserve the user's original facts.
Do not add companies, roles, technologies, metrics, or achievements.
If a metric is missing, put it in missingInformation.
If a claim is uncertain, keep it conservative and add a warning.

Prompt instructions cannot guarantee factual accuracy on their own. I do not want to pretend otherwise. Zesume still asks the user to review the result before using it.

The instructions are one layer in a design that also constrains what the model returns and makes uncertainty visible to the user.

Separating career direction from resume structure

One early design decision was to avoid treating “template” as a single choice.

A resume has at least two independent dimensions:

Career direction — what evidence should be emphasized?
Document structure — how should that evidence be organized?

Zesume therefore lets users select a career target separately from a structure.

The current career targets are:

Software engineering
Quantitative research and trading
Finance and spring-week applications
General internships

The built-in structures include a classic ATS layout, a project-heavy software engineering layout, a quant research layout, a finance layout, and a one-page student layout.

This separation matters. A software engineering applicant may want a project-heavy structure, while another applicant with more work experience may prefer a classic chronological layout. Both can still receive software-engineering-specific rewriting guidance.

Career rules are also conservative in different ways. For example, the quant target explicitly prohibits inventing Sharpe ratios, returns, information coefficients, drawdowns, or backtest performance. If those values are absent, the model can recommend that the user add them, but it should not guess them.

Why the model returns structured data

The model does not return only a large Markdown string. It produces two synchronized representations:

professional resume text for reading and copying;
structured resume data for rendering and document export.

The structured representation contains a header, sections, items, details, bullets, and quality notes:

type StructuredResume = {
  header: {
    name: string;
    location: string;
    email: string;
    phone: string;
    links: string[];
  };
  sections: Array<{
    title: string;
    items: Array<{
      name: string;
      role: string;
      organization: string;
      date: string;
      location: string;
      details: string[];
      bullets: string[];
    }>;
  }>;
  qualityNotes: {
    majorChangesMade: string[];
    missingInformation: string[];
    warnings: string[];
  };
};

This gives the application a contract to validate. The server rejects invalid JSON shapes, limits oversized output, normalizes fields, and renders a text fallback from the structured representation when needed.

It also gives missing information a real place in the interface. A model no longer needs to “solve” every incomplete bullet. It can say that a result, scale, or metric would strengthen the resume and leave the decision to the user.

Again, structural validation is not the same as semantic fact-checking. It tells us that the response is safe to process and render; it does not prove that every sentence is supported. That distinction is important when building user-facing AI products.

Custom DOCX templates without trusting their example content

Zesume also supports custom TXT and DOCX templates for paid plans.

This introduced another source-of-truth problem. A template may contain example names, companies, dates, metrics, and achievements. Those examples are useful for understanding layout and writing style, but they must never become candidate facts for the user's resume.

The template flow therefore extracts a sanitized specification describing things such as:

section order;
density and length expectations;
bullet style;
formatting and content rules.

The template is treated as a structure and style guide, not as resume evidence.

For DOCX export, the browser keeps the original file for the current session. The export process modifies the document content while preserving as much of the template's existing layout as possible. The original uploaded template is not kept as a reusable server-side document library.

The current stack

Zesume is a full-stack Next.js application deployed to Cloudflare Workers through OpenNext.

The main pieces are:

Next.js and React for the application and route handlers;
Cloudflare Workers and OpenNext for deployment;
DeepSeek for structured resume rewriting and template analysis;
PostgreSQL and Prisma for accounts, access, saved history, and optional career memory;
Auth.js for Google sign-in;
DOCX and OOXML tooling for document extraction and export.

Resume generation uses bounded structured output and a request timeout. Uploaded resume and template files are processed in memory rather than being written to application logs or stored as original files.

Signed-in users can save selected generations and maintain optional profile or career memory. That memory is supporting context, not an unrestricted second source. The current resume remains primary, and potentially useful missing details should become suggestions rather than silently inserted claims.

What the product can do today

The current workflow is:

Paste resume text or upload a TXT/DOCX resume.
Choose a career target.
Choose a built-in or eligible custom structure.
Select a professional, concise, or technical tone.
Generate and review the rewritten result.
Export it as TXT or DOCX.

The core workflow works without sign-up. Accounts are used for features such as saved history, profile information, and career memory.

What it deliberately does not do yet

The current version does not support:

PDF import or export;
a full visual resume editor;
restoration of arbitrary source formatting;
every complex DOCX layout;
automatic verification of every generated claim.

These are not hidden behind optimistic copy. File formats and document layouts become complicated quickly, and resume accuracy is too important to present probabilistic output as verified truth.

What I learned

The largest lesson was that adding constraints can make an AI product more useful.

A resume rewriter does not need unlimited creativity. It needs controlled transformation, visible uncertainty, and a workflow that keeps the user responsible for the final version.

Structured output helped, but not because JSON magically prevents hallucinations. It helped because the product could represent uncertainty, validate the response shape, and separate content generation from document rendering.

The second lesson was to keep different sources in different trust categories:

the current resume is evidence;
user-approved memory is supporting context;
a template is a structural reference;
the model is a transformation engine, not an authority on the user's life.

That trust model now influences most implementation decisions in the project.

Try it

You can try Zesume at zesume.xyz/app. The core rewriting flow does not require an account.

I am particularly interested in feedback on:

whether the rewritten bullets stay faithful to the source;
whether missing-information notes are useful;
how well the career-target and structure choices fit real applications;
where the DOCX workflow breaks on unusual documents.

If you build AI features around user-provided facts, I would also be interested to hear how you separate useful transformation from unsupported invention.

DEV Community: Shaozhe Zhang