There is a whole desktop behind this site.
Windows, a media player, games: the full xudiyev.com experience.
Open desktop mode
Khayal Khudiyev
QA Engineering · UX/UI Design · Web Development · AI-Powered Solutions
Home › Blog

Agentic IDEs in 2026: What Changed and What Did Not

Published 2026-09-10 · 3 min read

The tools moved from autocomplete to agents that plan and execute across files. That is a real shift. It also moves the bottleneck somewhere most teams have not staffed.

Agentic IDEs in 2026: What Changed and What Did Not

Two years ago these tools completed the line you were typing. Now they take a task, plan it, edit several files and hand you a diff. Google shipped Antigravity, Cursor moved the same direction, OpenAI has Codex, and Windsurf, Kiro and Claude Code all sit in the same category.

The marketing frames this as a productivity story. From where I sit, doing QA on software for a living, it is mostly a review story, and that is the part nobody is planning for.

What actually changed

The unit of work moved. Previously you accepted a suggestion the size of a line and understood it immediately because you were already thinking about that line. Now you accept a change the size of a feature, across files you were not looking at, written while you were doing something else.

That is a genuine productivity gain and a genuine comprehension loss at the same time. Both are real. Teams keep budgeting for the first and not the second.

The shape of each one

Rather than a feature table that will be wrong in three months, the differences that seem durable:

  • Cursor sits closest to a normal editor. Least disruptive to how you already work, which is why it is the easiest to adopt across a team.
  • Claude Code runs in the terminal and leans on reasoning over a whole repository. Better when the task spans a lot of context.
  • Antigravity is the most autonomous of the group, which means the highest ceiling and the largest diffs to review.
  • Codex and Windsurf sit between those poles, and the choice mostly comes down to which ecosystem you are already in.

Entry pricing across the category has settled around the same monthly figure, with much higher tiers for heavy use. Price is not the differentiator it was a year ago.

The bottleneck nobody staffed

If a tool produces four times the code, someone has to review four times the code. That someone is a person, and reviewing generated code is harder than reviewing code a colleague wrote, because there is no author to ask what they were thinking.

Every failure I see in this pattern is the same failure. Not bad generated code, but generated code that nobody understood well enough to debug when it broke three weeks later. The tool made the fast part faster and left the slow part alone.

What I would put in place first

  • A rule that no agent-written change merges without a human who can explain it.
  • Tests written by a person, not by the same agent that wrote the feature. An agent grading its own homework passes every time.
  • Static analysis and dependency scanning in CI, because generated code pulls in dependencies nobody chose deliberately.
  • A limit on diff size. If the agent produces a change too big to review properly, that is the signal to break the task down, not to skim it.

Is it worth adopting

Yes, with the review layer built at the same time rather than afterwards. Teams that add the tool and keep the old review process end up shipping more code and understanding less of it, and that debt comes due at the worst possible moment.

The tools are good. The discipline around them is what decides whether they pay off.

Related

The developer-side version of this problem: vibe coding risks. Choosing between models: Claude vs ChatGPT vs Gemini.

More posts

I pay for more than one of these, which tells you the comparison is not as simple as picking a winner. Where each model is genuinely better, from daily use rather than benchmarks.

Every model is best at something and mediocre at something else. This is which one I open for which task, based on using all of them inside real client work rather than on benchmarks.

AI can write a WordPress plugin in a minute. Whether you should put that plugin on a live site is the part nobody covers. From someone who reviews this code for a living.

Most slow WordPress sites are slow for two or three specific reasons. Here is how to find which ones, in the order that gives you the biggest drop in load time for the least work.

AI can draft your test cases in seconds. Whether those cases find anything is a different question. What a year of using AI tools inside a real QA job actually changed.

AI writes the code in seconds. Someone still has to find out whether it works. A QA engineer’s view of what vibe coding actually costs, and how to use AI tools without shipping their mistakes.

Ten UX/UI trends worth knowing, sorted by whether they change what you actually build or just what design blogs look like this year.

A working checklist for hardening a WordPress site, logins, files, database, hosting and monitoring, written from what actually breaks on sites in production.

AI can lay out a screen, read behaviour data and run usability checks. It cannot decide what the product should be. A practical look at where the line sits.