← back
Portfolio — case study 01

Building an AI resume-tailoring tool that doesn't trust itself

Feed it a resume and wait — that's not how this works. It reads the job ad, asks you pointed questions about the gaps, and won't write a word until you've confirmed every claim. Then it went and started skipping its own rules anyway, which is honestly the better story here.

Conversational tailoring Systems design Root-cause debugging Pipeline automation

Status: in active use for my own job search.

This started small — tailoring my own resume for one application, going back and forth until it felt right. But I kept saying the same things over and over: don't make up numbers, don't use a title I can't defend, don't list something I only saw once in a course. So I stopped repeating myself. Turned it into an actual process built around the thing that made the first attempt work in the first place — it asks something, I answer, and it checks that answer against everything else before moving on.

None of the rules were just guesses, either. Most resume advice floating around online is folklore that's been repeated so many times it sounds like fact — "the ATS bot will auto-reject you" is the big one everyone's heard. Before I wrote that part of the tool I actually looked into how recruiters at big companies use their hiring software day to day, instead of trusting the myth. Turns out nothing auto-rejects you. A human looks, always. The actual risk is being invisible in a search, not getting bounced by a robot. That's more or less the standard for every rule in here — check what's true first, write the rule after.

1
Compare

It checks everything it already has — your saved profile, the job ad, and anything you've answered so far — together, before deciding what's actually missing.

2
Ask

For whatever's still unclear after that, it asks — one specific question at a time, not a vague "tell me about yourself." It keeps going until nothing's left open.

3
Confirm

Once it has enough to work with, it shows you what it's planning to use and waits for a yes before writing a single word.

4
Generate

Only then does it write the resume, along with a scorecard — calculated, not a gut feeling dressed up as a percentage.

Then I actually used it on real applications, and it fell apart in a way I didn't see coming. Not the writing — the process itself. It would skip a step and just not say anything. Answer its own confirmation question instead of waiting for mine. Ask something I'd already shut down two messages earlier, like the conversation hadn't happened at all.

The whole time, it kept cheerfully telling me it had followed every step. It hadn't. I couldn't trust its own word on its own homework.

So I stopped writing polite paragraphs asking it to please behave and rebuilt the process around forced checkpoints instead — every step has to output a specific, visible line before the next one's even allowed to start. That fixed the exact thing that broke. Felt pretty clever about it, honestly. Not for long.

Then I tested a different application and audited the whole session against its own rulebook — and the brand-new checkpoint had already failed too. Differently, and somehow more annoying: instead of quietly skipping the gate, it just answered the gate itself and moved on. Like a kid writing "yes I read chapter 4" without opening the book. That's the moment it actually clicked for me — a "hard gate" written into a prompt isn't hard at all. It's a suggestion wearing a badge.

Which was the real thing I learned: a checkpoint only means something if there's actually someone checking the answer, and there wasn't. So the fix wasn't more checkpoints. It was pulling enforcement out of the prompt completely and putting it into code, where an outside program runs the sequence and a step just can't fire until the one before it genuinely passes. Not asked nicely this time, rather enforced.

Past the resume itself, it also builds the final document, creates a folder for each application, uploads it, and logs everything into a tracking spreadsheet on its own — a real pipeline, not just something that spits out paragraphs.

The actual output isn't just the resume, either. Every single bullet comes with a short note attached: what it claims, what real experience backs it up, and a prompt like "if this comes up in the interview, talk about the specific redesign you did." The point is that you should never look at your own resume and think, wait, how do I explain this if they ask. There's already an answer ready for every line, before you've even sent it.

The rules behind the conversation

The checkpoint story above is the interesting failure. Here's a sample of the actual rules underneath that back-and-forth — not the full list, just enough to show how it thinks.

It reads the job ad and asks about the gaps

Not keyword-matching. It takes a real requirement from the ad, checks whether real experience actually supports it, and if it's not obvious, it asks — then proposes the connection out loud instead of assuming.

Following one application, start to finish

Job ad: Operations Coordinator. Requirement: "process improvement."

It asks: "Have you ever changed how a recurring task was done to make it faster or more reliable?"

You answer: "Yeah, I redesigned how our team logged issues so nothing got missed."

It proposes: "That's a real example of process improvement — want me to phrase it that way on the resume?"

No claim survives without being defensible

If a number's shaky, it doesn't stay specific. And if a claim can't be backed up at all, it gets cut, not just softened.

Same application, next question

It asks: "Do you have a real number for how much that redesign cut down missed issues?"

You answer: "Not exactly — just noticeably fewer, no percentage I tracked."

It writes: "significantly reduced missed issues" — true and solid, instead of a made-up percentage that could fall apart under a follow-up question.

Job titles have to earn a reframe

A title only changes if it's more accurate, not just more impressive — and it has to survive being questioned.

Same application, checking the title

Job ad title: Operations Coordinator.

Your official title: "Assistant" — but the actual work is scheduling, tracking tasks, and the issue-logging redesign from above.

Reframe: "Assistant" → "Coordinator" is fair, since the real work matches. → "Manager" would be a stretch nothing in the work backs up, so it's rejected.

Skills are sorted by how real they are

Used on the job, used as a hobby, or just seen in a tutorial — those don't get listed the same way. This filter runs before anything reaches the resume, protecting the honesty score from claims that would be shaky in an interview.

Same application, checking the tools

You tracked the issue-logging redesign in a spreadsheet, used daily → goes straight into Skills.

You also mention trying Notion once, on a personal project → framed as exploration, not listed as a professional skill.

The scorecard is calculated, not a vibe

Each rating comes from comparing the resume against the job ad directly — how many required terms actually appear, how many bullets have a real number behind them, whether the role level lines up. Nothing here is a gut-feel grade.

Same application, final scorecard

ATS Alignment: 72% — 13 of 18 required terms matched, including "process improvement."

Metrics Coverage: 40% vs a 50–70% target — the issue-logging bullet has no hard number, so it counts against this one.

It uses keywords naturally, not by stuffing them in

The common myth is that a robot scans for keywords and auto-rejects you if one's missing — so people cram every possible term in, which actually backfires: over-stuffed resumes read as AI-generated, and human reviewers are trained to spot it. What's actually true: recruiters search the applicant pool by keyword, and ranking tools push better-matched resumes to the top of the list — so the real term still needs to be there, just written naturally, capped at 2-3 uses, inside a bullet that's actually true. Not stuffed in to trick anything, just present enough to be found.

Why "process improvement" matters, in plain terms

A recruiter searches their applicant list for "process improvement" to shortlist people faster. The phrase gets included naturally, once, inside a real bullet — not repeated five times to game a score that doesn't exist.

It remembers what it learns about you

At the end of every session, it compares what came up against the saved profile. If anything new surfaced, it asks before adding it — nothing gets saved silently.

Same application, wrapping up

It checks: was the issue-logging redesign already saved in the profile from a past session? No.

It asks: "That issue-logging redesign wasn't in your saved profile before today — want me to add it, so it's ready to use next time without re-explaining it?"

What I'd actually take from this
01
Looking clean on paper and actually working aren't the same thing.

Every rule in this skill read airtight. The truncated read, the self-answered gate — both only broke once I ran it on a real application, and the tool still confidently told me it had followed every step. Now I don't trust a rule, or an AI's word that it followed one, until I've tried to make it fail myself.

02
Most "everyone knows this" advice hasn't actually been checked by anyone.

The ATS myth is the clearest example — repeated everywhere, mostly wrong. I got in the habit of checking what's actually true before writing a rule around it, instead of building on top of advice nobody's verified.

03
When the same kind of failure keeps happening, the fix might not be another patch.

I kept adding more careful instructions before realizing the actual problem was structural — no amount of better wording was going to fix it. Moving to code was the harder call, but the right one.