Vibe coder. Context engineer. Chief AI Revenue Officer. Human-AI Interaction Designer. These job titles didn't exist two years ago. Now there are hundreds of listings for them on LinkedIn, ZipRecruiter, and Indeed – and somebody has to apply.
Every resume guide assumes an established career path. "Show progression." "Use industry-standard keywords." "Mirror the job description." That falls apart when the job description was written by someone who's also figuring this out for the first time.
Here are the five structural problems you'll hit – and how to solve each one.
The five problems with writing a resume for new roles
1. ATS doesn't recognize your keywords
Applicant Tracking Systems match your resume against a database of known job titles and skills – a database built from years of hiring data. If your role is "Context Engineer" or "Human-AI Interaction Designer," the ATS might have no reference point.
You can have every qualification the hiring manager wants and still get filtered out because the system doesn't know what to do with you.
2. There's no career ladder to show progression
Traditional resumes show a clear trajectory: Junior Developer → Developer → Senior Developer → Lead. Recruiters scan for this because it signals growth.
But what does progression look like when you're a "Vibe Coder" who was a frontend developer two years ago? Or a "Context Engineer" whose previous title was "Backend Developer"? The ladder doesn't exist yet.
3. Your qualifications are projects, not credentials
Nobody has a degree in context engineering. There's no certification for "vibe coding" that the industry has agreed means something. Your proof of competence is the work itself – side projects, open-source contributions, things you built because the tools existed and you were curious enough to learn them.
Resumes are designed to showcase credentials. The projects-as-proof approach requires a different structure.
4. The hiring manager isn't sure what they're looking for
In established roles, the hiring manager has a mental model of what good looks like. In emerging roles, they often wrote the job description by looking at what other companies posted and adapting it. They might not know whether they need a technical person who can communicate or a communicator who understands the tech.
The job description itself might be unreliable as a tailoring target.
5. Every company calls the same role something different
One company's "Vibe Coder" is another's "AI-First Developer" is another's "AI-Assisted Software Engineer." The same work, wildly different titles. This makes keyword matching a guessing game and makes your work history look scattered when it's actually focused.
Resume strategies for jobs without templates
Lead with a headline that bridges the gap
Your resume headline is the first thing both ATS and humans read. For new roles, it needs to do double duty: signal what you do now and connect it to something recognizable.
Weak: "Vibe Coder" Better: "AI-Assisted Software Developer | Full-Stack Engineer | Building with LLMs"
Weak: "Context Engineer" Better: "Context Engineer | RAG & LLM Systems | 5 Years in Backend Engineering"
Weak: "Human-AI Interaction Designer" Better: "Human-AI Interaction Designer | UX Research & Conversational AI | Ex-Product Designer"
The pattern: new title + domain keywords + recognizable background. The new title says where you're going. The domain keywords feed the ATS. The recognizable background tells the human you're not making this up.
Build a "translation layer" in your summary
Your summary is where you connect the dots that the rest of your resume can't – a translation layer between your non-traditional path and the role you're applying for.
A good summary for a new role answers three questions:
- What do you actually do? In plain language, not buzzwords.
- What's your foundation? The established skills that make you credible.
- What have you shipped? Concrete output, not abstract capabilities.
AI-assisted developer building production applications using LLMs for code generation, testing, and architecture. Background in full-stack engineering (React, Node.js, Python) with 5 years of experience shipping web applications. Built and deployed 3 AI-augmented internal tools at [Company] that reduced development time by 40% for the platform team.
A recruiter who's never heard of "vibe coding" can still understand exactly what this person does and why they're qualified.
Structure experience around outcomes, not responsibilities
In established roles, listing responsibilities works because the reader already knows the role. "Managed a team of 5 engineers" – the reader fills in the rest.
In new roles, responsibilities are meaningless because nobody knows what they imply. "Designed prompts for LLM-based workflows" – so what?
Flip every bullet point from what you did to what resulted:
Responsibility-based (weak):
- Developed AI-assisted coding workflows for the engineering team
- Created and maintained prompt libraries for code generation
- Evaluated new LLM models for development use cases
Outcome-based (strong):
- Reduced average feature development time from 2 weeks to 4 days by building AI-assisted coding workflows adopted by 12 engineers
- Built a prompt library for code generation that became the team's default starting point for new projects, used in 80% of sprint tasks
- Evaluated 6 LLM models and selected the one that cut code review iterations by 35%, saving ~15 engineering hours per week
The outcomes make the unfamiliar role concrete. A hiring manager doesn't need to know what "prompt engineering" means if they can see it saved 15 hours per week.
Make your projects section the centerpiece
For emerging roles, a Projects section isn't a nice-to-have – it's often the most important part of your resume. When credentials don't exist yet, projects are your credentials.
Structure each entry like this:
Project Name – one-line description
- What you built and why
- What technologies/skills you used
- What the measurable result was (users, performance, adoption)
Place this section right after your summary, before traditional work experience. For new roles, what you've built matters more than where you've worked.
Handle the "scattered titles" problem
If your last three jobs had different titles that all describe similar work, you have two options:
Option A: Use a consistent subtitle. List the official title, then add a parenthetical that groups them.
AI-First Developer (AI-Assisted Development) – Company A, 2026–present Vibe Coder (AI-Assisted Development) – Company B, 2025–2026 Full-Stack Engineer, AI Products (AI-Assisted Development) – Company C, 2024–2025
The parenthetical creates a visual thread that tells the reader "these are the same career, different labels."
Option B: Use a functional section. Instead of listing jobs chronologically, group your experience by what you did:
AI-Assisted Software Development – 3 years across 3 companies
- [outcome-based bullets that draw from all three roles]
This sacrifices chronological format but makes a much clearer case for your expertise. Use it when the title variation is extreme.
Stack your skills section strategically
For new roles, your skills section needs to serve two audiences at once: ATS bots scanning for exact keyword matches, and humans who need to quickly grasp your range.
Group skills into categories that bridge old and new:
AI & LLM Tools: GPT-5, Claude, LangChain, vector databases, prompt engineering, RAG pipelines Software Engineering: React, TypeScript, Python, Node.js, PostgreSQL, AWS Domain: Technical writing, API documentation, developer experience, user research
The first category signals "I'm in the new space." The second signals "I have real technical depth." The third connects it all to business value.
Tailoring when the job description is unreliable
With emerging roles, the job description might be wrong. The person who wrote it may have cobbled it together from other postings without fully understanding what they need. When writing a resume for these new roles, you need to read between the lines:
Translate impossible requirements. If a "Context Engineer" job description asks for "5+ years of experience," they don't literally mean five years of context engineering – it hasn't existed that long. They mean they want someone senior.
Research the team, not just the listing. Check who posted the role, who's on the team, what the company actually builds. A "Chief AI Revenue Officer" at a 10-person startup means something completely different than at a Fortune 500 company. Tailor for the real context, not the job title.
Mirror their language, but add yours. If they say "AI-assisted development," use that phrase – but also include specific terms (LangChain, RAG, fine-tuning) that demonstrate you know more than the job description does. In emerging fields, showing you understand the space better than the listing suggests is a strong signal.
Putting it all together
Here's how these strategies combine into a real resume for someone transitioning from frontend developer to AI-assisted development roles:
Headline: AI-Assisted Software Developer | Full-Stack Engineer | React, TypeScript, Python, LLMs
Summary: Full-stack developer with 5 years of experience building production web applications, now focused on AI-assisted development workflows. Built 4 internal tools that integrate LLMs into the engineering team's workflow at [Company], reducing feature delivery time by 35%. Experienced in both traditional software engineering and building with AI – from prompt design to RAG pipelines to evaluating LLM output quality in production.
Projects section (placed before work experience):
AI Code Review Bot – Internal tool that pre-reviews PRs using Claude API
- Built end-to-end: prompt engineering, API integration, GitHub webhook handler, Slack notifications
- Reduced human code review time by 25% across a 15-person engineering team
- Handled 200+ PRs in first month with 92% useful feedback rate (measured by developer ratings)
Every section answers the same implicit question: "Can this person actually do this new thing, or did they just put it on their resume?"
The bottom line
Writing a resume for a job that didn't exist two years ago isn't about finding the right template – there isn't one. It's about solving a communication problem: how do you prove you can do something when there's no established way to prove it?
Lead with what you actually do. Show outcomes, not responsibilities. Let projects speak where credentials can't. And translate your non-traditional path into language that both ATS systems and humans can follow.
The people landing these new roles aren't the ones with the most polished resumes. They're the ones whose resumes make the hiring manager think "this person gets it" – because every line demonstrates real understanding of a space that most people are still trying to figure out.