За последние пару лет LLM прочно вошли в мою (и не только мою) жизнь. Как говорится: “Мы не знаем что это такое, если бы мы знали что это такое, но мы не знаем что это такое!“. Я взял для заголовка публикации слегка переиначенное название культового фильма Кубрика, потому что сегодняшние разговоры об угрозах ИИ напоминают мне ту самую нервозную атмосферу из фильма, связанную с атомной бомбой.
На самом деле “BDSM” в контексте данной публикации расшифровывается очень просто – Управление программным продуктом при помощи ботов (Bot Driven Software Management).
Знакомство с OpenAI Codex
Месяца три назад OpenAI выкатили в публичный веб-доступ Codex – свой бот для разработки софта. Я его попробовал и он меня поразил. Подключаешь GitHub-репозиторий к Codex’у и просишь бота что-то сделать на обычном русском языке. Он там где-то, на мощностях Сэма Альтмана, что-то делает-делает, а потом – бах! готовый pull request для твоего репозитория. И даже с тестами! Можно разрабатывать со смартфона, пока едешь в поезде.
Пока что мы всё ещё плохо понимаем, как можно использовать LLM в разработке приложений, но очень активные изыскания идут по многим направлениям. Уже сейчас боты применяются в широком спектре – от автодополнения в IDE и до генерации целых проектов по одному промпту.
Я, разумеется, слышал про вайб-кодинг, но для себя считал (и считаю) это несерьёзным занятием – пока что у меня ни в ноутбуке, ни в смартфоне нет приложения, созданного таким вот прогрессивным способом. Но после того, как вживую потрогал Codex… это впечатляет! На первый взгляд кажется даже, что на этом можно заканчивать карьеру программиста – боты неплохо справляются сами. Вот где-то тут я и начал беспокоиться.
Ограничения и возможности LLM
Но чем больше я пробовал программировать через Codex, тем лучше я узнавал ограничения этого подхода. Бот хорошо работает короткими итерациями и малыми объёмами текста. Многоступенчатый рефакторинг ему даётся тяжело. Без руководящей роли “кожаного” бот начинает идти вразнос. Появилось ощущение, что это не конкурент, а инструмент. Тут меня подотпустило слегка и я начал думать, как же мне дальше жить с таким счастьем-то?
Стало понятно, что бот может значительно облегчить жизнь. Он может:
-
проанализировать имеющуюся кодовую базу и ответить на мои вопросы.
-
предложить типовое решение (всё уже придумано до нас)
-
обсудить варианты и нюансы нетиповой задачи
-
написать какой угодно код по готовому шаблону (пока-пока бойлерплейт)
-
проверить и отрефакторить значительный объём кода (но только на довольно простых задачах)
Да, бот работает с огромным контекстным окном – доходит до 1М токенов (но в браузере Firefox, например, кодовая база порядка 22 млн. строк). Выходной контекст у бота является частью контекстного окна и ограничен ещё сильнее – до 64К токенов у флагманских моделей. Поэтому большой программный продукт не может быть однофайловым – бот его даже если и поймёт, то вот отрефакторить уже не сможет.
Проекты должны состоять из множества небольших файлов, иерархически связанных друг с другом. Чтобы помещались в контекстное окно вместе, но изменялись независимо, по итерациям. Помимо исходного кода в контексте также должна быть документация проекта, задающая ограничения по генерации исходников (соглашения по проекту).
Спокойствие, только спокойствие (с)
На каком-то этапе пришло понимание, что боты – не конкуренты. В лучшем случае – помощники, но в большинстве случаев – просто инструменты. Им пока что не хватает своих мозгов, чтобы быть помощниками. Ну, а раз есть инструмент, то к нему должна быть и инструкция.
Беда в том, что к таким ботам нет единой инструкции. И не будет. Слишком уж разносторонен этот инструмент. Каждый может написать свою собственную инструкцию по использованию этого инструмента – в зависимости от своей сферы деятельности, опыта, потребностей, склонностей, в конце-концов.
DIY
Я решил, что раз уж самому приходится писать для себя инструкцию, то надо хотя бы дать ей название. После недолгих мучительных выборов название сложилось – Bot Driven Software Management. Оно прекрасно отражало не только суть описываемых процессов – управление разработкой приложений при помощи ботов, но и возникающие при этом отношения “master – slave”. В BDSM либо ты рулишь ботом, либо бот рулит тобой. Второй вариант все знают – это вайб-кодинг.
В общем, BDSM может быть и полезным, и приятным, и увлекательным. Надо только чётко определиться с правилами – что можно, что нельзя, какие инструменты и приёмы разрешены, кодовые слова и всё такое. Описать процедуры, соглашения, зоны ответственности и т.п.
Я уже начал классифицировать часто употребляемые промпты и описывать типовые процедуры, которые у меня возникали, но встал вопрос ребром с названием – BDSM слишком вызывающее название для IT-методологии. Я не ханжа, но для маркетинга (не, ну а вдруг?!) это может быть непреодолимой преградой. Или наоборот.
A/B-тестирование
Поэтому я решил применить A/B-тестирование в выборе названия. В маркетинге A/B-тесты – это метод сравнения вариантов на аудитории. Если коротко, то берёшь букву “A” вместо буквы “B” и смотришь на реакцию потенциальных пользователей – кому что больше нравится.
Вот смотрите, есть
-
BDSM – Bot Driven Software Management
-
ADSM – Agent Driven Software Management
Оно об одном и том же. Это просто разные названия одного и того же процесса – создания программных продуктов при помощи ботов/агентов. У каждого названия есть свои плюсы и минусы. У меня, разумеется, есть свои предпочтения, но моё мнение меня интересует в последнюю очередь.
Поэтому я прошу у уважаемой аудитории Хабра помощи в проведении А/Б-тестов.
Спасибо всем, кто дочитал до конца, и особенно тем, кто поучаствовал в тестировании!
Автор: flancer
