[{"data":1,"prerenderedAt":135},["ShallowReactive",2],{"$fBBQ5ulyG5jVWbIBJe3r8F-kTKQKf1scMJiu0B6qzX5k":3,"$f7AVZHmPutZ23_8XKkLbDtEszKCuiY3yPjIDp9eRXGag":5,"$fi3vrE4SQWUP5fhXAu4sgVYxn3xn-3N0hJEjyeqtT_R8":7,"$f3rJ3kCmsuXOcmGETSTgu9QXibHNg32Yb_e-POGzHzDI":111},{"data":4},[],{"data":6},[],{"data":8,"meta":107},[9],{"id":10,"documentId":11,"title":12,"seo_title":13,"summary":14,"seo_description":15,"slug":16,"published_date":17,"body":18,"content":19,"createdAt":38,"updatedAt":39,"publishedAt":40,"blogauthor":41,"cover":50,"categories":96},315,"ha8a4ct3vzhnoeasnbsuwv7a","JetBrains IDE: будущее не за горами","IDE для AI-агента: поиск, coverage и профилирование","Агенту мало grep и bash. Разбираем эксперименты JetBrains: как IDE-поиск, покрытие тестами и профилировщик помогают агенту работать быстрее и дешевле.","Зачем AI-агенту IDE: эксперименты JetBrains с IDE-native поиском, code coverage и профилированием. Поиск через IDE снизил latency и стоимость задач.","jetbrains-ide-budushhee-ne-za-gorami","2026-07-03","Если вы хоть немного следите за AI coding, то наверняка слышали новую мантру: IDE больше никому не нужна. Все «вайбанутые» живут в терминале, запускают Claude Code, Codex или OpenCode и уверенно объясняют, что профессиональная среда разработки — это пережиток эпохи, когда код писали руками.\n\nAgent-у хватает самых простых инструментов: `grep`, `bash`, `edit` и пары хороших prompt-ов. Сложные интерфейсы, UI-инспекторы, рефакторинги, дебаггер — всё это выглядит как пережиток прошлого. Открыл терминал, написал задачу, получил diff. Кажется, человечеству IDE больше не нужна. Или всё-таки нужна? Тут как посмотреть.\n\nJetBrains в этой картине обычно достаётся роль динозавра. Компания много лет задавала планку того, как должен выглядеть профессиональный инструмент разработчика. Но когда индустрия сместила фокус с IDE на agent-ов, предложенные JetBrains AI Chat (ex. AI Assistant) и Junie выглядели не как новый тренд, а скорее как попытка заскочить в уходящий поезд.\n\nНо у тезиса «IDE больше не нужна» есть слабое место: он смотрит на IDE только глазами человека. А что, если следующими пользователями IDE будут не люди, а agent-ы? В компании JetBrains с закатом IDE, естественно, не согласны и предлагают своё видение: среда разработки как набор инструментов и знаний о проекте, доступных AI Agent-у.\n\nКоманда [OpenIDE](https:\u002F\u002Fopenide.ru\u002F) здесь придерживается схожей позиции: мы считаем, что IDE никуда не денется. На данный момент ни один разработчик, которого я знаю, не удалил IDE с рабочего компьютера, хотя agent-ами пользуются уже все или почти все.\n\nНо сегодня поговорим не о том, зачем IDE нужна человеку и почему от неё не отказываются, а о том, зачем IDE нужна agent-у.\n\n\u003Ch3 id=\"ide-for-ai-agent\">IDE for AI Agent\u003C\u002Fh3>\n\n> Сразу договоримся о терминах. Когда я говорю об IDE для AI Agent-а, я имею в виду не среду, в которой человек общается с agent-ом. Не Air, не Claude Code и не очередную chat-панель внутри редактора. Я говорю об Integrated Development Environment в буквальном смысле: о наборе инструментов и знаний о проекте, которыми Agent может пользоваться для решения поставленной задачи.\n\nНа первый взгляд это звучит контринтуитивно. Зачем Agent-у IDE, если он и так неплохо справляется с задачами через `Grep`, `Bash`, `Edit` и `Find`? Но тут полезно вспомнить, как работает обычный разработчик. Когда нужно просто найти строку в проекте, `grep` действительно достаточно. Когда нужно понять связи между классами, пройти по references, безопасно переименовать метод, запустить конкретный тест или посмотреть состояние приложения в debugger-е, мы почти всегда обращаемся к IDE.\n\nС Agent-ами происходит то же самое. Базовый набор tool-ов закрывает простые сценарии, но как только вы захотите научить Agent-а профилировать приложение или дебажить тесты, вам понадобятся новые tool-ы. А к ним сразу понадобятся skill-ы, которые объясняют, когда эти tool-ы вызывать, какие параметры передавать и как интерпретировать результат.\n\nДальше начинается знакомая история. Вы добавляете tool, пишете под него skill, потом ещё один tool, потом ещё один skill, затем чините edge case-ы, обновляете инструкции после изменения API, договариваетесь о формате вывода. Через некоторое время у вас появляется то самое окружение разработки для AI Agent-а. Только теперь его нужно поддерживать: обновлять tools & skills, тестировать, распространять внутри команды, собирать обратную связь и следить, чтобы всё это не превращалось в набор локальных «костылей».\n\nПо сути, IDE всегда решала именно эту задачу: давала готовое окружение под конкретный стек, только пользователем был человек. Теперь тот же вопрос встаёт для AI Agent-а. Можно ли дать ему не россыпь отдельных shell-команд, а полноценную среду с поиском, навигацией, refactoring-ами, запуском тестов и debugger-ом?\n\nЭто направление мы видим одним из ключевых для OpenIDE. Давайте посмотрим, как с этой задачей справляется JetBrains.\n\n\u003Ch3 id=\"ide-native-search-tools\">IDE-Native Search Tools\u003C\u002Fh3>\n\nКогда coding-агентам нужно искать по коду, в подавляющем большинстве случаев они использую shell-инструменты. `grep` и `find` работают, но слепы к структуре проекта, границам символов и семантике языка — agent сжигает токены, просеивая шумный вывод и делая дополнительные вызовы, чтобы сузить поиск.\n\nЧто, если попробовать очевидное и дать агент возможность пользоваться встроенным поиском в IDE?\n\nВозьмем skill от JetBrains, который связывает поисковый промпт с единым MCP-tool; тот, в свою очередь, позволяет выполнять поиск файлов, текстовый поиск, regex и поиск символов.\n\nДля сравнения отслеживаем четыре метрики: quality, latency, cost и budget discipline. Quality показывает, прошли ли все тесты; latency — медиану и P95 времени выполнения задачи; cost — расход токенов, переведённый в доллары; budget discipline — как часто одна задача превышает лимит в $0.50.\n\nКак раз такой тест провели в компании JetBrains, посмотрим на результаты.\n\n#### Результаты\n\nВыбранная конфигурация — готовый search skill, единый IDE-native tool и универсальный router. По сравнению с baseline без IDE-native поиска она снизила latency и cost, при этом quality статистически значимо не изменилась.\n\n![]({{strapiUrl}}\u002Fuploads\u002F070661e1d48f2675938d675604baec9c_d3abb880d2.webp)\n\n**Разница видна по тому, как меняется путь поиска по проекту.**\n\n![]({{strapiUrl}}\u002Fuploads\u002F1ba8c3ecce24f1fe8f9be5af115daee8_bd087dcf71.webp)\n\n#### Cross-Model Validation\n\nУлучшения сохраняются на разных моделях и стеках. Ниже — результаты для GPT 5.4 на Java- и Kotlin-проектах: latency и cost снизились, а сильнее всего cost упал на Kotlin — на 13.48%.\n\n![]({{strapiUrl}}\u002Fuploads\u002Fbc6d84067d68bdfa2e3402a30b841f67_80dfb52f44.webp)\n\n\u003Ch3 id=\"code-coverage\">Code Coverage\u003C\u002Fh3>\n\nРано или поздно, программируя с AI Agent-ом, вы осознаёте необходимость и важность тестов. Естественно, основную массу этих тестов Agent будет писать за вас.\n\nЧтобы понять, куда этот тест положить, Agent-у приходится восстанавливать структуру проекта. Он смотрит имена файлов, проверяет папки, ищет похожие методы и читает соседние тесты — всё ради того, чтобы понять, как в проекте принято тестировать такой код. Токены при этом улетают быстро.\n\nКогда Agent-у нужно добавить тест, вопрос не только в том, что именно проверять. Ему ещё нужно понять:\n\n1. Где в этом проекте обычно лежат тесты на такой код?\n2. Какие существующие тесты уже покрывают соседний код?\n3. Какой testing framework, naming convention и стиль assertion-ов приняты в проекте?\n4. Есть ли уже тестовый файл, который логичнее дополнить, а не плодить новый?\n\nЧеловек часто знает это по опыту или быстро считывает по структуре проекта. AI Agent-у обычно приходится выяснять это более дорогим путём: через поиск, чтение соседних файлов и дополнительные уточняющие шаги.\n\n#### finding-tests skill\n\nЧтобы не собирать этот контекст каждый раз через хаотичный поиск по кодовой базе, JetBrains подготовила новый skill — `finding-tests`. Он поставляется в двух вариантах: как bundled skill для AI Assistant и как отдельный MCP-tool (`findTests`) для внешних agent-ов вроде Claude Code или Codex.\n\nИдея простая: в IDE уже есть мощный coverage analysis. Поэтому, когда AI Agent-у нужно понять, где тестируется тот или иной код, ему не приходится выводить эту связь только из имён папок и результатов поиска.\n\nРазберемся на примере IDE Rider для .Net\n\nRider использует данные о coverage от dotCover, чтобы определить, какие тесты связаны с кодом, над которым работает Agent. Так данные превращается в контекст для AI-сгенерированных тестов.\n\nВот как workflow выглядит под капотом:\n\n- **Агент решает, что нужен тест.** Когда AI пишет новый код, меняет существующее поведение или вы явно просите добавить test, в работу включается skill `finding-tests`.\n- **Rider запрашивает coverage context у dotCover.** dotCover прогоняет тесты из solution и строит coverage data вокруг кода, с которым работает Agent.\n- **Находится правильное место для теста.** Поскольку Rider знает, какие тесты уже покрывают соседний код, он возвращает путь к подходящему тестовому файлу — без ручного поиска по проекту.\n- **Агент следует вашему стилю тестов.** Agent получает нужный файл, читает окружающие тесты и генерирует тест, который вписывается в существующую кодовую базу.\n\n#### Результат: стоимость токенов снижается вдвое\n\nЭто не просто улучшение удобства. Такой контекст заметно влияет и на workflow, и на бюджет.\n\n✂️ **Расходы на токены сокращаются на 50%.**\n\nЕсли сразу передавать Agent-у релевантный тестовый файл, а не заставлять его восстанавливать структуру проекта через поиск, можно заметно снизить расход токенов.\n\nВо внтуренних benchmark-ах JetBrains, **прямой переход к нужному файлу сокращал потребление токенов до 50%.**\n\n![]({{strapiUrl}}\u002Fuploads\u002F322e9db1ac71b5f257ac61f62c64a9f5_e70e27a30d.webp)\n\nПроще всего понять, почему так происходит, на одной показательной траектории. На изображении ниже приведён пример траектории Agent-а для простой задачи в проекте Kavita: добавить coverage для `SeriesExtensions.GetCoverImage` в районе строк 79-80. Модель и кодовая база в обоих вариантах были одинаковыми. Отличался только доступ к Rider coverage context: мог ли Agent перед началом работы спросить IDE, какие тесты уже покрывают этот метод.\n\n![]({{strapiUrl}}\u002Fuploads\u002F19d9308bca996dc677fd69d4dfd96252_7e45b5ef20.webp)\n\nПрофит не только в том, что вы меньше тратите на AI. Для команд с quota-based доступом или общим пулом AI credits это ещё и снижение расходов на поиск и исследование проекта. Значит, большая часть вашего AI бюджета остаётся на более ценные задачи разработки.\n\n\u003Ch3 id=\"profiling\">Profiling\u003C\u002Fh3>\n\nРассмотрим ещё один пример: приложение зависает на десять секунд, и вы спрашиваете AI Agent-а, что пошло не так. Что происходит дальше? Agent анализирует код, строит догадку и приступает к редактированию. Решит ли написанный код описанную проблему? Вероятность примерно 50 на 50: может, решит, а может, и нет.\n\nДля решения таких задач разработчики используют profiler: он позволяет точно понять, куда ушло CPU-время. Однако Agent-у он недоступен. В результате остаётся единственный путь: анализировать проект, находить правдоподобные неэффективности и принимать их за bottleneck. Иногда это срабатывает, но на настоящем freeze — обычно нет.\n\nКоманда Rider предлагает помочь Agent-у, предоставляя profiling skill на базе dotTrace — `dottrace-analyze`. Идея простая: вы отдаёте Agent-у `.dtp` snapshot, уже снятый через dotTrace — standalone profiler, command-line tool или dotTrace внутри Rider, — и вместо анализа исходников вслепую он сначала читает profile. Skill показывает, куда на самом деле ушло время, ведёт hot path обратно в ваш код и объясняет, что тормозит и почему, с рекомендациями, куда смотреть дальше.\n\nДальше приведены результаты benchmark-ов JetBrains по методике LLM-as-judge. Оценивалось, выявил ли Agent основной проблемный участок, объяснил ли механизм проблемы, избежал ли вводящих в заблуждение отклонений и предложил ли исправление, которое следует из имеющихся данных.\n\n#### UI-freeze, который агент не нашёл без dotTrace\n\nОдним из тестовых сценариев была ранняя версия [Avalonia](https:\u002F\u002Fgithub.com\u002FAvaloniaUI\u002FAvalonia), которая зависала при shutdown. Похожая проблема пару лет назад попадала и в сам Rider — хороший пример того, как легко performance degradation из популярных open source проектов может просочиться в ваши приложения.\n\nВ JetBrains специально тестировали версию Avalonia до фикса в [AvaloniaUI\u002FAvalonia#16633](https:\u002F\u002Fgithub.com\u002FAvaloniaUI\u002FAvalonia\u002Fissues\u002F16633). Было важно взять известный, уже исправленный bug, чтобы у eval-а был чистый пример решения.\n\nОдного и того же Agent-а запускали на этой проблеме десять раз со skill-ом и десять раз без него, а затем просили LLM-judge оценить каждый диагноз относительно известной root cause по шкале от 0 до 10.\n\nБез skill-а Agent в среднем набрал **1.6 из 10**. Он уходил в rendering-код, перечислял общие рекомендации и так и не добирался до реальной причины.\n\nСо skill-ом результат был **10 из 10 в каждом из десяти запусков**.\n\n![]({{strapiUrl}}\u002Fuploads\u002Ff675787ec0660e4fafba843aa1195755_0b0b59cd18.webp)\n\nВ результате добавления skill-а мы получили Agent-а, который **стабильно находит** причину проблемы.\n\nПри этом такие проблемы действительно сложно найти простым чтением кода, даже если у вас есть пара свободных часов. Freeze не находился в одном очевидном месте. Он возникал из-за посимвольной операции глубоко в text layout path: сама по себе она дешёвая, но выполнялась столько раз, что съедала большую часть CPU. Эта цена становится видна только тогда, когда понятно, куда на самом деле ушло время. Snapshot привёл Agent-а прямо к проблеме: он объяснил, почему операция оказалась такой дорогой, и указал на изменение, которое её исправляет.\n\n#### Полный бенчмарк: восемь сценариев, 80 запусков\n\nСценарий с Avalonia был лишь одной частью оценки. После повторных запусков набор расширили до восьми сценариев расследования performance-проблем в .NET из разных проектов и сравнили одного и того же Agent-а с доступом к profiler-у и без него. Вот как skill изменил средний показатель точности в каждом сценарии по шкале из 10 баллов:\n\nПо всем 80 запускам средний показатель точности вырос с 4,71 до 8,15. Число запусков с оценкой 8 и выше почти удвоилось — с 29 до 59. Запусков, в которых root cause была определена точно, стало более чем вдвое больше: 48 вместо 20.\n\n![]({{strapiUrl}}\u002Fuploads\u002Fed32381f6c8665d3c869277f508c17d8_7a61caa2c9.webp)\n\nВ этой таблице есть два момента, о которых стоит сказать отдельно.\n\nПервый — skill по настоящему окупается в сценариях, где базовый вариант был безнадёжен. Там, где ответ находился в runtime-данных, например в зависании Avalonia или нагрузке Cyclops, базовый вариант набирал 1–2 балла, а skill поднимал результат до 9 или 10. Agent переставал распыляться на общие идеи оптимизации и удерживался на том, что действительно тормозило.\n\nВторой — нижняя часть таблицы. `game-of-life`, `checkers-copy` и `checkers-update` уже хорошо решались без profiler-инструментов, а в двух случаях с `checkers` skill снизил оценку на несколько десятых. Вывод не в том, что skill ухудшает результаты, а в том, что некоторые задачи в нём не нуждаются. Иногда запускать полноценный profiling workflow там, где достаточно быстро посмотреть на код, — это просто пустая трата токенов.\n\n#### Сколько это на самом деле стоит\n\nНачнём с очевидного: работа с профайлером — это реальная работа. Agent загружает данные profiler-а, проходит по деревьям вызовов и связывает доказательства с исходным кодом, прежде чем перейти к рассуждению. В серии из 80 запусков это отразилось на счёте: стоимость выросла примерно с 1,91 доллара за запуск без skill-а до 2,61 доллара со skill-ом. Общая стоимость серии составила около 153 долларов без skill-а и 209 долларов со skill-ом. Учитывая, насколько улучшилась диагностика, это выглядит как хороший trade-off, но рост затрат реален, и о нём лучше сказать прямо.\n\nНо есть и второй эффект, работающий в обратную сторону. В дополнительном тестовом случае с Avalonia — приложении, которое медленно завершало работу, — Agent без skill-а так и не нашёл настоящую причину. В десяти запусках он снова и снова строил одну и ту же правдоподобную, но неверную теорию, широко искал по проекту и просматривал файл за файлом, каждый раз получая 0 из 10. Со skill-ом он сначала использовал данные profiler-а, сразу вышел на нужный path в коде и получил 10 из 10. Отказ от этих лишних поисковых шагов сделал запуски дешевле и быстрее: 2,58 доллара за запуск вместо 3,74 доллара и 206 секунд вместо 373.\n\nЧестное резюме такое: больше бюджета тратится на работу с profiler-ом, меньше — на исследование тупиковых направлений. Иногда итоговый запуск становится дороже, иногда дешевле, но в обоих случаях вы платите за ответ, основанный на том, что приложение действительно делало. И это, как мне кажется, того стоит.\n\n![]({{strapiUrl}}\u002Fuploads\u002F8f3007407183345b15915bd58d6b596d_98e17c92fb.webp)\n\n\u003Ch3 id=\"zaklyuchenie\">Заключение\u003C\u002Fh3>\n\nРезультаты, полученные JetBrains, похожи на результаты OpenIDE на внутреннем benchmark-е. Как и JetBrains, команда OpenIDE считает направление IDE for AI Agents одним из ключевых. Поэтому набор инструментов OpenIDE, доступных AI Agent-у, будет только расширяться.\n\n[Amplicode](https:\u002F\u002Famplicode.ru\u002F), входящий в базовую поставку [OpenIDE](https:\u002F\u002Fopenide.ru\u002F), уже включает [Spring Skills](https:\u002F\u002Fgithub.com\u002FAmplicode\u002Fspring-skills) и [Spring MCP](https:\u002F\u002Famplicode.ru\u002Fdocumentation\u002Fspring-agent\u002F). Вместе они дают хорошую поддержку для Spring-разработчиков:\n\n- анализ Spring-приложения с учётом архитектуры, в том числе DDD;\n- понимание Spring Data JPA: настройка модели, работа с репозиториями и транзакциями;\n- работа с DTO и мапперами, включая MapStruct и ModelMapper;\n- конфигурация Spring Security;\n- создание CRUD REST и настройка Spring MVC;\n- отладка приложения с помощью Agent-а.\n\nА что дальше? Провести схожие эксперименты на меньших моделях. Гипотеза в том, что они выиграют от IDE-native инструментов ещё больше, поскольку у них меньше встроенных возможностей поиска, на которые можно опереться.\n\nНа текущий момент самые сильные результаты получены для Java, Kotlin и .NET. В планах — расширение набора стеков и поддержка Python, Go и TypeScript.\n\nЧтобы оставаться на связи, следить за новостями и ничего не пропустить, подписывайтесь на [OpenIDE](https:\u002F\u002Fopenide.ru\u002F): в [Telegram](https:\u002F\u002Ft.me\u002Fopenide_official) или на [YouTube](https:\u002F\u002Fwww.youtube.com\u002F@openide).\n\n![]({{strapiUrl}}\u002Fuploads\u002F51a0c031045ccd9b195dfd22176efc53_8a9669b47f.webp)\n\n---\n\n_Впервые опубликовано на [Хабре](https:\u002F\u002Fhabr.com\u002Fru\u002Fcompanies\u002Fhaulmont\u002Farticles\u002F1054434\u002F)._\n",[20],{"title":21,"links":22},"Содержание",[23,26,29,32,35],{"label":24,"href":25},"IDE for AI Agent","#ide-for-ai-agent",{"label":27,"href":28},"IDE-Native Search Tools","#ide-native-search-tools",{"label":30,"href":31},"Code Coverage","#code-coverage",{"label":33,"href":34},"Profiling","#profiling",{"label":36,"href":37},"Заключение","#zaklyuchenie","2026-11-12T11:23:24.703Z","2026-11-13T11:49:13.338Z","2026-11-13T11:49:13.399Z",{"id":42,"documentId":43,"firstname":44,"lastname":45,"createdAt":46,"updatedAt":46,"publishedAt":47,"slug":48,"photo":49},32,"o6vt7fwz9hd363ulcgbilr84","Илья","Кучмин","2026-11-12T11:20:31.602Z","2026-11-12T11:20:50.815Z","ilya-kuchmin",null,{"id":51,"documentId":52,"name":53,"alternativeText":49,"caption":49,"width":54,"height":55,"formats":56,"hash":91,"ext":60,"mime":61,"size":92,"url":93,"previewUrl":49,"provider":94,"provider_metadata":49,"createdAt":95,"updatedAt":95,"publishedAt":95,"focalPoint":49},1213,"qojgmd6wc1err6g928fa626q","cover-jetbrains-ide-budushhee-ne-za-gorami.webp",1671,941,{"thumbnail":57,"small":67,"medium":75,"large":83},{"name":58,"hash":59,"ext":60,"mime":61,"path":49,"width":62,"height":63,"size":64,"sizeInBytes":65,"url":66},"thumbnail_cover-jetbrains-ide-budushhee-ne-za-gorami.webp","thumbnail_cover_jetbrains_ide_budushhee_ne_za_gorami_4220e2df4e",".webp","image\u002Fwebp",245,138,13.4,13398,"\u002Fuploads\u002Fthumbnail_cover_jetbrains_ide_budushhee_ne_za_gorami_4220e2df4e.webp",{"name":68,"hash":69,"ext":60,"mime":61,"path":49,"width":70,"height":71,"size":72,"sizeInBytes":73,"url":74},"small_cover-jetbrains-ide-budushhee-ne-za-gorami.webp","small_cover_jetbrains_ide_budushhee_ne_za_gorami_4220e2df4e",500,282,47.44,47442,"\u002Fuploads\u002Fsmall_cover_jetbrains_ide_budushhee_ne_za_gorami_4220e2df4e.webp",{"name":76,"hash":77,"ext":60,"mime":61,"path":49,"width":78,"height":79,"size":80,"sizeInBytes":81,"url":82},"medium_cover-jetbrains-ide-budushhee-ne-za-gorami.webp","medium_cover_jetbrains_ide_budushhee_ne_za_gorami_4220e2df4e",750,422,100.16,100164,"\u002Fuploads\u002Fmedium_cover_jetbrains_ide_budushhee_ne_za_gorami_4220e2df4e.webp",{"name":84,"hash":85,"ext":60,"mime":61,"path":49,"width":86,"height":87,"size":88,"sizeInBytes":89,"url":90},"large_cover-jetbrains-ide-budushhee-ne-za-gorami.webp","large_cover_jetbrains_ide_budushhee_ne_za_gorami_4220e2df4e",1000,563,169.87,169868,"\u002Fuploads\u002Flarge_cover_jetbrains_ide_budushhee_ne_za_gorami_4220e2df4e.webp","cover_jetbrains_ide_budushhee_ne_za_gorami_4220e2df4e",453.16,"\u002Fuploads\u002Fcover_jetbrains_ide_budushhee_ne_za_gorami_4220e2df4e.webp","local","2026-11-13T11:43:54.145Z",[97],{"id":98,"documentId":99,"title":100,"published":101,"weight":102,"slug":103,"createdAt":104,"updatedAt":105,"publishedAt":106,"color":49},6,"lky7cgb1xah86knhb7cblhsg","Мнения",true,5,"opinions","2026-11-12T11:20:31.505Z","2026-11-12T11:22:44.480Z","2026-11-12T11:22:44.467Z",{"pagination":108},{"page":109,"pageSize":110,"pageCount":109,"total":109},1,25,{"data":112,"meta":131},[113,119,125],{"published_date":114,"id":115,"documentId":116,"title":117,"slug":118},"2026-10-19",343,"rqn2rjpmxlg9cf0v7h7ibddq","Меня заставили использовать OpenSpec","menya-zastavili-ispolzovat-openspec",{"published_date":120,"id":121,"documentId":122,"title":123,"slug":124},"2026-09-29",349,"m4ub2qhs589ts46l90x2sz1y","Режим планирования мёртв","rezhim-planirovaniya-myortv",{"published_date":126,"id":127,"documentId":128,"title":129,"slug":130},"2026-06-25",347,"lpkly83282obll49h6bg6idb","Java против Go в 2026: бенчмарк через шесть лет показал другую картину","java-protiv-go-v-2026-benchmark-cherez-shest-let-pokazal-druguyu",{"pagination":132},{"page":109,"pageSize":133,"pageCount":133,"total":134},3,7,1794584598616]