Since large language models arrived in everyday tools, mentions of "generative AI", "LLM" or "prompt engineering" have multiplied on the resumes of developers, data scientists and product managers. For a CTO who is hiring, they can signal a rare, sought-after skill, or on the contrary a line added to follow the trend. The difference lies in what is behind the word. This article distinguishes four levels of skill, shows what a technical leader wants to read, suggests wording for an integration or RAG project, and lists the phrases that undermine your credibility.
Four levels of skill behind "generative AI"
The same word covers practices that have almost nothing in common. Telling them apart is the first step towards a credible resume.
- Using a coding or writing assistant. You work with an assistant built into your editor, or with a chatbot, to write, review or document code. It is now common practice, comparable to mastering a good development environment. It is not a skill in its own right on a resume, unless you organised its adoption within a team.
- Integrating a language model API into a product. You call a model hosted by a provider to summarise, classify, extract or generate text in a real feature. The difficulties are those of software in production: costs, latency, error handling, output formats, security of the data sent.
- Building a retrieval-augmented generation (RAG) system or an agent. You combine a model with a knowledge base (document chunking, embedding, retrieval, reranking) or with tools it can call. The core of the work becomes evaluating answer quality and controlling failure cases.
- Training, fine-tuning or serving models. You adapt a model to a domain (fine-tuning, distillation), host it yourself and optimise its inference. This is the territory of machine learning engineers and applied research teams.
Each level has its place on a resume, provided it is named correctly. A backend developer who integrated a language model API into a product has a real and valued skill; they have no need to suggest they train models.
What a CTO wants to read
A technical leader who reads a line about generative AI wants to answer three questions.
Is the system in production? A demo prototype and a feature used by customers do not require the same skills. Say which of the two you built, and for whom.
How do you know it works? This is the central question. A language model’s outputs are not deterministic; a serious team builds a set of test cases, measures the quality of answers and monitors drift. A candidate who can explain their evaluation method stands out immediately.
Did you handle real-world constraints? Cost per request, latency, rate limits, data confidentiality, hallucinations, malicious prompt injection. The OWASP top 10 for large language model applications 🔗 lists the main security risks, and the French data protection authority CNIL publishes resources on artificial intelligence 🔗 and data protection. In Europe, the Artificial Intelligence Act 🔗 adds obligations depending on a system’s level of risk. Mentioning one constraint you dealt with is worth more than ten model names.
In short, the CTO wants to read an engineer’s experience, not enthusiasm.
Describing a RAG project or an LLM integration
A good bullet follows the same logic as for any feature: the problem, the solution, how the result is measured. It adds what is specific to generative AI: evaluation and safeguards.
An API integration in a product
Before: "Integrated ChatGPT into the application."
After: "Added automatic summaries of support tickets to the back office (hosted language model API, Node.js): structured output validated against a schema, fallback to raw text on error, cost per ticket tracked in the team’s dashboard."
The second version does not necessarily name the provider, but it shows the feature, the stack, error handling and cost tracking. These are exactly the topics a lead will want to dig into.
A RAG system
Before: "Developed a chatbot with RAG and LangChain."
After: "Designed an assistant for searching internal documentation for the support team (RAG: document chunking, hybrid full-text and vector search in PostgreSQL, reranking); evaluation set of two hundred real questions annotated by the team, rerun at every change to the chunking or the model."
Here the value lies in the evaluation: a set of annotated questions, replayed at every change. That is what distinguishes a maintained system from a demo. The machine learning engineer resume template shows the same logic applied to vision models: service, latency, drift monitoring.
In the skills section, group these elements in a dedicated line, as explained in our article on presenting your tech stack: "Generative AI: language model API integration, RAG, answer evaluation, vector search (pgvector)".
The subject also extends well beyond product teams: consulting firms are hiring profiles able to scope and deploy these use cases for their clients, with a resume built differently. The resume of a data and AI consultant at a firm 🔗 shows how these projects are presented when the deliverable is an assignment rather than a product.
Wording that undermines credibility
Some lines make technical leaders smile, and can cost you an interview.
- "Generative AI expert" without a project in production: the word "expert" invites the hardest question, and almost everyone still lacks hindsight on these technologies.
- "Prompt engineer" as a developer’s main title: writing prompts is part of the job, not a job in itself in most teams.
- A list of model and library names with no feature behind it: it ages within months and says nothing about your skills.
- "Proficient in ChatGPT" in the skills section: the equivalent of "proficient in the Internet".
- Unverifiable productivity gains ("productivity tripled thanks to AI"): without a measurement method, they worry more than they reassure.
- A demo project presented as a product: a lead will ask about users, costs and incidents, and the difference will show quickly.
The general rule: describe what you built and how you checked it, and leave the fashionable vocabulary to the job ads.
Learning without waiting for a job
It is possible to gain credible experience before an employer entrusts you with a generative AI project.
- Build a small complete system on a corpus you know: the documentation of an open source tool, public texts, your own notes. Add an evaluation set, even a modest one, and document your results in the README.
- Add a useful feature to an existing project: message classification, field extraction from documents, summarisation. Treat errors, costs and confidentiality seriously.
- Read the providers’ documentation on structured outputs, tool calling and evaluation, as well as OWASP’s security recommendations.
- Contribute to an open source project for tooling, evaluation or vector search.
Publish the result on GitHub with a clear README, as detailed in our article on the GitHub link on a resume. A small evaluated project is worth more than an online course certificate with nothing built.
Content separates a strong signal from a buzzword; form just must not spoil it. The TechCV editor keeps your skills lines and bullets as readable text that recruitment software extracts correctly, and helps you rephrase an experience without losing its technical details. You can rework your resume starting from the machine learning engineer template or from your current resume.
Frequently asked questions
Should I mention using a coding assistant on my resume?
Generally not, or in one line under practices. It has become a common tool. It deserves a more visible mention if you organised its rollout in a team, defined usage rules or measured its effect on code quality.
Can a developer without machine learning training target generative AI roles?
Yes, for integration roles and for building RAG systems, which are largely software engineering. Roles involving training and fine-tuning models, on the other hand, require solid training in machine learning.
Should I name the models I used?
You can name the model family or provider if the ad mentions it, but the essentials lie elsewhere: the feature, the evaluation, the constraints you handled. Models change quickly; your engineering skills remain.
How do I talk about a confidential project?
Describe the type of problem, the architecture and the evaluation method without revealing the data or the client. It is the same rule as for any professional project, and recruiters know it.