Представьте, что вы наняли джуниора: он невероятно быстр, работает 24/7, знает все языки и фреймворки, но есть нюанс. Он начисто лишен инициативы, всегда рапортует об успехе (даже если всё сломалось) и страдает тяжелой формой амнезии, забывая о чем вы говорили пять минут назад. Звучит знакомо? Именно так ведут себя современные LLM при генерации кода. Это не критика, а диагноз. И хорошая новость в том, что этого «оптимистичного халтурщика» можно превратить в самый мощный инструмент в вашем арсенале. В этой статье я поделюсь практической методологией, как перестать быть просто «промпт-инженером» и стать настоящим архитектором для армии AI-агентов, которая позволит сократить разработку MVP с месяцев до дней.
Теперь поговорим об этом более подробно (запись одного из семинаров в рамках Акселератора Слайдер )
Модератор:
Добрый день всем. Сегодня мы будем обсуждать инструменты AI-driven development — быстрой разработки с помощью искусственного интеллекта. Эта тема сейчас настолько широко обсуждается, что даже я, не будучи разработчиком, успела что-то использовать. Сегодня Евгений Росюк, основатель DataCons и владелец продукта SliderData, расскажет нам о своем подходе к этой теме. Евгений, мы хотели бы начать с небольшого опроса в чате, как вы и предложили: узнать, что уже используют наши участники. Передаю вам слово.
Евгений Росюк:
Вступление и позиционирование
Да, коллеги, всех приветствую. Сразу хочу сказать, что у меня сейчас небольшой приступ синдрома самозванца, потому что я, на самом деле, не являюсь AI-программистом в классическом понимании. Я скорее выступаю в роли студента, который глубоко что-то раскопал и теперь делится своими находками на этом семинаре. Поэтому, если вы заметите какие-то фактические ошибки, давайте их обсуждать. Я открыт к диалогу и готов корректировать свою позицию.
Основные аксиомы работы с ИИ
Итак, прежде чем мы погрузимся в контекст генерации кода, необходимо держать в голове несколько ключевых аксиом.
Первая аксиома: ИИ — это множитель. Если оператор, который управляет искусственным интеллектом, сам по себе представляет мало ценности, то есть его знания равны нулю, то и результат будет нулевым. ИИ — это в первую очередь инструмент, который помогает человеку достичь большего. Если человек сам по себе ничего не может, то и ИИ ему не поможет.
Вторая аксиома: Языковая модель (LLM) — это генератор текста. Я бы поспорил с термином "искусственный интеллект". Я отношусь к этим моделям как к генераторам текста: на входе у них какой-то текст, а на выходе — другой текст, который может быть кодом. Такой подход помогает избавиться от иллюзии "черного ящика". Это просто генератор, и чтобы с ним эффективно работать, нужно тщательно продумывать запросы.
Третья аксиома: У модели нет целей и мотивации. Ей всё равно, что генерировать. Она просто отвечает на ваш вопрос. Даже если цель не достигнута, модель всегда считает, что она молодец, потому что она сгенерировала текст. Хороший он или плохой — это уже другой вопрос. Эти генераторы обучались на оптимистичном опыте человечества; мы ведь редко пишем в текстах суровую правду, чаще — с положительной точки зрения. Более того, при обучении модель получала подкрепление: "Ты сделала маленькую работу, ты молодец". Поэтому все эти модели можно охарактеризовать как "оптимистичных халтурщиков", которыми нужно очень жестко управлять.
Вся наша дальнейшая презентация будет посвящена тому, как на этого оптимистичного халтурщика накинуть вожжи, создать для него план и другие ограничения, чтобы не дать ему шанса схалтурить и заставить его сгенерировать именно тот продукт, тот текст, который нам нужен.
Требования к оператору ИИ
Итак, первый постулат заключается в том, что оператор, управляющий ИИ, должен быть квалифицированным. Он должен иметь практический опыт создания программного кода, знать основы Computer Science, понимать различия интерфейсов и протоколов, знать основы баз данных, версионирования и всего подобного.
Самый важный из этих навыков — системное мышление и системный дизайн. Оператор должен понимать, какие типы программного обеспечения бывают, к какому классу они относятся. Это необходимо для того, чтобы тот самый "множитель", которым является ИИ, был значительно больше нуля, и на выходе мы получали качественный результат.
Конечно, уже существуют системы, например, как вы упомянули, Vercel, где можно просто сказать: "Сделай мне одностраничник", и он по простому промпту что-то генерирует. Эти стартапы ориентированы на массового пользователя, на непрограммистов. Всю работу по системному дизайну они уже сделали за вас. Но если мы говорим о промышленной разработке, системный дизайн — это основа.
Три правила промптинга
В основе всего промптинга и генерации текста лежат три простых правила:
Знайте, чего хотите. Чтобы получить правильный ответ, нужно задать правильный вопрос. Вы должны четко понимать, что хотите получить, как и, возможно, даже почему.
Промпт — это координаты. Ваш запрос — это координаты в многомерной матрице токенов. Двумя-тремя фразами вы вряд ли получите адекватный результат. Поэтому первое, что нужно сделать на основании вашего запроса, — это создать план работы, то есть расширить и углубить его. Пусть ИИ сам создаст подробную инструкцию из нескольких десятков строк. Ваша основная задача — контролировать и вычитывать этот план. Если вам что-то не нравится, не правьте ответ руками, а скажите: "Мне не нравится такой-то пункт, давай подумаем, найдем лучшие практики и перепишем его".
Используйте итерации и альтернативы. Один и тот же запрос можно отправлять несколько раз и получать разные ответы. Например, если вы попросите "подумать сильнее, в два раза сильнее, с объяснением подхода", вы можете получить разные результаты и выбрать тот, который лучше всего соответствует вашему видению.
Три основных подхода к генерации кода
Сейчас существует три основные практики генерации кода. Первые две активно обсуждаются в интернете, а вот третья, как мне кажется, пока является изобретением нашей команды — я не встречал, чтобы о ней активно рассказывали на Хабре или YouTube.
Классический подход: подробные спецификации. Этот подход берет начало в классическом управлении проектами. Программисты, как правило, не разбираются в бизнесе; они умеют писать код. Им нужны спецификации от аналитиков и менеджеров. Эта модель отлично ложится на AI-driven development: мы пишем для ИИ очень подробные спецификации, вплоть до уровня "введи эту букву сюда". Это хорошо работает, но требует большой и усидчивой предварительной работы.
Test-Driven Development (TDD). Этот подход тоже произрастает из общечеловеческих практик. Мы не уходим от спецификаций, но сначала пишем не код, а сценарии тестирования. Спецификация покрывается программами, которые проверяют, что должно получиться на выходе, и только потом пишется программа, которая реализует эту логику. Это долго и муторно, но это стандарт индустрии.
-
Подход "срезания углов" (наш метод). За 12 лет сольного предпринимательства моим основным навыком стало "срезание углов" — нахождение нестандартных решений, чтобы получить преимущество на рынке и не умереть на работе. Из этого опыта вырос следующий подход: мы сокращаем время на написание спецификаций и тестов за счет того, что не создаем проект с нуля, а ищем шаблонные или аналогичные open-source проекты на GitHub.
Мы берем этот код за основу для создания спецификации. Например, вы создаете систему бухгалтерского учета. У нее могут быть уникальные фичи, но в своей базе это одна из сотен ERP-систем. Мой совет: найдите проекты, созвучные вам по духу, и возьмите их за основу — как минимум их документацию, а как максимум и код. Вы "скармливаете" этот open-source проект языковой модели, она его документирует, размечает и создает спецификации. Эти спецификации уже будут выверенными, потому что они базируются на рабочем коде. Вам не придется тратить время на вычитку и проверку базовой логики. Далее можно пойти на этап рефакторинга: покрыть этот код разметкой, комментариями, ссылками на документацию, и у вас будет готов костяк для дальнейшей доработки. В этом и заключается "секретный соус", о котором я хотел рассказать.
Инструменты: почему Claude Code?
На рынке существует множество моделей — Claude 3 Opus, GPT-4, Gemini Pro. Я многое попробовал и в итоге остановился на моделях от Anthropic (Claude Sonnet, Opus), которые использую через инструмент Claude Code. При этом я периодически возвращаюсь к классике — Gemini Pro и GPT-4 для определенных задач.
Что касается инструментов, есть классика вроде плагинов для VS Code (Cursor, Codeium), но я в итоге остановился на консольных инструментах, в основном на Claude Code. Почему? Это единственный на данный момент инструмент, который позволяет полноценно реализовать практику генерации кода с использованием агентов. И это критически важно. Claude Code я бы назвал полноценной операционной системой для создания кода. У нее есть набор инструментов: она может сходить за вас в интернет и провести исследование, как Perplexity; она может работать с файлами на вашем компьютере — создавать папки, запускать и компилировать код; и самое главное — она позволяет создавать своих агентов.
Еще одна причина выбора Claude Code — лимиты. Подход с анализом существующих проектов очень затратный с точки зрения токенов. Исследовать код на несколько сотен тысяч строк — это дорого. В моменте можно было сжечь до 100 долларов в час. Это очень дорого, особенно когда платишь из своего кармана. Claude Code предлагает тариф с неограниченным количеством токенов. Насколько я знаю, другие системы такого не предлагают, поэтому Claude Code — наш выбор.
Концепция агентов: борьба со склерозом ИИ
Нужно помнить, что LLM — это оптимистичный халтурщик, который к тому же страдает склерозом. Окно внимания у модели маленькое, и на большой задаче результат предыдущей итерации может негативно влиять на следующую. Например, в процессе поиска модель могла найти какую-то фейковую страничку "как ограбить Пентагон", и при кодировании нам нужно, чтобы она об этом забыла. Умение помнить и забывать — важнейший фактор.
Концепция агентов в Claude Code решает эту проблему. Агент — это инструкция в отдельном файле. Вы создаете серию таких агентов:
Инструкция для агента-исследователя: "Ты ищешь информацию только на этих сайтах".
Инструкция для агента-документалиста: "Ты пишешь документацию по такому-то шаблону".
Инструкция для агента-кодировщика: "Дорогой кодировщик, в этой папке лежит архитектура проекта. Прежде чем что-то делать, сверься с ней, а по завершении — обнови ее".
Эти инструкции — не статичны. Вы постоянно их дорабатываете. Заметили, что что-то пошло не так — добавляете в инструкцию: "Проводи тестирование дважды".
Каждый раз, когда запускается агент, он стартует с чистого листа, загружая только свою инструкцию. Это процесс забывания. А инструкция — это процесс вспоминания, ваш контекст и ваши знания. Вот почему я считаю, что остальные инструменты, такие как Cursor или Braintrust, уже устарели. У них нет механизма забывания, они помнят всё, и предыдущие действия влияют на последующие. А это плохо. Нам нужны узкоспециализированные работники с определенным набором навыков.
В Claude Code можно создавать агентов на разных уровнях: на машину, на проект, на папку, что позволяет их детализировать.
Практический процесс работы и роль человека
Итак, как выглядит процесс? Все начинается с глобального видения. Далее вы детализируете его на бизнес-модель, дорожную карту, бэклог задач и архитектурные соглашения — правила того, как должен выглядеть ваш код.
Очень хорошо работает подход с модульностью и микросервисами. Старайтесь проектировать архитектуру так, чтобы каждый компонент был замкнутым, независимым и, главное, тестируемым. Вы должны четко понимать, что он принимает на вход и что дает на выходе. А потом из этих "программных кубиков" вы собираете большую систему.
Важно вести трекинг. Просите ИИ перед началом генерации кода создавать задачу в определенной папке по шаблону. Это логирование. Вы не просто нажимаете кнопку "сделай мне условный Яндекс", а говорите: "Сделай мне Яндекс, а логи своей работы положи в эту папку". Если что-то пойдет не так, вы сможете прочитать логи и понять, где были ошибки. Эти логи важны для анализа.
Есть еще одна хорошая практика. Допустим, вы долго бились над багом, и внезапно все получилось. В этот момент счастья попросите LLM: "Дорогой друг-кодировщик, положи это удачное решение в нашу базу знаний, чтобы в будущем мы с такой ошибкой не сталкивались". Так вы итеративно создаете базу знаний вашего проекта. Эта документация — по сути, и есть ваш проектный "искусственный интеллект". С этой базой знаний вы можете переходить от одного генератора к другому. Если Claude Code не справляется, я беру эту папку, иду в GPT-4 и говорю: "Прочитай эти архитектурные решения и попробуй найти ошибку". Мне не нужно обучать новую модель проекту с нуля.
Роль архитектора и заключение
Роль архитектора в проектах с участием ИИ кардинально меняется. Это уже не просто выделенная роль человека, который определяет стратегию. Это роль, которая закрывает всю линейку проектного управления: он и аналитик, и руководитель, и тестировщик. Но самое основное — это принятие результатов. LLM очень продуктивны, но как оценить то, что получилось? Это то, что вам нужно придумать.
Подведем итоги:
Вы работаете с генератором текста, а не с полноценным интеллектом. Эти подходы применимы не только для кода, но и для исследований, написания книг и т.д.
Ключевая особенность LLM и человека — не только помнить, но и забывать. Управление контекстом — это главный тренд.
Инструменты активно развиваются. Нужно экспериментировать, пробовать новое, но относиться к хайпу с долей скепсиса.
Выбор LLM — это почти как выбор религии, дело привычки.
Агентные системы — это основа. В Claude Code сейчас самая продвинутая реализация. Если вы работаете с open-source, посмотрите в сторону плагина для VS Code под названием RooCode. Там тоже есть концепция оркестратора и рабочих пчел, но главная проблема — стоимость. Он работает через API, которое продается за токены, а это очень дорого для больших проектов. Чтобы прочитать чужой код на несколько сотен тысяч строк, нужно потратить 50 долларов. В Claude Code с безлимитным тарифом это бесплатно.
На этом у меня всё, коллеги. Готов ответить на вопросы.
Сессия вопросов и ответов
Модератор:
Евгений, спасибо большое. Предлагаю перейти к более практическим примерам. Можете ли вы описать пошаговый путь разработчика, который создает MVP с помощью ИИ? Хочется применить все, о чем вы говорили, к конкретному примеру, чтобы сложить цельную картину.
Евгений Росюк:
Да, давайте соберем все воедино и рассмотрим конкретный путь создания MVP.
Шаг 1: Исследование рынка и поиск аналогов.
Первое, что необходимо сделать, — это применить системное мышление. Нужно понять место продукта на рынке и определить конкурентов. Это исследование можно провести с помощью тех же инструментов ИИ, таких как Claude Code или Perplexity. Вы анализируете сильные и слабые стороны конкурентов и, что самое важное, ищете аналоги в open-source. На этом этапе вы уже определяетесь с функциональными и системными требованиями.
Шаг 2: Создание документации на основе проекта-донора.
Скорее всего, вы найдете подходящий open-source аналог. Вы берете этот проект и на его основе с помощью LLM создаете полную документацию: архитектурную, бизнес-требования, описание форм ввода, принятые архитектурные решения и так далее. Этот текст, по большому счету, уже и есть ваш проект. Вы его вычитываете и понимаете, какую функциональность нужно усилить, а какую — изменить, чтобы получить конкурентное преимущество. Отдельно прорабатываете технологические способы улучшения этой функциональности.
Шаг 3: Создание промптов и агентов для кодирования.
Когда документация готова (а это может быть длительный процесс, требующий вдумчивой работы), вы переходите к созданию промптов, или, как я их называю, агентов для кодирования. На основании функциональных и технологических требований вы определяетесь со стеком, ищете в интернете лучшие практики (например, Clean Architecture и т.д.) и закладываете все эти требования в промпт для агента-кодировщика. В этот же момент вы создаете контекст приемки: что будет являться результатом работы? Как будет проходить тестирование?
Шаг 4: Итеративная генерация кода и контроль.
И только на этом этапе начинается самое интересное — генерация кода. Вы отдаете агенту задачу из вашего ранее созданного плана, он ее выполняет. Вы смотрите на результат и либо принимаете его, либо отправляете на доработку. Этот цикл повторяется по каждой задаче, и на выходе вы получаете свой MVP.
Самое важное здесь — не уйти в "бантики". Генераторы кода могут предложить вам сразу построить "дом с гаражом и бассейном на крыше". Но ваша задача — построить "сарайчик из соломы", то есть MVP. Поэтому вы должны постоянно проверять тексты и планы, чтобы убедиться, что ИИ не отклонился от курса.
Практический пример:
Недавно я делал сервис для индексирования файлов для кодогенерации. Весь проект занял у меня примерно два дня чистого времени. Основное время ушло на поиск "донора": я изучал, что происходит в этой сфере, какие есть проекты. Когда нашел подходящий, я поставил себе цель — заставить его работать локально и адаптировать под свою нишу, то есть изменил техническую архитектуру. Основная сложность была в том, что Claude Code в какой-то момент "тупил", и мне пришлось переключиться на GPT-4, чтобы вывести его из ступора. Если бы этот проект делали люди в обычных условиях, без кодогенерации, по моим ощущениям, это заняло бы около двух месяцев, учитывая технологическую сложность.
Главный выигрыш — мы получаем разительный рост количества экспериментов, которые можно провести в единицу времени, и, соответственно, количества MVP, которые мы можем выпустить.
Модератор:
Я могу поделиться своим опытом как обыватель. Мне нужно было сделать простой лендинг. Я обращалась к ChatGPT, потом к Perplexity, но для меня это было сложновато. В итоге эти же модели помогли мне найти сервис Vercel, который справился с задачей.
Евгений Росюк:
Да, это как раз тот случай, когда за вас уже продумали типовую архитектуру приложения. Под капотом таких сервисов сидят агенты, которым сказали: "Мы создаем веб-приложения, они должны соответствовать таким-то правилам и работать по такой-то архитектуре". Всю эту подготовительную часть они уже сделали, а вам отдали только кнопку "сделать красиво". Вы пишете "сделай лендинг с единорогами", и у вас есть пространство для вариаций, но весь технологический стек под капотом уже проработан и заложен в шаблоны. Этот подход можно масштабировать: если вам нужно создавать однотипные приложения, вы один раз создаете такие шаблоны и затем по ним быстро генерируете новые решения, пропуская этапы поиска и архитектурного проектирования.
Алексей (участник):
Хотел бы добавить, что здесь отлично работают все классические практики, которые были придуманы до нас, в том числе подходы к управлению разработкой и декомпозиции задач. Если следовать классической истории по декомпозиции, не отказываться от устоявшихся практик, а просто применять их в работе с нейросетями, результат получается гораздо лучше. Моя небольшая практика с сайтами показала, что несколько итераций по уточнению промпта, по сути, являются детальной декомпозицией задачи, и это приводит к нужному результату.
Олег (участник):
Евгений, у меня вопрос. Вы совершенно правильно подытожили, что нужно провести аналитику, декомпозировать задачу и затем получить результат в нейронке. Но интересуют практические цифры. Получается, что анализ и архитектуру все равно делает человек. В общих затратах на создание приложения, особенно если говорить не об MVP, а о полноценном продукте, где именно мы экономим? На затратах на разработчиков младшего уровня? Каков экономический эффект в цифрах для реальной, не учебной задачи?
Евгений Росюк:
По ощущениям, выигрыш в следующем:
Снижение зависимости от конкретных разработчиков. У нас был реальный пример: проект, от которого отказались все люди, и последний разработчик сказал: "Я все, я устал, я ушел". LLM спасла этот проект: она его разобрала на модули, отрефакторила. Человек занимался рефакторингом три месяца, а LLM сделала это за две недели. И это был Senior, а не Junior.
Экономия на разработке и CI/CD. Я не работаю в крупных корпорациях вроде "Тинькофф", но они внедряют эти технологии и называют цифры порядка 20% сокращения затрат на разработку и до 50-80% сокращения затрат на CI/CD. Процесс развертывания, приемки, поиска багов почти полностью автоматизируется с помощью LLM.
Автоматизация тестирования. Создание тестов — это задача, которую можно практически на 100% отдать на откуп ИИ.
Безграничность в технологиях. LLM дает возможность создавать проекты, не будучи глубоко погруженным в детали конкретного языка, будь то JavaScript или WebAssembly. Я знаю, что я хочу, каким способом это получить и какой результат ожидаю. Я детализирую задачу и общаюсь с LLM, не привлекая людей для создания прототипов.
Конечно, в итоге мы всегда отдаем эти решения людям, потому что на данный момент принято, что за результат отвечает человек, а не машина. С человека можно спросить.
Алексей (участник):
По моим наблюдениям, на текущий момент инструментарий отлично повышает эффективность не самых профессиональных разработчиков на простых задачах. У нас, например, аналитики теперь делают простые задачки сами, чтобы не дергать разработчиков. С другой стороны, это сильно ускоряет создание MVP и прототипов для демонстрации заказчику.
Но здесь возникает интересный философский эффект и новый риск. Если мы встанем на точку зрения заказчика, мы можем потерять возможность фильтровать команды на входе. К вам приходят четыре команды, и все они сделали отличные MVP с помощью нейросети, которые по качеству почти не отличаются. А потом вся эта история может жестко сломаться на этапе реализации, когда включаются люди и требуется уже человеческий профессионализм для доведения MVP до продуктивного решения. Появляется забавный риск при выборе подрядчика.
Модератор:
Отлично. Тогда на этом мы можем завершать. Мы эту запись обработаем и выложим в текстовом виде, чтобы к ней можно было возвращаться как к обучающему материалу. Всем спасибо, до свидания.
* полезные ссылки
https://habr.com/ru/articles/934806/
https://habr.com/ru/articles/946748/
https://habr.com/ru/articles/941934/