С чего всё началось

Пожалуй, начну с того, что расскажу о себе

Я человек, который каким‑то образом попал в ИТ. Я не программист, я не инженер. Мой опыт исключительно вокруг проектов и продуктов. Я долго работал в одном из вендоров ПО и повидал, как надо и, самое главное, как не надо делать проекты, причем в различных видах бизнеса.
Еще я музыкант, регулярно выступаю со своим материалом, и до января 2026 года я выступал с уже собранным, откалиброванным и изученным сетапом из железных синтезаторов.
Это так называемый Dawless‑формат, когда создаёшь музыку без использования компьютера.

Мой сетап выглядел так:

Но в январе 2026 мне пришлось все продать, неважно почему, просто так получилось.
И я начал искать успокоение в Ableton, благо я им пользуюсь с 17 лет, поэтому вливаться обратно было не сложно.
Купил себе контроллер AKAI APC 40 MK1 и начал пробовать играть вживую.

Вот тут меня ждала засада, все плагины, которые мне попадались, в основном заточены именно на работу мышкой в студии. То есть перформативности в них явно не хватает. Да, в них можно настроить идеальный звук, автоматизировать все до мелочей и записать трек. Но для живых выступлений, где ты играешь или импровизируешь это уже не подходит.

Здесь мы подходим к основной теме. Я установил себе Claude Code

Первые шаги

Коротко о моих впечатлениях в первые дни — мне как будто дали волшебную палочку, с которой важно правильно произнести заклинание и получишь нужный результат. Вот так вот я впечатлился. Всё, что я раньше хотел сделать, но не мог, потому что у меня не хватало компетенций теперь стало мне доступно.

Первым я сделал дрон‑синтезатор, сразу пошёл на максимум — 16 осцилляторов, взаимная модуляция нескольких видов, модуляция входящим аудиосигналом, блок эффектов.
Примерно за день все было сделано, я потестил его немного, нашел несколько багов, но меня он сильно не зацепил.

Потом сделал дилей, потом что‑то еще (уже не помню хронологически что именно)

Первая глобальная идея

И тогда я решил сделать суперультимативный синтезатор, который генерирует любой звук по текстовому запросу в LLM. Но не просто аудио генерирует, а собирает патч, который будет под это описание подходить.
Когда я более‑менее осознал эту идею, мне стало понятно, что надо создать определенный набор модулей для синтезатора, чтобы из них можно было собрать любой звук. Нужны были осцилляторы, генераторы LFO, огибайки, фильтры, эффекты и так далее и тому подобное. Итого первоначальный список получился примерно из 40 модулей (сейчас точно не помню).

Мой процесс выглядел так:

1. С DeepSeek обсуждался список модулей, корректировался и наполнялся. Составлялся примерный план, как их нужно реализовывать. Я воспринимаю его как очень начитанного студента‑отличника: делает много правильного, но может ошибаться в каких‑то глобальных вещах.

2. Claude в пух и прах критикует все, что было написано с помощью других LLM, мол, это явно писал какой‑то дилетант: надо делать все по‑другому.

3. Получается итоговое ТЗ и приступаем к работе.

С какой идеей я зашел в эту задачу

До этого каждый мой плагин был отдельной вещью со своим жёстко прошитым звуковым трактом. Модули внутри повторялись, но собрать из них что‑то новое можно было только заново создавая новый плагин.
Тут я решил перевернуть схему. Звук описывает уже не код, а схема соединений: какие блоки взять (осцилляторы, фильтры, сатурация, дилеи, реверберация), как их соединить и что чем модулировать. Схема записывается в текстовый формат, JSON‑патч. Текст умеет писать языковая модель. Значит, модель может «собрать синтезатор» по фразе вроде «холодный ржавый дрон на рассвете», остаётся сделать движок, который эту схему исполняет.
Позже был сделан даже тестовый плагин, который умеет воспринимать JSON:

В итоге были собраны все модули, написан движок и даже была попытка дофайнтюнить локальную LLM (хотел, чтобы это все работало автономно).
Но локальная LLM требовала еще доп. файнтюна и качественного датасета (у меня был собран один, но он явно требовал валидации и корректировок). Поэтому я решил отложить локальную версию и просто подключил туда API DeepSeek, который по препромпту хорошо справлялся с составлением патчей.
Но получилось все не так радужно, как я себе представлял. Тут надо отметить, что всё‑таки интереснее крутить звук, чем описывать его. Тем не менее плагин есть и даже был использован в одном из последних лайвов.
Вот он:

Как появились остальные плагины

Далее я решил уже не заморачиваться с этими супер‑идеями с LLM и в этот момент я осознал, что у меня есть универсальный конструктор любого нужного мне синтезатора или эффекта.

Здесь началась работа с правилами для Claude

Основное правило было — максимальное переиспользование всех компонентов, моя идея была в том, что если улучшим что‑то в одном синтезаторе, то оно должно улучшиться и у всех. Но тут встал вопрос: если сломаем где‑то, то сломается везде, поэтому были созданы правила ревью — тронул общее ядро — тесты всех плагинов.
Потом появился отдельный субагент‑ревьювер, который в течение дня копит задачи, а по команде ночью запускается и проводит ревью — чтобы не тратить дневной лимит токенов.

Так начался марафон по созданию плагинов

Все было более‑менее по одной схеме:

1. Обсуждение

2. Написание первого варианта ТЗ

3. Переписывание ТЗ

4. Реализация с предварительной проверкой:
   Каждый плагин проверялся еще до создания интерфейса, так как в одном из правил было указано — ядро не зависит от JUCE. Чистый C++, который собирается любым компилятором и тестируется без VST‑обвязки. По сути генерировалось несколько примеров звучания, если все подходит — идем дальше, если нет — дорабатываем.
   

Улучшение качества звучания и рабочего процесса

Когда плагинов стало больше 10, я задумался — а звучат ли они хорошо? Ведь их делал ИИ и мне не хотелось, чтобы они звучали как самый простой плагин.
Так родился аудит.
На него ушло где‑то две недели: первую неделю занял сам аудит, вторую — исправление того, что нашлось. Чтобы правильно направить ИИ, я погрузился в тему «Как заставить звучать плагины лучше»

В итоге был выработан такой план:

1. Сначала исследовать, ничего не чинить. Пока нет фактов, код не трогаем.

2. Изучить, как делают другие. Claude разобрал 18 источников, от научных статей до подходов FabFilter: как бороться с цифровой грязью в сатурации и дисторшне.

3. Собрать измерительный стенд и снять замеры «до» любых правок. Теперь эти замеры сверяет CI.

4. Пройти всё ядро по шагам. Каждая находка записывается с численными показателями, а не со словом «кажется».

5. Чинить в порядке зависимостей и классом, а не модулем. Если ошибка повторяется в 24 местах, это одна правка, а не 24 заплатки.

Итог: больше сорока подтверждённых находок, шесть выводов аудита отозваны после перепроверки, исправления прошли шестью волнами. Но главным результатом стали семнадцать новых правил. Правка чинит один модуль, правило закрывает целый класс ошибок.

Кстати, одним из пунктов аудита я также заложил и анализ того, как экономить токены в проекте. Правила для Claude копились по ходу работы и ни разу не пересматривались целиком. А каждое правило читается в начале каждой сессии и занимает место в контексте, нужно оно сейчас или нет.
Файл правил разросся до 43 тысяч токенов на каждую сессию, и после чистки стал втрое меньше: устаревшее удалили, историю разнесли по плагинам, тяжёлые отчёты стали читаться только по требованию.

Итог

Оглядываясь назад, главное, что я вынес из этих месяцев, не сами плагины, а понимание того, как работать с ИИ. Волшебная палочка действительно работает, но заклинание — это не один удачный промпт. Это система: правила, проверки, замеры. Мой опыт в проектах тут пригодился больше, чем пригодилось бы умение программировать. ИИ пишет код быстрее, чем кто‑либо, но решать, что делать, в каком порядке и как понять, что получилось, всё равно мне.

А ещё я понял, что интереснее крутить звук, чем описывать его. Моя изначальная проблема никуда не делась: мне по‑прежнему нужны инструменты для живой игры, а не для студии. Об этом будет следующая часть: как появился формат «live performance first», как я делал свою первую драм‑машину и как из случайной идеи в чате музыкантов вырос VST‑модуляр D‑SP.