The AI filter in dev recruiting is testing the wrong thing
Recruiters already ask, in interviews, how candidates use artificial intelligence at work. The problem isn't that the question exists: it's that it usually stops at the right word, not at real competence.
- Reading
- 4 min
- Tables
- 1
Recruiters already ask, in interviews, how candidates use artificial intelligence at work. The problem isn't that the question exists: it's that it usually stops at the right word, not at real competence.
A report from Exame, a Brazilian business and technology magazine, published on November 1, 2026 confirms something that anyone going through a technical hiring process has already felt: recruiters are asking, in interviews, how candidates use tools like ChatGPT, Microsoft Copilot, and Gemini in their day-to-day work. The report is careful to say that there's no universal resume filter based on this, and that the requirement varies by role and company maturity.
I agree with the fact. I disagree with the criterion being used in practice. The problem isn't asking about AI. It's asking wrong: treating "knows how to use AI" as if it were an isolated line item of competence, when it's a tool embedded in the work of programming, just like Git, just like the terminal, just like the debugger.
Naming the tool on your resume says nothing
Exame itself notes that screening systems identify keywords, but that the absence of the term "AI" doesn't imply automatic exclusion. That's true, and it's also the filter's weak point: if the presence of the word says little about real competence, why does it keep carrying weight in pre-selection?
For programmers, writing "ChatGPT" or "GitHub Copilot" in the skills list has the same value that writing "Google" had in 2012. It's expected, it's almost universal among active devs, and it doesn't set anyone apart. What sets someone apart is the account of use: which task, which tool, which decision about when to trust it and when to review it.
What separates real fluency from varnish, for those who build software
Exame recommends replacing vague descriptions with verifiable experiences: platform used, activity, purpose, and, if possible, measurable results. That applies doubly to devs, because it can be verified in a way recruiters in other fields can't: by asking for the code, the pull request, the changelog.
That's the kind of data that backs up a resume line: a measurable result, not a generic claim. "I used Copilot to generate unit tests for a legacy module and reduced coverage time from X to Y" says infinitely more than "fluent in generative AI."
In short: fluency isn't having used the tool. It's knowing how to name, precisely, what it did for you and what you had to correct in it.
The risk almost no one asks about in dev interviews
Exame's report rightly points out that knowing AI's limitations matters as much as knowing how to operate it: incorrect answers, exposure of confidential data, mistaken interpretations. For software engineering, that risk has a technical name: insecure code generated without review.
Code suggested by an AI assistant can contain vulnerabilities that go unnoticed when accepted without careful review. Add to that the risk of pasting proprietary code into a public LLM with no clear data retention policy, and you have a governance problem, not just a productivity one.
No interview I've seen reported so far asks that. They ask "do you use AI?" They rarely ask "what do you do when the model suggests a dependency that doesn't exist, or a snippet that looks right but opens a vulnerability?" That's the question that separates those who use AI as a shortcut from those who use AI as an engineering tool.
| Signal on the resume | What it actually measures |
|---|---|
| "Fluent in ChatGPT/Copilot" | Nothing verifiable |
| Task + tool + numerical result | Real, provable application |
| Mention of reviewing generated code | Awareness of risk |
| Total silence about limitations | A warning, not automatic disqualification |
The counterargument I take seriously
I recognize the recruiter's side. When a job opening gets hundreds of applications, some proxy for screening at scale is needed, and "mentions an AI tool" is cheaper to process than reading each person's project account. Exame itself notes that how these filters work depends on the configuration each company adopts.
The point isn't to abolish the filter. It's that a company using only the keyword is optimizing for noise, because a junior who copied the phrase from a resume template and a senior who debugs agent output every day pass through the same sieve. A board that asks for a productivity report from squads that adopted generative AI wouldn't accept that same crudeness of criterion; technical hiring shouldn't accept it either.
What changes for those applying right now
If you code and are on the job market, the practical change is small to write and big in effect:
- Replace "knowledge of generative AI" with a sentence that includes the tool, the task, and the result, the way Exame itself recommends.
- Prepare an example where the model got it wrong and you caught it, not just where it got it right. That proves judgment, which is what's missing in someone who just "uses" the tool.
- Have a ready answer about sensitive data: have you ever pasted code from a previous employer into a public LLM? Why or why not?
- If you've never used any of these tools at work, say so and show that you've learned other things quickly before. A documentable learning curve is worth more than an empty mention.
The fluency that matters isn't knowing the product's name. It's knowing where it errs, and what you do about it.
Translated from the Brazilian Portuguese original · Read the original
YC's post-money SAFE: the cap stacking that dilutes the founder without them noticing
Y Combinator documentation shows how the post-money SAFE, the standard since 2018, promises cap-by-cap transparency, but that clarity vanishes in practice when founders stack several bridge rounds without recalculating the total sold.



