Теперь давайте посмотрим на процесс Агентной разработки и на роль человека в нем, как... LLM. Человек-LLM.

Продолжаем разбираться. Представить человека как еще одну llm-модель, которая при агентной разработке выполняет роль ревьювера и оркестратора "высшего порядка", что бы очень грубо оценить границы возможностей человека и прикинуть, далеко ли моделькам до таких показателей. Честно скажу, что я не llm-инженер, поэтому консультировался по цифрам с самими llm 😅

1. Оперативная память (аналог Фокуса контекстного окна) = 7 +/- 2 объекта (т.е. от 5 до 9 объектов). Автор исследования Джордж Миллер "Магическое число семь плюс минус два". В моделях рабочей памяти "ядро" часто считают ближе к 3–5 чанкам; остальное добирается за счёт группировки и репетиции (что справедливо для работы специалиста с его сферой и цикличным проходом по задаче).
Для LLM - это 50-100 токенов с максимальным весом. 100 токенов (на латинице) - это 2-3 абзаца текста или 15-20 строк кода. Для кириллицы - это будет 1 абзац и 8-12 строчек кода.
В процессе мышления/работы фокус постоянно смещается.

Если представить визуально (тут наверное у каждого по своему, говорю о себе), когда ты строишь в голове модель чего-то, Фокус - это то, что ты "видишь внутренним взором". Из-за того, что этот Фокус ограничен - мы Рисуем модели и схемы. Полный рисунок превращается в контекст, а наш фокус - это некое "пятно внимания" перед глазами.

2. Кратковременная память (Контекстное окно)
Для LLM:
1 мил контекстного окна - эффективное окно рассуждений в диапазоне 200 - 300 тысяч контекста.
200 000 контекстного окна - эффективное окно рассуждений до 50 - 100 тысяч. Дальше повышаются шансы, что модель не учтет часть имеющейся информации. И чем дальше, тем больше.

100 000 токенов - это порядка 250-300 страниц технического текста формата А4. А у человека всего ~7 объектов ? Но есть интересный нюанс, который является главным технологическим ограничителем (на текущий момент). Объекты, с которыми работает человек могут быть почти Любой сложности. Миллер ввел понятие "Чанк".
Условно мы берем 7 объектов, группируем и придаём им новый смысл.. и запоминаем теперь 1 объект (1 смысл). И так может происходить множество раз, зависит от способностей индивида "повышать уровень абстракций".

Приведу очень простой пример такого эффекта:
Не пиши Номенклатура.Наименование - это плохо для производительности.
Не пиши Номенклатура.Код - это...
Не пиши ЗаказКлиента.Сумма...
Таких правил может быть миллион и всё "наизусть не запомнишь", но мы повышаем уровень абстракции: не обращайся через точку к объекту, т.к. это вызывает полное чтение объекта. Профит. Мы агрегировали сотни разрозненных примеров в одну смысловую единицу.
Примерно также выглядит представление архитектора о системе - "мышление блоками" это тоже уровень абстракций.

Мышление абстракциями и моделями позволяет человеку запихнуть в один и тот же контекст больше информации, чем может модель. Компактизации - попытка "закостылить" недостающие возможности. И как часто агент при этом теряет важную информацию. Именно потому, что LLM не умеет формировать абстракции (обобщения).

3. Долговременная память - это "веса модели". Человек учится "онлайн" постоянно. Модель обычно не учится в рантайме (контекст — не обучение); чтобы менять "веса", нужны отдельные дорогие процессы. Зато при наличии ресурсов модели могут перерабатывать огромные объёмы данных очень быстро..

💡 Что мы имеем по итогу?
LLM быстрее, LLM не устаёт, но не умеет мыслить Абстрактно и Модельно. Для этого нужен человек-верификатор, который описывает правила, знания.
Фокус внимания модели больше, чем у человека, но только на первый взгляд (зависит от уровня натренированной абстракции человека).
Вот мы и пришли аргументированно к ситуации, когда в процессе агентной разработки нужен человек, но не любой, а с прокаченным уровнем абстракций и модельного мышления (сеньоры и архитекторы). И он будет нужен до тех пор, пока LLM не научится это делать как следует. Такие попытки есть, но результаты существенно уступают возможностям человека. На долго ли? Время покажет.

Агентный цикл разработки 1С: как масштабировать сеньора

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

ИИ-Техлид (человек) выстраивает рабочий процесс агентного кодинга и развивает его. На текущий момент можно считать, что вся функциональность по работе с 1С, доступная человеку, технически доступна агенту. Проблемы еще будут вылезать, но уже с уверенностью можно сказать что все они решаемы (наработка правил, навыков, воркфло), да и llm не стоят на месте.

ИИ-Аналитик (человек) - работает с бизнес-заказчиком, валидирует ФТ. Ему ИИ помогает исследовать базу, работать с данными… да много чего еще, но никак не заменяет (можно экспериментировать, но я пока не уверен, что получится научить модель относиться к заказчику со скепсисом и не принимать любое требование как закон, помешает текущий стиль обучения.. слишком они привыкли стремиться выполнить любое требование).
В мире 1С чаще всего Аналитик выполняет функцию тестировщика, проводя сценарный анализ. Агент сам выполняет сценарный анализ, но человек его валидирует.

ИИ-Архитектор/Сеньор (человек) - определяет архитектуру приложения, валидирует Техническое задание, проводит код-ревью того, что напишет модель (валидирует результаты агентского ревью).

А отсюда вывод, что не только Джуны, но и мидлы будут не особо нужны, стоит немного подкачаться агентам и их llm.

Выходит те, у кого не хватает знаний и компетенций для работы с ИИ будут существенно уступать своим «ИИ-шнутым» коллегам.
Миф о том, что с ИИ может создавать продукт даже не айтишник - только миф. Но его мы уже рассмотрели отдельно на примере Вайбкодинг vs Агентной разработки (тут будет ссылка на предыдущий пост).

Но подождите... ведь и сейчас Сеньор может выполнить все технические задачи в одно лицо? Сеньор - это узкое место, которое мы расшиваем джунами и мидлами, классифицируя задачи и отдавая им ту сложность, где справится и мидл.. или джун. Это важная точка в рассуждениях, дальше особенно внимательно.

Какие задачи мы отдаем джуну? Не критичные, или те, которые нам не горят, понимая что потом их внимательно перепроверим (процесс обучения).
А какие задачи отдаём мидлу ? Которые не требуют сложных архитектурных решений. За джуном может проверить мидл, за мидлом - сеньор.
А даже если задача требует архитектуру - то Сеньор/Архитектор её обозначает в задаче, а код реализует Мидл.
Сеньор определил ТЗ - выполнил мидл. Сеньор проверил. Ничего не напоминает?
Сеньор утвердил спеку, агент выполнил, Сеньор проверил.

Задача не требует архитектуры? - пусть выполнит мидл или джун. Джун выполнил - мидл проверил.
Задача раскладывается по ролям? Да.

А теперь еще один интересный факт - личное наблюдение, среди 1С комьюнити на текущий момент основных успехов в работе с агентами достигли Тимлиды или Руководители отделов (или ребята, имеющие такой бекграунд). Это специальности, требующие умения формулировать, ставить и проверять задачи. И способные повысить уровень абстракции, описав Как должен выполняться этот процесс.

И мы настраиваем фреймворки, которые выполняют задачу "от и до" сами, либо с участием человека на "чек-поинтах". Мы сразу и в роли ии-аналитика, и в роли ии-сеньора (ведь ии-архитектор должен понимать их всех, что бы автоматизировать).

Как это снова разбить по ролям? Не нужно придумывать велосипед. Старый добрый канбан и очередь задач. Каждая задача выполняется своим сабагентом. Оркестратор обеспечивает её выполнение и первичную верификацию (силами llm). Дальше задача падает человеку и ждет его. Человек пишет замечания и возвращает задачу в очередь предыдущего шага... или "окает" и кладет в следующую очередь.

Это и есть агентный цикл. Агентный цикл разработки на 1С и способ его масштабирования.

А значит, в зависимости от класса задачи найдется место для мидла. Точно найдется.
А для Джуна ? А ведь также и для Джуна. Он сейчас пилит печатки? А будет Валидировать разработку Печаток.
Он сейчас пишет простые отчеты? Значит будет валидировать разработку простых отчетов. И учиться, и набираться опыта.

Идея была в том, что бы проверить влияет ли опыт декомпозиции и постановки задач на осваиваемость ИИ агентов (проще ли с ними работать с таким опытом).

Уберем тех, кто "Просто посмотреть", тогда получим такие доли тех, кто считает, что успешно освоил агентную разработку:
Разработчик: 54%
Архитектор: 11,4%
Тимлид: 1,4% (видимо у нас не очень распространена такая роль)
Руководитель: 18.5%
Не получилось / не понравилось - 10% из голосовавших (но надо понимать, что опрос проводился только в комьюнити про разработку с ИИ, поэтому ожидаемо, что большая часть тех, кто в них состоит и голосовал - справляются с агентной разработкой).

При этом охват был в районе 3000 человек, а проголосовало всего 110 (посмотреть ответы не в счет), т.е. в целом от всего комьюнити освоили агентную разработку около 3%... пусть кто-то поленился отметиться или помешал "синдром самозванца"... но даже 5% - это достаточно мало.

Вернемся к гипотезе про управленческий опыт - средний коэффициент Разрабов к "Управленцам" 5:1 (5 разрабов на одного с опытом декомпозиции и постановки задач). При естественном разделении мы должны были бы видеть 83% разработчиков.
Минимальный порог в районе 3:1, но даже так это дало бы 75% разработчиков.

Если мы возьмем только тех, кто отметился об успешном освоении агентной разработки, то разрабов там 63%, а это коэффициент 2:1, а значит можно сделать, что гипотеза подтвердилась.

Это означает только одно - учиться формулировать свои желания полезно )))

Агентный цикл разработки 1С. Джуны спасены?

Вы согласны с картиной из предыдущего поста? Если "ДА", то мне удалось осознанно завести вас в ловушку.

Мы решили, что джун будет валидировать печатки и простые отчёты. А теперь вспомним, что хорошо собранный агентный фреймворк при соблюдении SDD + TDD работает на уровне мидла, что делает участие джуна в них бессмысленным. В недалёком будущем за счёт развития самих LLM и дистилляции навыков технических специалистов, вполне вероятно, что станет как Middle+.

На чисто кодерских задачах джун проигрывает LLM по скорости и качеству. А задачи, где нужно модельное Мышление в коде (архитектура, сложная отладка, декомпозиция) — требуют уровня мидл+. Между этими двумя полюсами для джуна-кодера — пустота.

А может, сделать из джуна "оператора" агента — пусть формулирует задачи и принимает результат? Звучит красиво, но тут быстро упираемся в ограничения. Чтобы сформулировать задачу — нужно понимать требования (это аналитик). Чтобы принять результат — нужно понимать код (это разработчик). Без этих навыков "оператор" просто жмёт "принять", не понимая что принимает. А чтобы понимать код — нужно учиться его писать. И мы возвращаемся к исходной проблеме.

На этом месте напрашивается жёсткий вывод: джуны не нужны. Но и схема работать "за хлеб" на перспективу... вы уверены, что это будет интересно джунам и что они к вам пойдут? Вырасти из джуна в мидла — это при лучшем раскладе не меньше года, а в среднем два. Два года работать "за еду"?

💡 А может, и "фиг с ними, с джунами"? Будет рост спроса на сеньоров, у нас будут расти зарплаты, а остальное не наша боль? Давайте проведём сценарный анализ, чтобы ответить на этот вопрос.

Сценарный анализ: что будет с рынком 1С-разработки

Продолжим. Давайте посчитаем на пальцах. Берём два типа компаний:
- Тип А — агентная разработка (ИИ-сеньоры + ИИ-мидлы + агенты, ИИ-архитектор строит фреймворк)
- Тип Б — классический подход (сеньор + мидлы + джуны, ручной кодинг)

Считаем на одинаковый объём работ. Классическая команда: сеньор (325к) + 4 мидла (по 225к) + джун (85к) + пара-тройка аналитиков (по 225к) — набегает под ~1 870к/мес на ~9 человек. А теперь смотрите, что даёт агентный подход на ранних фазах (×2 продуктивность): 1 ИИ-сеньор (350к) + 2 ИИ-мидла (по 250к) + те же аналитики + инфра агентов (150к) + ИИ-архитектор (один на компанию, ~75к на команду) = ~6 человек, ~1 640к/мес. Тот же объём — на 12% дешевле и на 3 человека меньше.

Но подождите, 12% — это ерунда, кто ради этого будет перестраивать команду? А вот сроки — это уже другой разговор. Каждая отдельная задача выполняется в 2 раза быстрее. На тендере это звучит так: "Мы сделаем за 2 недели, а не за месяц". Для серьёзных проектов — это критично.

Фаза 1 (1-2 года): Тип А только формируется, подход сырой, экспериментальный. Тип Б стабилен. Джуны приходят, учатся, всё как раньше. Пока ничего страшного.

Фаза 2 (2-4 года): А вот тут начинается самое интересное. Агенты дозрели. Тип А побеждает не ценой, а скоростью + управляемостью. Начинается утечка: лучшие мидлы из Типа Б осваивают агентов и уходят в Тип А как ИИ-мидлы. Мотивация: +30-50% к зарплате (было 225к → стало 300-350к). Важный момент: ИИ — это не повышение грейда, а способ работы. Мидл остаётся мидлом по знаниям 1С, но с агентом его продуктивность ×2. Уходят именно лучшие — костяк команды. А в Типе Б остаются слабые мидлы, немотивированный сеньор, джуны. Качество падает, клиенты уходят.

Фаза 3 (4-7 лет): Тип Б сжимается. И тут парадокс: он всё это время был единственным местом, где выращивались джуны → мидлы → сеньоры. Тип А их не выращивал — переманивал. По сути Тип Б субсидировал обучение кадров для всего рынка за свой счёт. Классическая проблема "безбилетника" (free rider): одни вкладываются в людей, другие потом забирают готовых. Когда Тип Б сжимается — иссякает источник кадров для Типа А.

Фаза 4 (7+ лет): Кадровый кризис. Сеньоры стареют, выгорают, уходят в менеджмент. Новых неоткуда взять. Зарплаты ИИ-сеньоров (600-700к) и ИИ-архитекторов (1000к+) взлетают. Себестоимость Типа А растёт — преимущество тает.

А что с Типом Б? Он мог бы стать конкурентоспособным на этой фазе — ведь зарплаты в Типе А взлетели. Но нет — конвейер уже сломан: джуны не шли в отрасль 5-7 лет, мидлов мало, те что остались — слабые.

Похоже, что в итоге все дороги ведут к гибриду (назовём его Тип В):
- Тип А вынужден строить обучение → становится Типом В
- Тип Б вынужден внедрять агентов → становится Типом В

Кто из них придёт к гибриду раньше и с меньшими потерями — тот и выиграет.

Отдельно про спрос. Тут есть неприятный момент. Когда разработка становится быстрее и дешевле, бизнес "входит во вкус" — начинает заказывать больше доработок, которые раньше "не стоили того". Спрос растёт. Но узким местом станут аналитики: программист с агентом "съедает" задачи от двух аналитиков, а аналитик ускоряется слабо (бизнес-анализ агенту почти недоступен). Рынок перестроится: меньше программистов, больше аналитиков.

💡 Как вам такая картина? Какой сценарий кажется наиболее вероятным именно вам? Или видите иной?

Ручной кодинг как лётный тренажёр

Мы столько всего разобрали, но Главный вопрос так и остался: если гибрид неизбежен — как должно выглядеть обучение джуна?

Тут мы выходим на неприятный, но важный вывод: ручной кодинг всё-таки нужно сохранить. Но не как работу на проекте, а как учебную функцию.

Как лётный тренажёр. На нём не перевозят пассажиров, но без него не будет пилотов. Компания, которая убрала "тренажёр" ради экономии — через 5-7 лет обнаружит, что пилотов нет. И купить их будет в разы дороже, чем стоило содержать тренажёр.

Я к этому пришёл не сразу, но, кажется, вывод один: затраты на джунов в гибридной модели — это не "расход на неэффективного работника", а вложение в людей, которые через пару лет будут тянуть ваши проекты. Как R&D: не приносит прибыли сейчас, но без него нет будущего. И чем раньше компания это поймёт — тем дешевле обойдётся. Потому что потом мидлы и сеньоры будут стоить кратно дороже, а их будет кратно меньше.

Чтобы минимизировать потери на обучении, можно:
- Выделить задачи, где агент наименее эффективен (много итераций с платформой, работа с "грязными" данными, плохо формализуемые требования) — и отдавать их джунам. Разрыв в скорости там минимален, а обучающий эффект максимален.
- Но таких задач немного (10-20%) и с каждой фазой развития агентов их будет меньше.

Есть и другой ход, уже на уровне системы: коллаборация ВУЗов и работодателей. Схема: студент работает на учебных/демо-базах → выполняет задачи → ИИ-агент проверяет и даёт обратную связь → к выпуску студент на уровне мидл-.

Что это даёт:
- Снижение потерь для бизнеса — обучение вне коммерческих проектов
- ИИ-агент как преподаватель — масштабируется, даёт обратную связь мгновенно, не устаёт
- Студент пишет код руками — через набивание шишек формируется модельное и абстрактное мышление
- Компания получает мидл- и может быстро подтянуть его до "продуктивного уровня"

По сути: то, что раньше делала компания за свой счёт (обучение джуна), теперь должен делать ВУЗ + ИИ-агент. А компания доводит оставшиеся 20-30% — адаптацию к конкретным проектам.

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

А что ВУЗы? Зачем им что-то менять?

Объективно: сейчас — незачем. Набирают студентов, учат по программе, выпускают, получают финансирование. Всё работает. Но давайте посмотрим, как это будет выглядеть через пару фаз нашей модели.

Проблема №1: трудоустройство выпускников. Если рынок через 3-5 лет не берёт классических джунов. А мы показали, что не берёт. И практика показывает что репутация ВУЗов как класса учреждений падает, для многих в отрасли "корочка ВУЗа" перестала быть обязательным требованием еще лет 10 назад. С усугублением ситуации — выпускники ИТ-факультетов массово не находят работу. Это бьёт по репутации ВУЗа, по рейтингам, по набору следующих лет. Показатель трудоустройства — один из ключевых для аккредитации.

Проблема №2: конкуренция между ВУЗами. Если один ВУЗ начнёт выпускать "готовых мидл-минусов" с агентным опытом, а другой по-прежнему учит по учебнику 2015 года — студенты пойдут в первый. Абитуриенты голосуют ногами.

Проблема №3: конкуренция с не-ВУЗами. Онлайн-курсы, корпоративные академии. Если буткемп за 6 месяцев даёт "готового к работе" специалиста с агентным опытом, а ВУЗ за 4 года — "теоретика без практики" — зачем идти в ВУЗ?

Но подождите... а зачем ВУЗам делать это самим? Когда дефицит кадров станет острым (фазы 3-4 нашей модели), работодатели сами придут с предложениями: "Мы дадим демо-базы, фреймворки, агентов-преподавателей, экспертов для гостевых лекций — а вы нам готовых людей". Целевые программы, гранты, совместные кафедры. Для ВУЗа это бесплатная модернизация программы + связь с индустрией + трудоустройство выпускников.

И ещё один момент: рынок 1С — значимая часть ИТ-сектора в России, а значит кадровый кризис в нём — проблема уровня министерства. Могут появиться государственные программы, гранты, стандарты. ВУЗы, которые уже встроились в эту повестку — получат финансирование первыми.

Но и тут есть неприятная сторона. ВУЗовская бюрократия. Изменение учебной программы — это долго. Согласования, стандарты, учебные планы. Даже интересно за какое время ВУЗ может "переформатироваться", если очень захочет?

Консервативный сценарий:
- Фаза 1-2: ВУЗы не шевелятся. Отдельные преподаватели-энтузиасты экспериментируют.
- Фаза 2-3: Первые онлайн-платформы и корпоративные академии запускают "агентные программы". ВУЗы чувствуют конкуренцию, но большой разброс качества.
- Фаза 3-4: ВУЗы начинают адаптироваться. Первые совместные программы с работодателями.
- Фаза 4+: Новый стандарт обучения. Но к этому моменту прошло 7+ лет.

ВУЗы опоздают на 3-5 лет. Этот разрыв будут закрывать онлайн-курсы и корпоративные академии. Что, кстати, может быть отдельной бизнес-возможностью для тех, кто сейчас строит агентные фреймворки 😉

💡 Что имеем по итогу с Агентной разработкой в 1С? Агенты вытесняют джунов, а в потенциале и мидлов. Компании, применяющие Агентную разработку, получают преимущество за счет хантинга лучших спецов (так как могут предлагать выше доход) — но через 5-7 лет столкнутся с кадровым кризисом. "Оператор агента" без навыков кодинга — фикция. Ручной кодинг нужно сохранить как тренажёр. А систему подготовки кадров — перестроить через коллаборацию бизнеса и образования. Кто начнёт раньше — тот не будет потом бегать по рынку за сеньорами за миллион. Сеньорам, освоившим агентную разработку это время должно понравиться 😂

Про автоматизацию бизнеса

Этот разговор начался с того, что начали появляться фреймворки для агентной разработки, которые показывают рост эффективности ИТ-специалистов в разы. По сути мы видим автоматизацию через LLM бизнес-функции разработки ПО.

А что мешает аналогично сделать фреймворк для автоматизации задач другого профиля? Маркетинг, Логистика... любая, связанная с работой за компьютером. И проблема "тренажёра" будет актуальна и там.

Фреймворк для Управления контент-маркетингом. Это будет первое, что я буду разрабатывать для своего стартапа. Все принципы ровно те же самые, что в работе с фреймворком 1С:
Набор сабагентов, которые вызываются для своего типа задач. Каждый содержит свои правила и навыки, релевантные для Его задачи. Отдельные стадии "чек-поинты" с человеком-валидатором. Не вижу никаких принципиальных проблем, кроме выбора "лучшей методологии управления маркетингом". А теперь давайте задумаемся: Будет ли принципиально отличаться Механизм агентной автоматизации логиста? Менеджера маркет-плейса? А быть может Юрист или HR? Всё упирается только в навыки и правила... а точнее в их дистилляцию "из носителей компетенций". Если вам кажется, что LLM с чем-то плохо справляется, то только потому, что у неё нет профильных навыков, которые можно обеспечить в агентной системе.

Реальных ограничений у LLM сейчас только два (как это было рассмотрено в посте №3):
- ограниченное модельное мышление
- невозможность построения абстракций высокого уровня (слабое или почти отсутствующее абстрактное мышление)

Ну и ладно, пусть страдает офисный планктон? А мы будем класть плитку, выращивать овощи и заниматься другим ручным трудом. Но и это самообман. Смотрите как сейчас работают агентные системы по написанию кода:
1. Мы даём ей запрос, передаём информацию о навыках, правилах и доступных инструментах (чтение файла, запись файла, вызов внешнего сервиса и т.д.)
2. LLM анализирует доступное окружение и строит план выполнения задачи. Передаёт его "клиентской части"
3. Клиентская часть по указаниям LLM читает файлы, пишет, что-то делает — результаты передаёт LLM.
4. Та даёт новые указания и так, пока LLM не сочтет задачу выполненной.

А теперь "анти-магия":
Вызов инструментов по чтению и записи файлов ничем принципиально не отличается от передачи "команды для манипулятора".
Есть проблемы с помещением мощной LLM в "рабочего робота" (нет места, дорого), однако стоит учесть, что:
А) 50 лет назад компьютер в сотни раз слабее вашего ноутбука занимал места как крупное здание.
Б) Современные беспроводные каналы связи обеспечивают скорость передачи данных, достаточную для удаленной работы LLM и робота.
Большой мозг - на удаленном сервере, агентные системы - устройства, выполняющие команды.

‼️ Я не хочу строить фантастические утопии, я лишь показываю, что применённые принципы автоматизации могут работать и на других направлениях, а значит они столкнутся с теми же самыми проблемами немного позднее... и чем раньше начать их решать, тем менее болезненными они будут.

Интересная статья подъехала :) Как раз в тему всей серии про ИИ.
Для тех, кто не в теме - Карпатый Андрей это один из исследователей и Сооснователей OpenAI

Выделю жирным:
данные с HH, залиты в модель Корпатый. Посмотреть можно вот тут:
https://ai.apigpt.ru/jobs/

Сегодня поговорим на встрече с 1С AI Club о разработке в 1С с ИИ агентами, покажу мой фреймворк и поработаем "онлайн" над одной из задач в нашей учетной системе