Claude Opus 5, Claude Fable 5, GPT 5.6 Sol, Kimi K3, Claude Opus 4.8, Grok 4.5, Composer 2.5, GPT 5.5, DeepSeek v4, GLM 5.2, Qwen 3.8 Max, Claude Sonnet 5, Mimi 2.5, MiniMax M2.7.
Для тех, кому лень читать до конца, текущий итог:
Заголовок конечно очень похож на классический ИИ SEO слоп, но не спешите закрывать. Анализ вцелом я делал для себя и не претендую на истину в последней инстанции. Просто делюсь вдруг кому окажется полезным.
OpenRouter — самый крупный и известный в мире агрегатор нейросетей. C 26 июля стал пытаться блокировать пользователей из России. В целом, с учетом простоты регистрации и возможностью оплаты криптовалютой — это не такая большая проблема. Но только вот пользование сервисом из 3 букв может добавлять определенные задержки к ping‑у. А если на агрегатор завязано достаточно много сервисов, то сервис из 3 букв должен работать как часы. Эту проблему можно решить именно так, но откровенно говоря ценность OpenRouter как агрегатора в данном случае сводится практически в нулю, поэтому я решил поискать альтернативу — кто уже озаботился решением этого вопроса, попутно получив и другие полезные плюшки, вроде использования российских моделей если в агентах светит 152 ФЗ (строго для этих запросов) и более простой оплаты без переводов на зарубежную карточку.
Для тех, кому лень читать, краткий итог ниже:
Наверное, всем уже очевидно, что ИИ крайне полезен, мир поменялся, нас всех заменят роботы и вообще ИИ уже нас во всём превзошёл.
Всё так или почти так, "но есть одно но" как поётся в одной известной песне. ИИ стоит денег, и весьма немалых при текущих ценах. А про локальные модели для большинства пользователей и компаний в РФ можно забыть. Ну и в целом кажется локальные модели - это не сценарий ИИ будущего.
Соответственно, как мы платим за интернет и за свет - регулярный платёж за ИИ — то, что нам светит в будущем, а большинству уже сейчас. На текущий момент времени расход токенов - пожалуй, самое главное что-тормозит повсеместное внедрение ИИ. Полностью без оплаты конечно не обойтись (нуу почти), но существенно сократить её точно можно. Далее все методы, которые я испробовал и использую за 3 года работы. По убыванию - от самых жестких и очевидных, до самых хитрых и "технологичных".
В статье рассмотрим SDD фреймворки (Spek-Kit, OpenSpec, Kiro, BMAD) и решения не являющиеся полностью SDD, но решающие вопросы упорядочивания разработки с ИИ (Cursor Memory Bank, TaskMaster, Tessl, Supercode, Claude-flow).
Слово "вайбкодинг" в современном мире прижилось плотно, но у большинства разработчиков с опытом вызывает безусловный рвотный рефлекс. С одной стороны ИИ пишет код очень хорошо. Современные модели в алгоритмике уже почти всегда лучше разработчиков.
Но если дело касается большого проекта и Production, всплывают многочисленные проблемы:
В статье приведен результат опроса сообщества 1С разработчиков на предмет применения ИИ в своей текущей деятельности.
На конец 2025 года был проведен опрос сообщества на предмет использования ИИ. Цель — понять какие технологии\модели\подходы\практики обрели популярность.
Какие технологии «прижились» среди 1С разработчиков, а какие пока воспринимаются с опаской. Так получилось, что моя деятельность во многом связана с продвижением ИИ в среде 1С. Так вот, главный интерес заключается в том что получилось а что нет. А может некоторые практики и технологии упущены.
Также достаточно интересно с какой стороны и кто занимается внедрением практик работы с ИИ в компаниях. «Снизу» или «сверху».
Поэтому аудиторию, пожалуй, нельзя считать среднестатистической, хоть попытки и были.
В статье будет рассмотрена большая часть современных агентских IDE которые хоть кто то из знакомых и подписчиков использовал, а именно: Cursor, Kiro, Claude Code (Расширение), Roo Code, Kilo Code, Antigraviry, Cline, WindSurf, Continue, TRAE, Qode, Warp ADE, Zed
Для тех кто не любит читать итоговая табличка конечно же в начале:
В этой части добавил Claude Opus 4.5 и GPT 5.1-Codex-Max
Для тех, кто не любит читать, результат сразу тут:
Обзор сетей и инструментов для Вайб кодинга на 1С. Очередная порция сетей: Claude 4, Grok, Qwen3, Llama4, GPT o3 и 4.1. MCP серверы для Cursor для 1С. Плагин EDT для вайб кодинга на 1С.
В статье кратко на реальных примерах проанализированы возможности генерации кода 1С сетями от Yandex, Sber, Microsoft, Anthropic, DeepSeek, OpenAI, Google
Сразу оговорюсь — статья не является истиной в последней инстанции или какой либо глубокой научной работой, которые вы привыкли видеть для всяких бенчмарках.
Я решал свою исключительно практическую задачу из разряда «лучший код — код который не написан» с уточнением: не написан своими руками.
Своей цели я, к слову, достиг и выводы сделал, ими и делюсь, поскольку всё равно написать надо.
Много деталей приводить не буду — что отвечают нейросети можете проверить сами. Приведу только свои запросы и краткие выводы по ним. Полные выводы можете найти в конце статьи, так что кому нужен итоговый результат — листайте сразу в конец.
Что касается 1С:Напарники. Да, я его потестил. Нет, результаты написать не могу потому что NDA.
Ну и в данном случае не могу даже пожаловаться на политику 1С (хотя в общем и целом постоянные NDA для новых фич в бета сильно раздражают), потому как Напарник проектировался под автодополнение по большей части, а мы будем говорить про кодогенерацию.
Полный код ответа LLM как и скоринг приводить не буду — ибо нет цели написать научный труд. Более того, когда выводы по модели становятся очевидными я прекращал давать ей новые задачи.
Далее — почему задачи все такие алгоритмические и без контекста? Контекст — отдельная задача, главное чтобы сеть умела ориентироваться в алгоритмических задачах и «знать» определенные особенности 1С.
Профессиональная деформация дело серьёзное. Чаще мы говорим про неё в негативном ключе, но в данный статье я собрал принципы которые мне лично в жизни сильно помогают.
И нет, я тут не буду писать про «как мы ставим друг другу задачи в Jira на помыть посуду или погулять с собакой». Речь скорее про принятие решений или использование привычек, приобретенных за время работы в IT сфере. Это сугубо мой опыт и ИМХО конечно, если покажется не релевантным – дизлайк доступен, комменты тоже (лучше комменты :)).
Правило 1. Стоимость владения надо учитывать.
У опытного ИТ директора в "библии" или в "букваре" черным по белому написано: "У любой системы\оборудования\технологии есть стоимость владения". Если вы внедряете систему или онбордите технологию, то для того, чтобы учитывать в бюджете её стоимость, нужно закладывать не только стоимость изначальной покупки, но и стоимость владения технологией ежегодно. В неё обычно входят затраты на обслуживание, поддержку, обновления и подобное.
Чем помогает в жизни:
В жизни мы почему то про этот принцип забываем. А ведь тут то же самое:
Умеете водить машину - надо регулярно водить иначе забудете как
Знаете английский – на нём надо регулярно разговаривать
Знаете C++, но не писали на нём код 3-5 лет… у меня для вас много новостей.
Ну и так далее. Только в отличие от компании у нас бюджет один – время, и он очень ограничен. Так что как пели в старой песне "Думайте сами, решайте сами, иметь или не иметь".
Правило 2. Все ключевые элементы инфраструктуры должны иметь минимум 2-кратное резервирование
Графовые СУБД, пожалуй, одни из самых специализированных хранилищ, существующих на корпоративном рынке. Neo4j при этом яркий представитель этой категории.
C Neo4j я познакомился ещё в далеком 2018-м году, в рамках задачи создания более приятной системы корпоративных знаний чем классические Wiki (некий такой корпоративный Obsidian), ну или основные его части. Это сейчас вы можете радоваться всем благам цивилизации, а в то далёкое время нам надо было очень внимательно относиться к структуре корпоративной базы знаний, т.к. даже поисковые алгоритмы часто оставляли желатель лучшего. Никакого вам ранжирования статей в выдаче по просмотрам и времени создания.
Но в целом с точки зрения базы знаний даже текущие варианты Wiki с ранжированием статей, отображением связанных, последних просмотренных, которые смотрят вместе и т.п. всё равно не решает вопрос оперативного поиска информации. А вот граф - уже другая история. Использовали Obsidian? Понравилось представление информации связанных заметок? Особенно если качественно проставлять связи. Собственно именно таким образом мы обычно и оперируем информацией. Табличная модель конечно удобна, но несколько более синтетическая история, которую придумали чтобы упростить себе жизнь, потому как оперировать графами технически всё-таки более сложная история.
Перед тем как приступать к основной части статьи, наверное стоит начать с вопросов «зачем». В контексте данной статьи их три:
1) Почему Postgres
2) Зачем Public Cloud
3) Почему Yandex.Cloud (в контексте постгреса)
