Агентный SDLC на внутренней LLM: инженерия вместо промптов

[andreygn]

Статья интересная. Есть что себе забрать.

По сути такая же ситуация. Свой harness, свои модели. Примерно по тем же причинам. Но вот на откуп модели: Оцени сложность - вообще не готов отдать. Даже моделям вроде Fable. Есть на неё у меня подписка. Модель, любая, как junior, пытается срезать углы, в результате упуская. Сам оценивая задачи бывает упускаю что-то (20+ лет в разработке: сеньор/техлид/тимлид - кем только не был). Подсвечивая модели потенциальные подводные камни бывает очень интересное вылезает.

В общем масса сомнений что это у вас работает. Для примера достаточно простая внешне задача. Надо в одну таблицу добавить новое знание. Обновить в другой одно поле - выставить id новой записи из первой таблицы. Микросервис, несколько pods. Во второй таблице несколько миллионов записей. Java/Kotlin Spring и т д. тут все стандартно. Выглядит просто. Ваши варианты решения. 🤔🙂

Замечу. В задаче ни слова о нескольких pods и размерах таблиц.

[kainullov]

Спасибо за комментарий. Согласен, любая модель может показать слабые результаты, да и с грамотным харнесом мы продолжим сталкиваться с проблемами.
При правильной настройке вероятность, что у модели что-то получится, заметно выше. Для любой нетривиальной задачи желательно описать правило - как бы вы сами поступили в этой ситуации. На вашем примере такое описание, оформленное в скилл, направило бы модель. Понимаю, что все не опишешь, но ваш пример выглядит как повторяющаяся задача.
По поводу сомнений вы правы: справляется не всегда, на больших задачах агента приходится вести под руку. И верно: на вашем примере агент решит задачу правильнее, если при передаче задачи добавить дополнительный контекст (про несколько подов и размеры таблиц). Но на небольших задачах классической продуктовой разработки (говорю про мобильную) даже не frontier-модель справляется довольно неплохо: отобразить новый блок с данными на странице товара по определенным условиям, собрать несложный экран с нужным наполнением и логикой взаимодействия, перелопатить беклог с багами.
В любом случае, по моему опыту, стоит начинать добавлять настройки (скиллы, плагины, MCP и т.д.), чтобы команда могла быстрее ориентироваться в проекте и принимать решения: набросать какую-то логику или прикинуть варианты. И уже потом то, что похоже на рутину, пытаться автоматизировать. И еще добавлю: год назад я не думал, что в наших условиях от локальных моделей получится выжать какой-то профит, но тем временем модели в шлюзе становятся только сильнее.