Open ten software job posts and two or more will mention AI. Open ten data and analytics posts and it is closer to five. In tech, the feeling that every JD mentions AI is not far off.
The numbers come from Indeed's Hiring Lab, which counts job posts that use AI words like "machine learning", "generative AI" or "artificial intelligence". In December 2025, 45% of data and analytics posts mentioned AI. Software development, IT, and scientific research posts each mentioned it 20% of the time or more. Across all U.S. job posts it was 4.2%, and accounting was at 6%.
The share keeps rising. Across all U.S. posts it reached 7.2% in September 2026, by the AI Tracker data, up from 2.7% in January 2025. Tech is ahead of that curve, not behind it.
Indeed's data covers the U.S., Canada, the UK and a few European countries. India is not in it, so read the numbers as a direction, not as a picture of Pune.
Why tech, and why now
Part of it is simple: tech companies are the ones building AI features, so they need people who can build them.
The other part is less obvious. In the same Hiring Lab report, tech posts mentioning AI at the end of 2025 were up 45% on February 2020, while all tech posts were down 34%. So the share went up for two reasons at once. More tech posts mention AI. And fewer tech posts without AI get written at all, because overall tech hiring has slowed. Hiring Lab's own summary: employers are concentrating their limited hiring on roles and skills tied to AI.
That is the honest, uncomfortable part. The AI line is not only fashion. In a slow tech market, it marks where the hiring that is left has gone.
Real demand, or copy-paste?
Both. Some teams are building AI features and need people. Many add the line because every other post in their market has it. The tracker can't tell them apart either: it counts words, so a post that says "machine learning a plus" counts the same as one that asks you to build a retrieval system.
You can tell them apart yourself.
- Look at the product. If the company doesn't ship anything that uses AI, the line is probably copy-paste. You will still be doing the job described in the rest of the post.
- Ask in the interview. "What AI work did the team ship last quarter?" A team doing real work answers in detail: what they built, what went wrong, what they measure. A team that copied the line goes vague.
- Read the verbs. "Exposure to AI tools" is a nice-to-have. "Build", "deploy", "evaluate" next to "LLM" or "agents" is a real requirement.
What "AI experience" means in practice
In the companies I have worked with, "AI experience" means two things, and rarely a third.
One: can you use AI tools to work faster? Coding assistants, AI search, drafting. Stripe's AI Engineer post says this well. It wants someone "fluent with AI-assisted development but not dependent on it", who can still debug without it.
Two: can you put an LLM call inside our product without breaking it? The same post asks for experience "building and deploying AI agents, LLM-powered tools, or workflow automation beyond basic prompt engineering". That means the model call sits inside a real backend: it can time out, return bad output, cost money, and give a different answer tomorrow. Your code has to handle all of that.
Rarely: training models. When we read 57 AI engineering posts for what AI engineering JDs ask for, only one named PyTorch, TensorFlow or JAX.
Most backend developers are closer to meaning one and two than they think. The gap is one real project.
What to do this month
Build one small thing that uses an LLM inside a real backend. Not a chat window over an API key. Something with:
- a queue, so the model call runs in the background and a slow answer doesn't block a request
- structured output, so the model returns JSON your code checks, and a bad answer gets rejected instead of saved
- a few test cases, ten real inputs with the answer you expect, that you run every time you change the prompt
Keep it small. One job, done properly, beats a demo with ten features. Summarise support tickets. Pull fields out of invoices. Sort incoming emails into three folders. Pick something where you can tell a right answer from a wrong one, because that is what lets you write the test cases.
Put it on GitHub. Add a short write-up of what broke and how you found out. Something will break: the model returns a field you didn't ask for, a long input times out, a prompt change fixes one case and breaks two others. Write those down. They are the most useful part of the README. A project like this covers what most of these lines mean, and it gives you something real to say when an interviewer asks about "AI experience".
If you want the longer version of what goes around a model call, read what you build around an LLM call and why AI features need background jobs.
The line in the job post is new. The work it points to is still engineering.