Комментарии 19
А можно ли делегировать ЛЛМ архитектуру? (провокационный вопрос)
На простых проектах - ТГ бот для опросов, генерации фоток - да, проблем нет.
Если это ТГ бот с разным 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 зашит в вопросе
я имею в виду, что в ней достаточно знаний по архитектуре. И я вполне уточняюсь у нее по большому количеству аспектов.
То есть сказать, что ЛЛМ не знает ничего про архитектуру точно нельзя. Пусть и не так знает, как знает человек. Но в ней хранятся все те же знания, которые мы используем, и даже гораздо больше.
ЛЛМ же может вполне составить программный код на основе того, что ты от нее просишь текстом. Ты сам писал об этом в статье. Нужно описать словами требования, а получишь код.
Вот как выглядел бы такой же алгоритм действий, чтобы она выдала архитектуру? В чем главное отличие подходов к архитектуре человека от того, как с ней работает ЛЛМ? И да, эти отличия есть и кардинальные. Но вопрос в том, как адаптировать процесс под особенности ЛЛМ? и можно ли?
Интересно что фундамент один и тот же, только пришли к нему с разных сторон. У меня не фриланс а продакшн монорепо на 200К+ строк TypeScript, и первой сломавшейся вещью тоже стал контекст. Модель теряет решения не потому что тупит, а потому что нет явного места где написано «вот что нельзя трогать и почему». Spec-driven подход это и решает, у нас оформилось в CLAUDE.md на уровне каждого модуля с архитектурными инвариантами. Особенно согласен про первый тезис про архитектурное мышление, именно так и ощущается смещение фокуса. Руки освобождаются, голова переключается на уровень выше. Любопытно про Skills как стандарт, использую их для ленивой загрузки инструкций под конкретный тип задачи. Как разделяешь Skills и CLAUDE.md в своей методике?
В CLAUDE.md не надо пытаться все закинуть)
Посмотрите на такой пример - это папка .claude в которой прописаны роли, команды, правила - именно в формате skills - для каждого отдельного этапа. Это пример для небольшого бота, но для каждого проекта надо по своему адаптировать

Очередная методичка разработки с LLM: работает только если ты разработчик