Вводная

Дорогой читатель лови привет.
Меня зовут Станислав и я не продажник, не разработчик, не учёный, не писатель и тем более не матёрый исследователь. Наверное, по частичке каждого навыка имеется, как и у многих, и мы не будем вдаваться в процентное соотношение каждого — сейчас это не важно. Моё основное направление деятельности — это функциональная архитектура систем и в большей степени PLM. Подходы, которые в ней применяются, можно перенимать, трансформировать и применять в других системах, как и наоборот. Но сейчас речь тоже не об этом, а то мы погрязнем в очередном холиваре и упустим главное.
А для меня сейчас важно пообсуждать идею, ее частичную реализацию и обменяться мнениями по теме.
Статья выросла из серии экспериментов с одним и тем же вопросом: можно ли поручить LLM‑агентам разработку кастомизации под крупную и закрытую PLM систему, так чтобы результат было не стыдно показать заказчику. Короткий ответ: можно. И не потому, что модели стали умнее, скорее потому, что их поместили в контекст и задали нужный вектор. А код стал не целью, а рядовым артефактом процесса.

Для кого эта статья? Да, наверное, для всех кто:

• интересуется темой применения ИИ в промышленных системах,

• решает прикладные задачи,

• думает над вопросами качества и рисками внедрения,

• также как я копается в своей песочнице и хочет сверить часы.

Что внутри

Личный путь от первого агента до фабрики с набором правил, поиском ответов и начальным списком ограничений.
Многие ответы были получены в разное время и местами хаотично. За время поиска менялись агенты, модели, их версии и цена использования. Но до описания всего в одном месте дошёл только сейчас.
Да, статья подвергалась чтению со стороны LLM, но только в качестве, соседа по парте, у которого не замылен глаз и он может посмотреть под разными углами. Задать дополнительные вопросы и подготовить рекомендации, без прямого вмешательства в текст и стилистику.
Погнали!

1. Проблема не в чат‑боте или агенте, а в контексте

Мы явно движемся вперёд, но в каком конкретно направлении — ещё точно неизвестно. Потому как на пути появляются развилки и варианты выбора. Одной из таких опций, на мой взгляд, является оркестрация человеком агентов, которые управляют системами. Причём мне видится, что управлению могут и должны быть подчинены или адаптированы практически все этапы жизненного цикла разработки и/или внедрения такой системы. Однако целиком всё и вся, как мы знаем по опыту, охватить трудоёмко, поэтому предлагаю рассмотреть на одном примере: серверная кастомизация для одной из крупных и развитых с точки зрения функциональности PLM систем.
Многие давно распробовали чаты и сформировали задачи, которые можно им передавать без необходимости перепроверки правды и с заметным повышением скорости получения информации — поиск информации в браузере, например, особенно яркий пример. А вот что касается разработки, то чаты пригодны, но не так быстры и качественны, как агенты. И тут вопрос лежит не в умности, размере или скорости используемой модели, а в том, что агента можно поместить в благоприятный контекст, что позволит повысить качество его работы — иначе говоря, повысить показатели финального артефакта или продукта.
А если разместить агента рядом с закрытой системой, научить его работать со схемами данных этой системы, подсказать, как правильно читать API, или научить, как скомпоновать REST‑запросы для решения конкретной задачи — все это позволит решать следующие задачи:

1. Ускорение проверки теорий и гипотез

2. Выработка правил, которые не нарушат существующую бизнес‑логику предприятия

3. Формирование корректного и реалистичного плана миграции на новую бизнес‑логику и/или систему

4. Снижение зависимости от использования внешних ресурсов

5. Закрытие части дефицита в ресурсах

6. Превращение разработки под систему из «чёрного ящика» в прозрачный, проверяемый и масштабируемый процесс

2. Путь от первого эксперимента

Первым моим вопросом к самому себе был: «А сможет ли агент, обладая лишь набором недокументированных REST‑запросов, разобраться с подключением к системе и определением значений аргументов для последующего запроса?» По опыту одной из прошлых исследовательских задач у меня осталась коллекция запросов в Postman. По логике коллекции выполнялось следующее: Postman, как клиент, логинился в систему, искал данные в системе, создавал внутри новые сущности, если их не было, и перезаписывал параметры, если сущность была.
Я накидал sequence диаграмму так, если бы задачу необходимо было поставить живому разработчику. Накидал входные данные и то, что должно получиться на выходе. Агенту эту информацию не показывал. Запустил агента и ушёл пить кофе и заниматься домашними делами. В тот момент я не понимал, что такое токены, инференс, KV‑кеш, контекст, системный промпт. Тем более не понимал, что за агентом нужно не только проверять результат, но и не доверять стенд полностью! Нет, стенд агент не положил. Но ушёл в циклы и галлюцинации по причине выработки контекста и множественных упаковок мыслей самим агентом. НО!!! в систему он залогинился. И даже нашёл такой запрос, про который я и думать не думал, и не знал.
Я не пошёл по пути формирования системных промптов для агента — не видел в них ценности на тот момент и преследовал цель общения с агентом на человеческом наречии. Также, не делал упор на формировании больших описаний всей задачи сразу. Мне ближе постепенное развитие наработки в процессе диалога. Однако, я точно понял другое: если задачу, её техническую реализацию и функциональную составляющую заставлять агента описывать, и самому(агентом) ещё и проверять — результат с каждой новой сессией становится качественнее. А если, ещё просить фиксировать неудачные моменты и в будущем не использовать такие практики — выдумок, ненужных шагов и галлюцинаций становится меньше.
Есть, конечно, ложка дегтя — появляются новые! И лечится это, по моему наблюдению, более умными моделями и более объёмным контекстным окном. Наверное, есть еще какие‑либо тонкости, только я до них еще не созрел.

Потом я запустил новую сессию агента, уже с расширенными знаниями и моим описанием. Результат был впечатляющим для меня, не побоюсь этого слова. Потому что мне было с чем сравнить. Живой программист (джун, не знакомый с системой) делал похожую задачу больше недели, по крайней мере он так списал время в трекере. Агент, даже с учётом первого захода, сделал за 18 часов, может чуть больше, может меньше. Тем не менее, разница видна: 40>18. Сам код в обоих случаях не смотрел, так как мне в первую очередь важна функциональная сторона вопрос, но есть предположение, что он(код) был бы одинаковым с точки зрения функциональности, качества и стилистики. Скорость исполнении задачи положительно повлияло на мою мотивацию продолжать эксперименты.
Дальше полетело стремительно, и вот краткое описание по верхам:

• Написал простенький плагин к UI на Java. Не «Hello, PLM!», так как агент мог подсмотреть на github, а чуть‑чуть поинтереснее логика. Трудоёмкость этой задачи нет смысла сравнивать с подобной задачей, реализованной человеком. Просто факт: агент написал код, понял как собирать артефакт, опубликовал плагин, зарегистрировал его и предложил мне его проверить примерно за 2 часа.

• Написал серверную утилиту по человеческому ТЗ и без моего вмешательства, так как пока готовил кофе закончился таймаут на ожидание ответов агентом(тут должен быть известный смайлик рука‑лицо). Скорость разработки чуточку выше, по моим субъективным ощущениям над аналогичными задачами, выполняемых человеком. А над качеством и стилистикой есть над чем подумать и что улучшать. Те же 2 часа с написанием, сборкой и публикацией артефакта. Функциональная реализация кода меня устроила полностью.

  

• Написал простенький плагин к UI на AngularJS по задания аналогичному для задачи на java. Боюсь соврать про реализацию, давно было. Пусть будет 4–8 часов, так как агент долго боролся с публикацией артефакта, а потом с дебаггингом в браузере(привет CORS). Однако после документирования всех нюансов первой задачи — все последующие агнет начал печь оперативнее. От 2 часов на задачу.

• И что совсем не ожидал — так это создание прототипа архитектуры для отчётогенератора на Jasper, так как у меня был негативный опыт по схожей задаче год назад от момента возникновения этой. Агент использовал все ранее собранные наработки и документирование прошлых задач и решил, что тут надо по‑взрослому! Он спросил меня только об одном: разработать собственный PDF‑генератор или использовать Jasper. На мой взгляд и не только, отчеты — самый трудоёмкий тип задач для разработчика. Результат меня более чем устроил, так как я получил внешне похожий на ГОСТовский отчет по реальным данным из системы за 1 день, если быть точнее, то за 10 часов. MVP отчета = 10 часов по бланку из стандарта и описанию работы с данными в PLM. И есть ощущение, что за неделю отчет можно причесать до нормального состояния.

Следующей сессией, или даже заходом в тему «PLM + агенты», была попытка внедрить агента внутрь самой системы, как активного помощника для разработки процессов согласования. Прототип сделать получилось, и даже был получен результат. Однако, мои ожидания разбились вдребезги о суровые скалы действительности. А именно: надо понимать, что такое RAG, уметь его строить и применять в нужном месте. И, возможно, делать это в связке с MCP и большим датасетом по различным схемам данных. А это совершенно другой уровень знаний и инфраструктурной обеспеченности. Да и целеполагание должно быть конечным и осязаемым.
Поэтому я взял паузу «на подумать», чтобы понять:

• а что же нужно рынку

• что я упускаю, пока был занят реализацией нишевых задач

• что пишут другие исследователи

Далее, агентские системы обзавелись функциями работы с картинками и планирования. Продолжили развиваться и сокращать бесплатные лимиты. А я перешёл на подписку, изредка думая над вопросом повышения качества кода и занялся собственным проектом по управлению личными финансами. Excel стал сильно тормозить, и понадобилась функция «что произойдёт с моим кэшфлоу, если я внезапно полечу в Мурманск смотреть северное сияние?» или «…, если полечу во Владивосток есть крабов?». Начал описывать архитектуру решения для агентов в ArchiMate — благо, агенты научились классно читать картинки. А также ставить задачи в Obsidian. Дополнительно, в фоне шумел openclaw с его самостоятельностью, непрерывностью и работой в чатах. И я решил попробовать объединить нескольких агентов в одной песочнице с разными ролями. Так у меня получились два репозитория одного и того же решения по управлению личными финансами(оба в альфа версии). Первое написано одним агентом под моим чутким и нежным надзором. Второе, полностью написанное группой из трёх агентов: менеджер, архитектор и разработчик. Оба решения с функциональной точки зрения работают одинаково и имеют схожую архитектуру: клиент, сервер и БД. Разница в UI, так как мой UI выстрадан) И обладая опытом связки нескольких агентов в одной песочнице, задался ещё одним вопросом: «А что если попробовать обкатать такую же технологию для автоматизированной разработки серверной кастомизации для PLM системы?» Ответом на этот вопрос стала схема, которая является центральным звеном данной статьи.

3. Фабрика

При разработке данной архитектурной композиции во главе была мысль о представлении максимально человеко‑независимого контура разработки кастомизации под систему, опираясь на полученные знания и опыт взаимодействия с LLM, агентами и их обвязками. И нельзя не заметить — на схеме это видно: показан коммерческий сервис, потому что мне казалось, что интеграторы или консалтинговые фирмы — первые, кто должен был заинтересоваться. Так сказать, решил сразу показать выгоду. А саму схему легко переработать под разные ситуации:

• перенести в инфраструктуру самого заказчика и удалить ненужные компоненты

• включить отчуждаемый тестовый стенд заказчика в контур разработки исполнителя

• заменить общение заказчика с ботом на живое общение с экспертом или продажником(сейлзом, если хотите) исполнителя.

3.1. Среды контура фабрики

Схема построена вокруг набора изолированных сред, через которые проходит задача:

*‑мое личное видение минимально необходимых конфигураций для запуска фабрики. Среды, как правило, отдельные VM на отдельных нодах, а мессенджер и Git развернуты в Docker на менее загруженной или отдельной ноде.

3.2. Мессенджеры как шина коммуникаций

Ключевое архитектурное решение — агенты и эксперт общаются только посредством мессенджера. Таким образом формируется единая среда коммуникации со всеми подтверждениями, согласованиями, дублированием ссылок на постановку и решение задач, а также фиксацией факта публикации кода в git. Это не просто удобство — это проектное решение. Стоит заметить, что вести разработку под PLM и контроль в мобильном телефоне для меня было в диковинку, несмотря на то, что в банках видел аналогичное, но без применения LLM. Плюс в том, что чат — это еще и журнал сообщений, который служит готовым источником данных для анализа метрик процессов и поиска узких мест.
На схеме приведено два мессенджера для разделения потоков информации — ведь заказчику, в большинстве своём, не так интересны процессы кухни, как интересно само блюдо и время его ожидания.

3.3. Архитектурный фреймворк и Память проекта

Компонент Память проекта была сразу в контуре Фабрики, так как без него сложнее контролировать выполнение задач и делать уточняющие указания по доработке. А вот компонент по Архитектуре был добавлен совсем недавно, так как нашел нужный mcp сервер по работе с Archimate, который меня устроил. Ведь согласитесь, что дать доступ изнутри к схеме позволит быстрее и дешевле оперировать данными, чем читая размытые местами скриншоты. Пусть работа со скриншотами останется для работы над ошибками разработки. Возможно, это покажется дополнительной бюрократизацией, однако, классно же когда 11 человек показывают красивый и слаженный футбол, а не бегают кто‑куда. Вот и я считаю, что разумные правила нужны, и использование Архитектурного фреймворка оправдано.

Ядро фабрики — два независимых, но работающих сообща, хранилища знаний:

• Архитектурный Framework — описание архитектуры решения. Является для агентов и человека истиной во всех смыслах и недоступен для изменения агентами, управляется только человеком.

• Память проекта — декомпозиция и кеширование архитектурных фрагментов в машиночитаемом виде. Может изменяться агентами, но только в части описания состава работ, функциональной и технической реализации, а также документирования развёртывания, настройки, использования и поддержки решения. Также содержит свод правил работы и ограничений при разработке, которые появляются при реализации проекта.

  Note

  Такое разделение снимает главный риск мультиагентной разработки — «плывущий» контекст: агенты могут накапливать и структурировать знания о проекте, но не могут переписывать основные правила игры!

3.4. Песочницы агентов и доступ к системе

Каждый ИИ агент выполняет все действия в своей изолированной песочнице и не может повредить соседние ноды. Для разработки под PLM систему агенты получают:

• Доступ к API системы. На схеме это MCP сервер работы с SOA API — контролируемая точка доступа: чтение API, создание и выполнение запросов. Если по честному, то на момент написания статьи MCP‑сервера для SOA не существует — единственный фантомный компонент схемы. Сейчас хватает коллекции запросов Postman. Для агента создается специализированный пользователь в системе со стандартными правами, которые расширяются по мере освоения новых запросов, которые требуют повышения полномочий

• Изолированный экземпляр PLM‑системы. Который служит для публикации артефакта, выполнения тестирования разработки и предоставления логов для замыкания цикла обратной связи агент‑код/тест‑кейс

• Репозитории. Кодовая база всей разработки с настроенным типовым git процессом: создание репозитория, создание ветки, PR, pull, commit. Причем ни у кого нет прямой записи в main — все записи только через PR с ревью и подтверждением Экспертом из ветки feature.

3.5. Жизнь задачи внутри контура фабрики

Ниже приведено описание работы нескольких агентов от задания до результата:

1. Задание на обработчик приходит агенту через внутренний мессенджер

2. Агент создаёт рабочее пространство и подготавливает состав работ из задания по требованиям Памяти проекта

3. Агент разрабатывает код обработчика и тест‑кейсы к нему, фиксирует результат в репозитории: commit, ветка feature

4. Агент разрабатывает тест‑кейсы по разработанному кода, фиксирует результат в репозитории: commit, ветка feature

5. Эксперт загружает тестовых данных (синтетика, подготовленная под функциональные требования) в изолированный экземпляр системы

6. Агенты выполняют кросс‑проверка кода соседа по утверждённым человеком процессам. Примерные тест‑кейсы агент создаёт сам, финальные дополняет человек по критериям и требованиям задачи, из которых должна родиться богатая библиотека знаний по тестированию системы

7. Агенты выполняют подтверждение изменений кода в ветке feature соседа и создают PR на мердж в ветку test

8. Выполняется функциональное тестирование через API‑запросы

9. Агент читает логи, анализирует ошибки, корректирует запросы и код. Цикл повторяется до прохождения тест‑кейсов.

10. Агенты создают PR на мердж в ветку main

11. Выполняется ручное тестирование Экспертом, подтверждается мержды в main

12. Собирается и публикуется артефакт и результаты тестирования в рабочем пространстве проекта и для передачи

13. Эксперт публикует статус завершения разработки в Общедоступном мессенджере

14. Артефакт передаётся заказчику, приёмочное тестирование — в его среде

15. По завершении проекта выполняется ретроспектива проекта: проблемы, улучшения настроек агентов и процессов, а также что можно вынести в типовые процессы CI/CD

    Note

    Каждый артефакт, предъявляемый заказчику — это результат прохождения всего контура фабрики: разработка кода → разработка тест‑кейсов → проверка тест‑кейсов → проверка качества кода → исправление кода → функциональное тестирование → публикация артефакта и результатов тестирования.

3.6. Эксперт PLM

Эксперт PLM — единственный человек внутри контура разработки. Его функции на схеме:

• аудит процесса и управление процессом

• подтверждение публикаций и слияний веток репозитория

• отслеживание сообщений и публикация статуса

• создание workspace, чтение и изменение состава работ (Память проекта)

• чтение артефактов и уточнение правил и ограничений разработки Эксперт не пишет код. Он создает контекст и граничные условия разработке, и управляет процессами работы агентов.

  Note

  Это не новая штатная единица. Под ролью эксперта могут выступать люди, которые уже есть в команде: руководитель отдела в качестве играющего тренера, архитектор/аналитик системы — при дефиците разработчиков, и сам разработчик, который разбирается в схемах данных и поведении системы. Именно поэтому в разделе про экономику фабрики нет упоминаний про найм — он или уже есть или должен вырасти из существующих ресурсов.

4. Правила игры

Восемь принципов, на которых строилось видение фабрика(возможно они уже встречали по тексту, но считаю показать их еще раз и в одном месте):

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

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

3. Агенты и эксперт общаются только посредством мессенджера, как единого средства коммуникации со всеми подтверждениями, согласованиями и дублированием ссылок постановки и решения задач, а также фактом публикации кода в git. Канал сообщений проекта — информация для анализа метрик процессов и поиска узких мест

4. Агенты выполняют все действия в своих изолированных песочницах и не могут повредить соседние ноды/среды

5. Агенты обладают доступом к API системы, для которой выполняют разработку, и умеют готовить тест‑кейсы для самостоятельной проверки выполнения основных функций по заданию и проверки функциональных ограничений решения. В будущем должны научиться готовить синтетические данные для тестов самостоятельно.

6. Агенты выполняют кросс‑проверки разработок друг друга, как с технической стороны, так и стилистической, и по процессам, утверждённым человеком

7. Все отчёты по процессу должны быть подготовлены и размещены в рабочем пространстве проекта и переданы заказчику

8. В конце каждого проекта обязательно запускается ретроспектива: поиск проблем, предложения по улучшению настроек агентов и процесса разработки, сокращение временных издержек, замена частого использования агентов типовыми процессами CI/CD

9. Сама модель агента в контуре фабрики заменяема, а при локальном инференсе контур становится ещё и автономным

5. Контроль качества: цикл обратной связи

Код при таком подходе — не продукт, а рядовой артефакт правильно выстроенного процесса. Обвязка фабрики строится вокруг 4-х контуров контроля:

• Понимание и применение API, MCP. Позволяет агенту плотно общаться с системой через API и MCP‑сервер, что в сочетании с архитектурными ограничениями дополняет его системный промт

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

• Покрытие функциональных требований ясными и полными тест‑кейсами, что позволяет перезапускать проверку регрессии при каждом изменении кодовой базы

• Кросс‑аудит агентов. Агенты проверяют разработки друг друга технически и стилистически

Намеки на независимую оценка качества. Замерять качество кода я не умею. Были точечные просьбы к знакомым разработчикам оценить результат. Вердикт можно свести к следующим тезисам:

• «код в целом соответствует функциональному требованию, детали не проверял»

• «главное, чтобы код выполнял заложенную логику и покрывал ФТ»

• «брутальный код», чтобы это не значило) Мои изыскания по улучшению качества кода при разработке серверной кастомизации системы ограничились включением готовых линтеров в процесс и они решают: поиск и устранение утечек памяти, удаление неиспользуемых фрагментов, стилистическое выравнивание, улучшение читаемости.

  Просто факт

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

6. Доверие к фабрике и почему это не должно быть так страшно

Основные страхи и риски, на мой взгляд в непредсказуемости результата(ведь LLM прогнозирует вариант решения), сложности и нежелании отладки «чужого» и в том, кто отвечает за то, что написала машина.
Предлагаемая архитектура и подход позволяют, если не полностью снять, то значительно снизить(как бы я хотел проверить этот тезис на реальной задаче) эти риски следующими способами:

• Прозрачность через отчётность, которая фиксирует каждый шаг

• Валидация через эксперта. Человек аудирует, подтверждает и так далее, иначе говоря, контролирует и оркестрирует процесс

• Полноценное тестирование в изоляции до переноса в Продакшн

6.1. Также стоит поговорить про безопасность данных

Весь контур работает на специализированном стенде, где нет реальных данных заказчика — только синтетика.
В случае запрета по правилам ИБ заказчика передачу облачному агенту единичных фрагментов реальной схемы данных, то как вариант можно применить маппинг данных в нейтральный формат. Человек составляет таблицу соответствия объектов и атрибутов (А → AA, Б → AB) и облачному агенту выдается задание в этом нейтральном формате. А таблица соответствия прячется от агента в укромном месте. Обратный перевод кода в «боевой режим» может быть выполнен: вручную или локальным агентом, как в контуре исполнителя, так и в контуре заказчика. Главное условие — соблюдать режим секретности от облачного агента.

Note

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

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

6.2. Юридическая сторона вопроса

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

6.3. Поддержка решения сгенерированного фабрикой

Поддержка артефакта, произведенного такой фабрикой, после передачи заказчику нужна в любом случае! Ведь всегда остаются те самые невидимые 2% случаев, которые: кто‑то не увидел, забыл или которые поменялись извне во время процесса разработки, например, документы регулирующих органов.
И поддержка должна быть законтрактована либо отдельным договором поддержки, либо включена в состав работ текущего оплачиваемого договора.

7. Экономика и масштабируемость

7.1. Из чего складывается себестоимость фабрики

7.2. Сроки запуска фабрики

по моему скромному мнению

7.3. Прочие Ириски

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

2. Переход на модель с очень большим контекстным окном ускоряет потребление квот примерно вдвое — без заметного ускорения или повышения качества разработки. Например, при переходе на модель с контекстом 1M токенов недельная квота закончилась за два дня! Отсюда обязательная практика, как новый ритуал — делай замеры потребления квот и/или токенов перед каждой сменой модели.

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

7.3. Масштабирование фабрики

На текущем уровне доверия фабрика может выполнять одну задачу за заход.
По мере роста доверия (и появления метрик из журнала сообщений и определения достаточности квот), роста прогноза задач, получение реальных трудоемкостей реализации задач и переходе не более квотоемкие подписки или переход на использование LLM по API станет возможным говорить о реальном распараллеливание задач. Многие ко многим, где общая пропускная способность будет равна пропускной способности экспертов.

8. Заключение

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