КАК Я СДЕЛАЛ ОНЛАЙН-ТЮНЕР ДЛЯ ГИТАРЫ ЧЕРЕЗ AI-АГЕНТОВ ЗА НЕСКОЛЬКО ЧАСОВ

Я давно хотел сделать простой онлайн-тюнер для гитары.

Не приложение, которое нужно устанавливать. Не перегруженный сервис с кучей лишних экранов. А обычный веб-инструмент: открыл сайт, выбрал строй, настроил гитару и пошёл играть.

В итоге я сделал MVP такого проекта — ToGuitar, онлайн-тюнер для гитары и бас-гитары.

Но самое интересное здесь даже не в самом тюнере.

Самое интересное в том, что я почти не писал код руками. Проект был собран через AI-агентов в формате, который сейчас часто называют Vibe Coding.

Об этом опыте я снял отдельное видео, а в статье хочу подробнее рассказать, как проходила разработка проекта, что получилось и какие выводы я сделал.

Что за проект

ToGuitar — это онлайн-тюнер, который работает прямо в браузере.

Идея простая: пользователь открывает сайт, разрешает доступ к микрофону, выбирает нужный строй и настраивает инструмент.

В MVP я заложил поддержку:

• обычной шестиструнной гитары;
• разных гитарных строев;
• Drop D;
• инструментов с разным количеством струн;
• бас-гитары;
• басов с разным количеством струн.

То есть задача была не просто сделать «ещё один тюнер», а собрать небольшой, но расширяемый музыкальный инструмент.

Сейчас это именно MVP. Не финальный коммерческий продукт, не идеально отполированная версия, а рабочий прототип, который уже можно открыть, протестировать и использовать.

Почему я решил это сделать

Мне было интересно проверить не теорию, а практику.

Сейчас много говорят о том, что AI уже пишет код, заменяет разработчиков, делает продукты за пару кликов и вообще скоро всё будет собираться само.

Но в реальности всё не так однозначно.

Да, AI действительно может сильно ускорять разработку веб-приложений. Но вопрос в другом: можно ли взять идею, почти не писать код руками и за несколько часов получить рабочий проект, который не стыдно показать людям?

Я решил проверить это на небольшом, но настоящем проекте.

Не на абстрактной todo-шке.

Не на демо-кнопке.

Не на лендинге из трёх блоков.

А на сервисе, который должен работать с микрофоном, частотами, нотами, интерфейсом, разными строями и реальным музыкальным инструментом.

Как я строил процесс

Я не начал с команды в стиле:

Сделай мне гитарный тюнер.

Такой подход обычно быстро приводит к хаосу.

Сначала я пошёл более привычным для разработчика путём:

• обсудил идею проекта;
• сформулировал, что именно должен уметь тюнер;
• составил примерную архитектуру;
• разложил проект на задачи;
• продумал интерфейс;
• подготовил описание дизайна;
• после этого передал весь контекст AI-агенту.

То есть я не просто попросил нейросеть «что-нибудь сделать». Я подготовил для неё контекст, ограничения и план.

И вот это, как мне кажется, ключевой момент.

Vibe Coding — это не когда ты вообще ничего не делаешь.

Это когда ты управляешь разработкой через постановку задач, проверку результата и корректировки.

Что пошло не сразу

Сначала я попробовал реализовать проект через OpenCode с моделью BigPickle.

Туда я передал заранее подготовленный контекст: описание идеи, архитектуру, список задач и наброски по дизайну. То есть это был не простой запрос уровня «сделай мне тюнер», а уже более-менее подготовленное техническое задание.

Но с первого раза всё не взлетело.

OpenCode + BigPickle не справились так, как мне было нужно. Где-то начинались проблемы с реализацией, где-то результат не дотягивал до нормального рабочего состояния, где-то проект не удавалось довести до версии, которую можно открыть и спокойно протестировать.

После этого я подключил Codex.

И вот с ним уже удалось довести проект до рабочего MVP.

Это важный момент, потому что в роликах про AI-разработку часто создаётся ощущение, что всё происходит магически:

написал запрос → получил готовый продукт → выложил в прод.

На практике всё иначе.

• AI ошибается.
• AI не всегда понимает задачу с первого раза.
• AI может сделать красиво, но не совсем то.
• AI может потерять часть логики.
• AI может собрать проект, который выглядит рабочим, но ломается на реальном сценарии.

И здесь всё равно нужен человек, который понимает, что должно получиться.

Сколько времени заняло

На получение рабочего MVP ушло примерно 4–6 часов.

Для небольшого проекта это хороший результат.

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

С AI-агентами процесс действительно ускорился.

Но я бы не сказал, что это было «нажал кнопку и получил продукт».

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

Только вместо человека-исполнителя — AI-агент.

Что получилось в итоге

Получился рабочий онлайн-тюнер.

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

Мне хотелось начать именно с результата.

Не с разговоров про инструменты.

Не с философии про AI.

А с простого момента:

вот гитара, вот тюнер, вот он работает.

Потом уже можно говорить о том, как я к этому пришёл.

Главный вывод

Мой главный вывод такой:

AI-агенты уже позволяют быстро собирать рабочие MVP, но они не отменяют роль разработчика.

Просто роль немного меняется.

Раньше разработчик в основном сам писал каждую строку кода. Сейчас в таких экспериментах он всё чаще становится человеком, который:

• формулирует идею;
• описывает требования;
• проектирует архитектуру;
• разбивает работу на задачи;
• проверяет результат;
• замечает ошибки;
• принимает технические решения;
• доводит проект до состояния, которое можно показать людям.

То есть опыт разработки всё равно нужен.

Без него можно получить что-то визуально похожее на продукт, но не факт, что оно будет нормально работать.

Почему это важно для разработки MVP

Для меня этот эксперимент хорошо показал, что разработка MVP продукта через AI-инструменты уже имеет практический смысл.

Особенно если нужно быстро проверить идею.

Например:

• небольшой веб-сервис;
• внутренний инструмент;
• прототип SaaS-продукта;
• демо-версия для клиента;
• интерфейс будущей системы;
• первая версия продукта перед полноценной разработкой.

Раньше такой эксперимент мог легко растянуться на несколько дней или недель. Сейчас часть этого пути реально пройти за несколько часов.

Но здесь важно не путать MVP и готовый коммерческий продукт.

MVP нужен, чтобы проверить гипотезу. Он может быть простым, местами сырым, без всех функций и без идеальной архитектуры.

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

AI помогает быстро стартовать, но не освобождает от инженерной ответственности.

Где AI реально помогает

По моему опыту, AI-агенты особенно хорошо помогают на старте.

Они могут быстро:

• накидать структуру приложения;
• собрать базовую верстку;
• написать черновую бизнес-логику;
• предложить варианты архитектуры;
• подготовить компоненты интерфейса;
• ускорить рутинные задачи;
• помочь с документацией.

Это особенно заметно в разработке веб-приложений, где много повторяющихся частей: страницы, формы, состояния, компоненты, API, обработчики, настройки.

Но сложные места всё равно приходится контролировать самому.

AI может уверенно написать неправильный код. Может не учесть ограничения. Может решить задачу «почти правильно», но не так, как нужно для реального проекта.

Поэтому полностью отключать голову нельзя.

Почему я хочу продолжать эту рубрику

Этот тюнер стал первым выпуском новой серии, которую я хочу вести дальше.

Условно назовём её Vibe Coding.

Идея простая: брать разные проекты, запускать их с помощью AI-агентов и показывать не только финальный результат, но и сам процесс.

Мне интересно проверять:

• где AI реально ускоряет разработку;
• где начинает ломаться;
• какие задачи он решает хорошо;
• какие задачи всё ещё требуют ручного контроля;
• можно ли на таком подходе запускать не только игрушечные прототипы, но и более серьёзные проекты.

Гитарный тюнер — хороший первый пример.

Он небольшой, понятный, визуальный и при этом не совсем примитивный: есть работа со звуком, частотами, интерфейсом, настройками и реальным пользовательским сценарием.

Дальше хочется попробовать проекты сложнее.

Итог

Для меня этот эксперимент оказался полезным.

Я не считаю, что AI уже заменил разработчиков. Но я всё больше вижу, что он меняет сам процесс разработки.

Особенно на этапе MVP.

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

Но при одном условии: человек всё равно должен понимать, что он делает.

• AI может писать код.
• AI может предлагать архитектуру.
• AI может собирать интерфейсы.
• AI может ускорять рутину.

Но ответственность за результат всё равно остаётся на человеке.

Если вам нужен MVP или веб-приложение

Я занимаюсь разработкой веб-приложений, MVP-продуктов, CRM/ERP-систем, интеграций и инструментов автоматизации для бизнеса.

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

Если коротко: я делаю не просто «сайт ради сайта», а рабочие веб-приложения, MVP и системы автоматизации, которые помогают проверять идеи и решать реальные задачи бизнеса.

Попробовать ToGuitar - https://toguitar.ru