Планирование — это новый код

Автор дважды создал одно и то же приложение. Первая попытка: день написания кода, несколько дней отладки. Вторая: несколько дней планирования, день написания кода — готовое приложение. Разница оказалась не в коде, а в плане.

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Планирование — это новый код

Planning Is the New Coding Автор: Philrox Оригинальный текст

Я создал одно и то же приложение дважды.

Первая попытка: день написания кода, несколько дней отладки. Потом я всё удалил.

Вторая попытка: несколько дней планирования, день написания кода. Готовое приложение.

Разница была не в коде. Разница была в плане.

Первая попытка: Vibe Coding пошёл не по плану

В конце прошлого года я хотел создать локальное приложение для транскрипции встреч на Mac. Распознавание говорящих. Генерация документов из расшифровок. Чат с транскриптом. Всё локально, без облака.

Я уже знал Whisper. Использовал его много раз в Python-приложениях. Очевидный выбор. Мой промпт был простым: «Хочу создать локальное приложение для транскрипции встреч с Whisper».

За день у меня было работающее приложение. Или так мне казалось. Распознавание говорящих было плохим. Не «требует настройки» плохим. Непригодным для использования.

Это меня удивило. Я тестировал другие приложения с той же функцией. Они отлично справлялись. Что они делали иначе? Я потратил часы на оптимизацию параметров. Ничего не помогало.

Потом я нашёл ответ: большинство приложений используют платную версию API. Вот почему это работает. Весь мой подход был ошибочным. Нужно было начинать сначала.

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

Вторая попытка: сначала исследование, потом код

На этот раз я сделал всё принципиально иначе. Я уже знал, что планирование важно в разработке с ИИ. Но проигнорировал это. Классическая самоуверенность «я уже это делал».

Шаг 1: Исследование

Я потратил время на поиск альтернатив. Обнаружил FluidAudio, оптимизированный для Apple Silicon. Это был ключ.

Шаг 2: Глубокое планирование

Я использовал DeepWiki MCP, чтобы дать Claude Code доступ к документации FluidAudio. Затем вместе с Claude написал детальный план.

Что должно делать приложение?

• Возможность записи
• Загрузка существующих аудио/видео файлов встреч
• Транскрипция с распознаванием говорящих

Это был MVP (минимально жизнеспособный продукт).

Шаг 3: Расширение scope

В процессе планирования я добавил:

• Создание документов из транскриптов
• Чат с транскриптами через Ollama (Qwen3 или gpt-oss)

Я записал всё в план. Разбил на фазы для ранней валидации.

Результат:

После реализации первой фазы приложение выглядело именно так, как я хотел. В нём были именно те функции, которые мне нужны.

Инвестиции в планирование: один-два дня. Это не было сделано с первого раза. Туда-сюда. Итерации. Но я получил приложение, соответствующее моему видению, быстрее, чем занял debug провалившейся первой попытки.

Vibe Coding vs. Планирование

Андрей Карпати придумал термин «vibe coding» (разработка в свободном стиле) в феврале 2025:

«Появился новый вид программирования, который я называю vibe coding — когда полностью отдаёшься вайбам, принимаешь экспоненты и забываешь, что код вообще существует».

Это работает. Но вот чего никто не говорит: это работает ЛУЧШЕ с планом. Моя первая попытка была чистым vibe coding. Мало информации. «Я уже использовал Whisper, я знаю, как это работает».

Это не сработало.

С конкретным планом vibe coding превращается в нечто совершенно иное. Ты всё ещё позволяешь ИИ делать своё дело. Но ты дал ему цель.

ПЛАНОВЫЙ VIBE CODING > ЧИСТЫЙ VIBE CODING

Цифры подтверждают это

Исследование Engprax/J.L. Partners (май 2024) опросило 600 программистов:

• 97% выше процент успеха для проектов с чёткими требованиями до разработки
• 50% больше успеха благодаря спецификации перед написанием кода
• 57% больше успеха благодаря точным требованиям
• 39% всех провалов связаны с плохими требованиями

Это было верно до ИИ. С ИИ это становится множителем.

Плохие требования с разработчиком-человеком? Медленный прогресс, раздражающий debugging.

Плохие требования с ИИ? ИИ создаёт именно то, что вы попросили. Быстро. Уверенно. Неправильно.

МУСОР НА ВХОДЕ — МУСОР НА ВЫХОДЕ. НА ГИПЕРСКОРОСТИ.

Работа изменилась

Раньше люди тратили годы, чтобы стать хорошими разработчиками. Понять, как работают системы. Знать подводные камни.

Теперь, с языковыми моделями и agentic (агентным) программированием, это меняется.

Разработчики становятся:

• Продуктовыми менеджерами
• Инженерами требований
• Бизнес-аналитиками

Но не только разработчики. Любой, кто знает, что хочет создать, теперь может создавать продукты с ИИ.

Вы описываете, что хотите. ИИ это создаёт.

Чем точнее ваше описание, тем лучше результат.

Что это значит для вас

Два варианта.

Можно продолжать давать ИИ размытые идеи. «Создай мне приложение, которое делает X». Смотреть, как он что-то производит. Отлаживать днями. Возможно, удалить.

Или можно инвестировать время заранее. Исследовать. Планировать. Писать детальные спецификации. А потом позволить ИИ исполнять.

Код больше не является работой. -> Ясность — вот что важно.

Планирование — это новый код.

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot