За последние пару лет 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
Оно об одном и том же. Это просто разные названия одного и того же процесса — создания программных продуктов при помощи ботов/агентов. У каждого названия есть свои плюсы и минусы. У меня, разумеется, есть свои предпочтения, но моё мнение меня интересует в последнюю очередь.
Поэтому я прошу у уважаемой аудитории Хабра помощи в проведении А/Б‑тестов.
Спасибо всем, кто дочитал до конца, и особенно тем, кто поучаствовал в тестировании!
