What changes about hiring when every developer uses an AI agent

AI coding agents are no longer a differentiator. They have become a normal part of software development.

JetBrains surveyed more than 15,000 professional developers in 2026 and found that 90% use AI coding agents at work at least weekly. More than two thirds use them every day. Adoption is growing quickly, with tools such as Claude Code becoming increasingly common among professional developers.

This changes what employers should look for when hiring developers.

Knowing how to use an AI agent is no longer enough to set a candidate apart. If almost every developer has access to the same tools, the more important question is whether they can evaluate the output those tools produce.

Can they spot errors? Do they understand the code well enough to challenge an AI-generated solution? Can they recognise when a change should not be approved?

As AI takes on more of the work of generating code, human judgement becomes more important. Hiring needs to move beyond asking what a developer can produce with an agent and focus more closely on what they can safely review, verify and approve.

In this article

• How many developers actually use AI coding agents now?
• What did the surveys measure, and where do they disagree?
• What does an agent audit trail actually have to record?
• What should you test in an interview now?
• Does agent fluency make junior engineers more or less valuable?
• Conclusion
• FAQ

How many developers actually use AI coding agents now?

Nine in ten.

The JetBrains Developer Ecosystem Survey 2026 found that 90% of professional developers used AI coding agents at work at least weekly between May and July 2026. More than two thirds, or 68%, used them daily. The survey covered more than 15,000 professional developers worldwide.

That level of adoption should change how companies approach technical interviews.

A tool used regularly by nine out of ten developers is no longer a specialist skill. It is becoming part of the standard development environment. Asking whether a candidate knows how to use an AI coding agent is therefore becoming less useful as a hiring signal.

The tools themselves are also changing quickly. JetBrains found that Claude Code had reached around 39% adoption among professional developers, up from 18% in January 2026. Codex grew from 3% to 16% over the same period. Meanwhile, GitHub Copilot and Cursor both saw their reported adoption decline.

This matters because tool-specific experience has a short shelf life. A hiring process built around finding someone with experience in one particular agent can quickly become outdated as developers move to different tools.

The broader trend was already visible in the Stack Overflow Developer Survey 2025. The survey found that 84% of respondents were using or planning to use AI tools in their development process, while 51% of professional developers reported using them daily.

However, widespread use does not mean blind trust.

Stack Overflow found that more developers distrusted the accuracy of AI output than trusted it. Only 3% said they highly trusted AI-generated output, while 46% expressed some level of distrust.

That gap between adoption and trust is important for hiring.

Developers are increasingly using AI to produce code, but they still need to decide whether that code is correct. The strongest signal is therefore moving away from which AI tool a candidate has used and towards something more durable: their ability to review, question and verify AI-generated work.

Source: JetBrains Developer Ecosystem Survey 2026, covering more than 15,000 professional developers.

The practical consequence is simple. Tool-specific experience is becoming a weaker hiring signal because the tools themselves can change quickly. Requiring experience with a particular AI agent may exclude capable developers without telling you much about whether they can actually do the job.

The more useful question is whether the candidate can tell when AI-generated code is right, when it is wrong and when it needs further investigation.

What did the surveys measure, and where do they disagree?

The surveys agree on the overall direction, but they measure different groups of developers. That explains why their numbers are not identical.

Temporal's 2026 State of Development report found that 80.8% of its respondents used AI agents daily, compared with 47.3% a year earlier. JetBrains reported daily use at 68%.

These figures cannot be compared directly because they use different denominators.

Temporal surveyed people who were already using AI agents. Its survey provider contacted 650 qualifying respondents, with 554 responses passing quality screening. The research was conducted between 29 April and 25 May 2026.

JetBrains, by comparison, surveyed professional developers more broadly. Its 68% figure therefore represents daily AI agent use across its wider sample, rather than only among developers who had already adopted agents.

Read together, the findings tell a clearer story: AI agent adoption is widespread among professional developers, and developers who have adopted these tools tend to use them frequently.

This distinction matters because the figures are sometimes quoted as though they describe the same population. They do not.

"80% of developers use agents daily" is a statement about the wider developer market. "80% of developers who already use agents use them daily" measures how deeply existing users have incorporated the tools into their work. Those are very different claims.

It is also worth considering who produced the research. Both organisations have a commercial interest in AI development. JetBrains sells developer tools, including AI products. Temporal provides infrastructure for building and operating agentic applications.

That does not invalidate either survey. Instead, confidence in the broader trend comes from the fact that the studies used different samples and methodologies while reaching a similar conclusion: AI agents are becoming a regular part of software development.

There is, however, an important gap in both datasets.

Neither survey measures how much AI-generated code developers actually review before approving it. We know that developers are using agents and, in many cases, using them daily. What remains much harder to measure is how carefully humans examine the output.

For hiring managers, that may be the more important question. Adoption tells you whether a developer uses AI. It does not tell you whether they can recognise when its output is wrong.

What does an agent audit trail actually have to record?

An agent audit trail needs to record more than the final code change. It needs to capture the session that produced it.

When a developer gives instructions and an AI agent carries out the work, the final diff does not show the full decision-making process. The developer's original intent may have existed in prompts, planning steps and tool calls that version control never recorded. This makes it harder to understand why a change was made or how the agent reached its final output.

As AI agents become a standard part of software development, this gap becomes more urgent. The reviewable unit is no longer just the final diff. In many cases, it is the entire session behind it.

A useful audit trail should therefore capture several parts of that process:

Each layer answers a question that a normal code diff cannot.

The challenge is deciding how much to record

A complete tool-call log from a long-running agent session could contain thousands of entries. Storing everything may create a record that is technically complete but practically impossible for a human to review.

Teams therefore need to balance completeness against usability.

The audit trail needs enough detail to reconstruct an important decision, investigate an incident or understand how a change was produced. At the same time, it cannot require reviewers to work through thousands of routine actions.

This means summarisation becomes part of the system. The challenge is deciding what information can safely be condensed and what needs to remain available in its original form.

Agent identity also becomes part of provenance

Traditional version control assumes that changes can be traced back to a human author.

That becomes less straightforward when multiple agents contribute to the same piece of work. One agent may create a plan, another may write the code and a third may review or modify the result before a human approves it.

In that environment, authorship becomes a chain rather than a single name.

An audit trail should make it possible to identify which human and which agents were involved at each stage. This becomes particularly important after an incident, when a team needs to understand not only what changed but how the decision to make that change moved through the system.

Retention is another problem teams need to solve

Full agent session records can be substantially larger than the code they produce.

Keeping every transcript indefinitely creates storage costs and leaves teams with large volumes of information they may never use. Keeping too little creates the opposite problem: when something goes wrong, the evidence needed to understand the decision has already disappeared.

A practical approach may involve different retention periods for different types of information. Teams could retain plans and important tool-call summaries for longer while keeping complete session transcripts for a shorter period.

The important point is that this should be an intentional policy. It should not be left to whatever retention settings happen to come with an agent tool.

The infrastructure for agent activity is also expanding

The Model Context Protocol is becoming an increasingly important part of this ecosystem. Its JavaScript SDK recorded more than 203 million downloads from npm in the month ending 29 August 2026.

That level of adoption suggests that model integrations are moving beyond experimental projects and becoming part of ordinary software infrastructure. The growing number of MCP servers and integrations also means agents are gaining access to an increasingly broad range of tools and systems.

This creates a larger review challenge.

GitHub's Octoverse 2025 reported that more than 1.1 million public repositories were using an LLM SDK. Model-calling code is increasingly becoming ordinary application code, which means the ability to review AI-assisted work can no longer be treated as a niche requirement.

An AI reviewer does not automatically solve the problem

One obvious response is to use another AI agent to review AI-generated code.

That can be useful, but it does not remove the need for external judgement. A March 2026 preprint argued that AI generation and AI review can become structurally circular when there is no independent specification against which the output can be evaluated. A separate preprint examined the longer-term risks of generated code feeding back into future training data. Both papers are preprints rather than peer-reviewed research, so their conclusions should be treated as emerging arguments rather than settled evidence.

The underlying problem remains simple: a reviewer needs something independent against which to judge the output.

That reference may be a specification, a test suite, a clear business requirement or human expertise. Without it, an AI reviewer may simply confirm the assumptions made by the AI that generated the code.

As agents take on more of the work, audit trails become part of how teams maintain accountability. They provide the missing context between a developer's original instruction and the code that eventually reaches production.

When everyone can generate code, the scarce skill is knowing what to reject.

What should you test in an interview now?

Test a candidate's ability to review code they did not write.

As AI agents take on more of the work of generating code, developers are increasingly responsible for deciding whether that output is correct. Recent research has started examining this shift from code authoring towards reviewing and evaluating agent-generated work. Two separate 2026 studies explored AI-generated code and how developers respond to agent-generated review feedback. Both are preprints, so they should be treated as emerging evidence rather than settled findings.

The practical implication is that the interview process needs to change.

The goal is not to stop testing technical ability. Developers still need to understand how software works.

The difference is where that ability is applied.

When an agent can generate a plausible implementation in seconds, producing code is no longer enough evidence of good judgement. A developer also needs to recognise hidden defects, understand what information is missing and know when a solution should not be approved.

Test judgement under realistic constraints

One practical exercise is to give the candidate a pull request generated by an AI agent.

Include one genuine defect and one change that looks suspicious but is actually correct. Give the candidate a limited amount of time to review the code.

Then ask three questions:

• What would you approve?
• What would you send back?
• What additional information would you need before making a decision?

The third question may reveal the most.

Strong developers do not always immediately have an answer. Sometimes good judgement means recognising that there is not enough information to make a safe decision. The questions a candidate asks can therefore be as informative as the problems they identify.

State management is another useful area to test

Temporal's 2026 State of Development report found that tracking state was the most commonly reported barrier to greater agent use, cited by 35.7% of respondents.

That problem goes beyond writing effective prompts.

An engineer may need to reason about work that moves across multiple steps, tools or agents. They need to understand what happens when a process fails halfway through, whether state can be recovered and how the system avoids producing inconsistent results.

These are established engineering problems, but AI agents can make them more visible by increasing the number of automated steps involved in a workflow.

Code review is becoming a more important hiring signal

Practitioner discussions also reflect growing concern about the effect AI-generated code could have on review workloads. Hacker News discussions in 2026 have focused on whether teams can maintain effective review standards when the volume of generated code increases.

These discussions are not evidence of a broader industry consensus. They show that the issue is actively being debated by practitioners, many of whom have strong opinions or commercial interests.

The central hiring question is therefore changing.

Instead of focusing only on whether a developer can produce working code, interviews should increasingly test whether they can evaluate work critically. Can they identify what is wrong? Can they recognise when something only looks wrong? And, perhaps most importantly, do they know when they do not yet have enough information to decide?

Does agent fluency make junior engineers more or less valuable?

The honest answer is that we do not have enough public data to know.

US employment in computer systems design and related services was 2.37 million in July 2026, according to the Bureau of Labor Statistics. The figure had remained within a relatively narrow range over the previous four months. The wider US unemployment rate was 4.1% in July, down from 4.3% in April and May.

Neither measure tells us how many junior or senior software engineers companies are hiring.

There is no public employment series that separates software developers by seniority. That means claims that AI agents have caused junior hiring to collapse cannot currently be confirmed from aggregate employment data.

What the data does show is that any such collapse is not obvious in overall industry employment. Going further requires evidence that is not currently available.

Adoption does not automatically mean productivity

There is another reason to be cautious about drawing conclusions from AI adoption figures.

METR, a nonprofit AI evaluation organisation, ran a randomised controlled trial involving experienced open source developers working in their own repositories. In that particular study, developers using AI tools took 19% longer to complete their tasks than developers who did not use them. The researchers described the result as a snapshot of AI performance in a specific setting and later published research examining newer tools.

That does not mean AI makes developers slower in general.

It does show why adoption should not be treated as a proxy for productivity.

A technology can be widely used while developers remain uncertain about its output. It can also improve performance in some situations while making it worse in others. Those findings can exist at the same time.

So far, the public evidence supports a few narrower conclusions. AI agent adoption is high. Developers do not necessarily trust the output blindly. Productivity results are mixed. There is not yet reliable public evidence showing that AI agents have reduced engineering headcount or made junior developers redundant.

There is another way to look at junior engineers

If AI reduces the amount of code developers need to write, the bottleneck may move towards reviewing and approving that code.

That creates an interesting problem for teams that stop hiring junior engineers.

Good reviewers need experience. Experience comes from seeing code, making mistakes, receiving feedback and learning how to identify problems. Junior engineers are part of that development pipeline.

A company that removes junior roles may therefore reduce its future supply of experienced reviewers. It could eventually need to hire those people from elsewhere instead.

That is a structural argument, not a proven industry trend. There is also an obvious commercial interest behind it, so it should be treated as a position to consider rather than an established finding.

The decision should be deliberate

Whatever happens to junior hiring across the wider market, companies should be careful about treating AI adoption as a reason to remove junior roles automatically.

If a team decides it needs fewer juniors, it should also consider where its future senior engineering and review capacity will come from.

AI may change the work junior engineers do. It may change how quickly they become productive. It may change the skills companies expect from them.

Conclusion

AI coding agents have changed what it means to be a software developer, but they have not changed the fundamentals of good engineering.

The tools are now widely used. That makes agent familiarity a weaker hiring signal. Knowing how to prompt an agent or use a particular coding tool is increasingly a baseline rather than a differentiator. The more valuable skill is judgement.

Developers need to understand what an agent is doing, recognise when its output is wrong and know when they need more information before approving a change. They also need to understand the state, risks and consequences of work that may pass through several automated steps. That should change how companies interview.

Instead of focusing so heavily on whether candidates can produce code from scratch, hiring processes should create opportunities to assess how they review code, question assumptions and handle uncertainty. An AI generated pull request can reveal more about a developer's judgement than another timed coding exercise.

The same caution applies to junior hiring. There is not yet enough public evidence to conclude that AI agents have made junior engineers redundant. Cutting junior roles because agents can produce more code may solve a short term capacity problem while creating a future shortage of experienced reviewers. The central shift is therefore not from human engineers to AI engineers. It is from code generation towards code evaluation.

When generating code becomes cheap, knowing what deserves to reach production becomes more valuable. The teams that recognise that shift will hire for judgement, build better review processes and use AI as a tool without handing it responsibility that still belongs to people.

But the public data does not currently justify saying that AI agents have made junior engineers obsolete. The safer conclusion is that the market is changing faster than the data can tell us exactly how.

Practical hiring takeaway

Do not make AI tool experience the centre of your hiring process. Assume capable developers can learn the tools. Instead, test how candidates use them.

Give candidates an AI generated pull request and ask them to review it under a realistic time limit. Include a genuine defect alongside code that is correct but looks questionable. Ask the candidate to explain what they would approve, what they would reject and what information they would need before making a decision.

Pay attention to their reasoning, not just whether they find the planted bug.

A strong candidate should be able to question the agent's output, explain the potential consequences of a change and recognise when they do not have enough information to approve it. That is the skill AI agents cannot make redundant: knowing when the code is good enough to trust.

FAQ

What percentage of developers use AI coding agents?

90% of professional developers used an AI coding agent at work at least weekly between May and July 2026, while 68% used one daily, according to the JetBrains Developer Ecosystem Survey 2026. The survey covered more than 15,000 developers. Among engineers who already use agents, Temporal reported that 80.8% use them daily or more.

Should you let candidates use AI in a technical interview?

Yes. Banning AI can test a working style that no longer reflects how many developers actually work. A better approach is to allow the candidate to use an agent and then assess how well they evaluate its output.

Ask what they would change, what they would reject and what they cannot verify. The goal is to test their judgement rather than their ability to work without tools.

What is an agent audit trail?

An agent audit trail records an AI agent's working session, not just the final code. It can include the original plan, tool calls, files accessed and changes made by each agent.

This matters because a code diff does not always show why a change was made or what happened before it reached the final version. An audit trail provides the context needed to review the work and investigate problems later.

Are junior developers still worth hiring?

Public data cannot answer this conclusively. US employment in computer systems design stood at 2,366.4 thousand in July 2026 and has not shown a sharp recent decline, but public employment data does not separate junior from senior software roles.

There is also a longer term consideration. Review judgement develops through experience. A company that stops hiring and developing junior engineers may reduce its future supply of experienced reviewers.

That does not prove that companies should hire more juniors. It means the decision should be made deliberately rather than assuming that AI agents have made junior engineers unnecessary.

Where this leaves hiring

If generation is universal and review is the constraint, the hire that matters is the one you can trust to approve someone else's work. That is a claim about judgment, not about tools, and judgment is expensive to test and easy to fake on a CV.

That is the whole reason our assessment runs 6–8 hours per developer rather than a one-hour screen. An hour tells you whether somebody can produce something that runs. Six to eight hours, structured around real work with real ambiguity in it, tells you whether they know what to reject. 98%+ of applicants do not get through it, and the developers who do are the top 2%.

If you would rather test that judgment yourself than take our word for it, the 14-day risk-free trial exists for exactly that. Start with a vetted engineer from RocketDevs at $9.99/hr for the Associate tier, give them a review-heavy task, and see what they send back. It is the same argument we make for hiring pre-vetted engineers generally.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• JetBrains, Developer Ecosystem Survey 2026: AI coding agent adoption
• Temporal, The State of Development 2026
• Stack Overflow Developer Survey 2025, AI section
• METR, metr.org
• GitHub Octoverse 2025
• GitHub API, modelcontextprotocol/servers
• Assessing AI Agent Python Code Proficiency in the Wild, arXiv:2604.00299
• The Specification as Quality Gate, arXiv:2603.25773
• When AI Reviews Its Own Code, arXiv:2606.28438
• Understanding Developer Responses to Agent-Generated Code Review Comments, arXiv:2607.21997
• agenttrail on GitHub
• sprix-sage-router on GitHub
• x64dbg-mcp-server on GitHub
• npm download statistics, @modelcontextprotocol/sdk
• npm download statistics, typescript
• US Bureau of Labor Statistics, computer systems design employment, CES6054150001
• US Bureau of Labor Statistics, unemployment rate, LNS14000000
• Hacker News discussion on human control of code review