Job posts for engineers have started naming specific AI tools as requirements. Dice's September 2026 Tech Jobs Report, published this month from an analysis of more than 7 million US tech postings, flags skills like Claude AI and AI tooling as a sign that employers now list particular AI products in what they ask for. If you are writing the post for your first or second senior engineer, you will be tempted to do the same.
Short answer: do not make a specific AI tool a requirement. Tools in this category change every few months, and the skill that matters is judgment about when to trust generated code, not familiarity with one product. Say in the post that your team works with AI coding tools daily, describe how, and then test the real skill with a work sample. That attracts the engineers you want and filters out the ones you do not, without tying your hiring to a product that may not be your tool by next spring.
What the data is actually saying
The headline numbers in the Dice report are about demand: total tech postings up 17 percent on a year earlier, and AI and machine learning postings up 88 percent. The more interesting detail for a founder is qualitative. Employers are no longer just asking for "AI experience." They are naming tools, in the same way job posts once named specific frameworks.
That shift makes sense at large companies. If a 400-person engineering organisation has standardised on one assistant, with enterprise licences, security review, and internal training, then asking for familiarity with it saves onboarding time. A small startup is in a different position, and copying the pattern brings the costs without the benefit.
Why naming a tool backfires at a startup
Your tool will probably change. Early teams switch AI coding tools often: a better model ships, pricing moves to metered billing, a competitor adds the feature you needed. We covered the cost of that churn in what switching AI coding tools really costs. A requirement written for this quarter's tool is stale by the time your hire passes their first review.
Tool familiarity takes days to learn. A strong engineer picks up a new assistant, its shortcuts, and its failure modes within a week or two. Listing it as a requirement screens for something you could teach in an afternoon.
It filters for the wrong people. Candidates who lead with a long list of AI tools are often advertising speed. Speed is cheap now. What is scarce is the engineer who knows when the generated code is subtly wrong, when a feature should not be built at all, and when to stop the agent and think. A tool requirement does not find that person. It may push them away, because experienced engineers read tool-name requirements as a sign of a team that confuses tools with judgment.
It invites keyword gaming. If the post says "must have Claude experience," every application will say it. You learn nothing.
What to say instead
Your first-engineer post has two jobs: describe the kind of person who will thrive, and sell the role to someone who is not looking. Our guide to writing the first engineer job post covers both. On AI tools specifically, three sentences do more than a requirements line:
- How you use them today. "We use AI coding assistants every day, for first drafts, tests, and migrations. Every change still gets human review before it ships."
- What you expect the engineer to own. "You will decide where these tools help and where they create risk, and set the guardrails for the team as it grows."
- What you value. "We care more about whether code is right and maintainable than how fast it was written."
That tells a strong candidate everything they need: the team is current, nobody is pretending AI is optional, and the job includes the judgment, not just the typing.
If the honest answer is that you have no policy yet, say so. "Help us decide how we use AI tools" is an attractive line for a senior engineer, because it is real ownership.
How to test the skill that matters
The thing you want to know is not "have you used tool X" but "can you work well with generated code." That is testable in an hour without an engineer on staff.
Review a flawed AI-written change. Give the candidate a short pull request, generated by an AI tool, that works for the happy path but has one or two real problems: a missing permission check, an unhandled empty state, a query that will not scale. Ask them to review it out loud. Strong candidates find the problems and explain the risk in business terms. Weaker ones skim it and approve.
Build something small with their own tools. Let them use whatever assistant they prefer on a realistic task. Watch where they accept suggestions, where they rewrite, and whether they run and test the result before calling it done. This is the format we recommend in the work sample that replaced the take-home test.
Ask about a time AI got it wrong. Every engineer who uses these tools seriously has a story about a confident, plausible, wrong answer that nearly shipped. The quality of that story tells you a lot. No story is itself an answer.
If you cannot judge these exercises yourself, that is the gap to close before you hire, not after. Our post on interviewing a senior engineer when you can't read code covers how.
When naming a tool is reasonable
There are a few cases where listing a specific product makes sense:
- The tool is the product. If you are building on a particular model provider's API or agent framework, deep experience with it is real domain knowledge, closer to "experience with Postgres" than "uses an assistant."
- You have a hard compliance constraint. If customer contracts or security review restrict you to one approved tool, say that as a fact about the environment, not as a skill requirement.
- It is a nice-to-have, clearly labelled. "Experience with tools like Cursor or Claude Code is a plus" is harmless. "Must have" is where it goes wrong.
The broader point for founders
The shift Dice is picking up is real: AI tooling has moved from experiment to standard practice, and engineering job posts are adjusting. But your first senior engineer is not hired to operate a tool. They are hired to make the technical decisions you cannot make yourself, including how much to trust the tools.
Write the post for that person. Test for that skill. And expect the tool line in your post to change twice a year, which is exactly why it should not be a requirement.
If you are about to open your first senior engineering role and want a second pair of eyes on the post and the interview loop, book a call. Hiring support is part of what a short fractional engagement covers.
FAQ
Should I require experience with AI coding tools at all?
It is reasonable to expect a senior engineer to have used them by now. Ask about it in the interview rather than listing it as a requirement, and focus on how they judge the output.
Will engineers who do not use AI tools apply?
Some will. If daily use is part of how your team works, say so in the post. Those who do not want that will self-select out, which is what you want.
Is it worth listing our current AI tools anywhere?
Yes, in the "how we work" part of the post, as a fact about the team. It is useful context for candidates without being a gate.
What if an investor asks how our team uses AI?
Have a one-paragraph answer: which tools, what review process, and who owns the policy. It is increasingly a standard question in technical diligence, and a clear answer helps.