В связи с блокировками мессенджеров
напоминаю, что у данного канала/чата по СППР есть резервный канал
на ЯндексДзен
и чат в МАХ
Пока в Дзен только транслируются посты, а маховский чат чисто резерв,
хотя общаться можно и в Дзене.
Пойдут ли они в ход и где из двух будет активный канал покажет время.

Весьма интересная и короткая статья про пути развития вайб-кодинга.
Ключевые мысли:

1. Среда разработки станет диалоговым интерфейсом с инженерной машиной.

2. ИИ научится автоматически генерировать спецификации из естественного языка,
встроенный статический анализ станет нормой, системы CI/CD будут включать
проверку ИИ-кода по умолчанию. ИИ превратится во «второго архитектора»,
но под контролем человека.

3. Самая коварная проблема vibe coding — иллюзия контроля.
Чрезмерная зависимость от ИИ без понимания основ — путь к потере экспертизы

4. Ссылка на доклад "О проектировании сложных систем в эпоху ИИ"
(Сергей Салищев, кандидат физико-математических наук и старший преподаватель кафедры информатики СПбГУ,
Его работа заставляет по-новому взглянуть на феномен vibe coding —
программирование через диалог с ИИ, которое стремительно меняет нашу профессию.)

Мысли, к которым приводит статья:
Общий тренд - программист всё больше и больше "выжимается" в архитектора (инженера).
Архитектор задаёт правила и рамки, а ИИ - кодит.
Следовательно востребованность систем, хранящих свод правил и контрольные тесты растёт
- а собственно это и должна быть СППР следующего этапа.

На бизнес-форуме 1С по ERP, который пройдёт 20.11.2025,
ожидается анонс по развитию СППР.
В чате СППР был продемонстрирован трейлер решения
с универсальным списком бизнес-процессов в ERP
и автоматическим построением графической иерархической схемы процессов.
Демо сделано на СППР судя по видео.
Весьма впечатляюще.
Ожидаем ответ в частности на такие вопросы:
1. К чему сходится графсхема в своей основе - к метаданным и/или коду?
2. Реально получаем постоянно сопровождаемый 1С детальнейший список бизнес-процессов в ERP?
(ужель даже с привязкой к метаданным?!?!)
Какие ещё вопросы вы хотели бы задать к бизнес-форуму?

Среди ассоциации производителей машин и оборудования
лесопромышленного комплекса тоже востребована экосреда СППР.
Судя по объявленному мероприятию среди ключевых потребностей -
цифровое документирование создания и сопровождения корпоративных систем.

Кто смотрел только что закончившийся вебинар по ERP-tools?
Ваше мнение?

Нужен срочный мозговой штурм - где на форуме 1С ERP может быть речь про СППР

Подозреваемый - секция "Управление ИТ-проектами, внедрение и сопровождение"
Но кто знает, может в секциях по ERP что-то всплывёт.

Интересные тезисы из выступления Нуралиева на бизнес-форуме 1C:ERP 2025

Реально наблюдаем случаи дефолтов-неплатежей, сворачивание программ
автоматизации

Что мешает фирмам-франчайзи развивать бизнес в
текущей ситуации, в чем они видят "узкие места"?
Опрос сентября 2025, 236 ответов -
и, бинго, 103 ответа "Нехватка специалистов"

При этом количество вакансий для "программист 1С упало вдвое в сравнении с 2021 годом

1с рекомендует стоимость часа специалиста среднего уровня от 4000р, а высокого уровня от 5500р
Сейчас час по всем уровням спецев стоит примерно 3-4 тр.

К 1С не поступало запросов на реализацию систем с более чем 30000 пользователей в одной базе.
И запросов на большие масштабы не предвидится.
Вот оценка по стороны ИТ (1С-сферы) масштабов российского бизнеса.

СППР получила в выступлении Нуралиева отдельный слайд и ссылку на отдельное выступление по ней.
Но никакой новой информации слайд не дал - просто описал предназначение СППР для различных видов пользователей.
Самое прикольное, что среди таких групп перечислены Руководители разработки, Разработчики, Техписы, Тестировщики,
а Архитекторы и Аналитики даже не упомянуты.
Символично.

Есть такой "закон Конвея"
Кратко его суть:
Создатель системы (организация) проецирует свою коммуникационную оргструктуру (чтобы это ни значило)
в проектируемую систему.
Наверное, можно это переизложить так: Создатель создаёт своё творение по своему образу и подобию
(уточнение в исходнике по Конвею только по своему коммуникационному образу и подобию - чтобы это ограничение не значило).
Вопрос:
Все кто сейчас проектируют свою "СППР" или доработки к ней не попали уже в ловушку "по своему образу и подобию"?

К предыдущему посту
Есть такой закон Эшби,
его суть кратко: "Разнообразие управляющей системы должно быть не меньше разнообразия управляемой системы"
Из него есть как бы следствие - Закон Седова (закон иерархических компенсаций),
кратко его суть:
"В сложной иерархически организованной системе рост разнообразия на верхнем уровне системы
обеспечивается ограничением разнообразия на предыдущих уровнях, и наоборот,
рост разнообразия на нижнем уровне разрушает верхний уровень организации (т.е. система как таковая гибнет)."

Отсюда можно сделать частный вывод:
Архитектура системы, как более высокоуровневая иерархически система, должна являться ограничением
для уровня кода.
"Архитектура режет код".
Отсюда следствие: программист не должен выходить за ограничения архитектуры, которая строится другими специалистами.
Другими словами: архитектура кода не должна противоречить или расширять границы архитектуры системы, созданной на уровне архитектора.
Вобщем, Архитектура - это ограничения для программиста.
Нарушил ограничения - усложнил систему сверх требуемого и т.п. и т.д.

Похоже вот так выглядит СППР в ближайшем будущем

Внимание, замечено, что бот-охранник в чате (не в канале)
иногда глючит и отправляет новых пользователей в бан
втихую и без всяких оснований (но даёт инфу что имя пользователя найдено в глобальной базе спамеров).
Пока это выявлено на тех кто был в чате, ушёл, а спустя какое-то время вернулся.

Если кто попал под раздачу и в чат не пускает,
напишите админу канала.

PS Чёрных списков за уход из чата/канала нет, это глюк бота.

Обратите внимание на то, что в чате канала сейчас идёт дискуссия по новой разработке СППР от 1С.
И самый интересный аспект - обсуждается проблема проектирования бизнес-процессов на уровне
предприятие-отрасль-инфосистема - о том что на некотором уровне детализации бизнес-процессов
происходит нарушение принципа иерархичности дерева процессов - что делать с дублями БП,
которые возникают при дроблении одного процесса на специфичные для предприятия, отдела.

А ведь это ровно таже проблема что есть у программистов, когда пытаются писать код на
принципах "чистого и глубочайшего микросервиса".
Там ведь тоже, есть абсолютные функции (процессы), вызываемые в высших по иерархии функциях (процессах)
неоднократно, но со своей спецификой при каждом вызове.

Может и решение здесь общее?

Предлагают рассмотреть курс "Архитектор 1С" на 160 часов
(не будем называть компанию дабы это не было рекламой),
при этом в интернете их описание курса говорит о том,
что Архитектор более технический, чем функциональный.
Однако, в программе курсов целый модуль из восьми про моделирование и описание бизнес-процессов
на 1С СППР
3.1. Моделирование и прототипы
3.2. Построение архитектурных схем (домашнее задание почему то архитектура на С4????)
3.3-3.5 Проектирование в 1С:СППР. (аж три темы по Техпроекту в СППР)

СППР становится стандартом знаний для архитектора.

В одном чате на просторах ТГ идёт обсуждение
стоит ли код и конфигурацию 1С грузить в RAG для ИИ.
Там упомянули и СППР в этом контексте.
Насколько понимаю главного инициатора диалога, он
против прогрузки кода и метаданных в RAG,
по мотиву, что это будет беспорядочная и несистемная информация,
которая только запутает ИИ и усилит галюцинации.

Ваше мнение на эту тему?
А загрузка кода и метаданных в СППР превратит информацию в системную?
Или СППР это только предварительная обработка перед передачей материала ИИ?
Или СППР лишняя в этом раскладе?

В связи с развитием технологий ИИ остаётся ли потребность в инструментах
типа 1С:АвтоматизированнаяПроверкаКонфигурации и SonarQube,
которые основаны на алгоритмическом разборе кодовых текстов
с помощью тех же регулярных выражений,
как думаете?

Или работа ИИ всегда должна быть обёрнута в оболочку алгоритмов?

Мысль на подумать:
У 1С есть такой инструмент "Корпоративное хранилище данных" (КХД).
Впрочем, не только у 1С есть.
Так вот, мысль такая:
а что если выгружать конфигурацию и код и прочую архитектурно-техническую информацию,
не в СППР, а в КХД.
По сути, СППР просто хранилище для метаданных, правда, позволяющее привязывать метаданые к требованиям, процессам, функциям.
Конвертировать КХД в векторную форму под ИИ и опять же хранить с последующим наполнением
логичнее чем использовать/развивать узкоспециализированную СППР?
Что думаете?

Ссылка на этот канал, если хотите поделиться с соратниками и коллегами
https://news.1rj.ru/str/+HoOiop970ms2NzI6