Разработчики всё чаще жалуются, что новые ИИ-модели, несмотря на статус «топовых», хуже справляются с повседневными задачами: дольше думают, дают почти правильный код, путаются в контексте и требуют больше ручной проверки. Однако проблема не всегда в том, что искусственный интеллект «отупел». Часто причина в неправильном выборе модели, неуправляемом контексте, избыточном «мышлении» и неверной работе с ИИ-агентами.
Почему разработчикам кажется, что ИИ-модели стали хуже
Главная претензия к современным ИИ-инструментам звучит просто: новые модели выходят с громкими обещаниями, показывают высокие результаты в бенчмарках, но в реальной работе могут медлить, ошибаться и генерировать лишний код. Особенно это заметно у опытных разработчиков, которые сравнивают работу новых моделей с предыдущими версиями.
Одна из ключевых причин — несоответствие инструмента задаче. Для простой операции, например переименования переменной или небольшой правки, разработчики нередко запускают самую дорогую и «умную» модель с максимальным режимом рассуждения. В результате ИИ начинает анализировать задачу так, будто от неё зависит архитектура всего проекта.
Попытка использовать флагманскую модель для тривиальной правки похожа на разогрев попкорна в адронном коллайдере: инструмент мощный, но выбран не по задаче.
Такое поведение создаёт ощущение, что модель стала «тупее»: она дольше отвечает, задаёт лишние уточняющие вопросы, тратит больше токенов и иногда уходит в переусложнение. Но на практике это часто не деградация интеллекта, а неправильная настройка рабочего процесса.
ИИ уже стал рабочим инструментом программистов
По данным опроса «JetBrains», в котором участвовали около 15 тысяч профессиональных разработчиков, примерно 90% специалистов используют искусственный интеллект ежедневно или еженедельно. Это показывает, что ИИ уже стал частью обычного рабочего процесса в разработке программного обеспечения.
При этом доверие к результатам остаётся ограниченным. По данным опроса «stack overflow», только около 29% разработчиков доверяли точности того, что генерирует ИИ. Среди главных причин недовольства назывались:
- примерно 66% респондентов раздражало, что модель выдаёт «почти правильный» результат;
- около 45% отмечали, что отладка кода, созданного ИИ, занимает больше времени, чем самостоятельное написание;
- многие разработчики не готовы полностью делегировать ИИ сложные задачи из-за недоверия к результату.
В отчёте «Anthropic» также отмечалось, что искусственный интеллект участвует примерно в 60% работы разработчиков, но полностью делегировать ему можно лишь ограниченную часть задач — примерно до 20%.
Что такое «переобдумывание» ИИ-моделей
Одна из важных проблем современных моделей — так называемое переобдумывание. Это ситуация, когда модель уже нашла правильный ответ, но продолжает генерировать дополнительные шаги рассуждения.
Для пользователя это выглядит так: простая задача решается слишком долго, ответ становится избыточным, а модель начинает добавлять проверки, предупреждения и рассуждения, которые не требовались. При этом пользователь платит не только временем, но и токенами.
Исследования 2025 года описывали несколько связанных эффектов:
- модель может слишком долго рассуждать над простой задачей;
- на сложных задачах, наоборот, она может не рассуждать достаточно глубоко;
- если в запросе не хватает условий, модель иногда не задаёт уточняющий вопрос, а начинает генерировать тысячи лишних токенов;
- после определённой длины рассуждений точность может не расти, а снижаться.
Иными словами, больше «мышления» не всегда означает лучший результат. У каждой задачи есть оптимальная глубина обработки. Если модель выходит за эту точку, качество может ухудшаться.
Почему топовая модель не всегда лучший выбор
У разработчиков часто есть соблазн использовать самую новую, дорогую и мощную модель по умолчанию. Но это не всегда рационально. Флагманские модели лучше подходят для сложной аналитики, архитектурных решений, исследования большого проекта или работы с комплексными требованиями.
Для ежедневной рутины — небольших правок, документации, коротких изменений, простого рефакторинга — часто достаточно более быстрой и дешёвой модели среднего уровня. В таких задачах топовая модель может быть не преимуществом, а источником накладных расходов.
Основные признаки неправильного выбора модели
- модель слишком долго думает над простой задачей;
- ответы становятся чрезмерно длинными;
- ИИ предлагает лишние архитектурные изменения;
- появляются уточнения там, где задача очевидна;
- стоимость работы через программный интерфейс резко растёт;
- после длинной сессии модель начинает путаться в контексте.
Особенно заметна проблема в агентных сценариях, где модель работает не как отдельный чат-бот, а как часть среды разработки: читает файлы, анализирует проект, редактирует код и выполняет последовательность действий.
Контекстное окно: почему длинные сессии вредят качеству
Ещё одна причина ухудшения качества — перегрузка контекста. Когда разработчик долго работает в одном чате или агентной сессии, модель накапливает много информации: требования, исправления, промежуточные решения, ошибки, откаты и новые инструкции.
Со временем модель может начать теряться. Особенно это заметно на длинных задачах, когда часть важной информации оказывается «в середине» контекста и хуже учитывается. Такой эффект часто называют проблемой потерянной середины.
Чтобы снизить риск, разработчику важно управлять контекстом:
- фиксировать решения в документации проекта;
- разделять большие задачи на этапы;
- завершать длинные сессии и создавать краткое резюме для новой;
- проверять сгенерированный моделью переходный промпт;
- хранить рабочий план агента в файлах проекта;
- не полагаться на память чата как на единственный источник истины.
Простой практический приём — перед завершением длинной сессии попросить ИИ подготовить краткий промпт для перехода в новый чат. Но такой промпт нельзя использовать вслепую: его нужно проверить, исправить и убрать лишнее.
Цена ошибки: почему «лишние рассуждения» стоят денег
Проблема не ограничивается качеством ответа. Избыточные рассуждения напрямую влияют на стоимость работы. У топовых моделей цена входящих и исходящих токенов может быть заметно выше, чем у быстрых или средних моделей.
Если модель для простой задачи генерирует длинные рассуждения, перечитывает документацию, создаёт лишние планы и многократно проверяет одно и то же, пользователь фактически платит за бесполезную активность. В агентных сценариях это может быстро расходовать лимиты подписки или бюджет при работе через программный интерфейс.
Поэтому грамотный выбор модели — не только вопрос удобства, но и вопрос экономики разработки.
Флагманские, средние и быстрые модели: как выбирать
У каждого уровня есть своя зона применения.
Флагманские модели
Флагманские модели подходят для задач, где действительно нужно глубокое рассуждение:
- архитектурный анализ проекта;
- поиск сложных причин ошибок;
- планирование крупных изменений;
- исследование большого кода;
- сопоставление требований, документации и реализации.
Но использовать такие модели для каждой мелкой правки невыгодно. Они дороже, медленнее и склонны к переусложнению простых задач.
Модели среднего уровня
Средние модели часто становятся оптимальным выбором для регулярной разработки. Они достаточно сильны для большинства практических задач, но быстрее и дешевле флагманов.
Такие модели можно использовать для:
- типовых изменений в коде;
- рефакторинга небольших участков;
- объяснения фрагментов проекта;
- написания тестов;
- работы с документацией;
- коротких агентных задач.
Быстрые модели
Быстрые модели лучше подходят для простых и коротких операций. Они могут быть полезны при генерации черновиков документации, небольших подсказках, форматировании текста или простых изменениях.
Главное — не ожидать от них стабильной работы на длинных и сложных задачах. В длительной сессии такие модели могут быстрее терять нить рассуждения.
Почему бенчмарки не гарантируют успех в реальном проекте
Разработчики часто ориентируются на бенчмарки, которые публикуют поставщики моделей. Однако результаты в тестах не всегда отражают реальную работу с конкретным проектом.
Например, разница между двумя моделями в бенчмарке для исправления кода может составлять всего несколько процентов, тогда как стоимость одной из них будет вдвое выше. В таком случае важно понять, оправдывает ли небольшой прирост качества дополнительные расходы именно в вашей ежедневной работе.
На результат влияют не только возможности модели, но и:
- качество промптов;
- структура проекта;
- наличие документации;
- настройка агентной среды;
- ограничения инструментов;
- умение разработчика контролировать ход работы ИИ.
Поэтому модель сама по себе не решает всё. Важна связка: модель, агентная обвязка, документация, правила проекта и человек, который проверяет результат.
Агент важнее, чем кажется
Многие разработчики до сих пор используют ИИ как обычный чат-бот: копируют туда фрагмент кода, получают ответ и вручную переносят его обратно в проект. Такой подход ограничивает возможности искусственного интеллекта.
Агентная работа отличается тем, что ИИ действует внутри процесса разработки: видит файлы, читает документацию, предлагает изменения, может выполнять последовательные шаги и сохранять промежуточный контекст.
Однако и здесь качество зависит от настройки. Если агент плохо управляет контекстом, не имеет чётких правил и не получает актуальную документацию, даже сильная модель может работать нестабильно.
Как снизить риск ошибок при работе с ИИ
Чтобы ИИ-модели не казались «тупыми», разработчику нужно управлять ими как инженерным инструментом, а не воспринимать как магическую кнопку. Практические рекомендации выглядят так:
- Выбирать модель под задачу. Не использовать флагманскую модель для мелких правок без необходимости.
- Ограничивать контекст. Не держать бесконечно длинные чаты, если задача уже изменилась.
- Документировать решения. Важные выводы и планы лучше сохранять в файлах проекта.
- Проверять код. ИИ может дать почти правильный результат, но ответственность остаётся на разработчике.
- Управлять агентом. Нужно задавать правила, роли, ограничения и ожидаемый формат результата.
- Следить за стоимостью. Дорогие модели и длинные рассуждения быстро расходуют лимиты.
- Разбивать задачи. Большие изменения лучше выполнять поэтапно с проверкой после каждого шага.
Главный вывод: ИИ не заменяет инженерное мышление
Жалобы на то, что новые ИИ-модели «тупеют», часто отражают не только реальные ограничения технологий, но и неправильный способ их использования. Современные модели могут быть мощными, но без контроля они переусложняют простые задачи, теряют контекст, расходуют лишние токены и создают код, который приходится долго отлаживать.
Для разработчиков ключевым навыком становится не просто умение открыть чат с ИИ, а способность встроить искусственный интеллект в нормальный инженерный процесс: выбрать подходящую модель, настроить агента, описать правила проекта, контролировать контекст и критически проверять результат.
ИИ-модели не всегда становятся глупее. Но без грамотного управления даже самая умная модель может вести себя так, будто она не понимает простейшую задачу.
На основе Топовые ИИ тупеют? Почему сеньоры плюются от новых моделей