Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 27
А можно ли делегировать ЛЛМ архитектуру? (провокационный вопрос)
На простых проектах - ТГ бот для опросов, генерации фоток - да, проблем нет.
Если это ТГ бот с разным AI функционалом, сервисами оплат, работа с БД/Celery - нет, он сделает монолит, который не выдержит нагрузки, или который будет крайне сложно масштабировать. Это уже проверенные кейсы.
Или наоборот - сделает сервисную архитектуру для бота с опросами.
Когда проект сложный - стоит разделять роли для каждого сервиса. Если дать задачу на большом проекте одному архитектору - он захочет упростить, сделает немасштабируемый монолит. Если дать на простом проекте - начнет делать круто, улучшать - сделает микросервисы вообще, ибо это круто.
короче - надо всегда контролировать и НЕ доверять
со статьей выше я согласен почти на 100% (разногласия не существенны, скорее вкусовщина)
А сейчас я как раз разбираю и описываю, что стоит перед Architecture2Doc и Doc2Code. А именно "как собрать архитектуру бизнеса или продукта с ЛЛМ". В общем задача интересная -)
Вот и решил спросить, раз уж тема тут подходящая подвернулась. А какие варианты? Как можно собрать архитектуру с ЛЛМ? или иначе, если нельзя, то почему? что сильнее всего ломает архитектуру, если ее собирает ЛЛМ?
В LLM одна проблема, из которой тянутся все остальные - это РАНДОМНАЯ генерация) мы не можем гарантировать что при одинаковых проектах при одинаковом промпте будет один и тот же результат. может конечно sed зафиксировать, но это уже извращения.
Есть кейс - если прописать круто доки по проекту - то воспроизводимость почти 100%.https://github.com/core-euler/aidd/tree/main/demo/docs такого формата. Но там текста в доках почти столько же, сколько в итоговом проекте строк кода.
Я в прошлом году тоже много об этом думал, разные методики выстраивал, но волшебной палки так и не нашел. скорее всего есть skills, ограничения, которые четко фиксируют требования. Например Emergent же делают рабочие mobile apps по промпту. Значит у них есть отточенная цепочка. Но мобильные приложения и сайты - это часто шаблонные сценарии. Про них достаточного много известно, это самое распространенное в IT, а потому и больше всего положительной практики с примерами
Да меня вот интересует вопрос... Как вайб-кодеру, который сам программировать не умеет и который вчера был маркетологом или стоматологом... Добиться надежности от проекта с ЛЛМ?
Если человек раньше был программистом, то он явно видит, в чем ЛЛМ плоха и подстраховывает ее. И потому все, кто +- понимает в архитектуре, в один голос твердят - не вздумай делегировать это, потом заипешся все это тестировать и переписывать.
А как быть тем, кто раньше в архитектуре ничего не понимал? И кто не в курсе, что нужно вообще делать на сервере, что такое фронтенд и бекенд... Условно как таким пользователям получить "надежный" продукт с ЛЛМ?
никак
Так же как программисту стать стоматологом или маркетологом - надо изучать и понимать.
вопрос в том, что архитектор может вполне решить вопрос маркетолога, через архитектурный подход можно разложить почти все, что угодно. Думаю, что история о вакцине от рака для собаки - неплохой пример. ЛЛМ могут помочь перейти в другой домен знаний, нужно только формализовать методики работы.
пока что не придуман адекватный способ "как собрать архитектуру с ЛЛМ". Но это не значит, что его нет. Просто мы все пока смотрим не с того угла на эту задачу
Да, но для ее решения нужны разработчики)
Возможно когда то они придут к шаблонам внутренних ароматом для безотказной генерации проектов. Но ведь для этого нужно разбираться в архитектуре, что бы знать как ее доносить до LLM
вот тут и есть каверзный вопрос и ответ... Но ведь ЛЛМ лучше нашего понимает в архитектуре. То есть сказать, что она не знает азов и правил - точно нельзя. Я с ней советуюсь по куче вопросов.
Не понимает.
LLM не "понимает" Ничего в привычном смысле этого слова. Это просто набор знаний зашитый в матрицу, а что бы достать нужное знание - нужно корректно задавать вопрос. Что бы получить ответ уровня эксперта р вопрос должен быть соответствующим.
Тут нужно понимать как именно LLM устроены - что такое цепи Маркова и Трансформеры. Если коротко - ответ от LLM зашит в вопросе
я имею в виду, что в ней достаточно знаний по архитектуре. И я вполне уточняюсь у нее по большому количеству аспектов.
То есть сказать, что ЛЛМ не знает ничего про архитектуру точно нельзя. Пусть и не так знает, как знает человек. Но в ней хранятся все те же знания, которые мы используем, и даже гораздо больше.
ЛЛМ же может вполне составить программный код на основе того, что ты от нее просишь текстом. Ты сам писал об этом в статье. Нужно описать словами требования, а получишь код.
Вот как выглядел бы такой же алгоритм действий, чтобы она выдала архитектуру? В чем главное отличие подходов к архитектуре человека от того, как с ней работает ЛЛМ? И да, эти отличия есть и кардинальные. Но вопрос в том, как адаптировать процесс под особенности ЛЛМ? и можно ли?
Так вопрос то изначально был:
который вчера был маркетологом или стоматологом...
Что бы корректно написать запрос на верную архитектуру - надо шарить в архитектуре. Нужно писать словами, требовать код - да, но нужно же знать критерии, что верно, а что нет. Маркетолог и стоматолог этого не зают.
То же самое с архитектурой, даже Джуны в разработке редко работают напрямую с проектированием всего проекта - это уже милы. то есть именно они и будут знать как словами дать запрос в LLM что бы получить корректную архитектуру.
Надо знать как задавать запрос, что бы получать нужный ответ. Разработчик может это сделать. а стоматологу придется изучать сперва вообще как устроены клиент-сервер и http и контейнеры
Интересно что фундамент один и тот же, только пришли к нему с разных сторон. У меня не фриланс а продакшн монорепо на 200К+ строк TypeScript, и первой сломавшейся вещью тоже стал контекст. Модель теряет решения не потому что тупит, а потому что нет явного места где написано «вот что нельзя трогать и почему». Spec-driven подход это и решает, у нас оформилось в CLAUDE.md на уровне каждого модуля с архитектурными инвариантами. Особенно согласен про первый тезис про архитектурное мышление, именно так и ощущается смещение фокуса. Руки освобождаются, голова переключается на уровень выше. Любопытно про Skills как стандарт, использую их для ленивой загрузки инструкций под конкретный тип задачи. Как разделяешь Skills и CLAUDE.md в своей методике?
В CLAUDE.md не надо пытаться все закинуть)
Посмотрите на такой пример - это папка .claude в которой прописаны роли, команды, правила - именно в формате skills - для каждого отдельного этапа. Это пример для небольшого бота, но для каждого проекта надо по своему адаптировать
Покопался. Интересно что воркфлоу прямо командами прописан, /discovery → /plan → /implement, и под каждый этап своя роль. У нас в итоге тоже пришли к разделению на agents/commands/standards, но без явного переключения между этапами, агент сам решал что делать дальше и это иногда вылезало в странных местах. Спасибо за пример, буду смотреть что внутри commands.
Относительно "общаться с LLM на английском " с точки зрения точности: в 2025 году исследование University of Maryland, UMass Amherst и Microsoft показало, что английский всего лишь на шестом месте. Русский, например, его опередил. Так что из-за точности английский нет особого смысла брать.
А вот из-за стоимости - да. Известный факт, что русский более токенов требует, чем английский.
Наконец-то статья, основанная на личном опыте, а не треп со ссылками на общеизвестную терминологию.
Это гарантированный конфликт — пока один пишет, другой меняет под ним основу, архитектор адаптирует доки, а там уже возникли новые ошибки (или наоборот - решения).
Можно, если обоих предупредить о работе другого, но довольно рискованно. У меня работало.
Соблазнительно подумать "запущу пять агентов и буду в пять раз быстрее". Это очень... ПРОБЛЕМАТИЧНО.
Реализуемо, но тогда чаще всего задачи будут разные. Одновременная работа в реалтайм над кодом - да, а если запускать на фоне исследования документов, чужого кода, написание кода по длинному спеку, отчеты, мониторинг CI + фиксы - то почему нет
Хороший контекст не спасёт плохо сформулированный промпт. И идеальный промпт не вытянет, если контекст забит мусором.
Fresh session > Handoff > Compact. Чуть что пошло не так - форкать сессию или в помойку ее.
возможно, MCP-сервер для Figma настроен не оптимально.
get_screenshot вместо get_design_context, но нужны конкретные ссылки на ноды, сама она искать не полезет. Figma MCP вообще помойка, у них такие же проблемы с написанием промптов, как и у всех, кто к MCP был не готов, но сделал, чтобы не отставать от хайпа. Хуже MCP только у Chronosphere из наблюдений.
Готовые из реестров. Имеет смысл искать готовое, прежде чем писать своё, адаптировать под текущий проект, контекст.
Не помешала бы ссылка на сам skills.sh, например
В целом, для меня LLM напоминает пистолет, но выстрел на сессию по сути только один - чем точнее целишься, тем точнее попадаешь. И в своей криворукости кроме себя особо и винить некого.
Я проехался по всем официцальным/платным моделям с момента выхода GPT-3, и, понятное дело, прогресс гигантский, но еще далеко от того, как менеджеры себе представляют - уволняют всех инженеров и пьют коктейли на Гаваях.
P.S.
которые до этого нормально ОТЛИЧНО.
Отлично или все же нормально?
Ох, благодарю за применимый коммент!
Да, если заниматься исследованием кода, структуры, на фазе архитектора - можно и 5 окон открывать.
Про форки сессий - вообще не знал, мощь!
Да, с MCP я пока слабоват. и сами МСР слабоваты пока что.
ОТЛИЧНО - там вообще должно было быть слово "работали"))
Еще раз спасибо за новую инфу)
Я бы сказал, что MCP скорее мертвы, чем живы. Многие кампании сделали миллион тулов и описания к ним, поэтому контекст моментально взрывается. Да, Anthropic "решили" проблему через dynamic discovery, но это подорожник на перелом. Тч пока что Skills на API > MCP. Но и Skills уже становятся проблемой, видел предупреждение о том, что скиллы занимают больше 2% контекста.
Ручной compact/fork - на 120k (12% 1M, ~40% 280k), иначе начинается деградация, которая прогрессирует очень быстро.
Еще небольшой совет по "ускорению" - если не пробовали - попробуйте голосовой набор промпта. WisprFlow, или что найдете для себя рабочее. Поначалу чувствуешь себя как идиот, но потом отлично нормально, заодно навыки эффективного объяснения тренируются.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Очередная методичка разработки с LLM: работает только если ты разработчик