Курс JetBrains на 2026: ИИ-агенты и классический воркфлоу сосуществуют в одной IDE
Краткое содержание
JetBrains публикует продуктовый манифест на 2026 год: компания признаёт, что сегодня код пишется двумя одинаково законными способами — «классическим» (типизация, рефакторинг, отладка вручную) и «новым» (через ИИ-автокомплит и агентов, которые генерируют целые куски). Цель JetBrains — обеспечить сосуществование этих двух режимов в одной IDE так, чтобы ни один не мешал другому. Главный принцип: человек остаётся ответственным за код, который уходит в прод, а IDE — лучшее место, чтобы прочитать, понять и присвоить себе этот код, кем бы он ни был написан.
Что значит «AI в IDE» по JetBrains
«ИИ в JetBrains IDE» — это не один «официальный» воркфлоу, а агентическая добавочная ценность: фичи появляются там, где они полезны. AI Chat — чат-первый режим; интегрированный терминал, в котором многие уже работают с CLI-инструментами; новые «opt-in» режимы для агентских систем, где агента можно оставить работать на часы. Идея: одна IDE — несколько ИИ-способов выполнять работу, выбираемые пользователем, формируемые командой и ограниченные реальными требованиями к разработке.
Стратегия: никакого vendor lock-in
JetBrains декларирует, что «лучшая» модель/провайдер/агент сегодня не будет «лучшей» через месяц. Поэтому AI-чат поддерживает несколько способов подключения: подписка JetBrains AI; BYOK (свой API-ключ); OAuth-вход в поддерживаемых провайдеров; и подключение внешних агентов через стандартный протокол ACP (Agent Client Protocol). Честная оговорка: OAuth не везде доступен — если провайдер не отдаёт его в форме, пригодной для IDE, JetBrains не может его «изобрести».
ACP позволяет подключать внешних агентов к JetBrains IDE через единый интерфейс — без отдельной интеграции под каждый продукт. Агенты ставятся из курируемого реестра или вручную и появляются внутри AI Chat. В качестве примера приведён агент Cursor — он уже доступен внутри JetBrains IDE через ACP и выбирается из общего пикера агентов. Концептуально подключение агента через ACP может выглядеть как простой манифест:
{
"name": "cursor",
"protocol": "acp",
"endpoint": "https://acp.cursor.com",
"auth": { "type": "oauth" }
}
Главное обещание — «классические» рабочие процессы не отодвигаются в сторону ради «режима агента».
«Профессиональный код с ИИ» = больше ответственности
JetBrains прямо отделяет себя от рынка одноразового кода: их IDE строятся для кода, который будет жить долго, и сгенерированный код должен рассматриваться как «настоящий». Это означает, что разработчик должен иметь возможность прочитать, отревьюить, изменить, откатить и понять влияние на кодовую базу любого ИИ-вклада. Базовые ожидания: изменения видны; изменения обратимы; проект не остаётся в «красном» состоянии после действия агента. Агенты могут менять много файлов, и это полезно лишь тогда, когда результат можно полностью проинспектировать и поправить — для этого и нужна IDE как центр ответственности.
Пять продуктовых обязательств
JetBrains фиксирует пять принципов на 2026 год. Первый — AI-режим и классический режим равноправны и работают параллельно: компания не строит «нарратив замещения разработчиков» и не подталкивает пользователя в единственно «правильный» воркфлоу. Второй — даже самые продвинутые агенты не должны жертвовать ядром IDE: глубокий код-аналайз, безопасный рефакторинг, отладка, навигация, инспекции и ревью остаются «обязательным» базисом профессиональной разработки. Третий — нулевая блокировка на вендора: множество путей активации (подписка, BYOK, OAuth, ACP-агенты) — это не «приятный бонус», а архитектурное обязательство. Четвёртый — приоритет долгосрочной полезности над хайпом: настоящий сигнал — это устойчивая ретенция фич через недели, на реальных проектах (с явной шпилькой в адрес модной «Ralph-loop»). Пятый — честная обратная связь от сообщества: Reddit, отзывы Marketplace и комьюнити, которые не обязаны JetBrains политесом, — это именно те, чьим судом компания готова руководствоваться.
Значимость
Это публичный стратегический документ JetBrains о позиционировании в постхайповый период ИИ-разработки. Ключевые маркеры: 1) отказ от ставки на один LLM-стек или один агент; 2) ACP как ставка на интероперабельность вместо проприетарных интеграций; 3) сохранение «классического» режима как полноценного, а не legacy-варианта; 4) явное смещение ответственности с инструмента на человека и подчёркивание роли IDE как места, где код понимается и присваивается. Запись задаёт ожидаемый продуктовый трек на ближайший год.
🧾 Транскрипт (формат)
Our 2026 Direction: AI and Classic Workflows in JetBrains IDEs Source: https://blog.jetbrains.com/ai/2026/05/our-2026-direction-ai-and-classic-workflows-in-jetbrains-ides-2/
Two valid ways of writing code. One place to own it.
Quick version for AI-news-tired readers: press here
There are two ways developers create code now:
The classic way: By typing, refactoring, debugging, and building up intent line by line. The new way: Through collaborating with AI – sometimes via autocomplete and other times by using an agent that can draft whole chunks of work. We don’t think one is better than the other.
Our goal is to ensure both workflows can coexist inside JetBrains IDEs without hindering each other. In practice, this means that:
If you want to write code yourself, the IDE should be focused on code writing, and AI shouldn’t compromise the core coding experience. If you want to generate code with AI (or delegate tasks to agents), the IDE should make that feel natural and powerful, both in terms of UX and functionality. Either way, one thing doesn’t change: A human is responsible for the code that ships. And the best place to read, understand, and own that code is still the IDE.
What “AI in the IDE” means without the snake oil or hype We’re not limiting this to one “official” workflow. The market is moving too fast for that – and developers are too diverse for a one-size-fits-all approach.
So when we say “AI in JetBrains IDEs”, we mean agentic added value: UX and features that become available as and when useful:
In the AI Chat tool window, as a chat-first workflow. in the IDE terminal, where many developers already work with CLI tools. In the new opt-in modes created for agentic systems, where you can run an agent and leave it to work for hours. Think of it as follows: One IDE, with multiple AI-powered ways to get work done – picked by the user, shaped by the team, and constrained by real development expectations.
The AI strategy: Avoid vendor lock‑in and keep workflows compatible If there’s one thing we’re confident about, it’s this: The “best” model, provider, or agent today won’t be the best forever – or perhaps even next month.
That’s why we’re deliberately building toward an IDE experience that does not depend on a single vendor’s roadmap.
Practically, that means our AI chat experience supports multiple ways to connect – depending on what’s allowed by providers’ terms, and what users actually want:
JetBrains AI-managed setup (with JetBrains AI subscription). BYOK: Bring your own API key. OAuth sign-in for supported provider accounts (where the provider supports it). ACP agents: Connect external coding agents through a standard protocol.
One honest footnote: OAuth isn’t always available. If an agent provider doesn’t offer OAuth (or doesn’t offer it in a way an IDE can use), we can’t invent it.
Agent Client Protocol (ACP): “Bring your own agent” ACP lets you connect external coding agents to JetBrains IDEs through a standard interface, so the IDE doesn’t need a bespoke integration for every agent. Agents can be installed from a curated registry (or configured manually), and the installed agents appear inside the AI chat.
A practical example of one that people have been asking for is the Cursor agent. Cursor is already available as an AI agent inside JetBrains IDEs through ACP – you can select it from the agent picker and use its agentic workflow inside your JetBrains IDE.
This is the shape we want:
You choose the agent that fits your workflow or team. You keep working in the IDE you already rely on. Classic IDE workflows don’t get shoved aside for “agent mode”.
“Professional coding with AI” means more responsibility We’re not anti-AI. We’re anti-confusion.
There’s a kind of coding that’s optimized for disposable output – and it’s totally valid in the right context. But JetBrains IDEs are built for code that isn’t disposable, but rather for code that is intended for long-term use.
So here’s the principle we design for: Generated code should be treated like real code. That means it should be possible to:
Read it Review it Change it Revert it when it’s wrong Understand its impact on the codebase In practice, our baseline expectation is boring (in the best possible sense):
Changes should be visible Changes should be reversible Your project isn’t left in a broken state (“no red code” is a pretty good starting point)
And yes, agents can edit many files. That can be a superpower – but only if you can fully inspect, understand, and correct the outcome. That’s where the IDE matters: It gives you visibility and control over the code produced by humans or AI.
AI on your terms: our product commitments 1. AI and classic modes live side by side Typing-first workflows and AI-first workflows are both valid. We’re not building for developer-replacement narratives, and we’re not building an IDE that nudges you into a single “approved” way of working. We respect both approaches.
2. AI agents must respect the core IDE promise Every push toward agents must keep the IDE’s core promise intact: deep code intelligence, safe refactoring, debugging, navigation, inspections, reviews – the stuff professional development is made of.
3. Zero vendor lock-in Multiple activation pathways (subscription, BYOK, OAuth, where possible, and ACP agents) are not a “nice to have.” We are committed to ensuring your workflow is never tied to a single vendor.
4. Long-term utility over hype If people keep using these workflows weeks later (real retention, real projects), that’s the signal. A lot of AI-driven workflows today are just hype (I’m talking about you, Ralph-loop).
5. Prioritizing candid community feedback We value the honesty of Reddit users, Marketplace reviewers, and community members who don’t owe us politeness. Those are exactly the people we want judging our progress.
AI will create a lot of code. That’s not a prediction anymore – it's the reality in April 2026.
But someone still has to be responsible for that code. Someone still has to read it before it merges. And right now, agents can help you move fast – but they can’t carry the risk for you.
So our commitment is straightforward:
We’ll keep building AI workflows that speed up creation – and we’ll keep strengthening the IDE as the best place to review, understand, and own what gets shipped.
You decide how much AI you want. We’ll make sure both paths – AI-assisted and classic – work great together, but you can stay on the path you prefer.