These days my career has reached the level where I can't use one generic résumé for job applications anymore. The jobs I apply to expect incredibly specific experience and a near-perfect fit, which means I need to submit highly customized résumés. I've thought about this problem for a long time. Years ago I had the idea of writing up a "super-résumé", an ultra-comprehensive CV that contained everything I've ever done, every employer, every role, every project. For any new job application I could take that super-résumé and just delete the items that weren't relevant. So I tried it out. It kind of worked ... but it was clunky and inefficient. The pieces didn't fit together. The résumés seemed like collections of random parts rather than cohesive arguments. And it didn't save much time. I was removing more than I was retaining and I was still modifying what remained to better fit each job posting. Eventually I gave up on this idea and went back to starting with a general purpose résumé and modifying it for each new application. But the problem remained. Reading and remembering what was on that general purpose starter résumé, remembering all the past experiences that needed to be added to it, then modifying the résumé heavily for a particular posting took me several hours on average. I could do two applications a day working like this. Now that I'm job hunting more actively, I needed a better solution.
It's 2026. Why should I write a large number of customized résumés manually when we have LLMs now? Because LLMs are terrible, that's why. Even when I walk them through the process of modifying my résumé step by step, they still screw up almost every step. They blur projects together. They invent credentials out of thin air. They inflate job titles and ownership, sometimes to absurd extremes, even when I explicitly tell them not to before we start. I've asked Gemini and ChatGPT and Claude to modify résumés for me and they've come out so deranged that I would never consider submitting them to employers. But this is strange. Why should they be so bad at this? I use LLMs almost every workday to write code. And sometimes coding LLMs make me want to punch my computer screen but most of the time they genuinely do a good job and save me time and effort. Why are they so bad at writing résumés? Or conversely, why are they so good at writing code? Because compilers, that's why.
Over the past year I've transitioned from not using LLMs in any meaningful way at work to using LLMs as my first tool for almost all coding projects. That's a pretty incredible shift! But the most important rule I've learned is, you need a feedback loop to get the best results out of a command. You need a built-in verification step. If I simply tell a coding LLM to "read this code and make this change", the odds that it will do so correctly on the first try is low. Very low. However, if I tell it "read this code and make this change, then build the directory using the command <compiler build whatever> and test it using the command <compiler test whatever>", the odds that it will make a correct change are very high. Like going from 10% reliable to 90% reliable. That's why LLMs are useful for writing code. The compiler checks their work and keeps them honest, instantly and automatically. Unfortunately I don't have a compiler for résumés. But why can't the LLM check its own work?
I had an idea and I came up with a plan. If I just ask an LLM to build or modify a résumé, I don't have any verification mechanism except reading the output document myself and correcting it line by line. Odds are that's going to take just as much time or maybe even more time than just making the change myself. But can I create a straight-forward test and a list of acceptance criteria that the LLM can apply to its own work, and then have it run that test? On top of that, instead of manually specifying the changes to be made to each new résumé, why not give the LLM all the information it could possibly need for any résumé and have it select whatever's most relevant for a particular job description? I already tried this before. Can LLMs make that old idea work?
The right prompt makes all the difference in the world. I imagined a thoroughly optimized prompt that could do everything I wanted in a single step, or at least in a single prompt.
- read a single job posting
- generate from my past work experience (my super-résumé) a new bespoke résumé that is a perfect fit for that individual job posting
- run some sort of feedback loop, checking the new résumé for accuracy, clarity, professionalism until it passes every test
It took a few days of solid effort to figure out, but it works. I created a new super-résumé, which from here on I'll call my "career database", that contains a deep and detailed history of basically everything I've ever done. Every employer, every role, every project, every skill, publications, college classes, college projects, hobby projects, amateur training and certifications, names, dates, cities, collaborators, stakeholders, suppliers, results, everything in one enormous text document. I worked on this doc for two days. More than 15,000 words. Initially I tried to dictate everything to an LLM and have it organize and summarize each story into about one page but that didn't go so well. Exaggerations and mischaracterizations abounded. This foundational database I think needs to be my own writing.
After I completed the first draft of my career database, I started on a prompt. I wrote a few myself, before bringing LLMs into the loop. "I'm trying to build a résumé generator prompt. It needs to take in one enormous text document containing my entire career history and a second text document containing a single job description and then spit out a bespoke résumé that is a perfect fit for that job description. But I don't trust you at all. I'm a high-assurance software engineer. Accuracy, integrity, and reliability are the currencies of my trade. YOU CAN NOT EXAGGERATE." I explained the idea of a feedback loop with guardrails and acceptance criteria and asked LLMs to help me generate prompts for LLMs. And they did a pretty good job.
Instead of a feedback loop of unknown length, we settled on a once-through generate+audit+edit process. I generated dozens of test résumés for many different real job postings, tweaking the prompt with smaller and smaller changes, before finally deciding that it was doing a genuinely good job. The final prompt was about 1,500 words and my career database ballooned to more than 25,000 words, but now that they're complete this process works really well for me. It's not perfect. It still makes mistakes and sometimes ignores its own instructions. So sometimes after reading the audit report and reviewing the PDF I have to have a follow-up conversation and tell the LLM to fix its mistakes. But I think I've hit the point of "this is good enough", and also the point of diminishing returns. I don't want to play microscopic-whack-a-mole and try to address every one-time mistake in the reusable prompt.
I'm quite happy with this system! As I said, it used to take me half a day to manually tailor a résumé. This new process generates an excellent bespoke résumé in five minutes. At this point my limiting factor is finding jobs I want to apply to.
And here is the finished prompt. I'm sure an LLM could modify it to work for you.
I am a software and robotics engineer with more than ten years of experience designing, building, and programming robots, ranging from underwater ROVs and AUVs to dynamically balancing bipedal humanoids to production autonomous vehicles. I have attached two files:
database.txt — a comprehensive career history containing every job, project, skill, and accomplishment of my career in detail. My contact information is at the top of this file.
posting.txt — a job description for a role I am applying to.
Write a bespoke, tailored résumé for this specific job using only information drawn from my career database, then immediately run a structured self-audit before delivering anything. Deliver the résumé as a PDF file, followed by the audit report in the conversation.
PASS 1 — DRAFT
Targeting & Framing
- Read the job description carefully and identify the most important technical skills, experience, and qualities the employer is looking for.
- Select and emphasize the experiences from my career history that best match those priorities. Omit or minimize experiences that are irrelevant.
- Frame my experience in the language and terminology used in the job description wherever my experience genuinely matches.
- Weight recent experience more heavily than older experience. My most recent 5–7 years of work should form the core of the résumé.
- Do not lead with or emphasize organizational dysfunction, under-resourcing, or being the only person on a project. These details invite skepticism about the claim or concern about the employer. Neither helps in a résumé. Focus on the scope, technical substance, and outcome of the work. If the scale of individual contribution is genuinely notable, let the specifics of the work imply it rather than stating it as a headline.
Leveling
- I am currently an L4 (junior) at Zoox, but I am targeting Senior and Staff level roles. Write the résumé to position me at that level.
- I am severely under-leveled in my current role at Zoox, so I want to avoid mentioning my official title or level and simply let my work speak for itself. My current title should be listed as "Software Engineer."
- Lead with impact, scope, and ownership, not just responsibilities.
- Quantify accomplishments wherever the career database provides specific numbers, timelines, team sizes, or measurable outcomes. Do not fabricate or estimate numbers that do not appear in the career database.
- Prioritize 'Force Multiplier' activities. If the database mentions mentoring, code reviews, architectural RFCs, defining standards, or cross-functional coordination with hardware/PM teams, these should be included. These are the markers of Senior/Staff engineers that AI often overlooks in favor of 'I coded X feature.'
Skills Section Abstraction Level
List skills at the domain or category level, not at the implementation-detail level. The Skills section should communicate breadth of capability more than enumerating specific parameters or techniques from individual projects.
Example: write "high-performance BLDC motor control," not "feed-forward sinusoidal commutation at 5kHz." Write "AUTOSAR standards" not "AUTOSAR E2E Profile 11a." Write "serial protocols (SPI, RS485, UART, CAN, LIN)," not "GPIO bit-banging."
Specific implementation details belong in bullet points under individual roles, where they serve as concrete evidence. In the Skills section, they read as narrow constraints on what I do know, implying that I might NOT know other variants.
Rule of thumb: if a skill entry names a specific parameter, frequency, profile number, or single sub-technique from a broader domain, it's too specific. Move up one level of abstraction.
Hardware & Cross-Functional Experience
- My career includes significant mechanical engineering, nuclear engineering, and hardware experience from earlier roles. How to handle this depends on the job posting.
- Default behavior: Focus the résumé on software engineering experience. Reference hardware and cross-functional background briefly in the Summary or Skills section for credibility and systems-thinking framing, but do not include early hardware-only roles as full job entries.
- Exception: If the job posting explicitly values breadth, systems engineering, hardware-software integration, or cross-functional experience, include more detail from these earlier roles. Use your judgment, but err toward the default.
Structure
- Target length: two pages. This means roughly 1000 words. A third page is acceptable only if the additional content is directly relevant to the job posting and meaningfully strengthens the application. Filler, redundancy, or marginal experience should be cut before adding a third page. When in doubt, cut.
- Prefer fewer, stronger bullet points over comprehensive coverage. Three to five bullets per role is typical. More than six per role is almost certainly too many.
- Contact information from the top of database.txt should appear at the top of the résumé.
- Sections: Summary, Skills, Professional Experience, Education, Publications (include only if relevant to the role).
- The Summary should be 3–4 sentences positioning me specifically for this role.
- Professional Experience must be sorted in reverse chronological order, with the most recent role first.
- For each job, include only the projects and accomplishments most relevant to this application. Do not attempt to include everything.
- Bullet points under each role should be achievement-oriented: what I built, what problem it solved, and what the outcome was.
- The per-role skills, processes, and tools listings in the career database may be used to populate the Skills section or to add technical specificity to bullet points. Do not construct entire bullet points from skills listings alone — they provide technical detail, not accomplishments.
Tone & Style
- Write as a senior engineer who is confident, precise, and has nothing to prove. Not boastful. Not falsely humble.
- Language must be factual, clinical, and precise. Use plain, specific, technical language throughout.
- Match my tone and voice as reflected in the career database. I write about my work in factual, technically specific language without hype or self-promotion. The résumé should read the same way. You may use specific phrases or terminology from the career database where they fit naturally, but do not try to preserve full sentences. Condense and restructure freely for résumé format while preserving my voice.
- Do not use "business speak", MBA jargon, or sensational language. Banned phrases include but are not limited to: spearheaded, leveraged, synergized, drove impact, transformed, world-class, passionate about, results-driven, dynamic, and any similar filler.
- Do not use em-dashes anywhere, ever, for any reason.
Accuracy & Integrity
- Every claim must be directly traceable to a specific passage in the career database. When in doubt, understate rather than overstate. Omit rather than embellish. A gap is better than a lie.
- Do not inflate job titles. If my title was "Research Engineer", "Employee #1", or "Graduate Research Assistant", use that title accurately or omit it. Do not substitute a more impressive-sounding title.
- Do not upgrade language: if the career database says I "contributed to" something, do not write that I "led" or "architected" it.
- Do not fabricate skills, technologies, or accomplishments not explicitly stated in the career database.
- Judgment on Numerics: Do not treat every number in the database as equally significant.
- Include numbers that represent Inherent Value or Outstanding Results (e.g., "95% code coverage", "25% cost decrease", "10x throughput increase", "reduced latency by 40ms").
- Project-specific configuration settings (e.g., "5kHz", "24V", "3-axis") should not be listed as standalone achievements. Only include them within a bullet point if they are necessary to explain how a specific "Inherent Value" result was achieved. If a number doesn't represent a clear win or a standard industry benchmark, omit it to maintain a high signal-to-noise ratio.
Output Format
- Deliver the résumé as a clean, professional PDF file suitable for submission to an employer.
- The final document should be two or three pages. A 2-page or 3-page résumé looks more professional than a 2.5-page résumé.
- Use a clean, professional font such as Georgia or Noto Serif or similar.
- Standard résumé formatting: clear section headers, consistent spacing, readable font size (size 10 by default).
- Use 1.25x-1.5x vertical spacing between lines for readability.
- You can adjust vertical spacing, font size, and page borders to fit the résumé to an even two or three pages.
- Do not use color, graphics, or elaborate design elements. The PDF should look like a traditional senior engineer's résumé.
- The PDF filename should follow the format: Travis Llado Résumé - <Employer>, <Role>.pdf, where Employer and Role are taken from the job posting.
PASS 2 — AUDIT
After drafting the résumé, before delivering anything, run the following three audits. Revise the résumé to fix any issues found, then deliver the final résumé as a PDF file followed immediately by the full audit report in the conversation.
Audit 1: Factual Accuracy
For every bullet point in the résumé, verify that a specific supporting passage exists in the career database. If it checks out, mark it with ✓ and a short name only, nothing else. If you cannot find a direct source, remove or revise it before delivery and flag with full detail.
Audit 2: Inflation Check
Scan every bullet point and the summary for inflated job titles, banned jargon, unsourced quantified claims, scope inflation, and language upgrades. Clean items get ✓ and a short name only, nothing else. Flag any issue with full detail: what the draft said, why it's a problem, and what it was revised to.
Audit 3: Job Description Match
Extract the 8-10 most important requirements from the job posting. For each one, verify whether the résumé addresses it. Addressed requirements get ✓ and a short name only, nothing else. Flag gaps with full detail.
Audit Report Format:
AUDIT REPORT
FACTUAL ACCURACY
✓ [Short bullet name]
⚠ FLAG: [Résumé claim] — [reason flagged] — revised to: [corrected version]
INFLATION CHECK
✓ [Short bullet name]
⚠ FLAG: [Draft language] — revised to: [corrected version]
JOB DESCRIPTION MATCH
✓ [Short bullet name]
⚠ GAP: [Requirement] — not found in career database. Flagged for applicant awareness.
FINAL DELIVERY
Deliver the résumé as a PDF file first, followed immediately by the audit report in the conversation. Do not deliver the résumé without the audit report. Do not summarize or explain your process outside of the audit report itself.