Обновить

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

Уровень сложностиПростой
Время на прочтение11 мин
Охват и читатели6.8K
Всего голосов 7: ↑6 и ↓1+5
Комментарии19

Комментарии 19

А можно ли делегировать ЛЛМ архитектуру? (провокационный вопрос)

На простых проектах - ТГ бот для опросов, генерации фоток - да, проблем нет.

Если это ТГ бот с разным AI функционалом, сервисами оплат, работа с БД/Celery - нет, он сделает монолит, который не выдержит нагрузки, или который будет крайне сложно масштабировать. Это уже проверенные кейсы.
Или наоборот - сделает сервисную архитектуру для бота с опросами.

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

короче - надо всегда контролировать и НЕ доверять

со статьей выше я согласен почти на 100% (разногласия не существенны, скорее вкусовщина)

А сейчас я как раз разбираю и описываю, что стоит перед Architecture2Doc и Doc2Code. А именно "как собрать архитектуру бизнеса или продукта с ЛЛМ". В общем задача интересная -)

Вот и решил спросить, раз уж тема тут подходящая подвернулась. А какие варианты? Как можно собрать архитектуру с ЛЛМ? или иначе, если нельзя, то почему? что сильнее всего ломает архитектуру, если ее собирает ЛЛМ?

В LLM одна проблема, из которой тянутся все остальные - это РАНДОМНАЯ генерация) мы не можем гарантировать что при одинаковых проектах при одинаковом промпте будет один и тот же результат. может конечно sed зафиксировать, но это уже извращения.

Есть кейс - если прописать круто доки по проекту - то воспроизводимость почти 100%.https://github.com/core-euler/aidd/tree/main/demo/docs такого формата. Но там текста в доках почти столько же, сколько в итоговом проекте строк кода.

Я в прошлом году тоже много об этом думал, разные методики выстраивал, но волшебной палки так и не нашел. скорее всего есть skills, ограничения, которые четко фиксируют требования. Например Emergent же делают рабочие mobile apps по промпту. Значит у них есть отточенная цепочка. Но мобильные приложения и сайты - это часто шаблонные сценарии. Про них достаточного много известно, это самое распространенное в IT, а потому и больше всего положительной практики с примерами

Да меня вот интересует вопрос... Как вайб-кодеру, который сам программировать не умеет и который вчера был маркетологом или стоматологом... Добиться надежности от проекта с ЛЛМ?

Если человек раньше был программистом, то он явно видит, в чем ЛЛМ плоха и подстраховывает ее. И потому все, кто +- понимает в архитектуре, в один голос твердят - не вздумай делегировать это, потом заипешся все это тестировать и переписывать.

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

никак

слишком простой ответ -) Исследовательская занудность "а может все же есть путь?" таким ответом не удовлетворяется -)

Царь Птолемей I спросил Евклида:

— Нет ли более легкого пути изучить геометрию, чем тот, который предлагает Евклид?

На это ученый ответил:

— Нет царских путей к геометрии.

Так же как программисту стать стоматологом или маркетологом - надо изучать и понимать.

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

пока что не придуман адекватный способ "как собрать архитектуру с ЛЛМ". Но это не значит, что его нет. Просто мы все пока смотрим не с того угла на эту задачу

Да, но для ее решения нужны разработчики)

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

вот тут и есть каверзный вопрос и ответ... Но ведь ЛЛМ лучше нашего понимает в архитектуре. То есть сказать, что она не знает азов и правил - точно нельзя. Я с ней советуюсь по куче вопросов.

Не понимает.

...

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

Тут нужно понимать как именно LLM устроены - что такое цепи Маркова и Трансформеры. Если коротко - ответ от LLM зашит в вопросе

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

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

ЛЛМ же может вполне составить программный код на основе того, что ты от нее просишь текстом. Ты сам писал об этом в статье. Нужно описать словами требования, а получишь код.

Вот как выглядел бы такой же алгоритм действий, чтобы она выдала архитектуру? В чем главное отличие подходов к архитектуре человека от того, как с ней работает ЛЛМ? И да, эти отличия есть и кардинальные. Но вопрос в том, как адаптировать процесс под особенности ЛЛМ? и можно ли?

Интересно что фундамент один и тот же, только пришли к нему с разных сторон. У меня не фриланс а продакшн монорепо на 200К+ строк TypeScript, и первой сломавшейся вещью тоже стал контекст. Модель теряет решения не потому что тупит, а потому что нет явного места где написано «вот что нельзя трогать и почему». Spec-driven подход это и решает, у нас оформилось в CLAUDE.md на уровне каждого модуля с архитектурными инвариантами. Особенно согласен про первый тезис про архитектурное мышление, именно так и ощущается смещение фокуса. Руки освобождаются, голова переключается на уровень выше. Любопытно про Skills как стандарт, использую их для ленивой загрузки инструкций под конкретный тип задачи. Как разделяешь Skills и CLAUDE.md в своей методике?

В CLAUDE.md не надо пытаться все закинуть)
Посмотрите на такой пример - это папка .claude в которой прописаны роли, команды, правила - именно в формате skills - для каждого отдельного этапа. Это пример для небольшого бота, но для каждого проекта надо по своему адаптировать

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации