Скажу сразу. Я не ярый фанат или ненавистник LLM-ов. Не считаю что они заберут работу у всех и поэтому нужно остановить/возглавить этот процесс. Я считаю их мощным инструментом. И им, как и многими сложными и гибкими инструментами, нужно уметь пользоваться. Собственно об этом и будет текст
Как я пытался использовать LLM
По началу попробовал пойти в лоб. То есть сказал: "сделай работу с уведомлениями, и чтоб по красоте". В общем поступил как любой уважающий себя проджект менеджер, да простят меня проджекты. Модель написала... какой-то код. Он выглядел нормально, но не делал что мне нужно. Немного по разъясняв задачу, но не получив желаемого, подумал "вот глупая" и бросил это дело
Это была моя первая ошибка. Модель, почему-то, не прочитала мои мысли и, главное, не начала задавать уточняющие вопросы
В следующий раз, когда захотел сделать модель данных и репозиторий, попробовал расписать все что мог: что за данные, зачем они нужны, какие операции с ними будет делать репозиторий. Но описал задачу как хороший заказчик расписывает ее хорошему исполнителю: верхнеуровнего и без лишних деталей имплементации. Модель снова написала... код. Он уже делал примерно то что нужно. Но про что-то забыл, например про обработку ошибок. Другое понял не верно, третье сделал не красиво
Вторая ошибка. Дал LLM слишком много ответственности и свободы. А она работает как хороший начинающий разработчик: пишет приличный код, но не умеет размышлять, продумывать наперёд, смотреть на проблему под разными углами
Получается, LLM нужно сильно ограничивать. Задачи для нее должны быть небольшими и конкретными
Например:
Плохо: Сделай репозиторий для работы с User. Он должен уметь сохранять, обновлять и удалять
Хорошо: Вот тебе интерфейс IUserRepository. Имплементируй его используя Drift и класс AppDriftDb. Назови DriftUserRepository. Файлы с примерами имплементации репозитория и drift table: ...
Во втором промте мы с помощью интерфейса четко описываем что делает репозиторий. Говорим о важных деталях имплементации и, самое главное, даём примеры
К чему я пришёл
Перейдем к заявленной теме. Мой флоу создания приложения, где 90% кода сгенерировано
Шаг 1: Болтаем об архитектуре
Делю приложение на модули. Говорю как они устроены внутри: какие слои используем, как они общаются. Спрашиваю советы у модели. Она, правда, хорошее и плохое во всем найдёт, но ее все равно можно послушать и сделать выбор
На этом этапе важно нарезать приложение таким образом, чтобы каждый слой делал не много и был достаточно простым для понимания джуном. Это нужно чтобы я мог легко описать задачу, а LLM мог легко ее имплементировать. Разумеется важно не переборщить
Дальше прошу сделать summary и сохраняю его в файлик. Я назвал его codestyles.instructions.md. Это архиважный файл. В нем будут храниться все правила проекта. Его буду прикреплять к каждому запросу к модели. И пополнять его правилами когда она будет делать что-то не то. Такие правила есть во всех командах. Их все помнят, но обычно они нигде не прописаны. LLM же не умеет держать всегда все в памяти
Шаг 2: Конкретизирую структуру модулей
Описываю структуру файлов. Как называются и где находятся файлы с моделями, интерфейсами, кубитами, репозиториями и вообще всеми сущностями которые могут быть в проекте
Пишу какие технологии используем: cubit для state management, get it и provider для зависимостей, equatable для моделей и так далее
Задаю подходы: модели имеют copyWith, state cubit-а выглядит таким образом, ошибки всегда возвращаем в Result
Теперь LLM понимает как организовывать код. Если попрошу написать модель пользователя, то хватит перечисления нужных полей. Дальше она сама поймет как назвать файл, куда положить, какой пакет использовать, какие методы добавить. И даже сама build runner запустит, главное упомянуть об этом в инструкции
Шаг 3: "Пишу" код
Самое приятное. Все настроено, LLM знает как писать и осталось лишь попросить
Допустим нужно сделать ленту новостей
Модель данных и Репозитории
Я начинаю "писать" код с них. Прошу сделать модель новости просто перечисляя названия и типы полей. Интерфейс репозитория создаю описывая: его название, в свободной форме методы с аргументами и возвращаемым значениями, и комментарии типо "добавь поддержку пагинации"
Дальше прошу имплементировать репозиторий, например используя Dio. По необходимости, прошу добавить DTO или что-нибудь ещё
State management
Здесь все совсем просто. Зачастую хватает запроса "сделай cubit для NewsRepository". LLM видит его методы и сама понимает что должно быть в состоянии и какие должны быть методы. Это работает так как я использую кубит почти исключительно для отслеживания состояния. Без бизнес логики
Поэтому и хорошо делить приложение на малые части - их очень легко сделать, проверить и изменить. В случае с кубитом нужно проверить лишь state - все ли нужные поля на месте, нет ли лишних. И методы кубита - есть ли обработка ошибок, правильно ли сделана пагинации
UI
Его я делю на 3 части:
View model: содержит все нужные данные и методы для UI. Так он становится полностью независимым от остального кода
Connector: собирает view model и создаёт виджет
Widget: рисует UI на основе view model
С первым и вторым все просто. LLM в легкую пишет view model и connector. А вот UI... Что ж, его она тоже может как-то сделать по скриншоту. Если ещё и хорошенько расписать компоненты и дизайн систему, то получится весьма не дурно. Все равно 20-80% этого кода нужно будет переписать. Но уже хорошо чтобы как минимум чтобы не начинать с чистого листа
Выводы
Качественная база знаний - наше всё. Чем больше правил записано, тем лучше результат
Разделяй и властвуй. Писать в ручную кучу простого кода очень неприятно. Просить LLM писать и редактировать его - другое дело
Теперь я могу тратить свой ограниченный запас энергии гораздо эффективнее. Думать и делать больше, уставать быстрее, но и работать меньше
Мысли о будущем
Казалось бы все хорошо. Но при этом мне и очень грустно. Для меня написание кода - это искусство. Скорее всего, скоро не будет смысла его писать. Код будет скрыт от программиста как сейчас скрыт ассемблер. И тогда программирование станет для меня больше работой чем хобби. Что может и к лучшему
Думаю качество новых программистов и их программ... Останется прежним. Программирование изменится, но суть останется. Вместо написания кода руками люди будут генерировать его. Будут быстрее понимать что пошли в неправильном направлении, быстрее узнавать как можно сделать лучше и соответственно быстрее развиваться. Си не убил программирование, высокоуровневые языки не убили его, фреймворки не убили и это не убьёт