Обзор сетей и инструментов для Вайб кодинга на 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 (в контексте постгреса)

Почему Postgres

              Ну да, казалось бы если речь пошла о cloud инфраструктуре то наверняка о быстром расширении и новом проекте. Postgres появился достаточно давно, может нужно рассмотреть альтернативные решения? Когда я выбираю СУБД для проекта я обычно заглядываю на https://db-engines.com/