Системы как библиотеки

Все больше и больше встречается использование мощной технологии расширений от 1С в корпоративном секторе. Однако, когда речь заходит о масштабных, бизнес-критичных системах, ее применение требует особой «гигиены». Неучтенные нюансы могут создать из суперудобного механизма точки отказа: нарушить и остановить весь бизнес клиента. Рассмотрим технические особенности использования расширений на больших корпоративных продуктивах 1С и выработаем оптимальный сценарий работы с ними. Доклад в виде статьи: https://infostart.ru/1c/articles/2727533/

Юнит-тестирование в 1С – тема, о которой много говорят, но внедряют далеко не везде: для одних это признак зрелой разработки, для других – избыточная формальность или лишняя трата времени. Разбираем, почему классическая пирамида тестирования в 1С часто оказывается перевернутой, какие ограничения накладывает платформа и почему юнит-тесты в реальных проектах нередко смешиваются с интеграционными. Показываем, где юнит-тесты действительно помогают ускорить разработку, упростить проверку логики и повысить качество кода, а где их применение превращается в хрупкую и дорогую поддержку. Отдельно разбираем типичные ошибки: зависимость тестов от данных и окружения, избыточное мокирование, тестирование платформы вместо бизнес-логики и отсутствие негативных кейсов. Доклад в виде статьи: https://infostart.ru/1c/articles/2726730/

Осознанное программирование помогает разработчикам принимать более взвешенные решения, понимать ценность своей работы и снижать вероятность ошибок. Показываем, как этот подход естественным образом сочетается с библиотечным методом разработки, особенно когда стандартных инструментов, таких как БСП, уже недостаточно. На примере создания библиотеки 1С Ozon демонстрируем, как единый компонент может ускорять проекты, повышать качество и уменьшать bus-фактор. Также объясняем, какие практики помогают развивать осознанность в профессиональной деятельности и применять ее в ежедневной работе. Доклад в виде статьи: https://infostart.ru/1c/articles/2724905/

Перегруженные формы в 1С могут превращаться в «стену плача»: пользователи теряются, дольше обучаются, чаще ошибаются и чаще обращаются в поддержку. Разбираем, чем хороший UI отличается от просто «красивого» интерфейса, как UX помогает выстроить понятный пользовательский сценарий и какие стандарты 1С стоит учитывать при проектировании форм. Показываем типичные признаки плохой формы – хаос, перегруз, отсутствие логики и единообразия – и объясняем, как поэтапно привести интерфейс в порядок. На практических кейсах «до/после» показываем, как выделить основной сценарий, убрать лишний шум и сделать формы удобнее для пользователей. Доклад в виде статьи: https://infostart.ru/pm/2724081/

Продолжаю развивать свой Harness для 1С — автономного кодового агента, который работает на локальных нейросетях без облака и без расхода токенов по подписке. В этом видео показываю новый инструмент: MCP-сервер, который ищет по метаданным конфигурации 1С и собирает готовый контекст под задачу разработки. Кодовый агент больше не перелопачивает десятки тысяч строк кода выгруженной ERP — он точечно получает структуру нужного объекта через графовую базу. Разбираю, зачем для автономной разработки в 1С нужен отдельный поиск по конфигурации, чем это отличается от подхода Claude Code, и как новые MCP-инструменты помогают агенту мгновенно находить справочники, реквизиты, табличные части и модули. На живых примерах показываю, как агент находит объекты по синонимам, даже если точного справочника в конфигурации нет. Также обновил локальную модель: теперь на сервере запущена Qwen3 (unsloth, квантование UD-Q8_K_XL, контекст 65k токенов) на связке видеокарт RTX 3090 + RTX 5070 Ti — это максимально близко по качеству к оригинальной модели. Инструмент позволяет кодовому агенту точно знать структуру метаданных конкретного объекта: реквизиты и их типы, ссылочные типы, перечисления, табличные части, модули. Это ускоряет и планирование, и саму доработку конфигурации. Пишите в комментариях, что ещё стоит добавить в такой инструмент, чтобы кодовый агент в 1С работал лучше. Свои мысли по развитию у меня есть, но обязательно учту ваши замечания.

Показываю свой MCP сервер контекстных подсказок 1С для кодового агента — он работает на полностью локальной нейросети, без интернета и утечки исходников. Вайб-кодинг в 1С на домашнем железе: две видеокарты RTX 5070 Ti, модель Qwen3 на 27 млрд параметров, квантование NVFP4 и контекст 64 000 токенов. Главная проблема разработки на 1С в том, что почти ни одна нейросеть толком не знает язык 1С — даже топовые модели Claude, OpenAI, часто ошибаются. Чтобы это обойти надо подавать кодовому агенту качественный, максимально сжатый контекст. Мой MCP сервер берет справку 1С, делает собственный поиск и через инструмент Research возвращает агенту только нужные типы, методы и свойства. В результате локальная модель пишет рабочий код 1С и почти не выдумывает несуществующие методы. В видео на живых примерах: обработка загрузки текстового файла и функция POST запроса к HTTPS сервису с защищённым соединением, обработкой исключений и логированием в журнал регистрации. Скорость генерации 71-73 токена/сек при максимальном качестве ответа. В итоге, связка локальная нейросеть + MCP сервер контекста 1С уже сейчас даёт быстрый и аккуратный код без отправки исходников в облако. Дальше - единый продукт для автономной разработки 1С. В следующих роликах: добавление третьей видеокарты, домашний AI-сервер и запуск Qwen3 27B на максимальной скорости с контекстом 256 000 токенов. Где взять итоговый продукт — расскажу в следующих уроках.

После замены устаревшего Java-модуля и реализации высоконагруженного биллинга на 1С 8.5 система обрабатывает более 1 миллиарда событий в месяц, формирует около 3 миллионов актов для 700 тысяч клиентов и работает в inFrame-режиме внутри корпоративной ERP. Разбираем архитектуру решения: слои данных, ретроспективность, drill-down до первичной операции, многопоточный конвейер, RabbitMQ, REST API, Grafana, партиционирование и охлаждение данных. Объясняем, почему именно архитектура данных стала ключом к производительности, масштабируемости и устойчивости системы. Доклад в виде статьи: https://infostart.ru/pm/2718550/

Показываем, как встроить ИИ-помощника в code review 1С без Git, SonarQube и EDT – только с Конфигуратором, RAG-контекстом и набором MCP-инструментов. Разбираем архитектуру решения на Open Web UI и OpenRouter, методику сравнения моделей по Precision, Recall, BonusRate и PenaltyRate, а также объясняем, почему контекст влияет на качество ревью сильнее, чем выбор самой модели. На реальных примерах показываем, какие ошибки ИИ находит хорошо, где все еще нужен архитектор и почему на старте пилота время ревью может не сократиться, а вырасти. В финале делимся метриками внедрения и выводами для команд, которые хотят повторить такой подход у себя. Доклад в виде статьи: https://infostart.ru/1c/articles/2718024/

Разбираемся, почему ИИ-агенты теряют контекст, путаются в инструментах и возвращают неполный результат, если всю задачу пытаться решить одним большим промптом. Показываем, как цепочки пошаговых промптов помогают сделать работу агента повторяемой: каждый шаг выполняет одно действие, имеет понятный вход и выход, отдельно проверяется и при необходимости исправляется. Объясняем, как применять этот подход в задачах 1С: анализировать действия пользователя, подбирать инструкции через RAG, работать с журналом регистрации, MCP-инструментами и локальными моделями. На примерах показываем, как снизить непредсказуемость ИИ-агента и превратить его из «угадывающего помощника» в надежный инструмент для бизнес-процессов. Доклад в виде статьи: https://infostart.ru/1c/articles/2713194/

Кажется, что code-review с помощью искусственного интеллекта устроено просто: достаточно отправить код в LLM, задать промт и получить список замечаний. На практике такой подход быстро упирается в недетерминированность результата, неверную оценку критичности ошибок в 1С-коде и рекомендации, которые сложно отличить от полезных замечаний. Описываем гибридный подход к автокод-ревью: статический анализатор работает вместе с LLM, а база знаний из стандартов 1С превращается в набор машиночитаемых норм. Такая архитектура помогает снизить количество галлюцинаций, точнее определять критичность нарушений и постепенно развивать качество ревью через итеративное пополнение правил. Доклад в виде статьи: https://infostart.ru/1c/articles/2711380/