Пока читал статью, всё чаще приходила в голову сказка про «суп из топора» в части итеративного создания ценности: начинаем с абстракции, постепенно добавляем структуру, контекст, связи.
Проделана серьёзная работа: связки «проблемы модели – причины – решения» описаны верно, очевидно, что Вы и самостоятельно разбирались долго и глубоко, и в диалоге с LLM выясняли их специфику (это заметно). Создать постоянный репозиторий под LLM-задачи – это реально хорошее с практической точки зрения решение.
Но есть момент, который я, возможно, упустил: какова конечная цель этой работы?
«Наведение порядка и устранение хаоса» – это метод, а не цель. Порядок – это отлично, но на практике цель всегда подчинена задаче. Кто или что является «потребителем» этого репозитория, как часто и для каких задач?
Без ответа на вопрос «зачем» даже самая красивая структура рискует стать артефактом, который жалко выбросить, но непонятно, как использовать. Не будем забывать, что создание этого репозитория – не финал. Поддержка актуальности таких систем – отдельная задача и отдельная стоимость.
Если не NDA – опишите, пожалуйста, полностью задачу, которую пытаетесь решить. Это помогло бы оценить не только качество исполнения, но и масштаб окупаемости усилий.
Спрашиваю не из праздного любопытства – просто вижу параллели со своей практикой.
Допускаю, что задача – генерация документации «на лету» в условиях ограниченного инструментария (недоступны ARIS / Sparx EA / Visual Paradigm). Если так – поделюсь своим костылём, который работает.
Мои аналитики чертят подробные BPM/EPC/Sequence с переиспользованием ключевых артефактов, я сохраняю их в XML или mermaid и отдаю в LLM с одним из отлаженных промптов. Эти форматы LLM читают охотно и корректно. На выходе получаю черновики БТ, пользовательских сценариев и даже тест-кейсов. Да, их приходится «причёсывать», но это не написание с чистого листа и время экономит заметно.
Может, такой подход снизил бы нагрузку на поддержку Вашего репозитория?
Знаете, мне не очень интересна судьба подобных управленцев.
А вот судьба ребят, к которым подобные управленцы придут и скажут "я тут прочитал про фабрики агентов, вот тебе 200 баксов на подписку, через неделю жду результат" меня волнует.
Сам бывал в схожих ситуациях на предыдущих "великих сингулярностях"
Пример задачи, которую не решить только подпиской за 200 баксов - привёл.
Владислав, я уже чётко пояснил, что меня триггернуло.
Сколько нам с Вами осталось ждать кого-то из ЛПР, которые придут и скажут "А вот на Хабре написано как закрыть квартальную задачу за 5 дней" (именно так звучит заголовок статьи). Пойди прочитай и сделай".
Недолго. Пользователи с ТЗ, полностью сгенерёнными AI, уже заходят.
Отобьёмся разумеется. Не впервой. Но почему мы вынуждены отбиваться от того, что кому-то пришло в голову хайпануть кликбейтным заголовком ?
Конкретно в этой задаче - весь "ТЗ" - текст закона. От регулятора нет ни Рабочих групп, где можно задать вопросы, ни дополнительных Писем и подзаконных актов. Вообще ничего. Читай и делай.
Это критически мало для запуска любого AI на задачу.
Недавно был отличный разбор темы от Дениса Бескова
Основная опасность этой (и не только этой) статьи не в том, что в ней написано, а именно в том, что в ней не написано. А не написано здесь, как Вы верно заметили, что данный метод релевантен довольно небольшому количеству реальных бизнес-задач.
Проблема современности. Подобные статьи на хорошо индексируемом Хабре читает множество ЛПР и, без явного упоминания ограничений, у них формируется ложное ожидание, что «вот теперь то ИТ-шники наконец ускорятся на 1000…%».
Не ускорятся.
Статьи про «300 агентов написали 30 километров кода за 3 дня» продают инструмент, а ЛПР нужен результат. Но результат в разработке — это не код, а согласованное состояние системы. И тут вступает в силу Закон Каравана. Скорость каравана равна скорости самого медленного верблюда.
Можно разогнать написание модулей и сервисов в 100 раз, но это не ускорит:
- ожидание публикации формата от ФНС (уже полгода ждём, а осталось до старта 3 месяца);
- получение ответов от разработки и техподдержки провайдера ЭДО;
- согласование нюансов организационной работы «костыля» с перевозчиком, у которого «у меня всё в Экселе».
- объяснение юристам, что нужно найти абсолютно легальный способ работы для случая, когда требуется сформировать на одно бизнес-событие два идентичных комплекта документов (это нонсенс, комплект документов должен быть один);
- рефакторинг легаси, где бизнес-правило зашито давно покинувшими нас сотрудниками в название переменной вида if (pogruzka_zavershena == 1) //это важно.
Агенты - это отличный мультипликатор скорости исполнения. Но они не мультипликатор скорости принятия решений. А в сложных интеграциях в энтерпрайзе 80% времени - это как раз второе.
Ирония в том, что чем чаще и громче звучат статьи про «революцию», тем больше времени потом уходит на то, чтобы объяснять ЛПР, почему «всё ещё не готово». То есть хайп не ускоряет, а замедляет разработку за счёт необходимости разгребать завышенные ожидания.
Я не буду принимать пари, однако разверну свой ответ.
Цифры в статье разумеется впечатляют, но они приведены явно для хорошо детерминированной среды. А это далеко не все ИТ-задачи
Интеграция в госсекторе РФ (текущий пример: ФЗ-140, транспорт) - это среда с высокой энтропией, где "поиск решения" является процессом скорее творческим, чем логическим.
Почему "ферма агентов" споткнется о задачу интеграции средней торговой сети прямо сегодня, даже с безлимитным бюджетом токенов:
- Пустой эталон. Один из ключевых документов всей системы - "Экспедиторская расписка". Его формат до сих пор не опубликован ФНС (за 3 месяца до старта). Агент будет тратить итерации на поиск несуществующего формата, а не на логику. Человек в этом месте просто пишет или звонит своему ЭДО-провайдеру или ждет публикации приказа.
- Правовая неопределенность. Часть экспедиторов заявляет, что ФЗ-140 к ним не относится (так как они находятся под Законом о почтовой связи). Это нюанс правоприменения. Агент не сможет самостоятельно обработать ситуацию "закон один, а толкования разные", если ему явно не указать исключения.
- Лоскутная автоматизация. Мелкие перевозчики работают на Excel, у них даже 1С нет. Они готовы подписывать документы, но не генерировать их. Требование "формировать ЭДО" для них технически невыполнимо. Нужен "костыль" (пока непонятно какой, хоть сам за них создавай и давай на подпись), а агенты спотыкаются на разработке обходных путей для случаев отсутствия автоматизации у одного из контрагентов. Даже если агент сможет сформулировать техническое обходное решение - он вряд ли оценит операционные и юридические риски, а также рост стоимости владения за счёт технической поддержки "чужих" решений.
- Юридическая коллизия (B2B-комиссия). Если сеть продает товар юрлицам по агентскому договору, она становится экспедитором для принципала, но сама заказывает перевозку у стороннего экспедитора. На одну физическую отгрузку нужно сформировать два зеркальных комплекта ЭДО с разными ролями. Это требует глубокого контекстного удержания бизнес-схемы, а не просто генерации кода по ТЗ.
- Легаси. "Средняя сеть" - это тонны недокументированного кода на 1С. Агенты отлично пишут новый код на популярных стеках, но очень неуверенно рефакторят чужую бизнес-логику 15-летней давности, где критичные правила "зашиты" в поведении пользователей, а не в коде.
- Взаимное влияние. В этой разработке нужно постоянно держать в уме и проверять пересечение с параллельными ФГИСами - "Честным Знаком" и "Меркурием". Агент по умолчанию может этого не учесть, либо учесть не полностью. Печать 2-х QR кодов, транспортного по ФЗ140 и эВСД "Меркурия" - это именно творческая задача. Нужно их не перепутать.
Резюме: Проблема не в том, что агенты не умеют кодить. Проблема в том, что в таких задачах 80% времени уходит не на написание кода, а на "проинтуичивание" краевых случаев, переговоры и принятие решений в условиях неполных данных.
Пока мы не можем формализовать эти неопределенности во входной промпт, запуск "фермы" - это просто очень быстрый способ сожрать весь бюджет токенов и получить на выходе технический долг.
Это реальная рабочая задача или чисто для примера ФЗ взяли?
Если рабочая - рекомендую всё-же вычитать глазами текст ФЗ, держа схему на втором мониторе.
На собственном опыте, LLM-ки мудрят на текстах ФЗ, и пропуская часть пунктов, и добавляя от себя по контексту. А промпты (если они реальные) у Вас без ограничений.
У меня 3й MX Master. Работаю имено мышью много. Больше половины времени редактирования любого документа, это точно. Специфика - у меня очень много схем.
Что удобно для меня и чем пользуюсь постоянно:
Зум под большим пальцем
Переключение режима скролла
Переключение между компами, у меня 2 ноута и планшет
Весом, размером и точностью - полностью доволен.
Заряжаю крайне редко.
...
Есть один недочёт - "засыпание"
...
Дорого? По мне - нет. Для повседневного интрумента - нормально.
...
В целом я мышом доволен. Не в прям в восторге, но для меня - вполне подходящий продукт.
...
Однако вес ПО просто дикий. И непонятно что там может столько весить
Есть масса нюансов, которые выясняются на практике.
Типовой пример примерно 3-летней давности из того, что помню. Бутылки воды в 1.5 и 0.5 литра одной номенклатуры очень часто распознавалась одинаково.
Выше приведены и другие засады: освещение, двойная съёмка одного объекта с разных ракурсов, частичное перекрытие одного объекта другим, неполные упаковки ...
Пока читал статью, всё чаще приходила в голову сказка про «суп из топора» в части итеративного создания ценности: начинаем с абстракции, постепенно добавляем структуру, контекст, связи.
Проделана серьёзная работа: связки «проблемы модели – причины – решения» описаны верно, очевидно, что Вы и самостоятельно разбирались долго и глубоко, и в диалоге с LLM выясняли их специфику (это заметно). Создать постоянный репозиторий под LLM-задачи – это реально хорошее с практической точки зрения решение.
Но есть момент, который я, возможно, упустил: какова конечная цель этой работы?
«Наведение порядка и устранение хаоса» – это метод, а не цель. Порядок – это отлично, но на практике цель всегда подчинена задаче. Кто или что является «потребителем» этого репозитория, как часто и для каких задач?
Без ответа на вопрос «зачем» даже самая красивая структура рискует стать артефактом, который жалко выбросить, но непонятно, как использовать. Не будем забывать, что создание этого репозитория – не финал. Поддержка актуальности таких систем – отдельная задача и отдельная стоимость.
Если не NDA – опишите, пожалуйста, полностью задачу, которую пытаетесь решить. Это помогло бы оценить не только качество исполнения, но и масштаб окупаемости усилий.
Спрашиваю не из праздного любопытства – просто вижу параллели со своей практикой.
Допускаю, что задача – генерация документации «на лету» в условиях ограниченного инструментария (недоступны ARIS / Sparx EA / Visual Paradigm). Если так – поделюсь своим костылём, который работает.
Мои аналитики чертят подробные BPM/EPC/Sequence с переиспользованием ключевых артефактов, я сохраняю их в XML или mermaid и отдаю в LLM с одним из отлаженных промптов. Эти форматы LLM читают охотно и корректно. На выходе получаю черновики БТ, пользовательских сценариев и даже тест-кейсов. Да, их приходится «причёсывать», но это не написание с чистого листа и время экономит заметно.
Может, такой подход снизил бы нагрузку на поддержку Вашего репозитория?
Знаете, мне не очень интересна судьба подобных управленцев.
А вот судьба ребят, к которым подобные управленцы придут и скажут "я тут прочитал про фабрики агентов, вот тебе 200 баксов на подписку, через неделю жду результат" меня волнует.
Сам бывал в схожих ситуациях на предыдущих "великих сингулярностях"
Пример задачи, которую не решить только подпиской за 200 баксов - привёл.
Да они и не кончатся никогда :))
Механизм утраты критического мышления на всеобщем хайпе многократно описан. Таблеток от этого вроде не продают :)))
Ну количество людей, искренне считающих, что "в интернете врать не будут" пока ещё довольно велико.
И подобные статьи явно провоцируют у многих желание "подсунуть текст закона на вход AI-фабрике и через неделю получить готовую систему".
Добро пожаловать в новый чудный мир :))))
Всё. Мы с Вами вроде на один берег встали, уже отлично.
Владислав, я уже чётко пояснил, что меня триггернуло.
Сколько нам с Вами осталось ждать кого-то из ЛПР, которые придут и скажут "А вот на Хабре написано как закрыть квартальную задачу за 5 дней" (именно так звучит заголовок статьи). Пойди прочитай и сделай".
Недолго. Пользователи с ТЗ, полностью сгенерёнными AI, уже заходят.
Отобьёмся разумеется. Не впервой. Но почему мы вынуждены отбиваться от того, что кому-то пришло в голову хайпануть кликбейтным заголовком ?
Конкретно в этой задаче - весь "ТЗ" - текст закона. От регулятора нет ни Рабочих групп, где можно задать вопросы, ни дополнительных Писем и подзаконных актов. Вообще ничего. Читай и делай.
Это критически мало для запуска любого AI на задачу.
Недавно был отличный разбор темы от Дениса Бескова
https://habr.com/ru/articles/1020406/
Нужна глубокая проработка. Именно она сжирает львиную долю time-to-market.
Я немного ниже отписался на тему того, зачем вообще зашёл тут поотвечать
https://habr.com/ru/news/1040860/comments/#comment_30035236
Извините, не буду повторять свой ответ, опубликованный чуть ниже
https://habr.com/ru/news/1040860/comments/#comment_30035236
Мне показалось :)) Видимо неверно интерпретировал Ваш изначальный вопрос :))))
Сразу захотелось песонализации, типа выставить в приложке свои критерии "комфортности" и "прогулочности"
У Вас нет ощущения, что мы об одном и том же разными словами ?
Отдел фантастики у нас на втором этаже
За "своих" - я спокоен. Но не все ж такие
Ускорять что именно ?
Скорость написания кода на современных популярных стеках ? Да, возможно.
Time-to-market ? В очень ограниченном количестве задач. Если речь о "х1000"
Основная опасность этой (и не только этой) статьи не в том, что в ней написано, а именно в том, что в ней не написано. А не написано здесь, как Вы верно заметили, что данный метод релевантен довольно небольшому количеству реальных бизнес-задач.
Проблема современности. Подобные статьи на хорошо индексируемом Хабре читает множество ЛПР и, без явного упоминания ограничений, у них формируется ложное ожидание, что «вот теперь то ИТ-шники наконец ускорятся на 1000…%».
Не ускорятся.
Статьи про «300 агентов написали 30 километров кода за 3 дня» продают инструмент, а ЛПР нужен результат. Но результат в разработке — это не код, а согласованное состояние системы. И тут вступает в силу Закон Каравана. Скорость каравана равна скорости самого медленного верблюда.
Можно разогнать написание модулей и сервисов в 100 раз, но это не ускорит:
- ожидание публикации формата от ФНС (уже полгода ждём, а осталось до старта 3 месяца);
- получение ответов от разработки и техподдержки провайдера ЭДО;
- согласование нюансов организационной работы «костыля» с перевозчиком, у которого «у меня всё в Экселе».
- объяснение юристам, что нужно найти абсолютно легальный способ работы для случая, когда требуется сформировать на одно бизнес-событие два идентичных комплекта документов (это нонсенс, комплект документов должен быть один);
- рефакторинг легаси, где бизнес-правило зашито давно покинувшими нас сотрудниками в название переменной вида if (pogruzka_zavershena == 1) //это важно.
Агенты - это отличный мультипликатор скорости исполнения. Но они не мультипликатор скорости принятия решений. А в сложных интеграциях в энтерпрайзе 80% времени - это как раз второе.
Ирония в том, что чем чаще и громче звучат статьи про «революцию», тем больше времени потом уходит на то, чтобы объяснять ЛПР, почему «всё ещё не готово». То есть хайп не ускоряет, а замедляет разработку за счёт необходимости разгребать завышенные ожидания.
Я не буду принимать пари, однако разверну свой ответ.
Цифры в статье разумеется впечатляют, но они приведены явно для хорошо детерминированной среды. А это далеко не все ИТ-задачи
Интеграция в госсекторе РФ (текущий пример: ФЗ-140, транспорт) - это среда с высокой энтропией, где "поиск решения" является процессом скорее творческим, чем логическим.
Почему "ферма агентов" споткнется о задачу интеграции средней торговой сети прямо сегодня, даже с безлимитным бюджетом токенов:
- Пустой эталон. Один из ключевых документов всей системы - "Экспедиторская расписка". Его формат до сих пор не опубликован ФНС (за 3 месяца до старта). Агент будет тратить итерации на поиск несуществующего формата, а не на логику. Человек в этом месте просто пишет или звонит своему ЭДО-провайдеру или ждет публикации приказа.
- Правовая неопределенность. Часть экспедиторов заявляет, что ФЗ-140 к ним не относится (так как они находятся под Законом о почтовой связи). Это нюанс правоприменения. Агент не сможет самостоятельно обработать ситуацию "закон один, а толкования разные", если ему явно не указать исключения.
- Лоскутная автоматизация. Мелкие перевозчики работают на Excel, у них даже 1С нет. Они готовы подписывать документы, но не генерировать их. Требование "формировать ЭДО" для них технически невыполнимо. Нужен "костыль" (пока непонятно какой, хоть сам за них создавай и давай на подпись), а агенты спотыкаются на разработке обходных путей для случаев отсутствия автоматизации у одного из контрагентов. Даже если агент сможет сформулировать техническое обходное решение - он вряд ли оценит операционные и юридические риски, а также рост стоимости владения за счёт технической поддержки "чужих" решений.
- Юридическая коллизия (B2B-комиссия). Если сеть продает товар юрлицам по агентскому договору, она становится экспедитором для принципала, но сама заказывает перевозку у стороннего экспедитора. На одну физическую отгрузку нужно сформировать два зеркальных комплекта ЭДО с разными ролями. Это требует глубокого контекстного удержания бизнес-схемы, а не просто генерации кода по ТЗ.
- Легаси. "Средняя сеть" - это тонны недокументированного кода на 1С. Агенты отлично пишут новый код на популярных стеках, но очень неуверенно рефакторят чужую бизнес-логику 15-летней давности, где критичные правила "зашиты" в поведении пользователей, а не в коде.
- Взаимное влияние. В этой разработке нужно постоянно держать в уме и проверять пересечение с параллельными ФГИСами - "Честным Знаком" и "Меркурием". Агент по умолчанию может этого не учесть, либо учесть не полностью. Печать 2-х QR кодов, транспортного по ФЗ140 и эВСД "Меркурия" - это именно творческая задача. Нужно их не перепутать.
Резюме: Проблема не в том, что агенты не умеют кодить. Проблема в том, что в таких задачах 80% времени уходит не на написание кода, а на "проинтуичивание" краевых случаев, переговоры и принятие решений в условиях неполных данных.
Пока мы не можем формализовать эти неопределенности во входной промпт, запуск "фермы" - это просто очень быстрый способ сожрать весь бюджет токенов и получить на выходе технический долг.
Возьметесь закрыть за 5 дней задачу интеграции средней торговой сети с контуром ЭДО в рамках Закона ФЗ140 об электронном документе на транспорте?
Как раз на квартал задачка.
Сколько триллионов агентов Вам для этого потребуется?
Немножко начинает надоедать ежедневно читать на Хабре одно и то же под одними и теми же кликбейтными заголовками.
Извините за резкость
Как минимум, нужна поддержка 4й версии инструментами.
В Archi пока не вижу.
Ну и согласовывать репозитории придётся.
Сами изменения лично мне нравятся
Беспилотные перевозки - не только такси справедливости ради.
По М4 и М12 грузовики ходят беспилотные.
Ну хорошо, ходили полгода назад. Давно там не был, не видел "прямо вчера"
Владимир, я на всякий случай уточню.
Это реальная рабочая задача или чисто для примера ФЗ взяли?
Если рабочая - рекомендую всё-же вычитать глазами текст ФЗ, держа схему на втором мониторе.
На собственном опыте, LLM-ки мудрят на текстах ФЗ, и пропуская часть пунктов, и добавляя от себя по контексту. А промпты (если они реальные) у Вас без ограничений.
Благодарю за совет. Посмотрю обязательно
Не знаю что Вы имеете в виду, говоря о "качестве"
У меня 3й MX Master. Работаю имено мышью много. Больше половины времени редактирования любого документа, это точно. Специфика - у меня очень много схем.
Что удобно для меня и чем пользуюсь постоянно:
Зум под большим пальцем
Переключение режима скролла
Переключение между компами, у меня 2 ноута и планшет
Весом, размером и точностью - полностью доволен.
Заряжаю крайне редко.
...
Есть один недочёт - "засыпание"
...
Дорого? По мне - нет. Для повседневного интрумента - нормально.
...
В целом я мышом доволен. Не в прям в восторге, но для меня - вполне подходящий продукт.
...
Однако вес ПО просто дикий. И непонятно что там может столько весить
Есть масса нюансов, которые выясняются на практике.
Типовой пример примерно 3-летней давности из того, что помню. Бутылки воды в 1.5 и 0.5 литра одной номенклатуры очень часто распознавалась одинаково.
Выше приведены и другие засады: освещение, двойная съёмка одного объекта с разных ракурсов, частичное перекрытие одного объекта другим, неполные упаковки ...
И эти краевые лезут.. лезут.. лезут