Гайд · доработка ИИ-продукта · сентябрь 2026
Собрал продукт на ИИ - что дальше: дорабатывай, не ломая
Продукт собран и работает, а следующий шаг страшнее первого: одна просьба «добавь ещё одно» может тихо снести то, что уже работало. По данным Cortex за 2026 год доля неудачных правок у команд с ИИ-кодогенерацией выросла на 30% - это цена пропущенной точки сохранения. Правило простое: рабочая копия перед правкой, одно изменение за раз, проверка сразу после
Прямо сейчас скопируй папку проекта и добавь к её имени сегодняшнюю дату - это займёт минуту и станет твоей первой точкой возврата. Дальше формулируй следующую просьбу к ИИ как одно предложение с одним действием, а не список из трёх задач подряд
Почему рабочий продукт вообще может сломаться от одной просьбы
ИИ не хранит в голове весь твой проект целиком: получив новую задачу, он может переписать больше файла, чем нужно было для неё, и задеть код, который вчера работал. Это не редкий сбой - это статистика по всей индустрии за 2026 год. Согласно «Engineering in the Age of AI: 2026 Benchmark Report» компании Cortex, у команд, активно использующих ИИ-кодогенерацию, доля неудачных изменений выросла примерно на 30%, а число инцидентов на одно изменение поднялось на 23,5% год к году
Прогон движка этого сайта (03.09.2026, повторён живьём 08.09.2026): взята тестовая страница с двумя пунктами списка, точка возврата сохранена git-коммитом, правка снесла старые пункты - и откат вернул файл одной командой. Полный вывод команд сохранён в логе рядом со статьёй
Прогон целиком: точка возврата - поломка - откат одной командой
- Точка возврата: рабочая версия закреплена коммитом «список дел показывает два пункта»
- Поломка: следующая правка снесла старые пункты (git diff показал: 1 файл, 4 вставки, 4 удаления)
- Откат: одна команда возврата файла - «файл вернулся к состоянию последнего коммита»
Дело не в том, что инструмент «плохой». Дело в том, что у него нет твоей интуиции насчёт того, что нельзя трогать - если ты явно не сказал об этом и не проверил результат сразу. Если ты вообще не умеешь читать код и не понимаешь, что именно проверять на экране, у меня есть отдельный разбор - как проверить код от ИИ, если не умеешь читать код: 7 проверок, эта статья продолжает его с того места, где продукт уже принят и стоит вопрос, как жить с ним дальше
Что значит «дорабатывать, не сломав работающее»
Значит ровно одно: после каждой новой правки всё, что уже работало вчера, продолжает работать сегодня. Не «в целом норм», а конкретно - та же кнопка нажимается, та же страница открывается, тот же результат выходит
Это разные задачи - «сделать новое» и «не сломать старое», и работают над ними по-разному:
| Что делаешь | Кто следит | Когда проверять |
|---|---|---|
| Просишь ИИ новую функцию | ИИ, по твоей формулировке задачи | Сразу после ответа, до следующей просьбы |
| Следишь, что старое не сломалось | Только ты, своими глазами | После КАЖДОЙ правки, не в конце дня |
| Откатываешься к рабочей версии | Ты, командой или заменой папки | В момент, когда заметил поломку |
Таблица прокручивается вбок →
ИИ хорошо решает первую задачу и плохо - вторую, потому что вторая требует помнить весь путь проекта, а не только последнюю просьбу. Если продукта у тебя пока нет вообще и ты только начинаешь - сначала загляни в вайбкодинг: что это простыми словами и как начать с нуля, эта статья про следующий шаг после того, как первая версия уже собрана и работает
Шаг 1: сохрани рабочую копию, прежде чем просить новую правку
Сделай снимок текущего рабочего состояния до того, как отправишь ИИ следующую задачу - командой или простым копированием папки с датой в названии
Шаг 1 на практике: два способа сохранить рабочую копию
- Способ для тех, кто уже открывал Claude Code напиши ИИ прямым текстом: «сохрани текущее рабочее состояние с понятным описанием того, что сейчас работает, чтобы потом можно было вернуться». Claude Code сделает это инструментом отслеживания версий сам, тебе не нужно знать, как называется команда
- Способ без единой команды скопируй всю папку проекта и переименуй копию, добавив сегодняшнюю дату: например, «мой-сайт-3-сентября». Через минуту у тебя есть точка возврата
- Что увидишь на экране в первом случае - короткое сообщение о том, что снимок сохранён. Во втором - новая папка с тем же содержимым рядом со старой
- Что это тебе даёт если следующая правка что-то сломает, ты вернёшься к этой точке за одну команду, а не будешь вспоминать, что именно нужно чинить
У Claude Code точки возврата есть и встроенные: официальная страница Checkpointing прямо пишет, что система сама отслеживает правки файлов и позволяет откатиться, если что-то пошло не так. Это подстраховка ПОВЕРХ твоей копии, а не замена ей:
Точка сохранения нужна перед КАЖДОЙ заметной правкой, а не один раз при старте проекта. Специалист по разработке через ИИ-инструменты формулирует это просто: сохраняй снимок перед тем, как просить ИИ поменять что-то важное, и фиксируй сразу после каждой рабочей задачи, а не в конце дня - именно так работает страховка, а не отчёт после факта. Если Claude Code у тебя ещё не установлен - с этого стоит начать: как пользоваться Claude Code: установка и 9 шагов до проекта
Шаг 2: проси ровно одно изменение за раз
Замени просьбу «сделай сразу три вещи» на одну конкретную задачу за раз, с проверкой между ними
Шаг 2 на практике
- Что написать вместо «поправь дизайн, добавь кнопку и почини форму» - три отдельных сообщения, одно за другим, с проверкой после каждого
- Что увидишь на экране меньше изменений за раз - меньше мест, где могла случиться поломка, и её проще найти, если она всё же произошла
- Что это тебе даёт если что-то сломалось после маленькой правки, ты точно знаешь, какая именно просьба это сделала - искать причину среди трёх задач сразу намного дольше
Правило одной правки особенно важно там, где цена ошибки высокая: форма с оплатой, отправка данных, всё, что видят твои посетители первым. На мелочи вроде цвета кнопки можно быть менее строгим, на форме с деньгами - нет. Формулировку самой просьбы к ИИ разбирает отдельный гайд - Claude промпт-инженер: 7 формул точного запроса без воды, узкая задача из одного предложения получается именно из точной формулировки
Как переформулировать широкую просьбу в узкую
Разница между «широкой» и «узкой» просьбой не в длине предложения, а в числе разных мест продукта, которые она затрагивает одновременно. Три живых примера переформулировки:
| Широкая просьба (рискованная) | Узкая просьба (безопасная) |
|---|---|
| «Поправь дизайн формы и сделай её понятнее» | «Увеличь размер текста в подписях полей формы, больше ничего не трогай» |
| «Сделай сайт быстрее и красивее» | «Сожми главную картинку на странице, чтобы она грузилась быстрее» |
| «Почини баг с оплатой и заодно обнови текст на кнопке» | «Почини баг с оплатой» - отдельным следующим сообщением: «теперь обнови текст на кнопке» |
Таблица прокручивается вбок →
Правая колонка в каждой строке решается ОДНОЙ правкой, которую легко проверить и легко отменить целиком. Левая колонка звучит как одна просьба, а на деле распадается на несколько независимых изменений сразу
Шаг 3: проверяй глазами сразу после каждой правки
Открой продукт и пройди то, что уже работало вчера - старые кнопки, старые страницы, старые сценарии - до того, как просить следующую задачу
Шаг 3 на практике
- Что открыть сам продукт в браузере или на телефоне - именно так, как его увидит обычный человек, а не только ответ ИИ в чате
- Что нажать по очереди все места, которые уже работали до сегодняшней правки: главную кнопку, форму, ссылку в меню - каждую
- Что увидишь на экране либо всё как было вчера, либо конкретное место, где что-то не открылось, не нажалось или показало не то
- Что это тебе даёт ты находишь поломку сразу, пока помнишь, что именно просил на этом шаге - а не через неделю, когда уже забыл, что менял
Второй прогон движка в том же демо показал, как выглядит правильная дисциплина на практике: в тот же список добавлен ровно один новый пункт, ничего больше не тронуто, и страница сразу открыта для проверки. Оба кадра ниже - реальные скрины этой страницы в браузере, прогон 08.09.2026:
Разница между двумя прогонами - не в инструменте и не в модели, а в дисциплине: в первом случае правка задела то, что не просили трогать, во втором - нет, потому что задача была одна и маленькая, а проверка сразу следом за ней. Если под рукой уже несколько таких помощников сразу и они работают в связке - у меня есть отдельный разбор, где команда агентов чаще всего ломается: мультиагентные системы простыми словами: 6 схем и 5 поломок
Шаг 4: если сломалось - откатывайся к сохранённой копии, а не проси чинить вслепую
Верни последнюю рабочую версию командой или заменой папки, и повтори ту же задачу меньшим шагом
Шаг 4 на практике
- Если сохранял точку через инструмент отслеживания версий напиши ИИ: «верни файл к последней сохранённой версии» - он сам подберёт нужную команду, ты просто описываешь результат, который хочешь получить
- Если сохранял копию папкой удали или переименуй сломанную папку и верни на её место копию с датой, которую делал в Шаге 1
- Что увидишь на экране продукт снова выглядит и работает так же, как до последней неудачной правки - за секунды, а не за час разбора того, что именно сломалось
- Что это тебе даёт ты не тратишь время на попытки «доисправить» сломанное поверх сломанного - у ИИ на это уходит ещё больше правок, каждая из которых рискует сломать что-то ещё
Автор гайда по этой практике для новичков без опыта программирования формулирует правило именно так: сравни изменения перед тем, как их зафиксировать, а если правка агента всё-таки сломала рабочую версию - откат к предыдущему сохранённому состоянию решает проблему быстрее, чем попытка почини поверх поломки. Если сама причина в том, что агент отчитался «готово», а результата на самом деле нет - это отдельный процессный вопрос, разобранный в гайде агент говорит «готово»: 4 шага, чтобы доделать до конца
Частые грабли при доработке своего продукта
Три ситуации, в которые новичок попадает чаще всего, когда только начинает применять эту дисциплину:
Три частые грабли
- Точка сохранения ставится «когда вспомнил», а не перед каждой правкой на третьей-четвёртой задаче за вечер кажется, что «эта правка точно мелкая», и точку пропускают - именно она потом и оказывается той самой, что всё сломала
- Проверка откладывается до конца дня «чтобы посмотреть всё разом» тогда поломку находят через пять правок после той, что её вызвала, и разбираться приходится в пяти местах вместо одного
- После поломки просят ИИ «почини, но не трогай остальное» вместо этого прежде отката: формулировка звучит как просьба к тому же самому агенту, который уже не увидел, что сломал что-то на прошлом шаге - откат к точке сохранения работает надёжнее
Что не входит в правило одной правки
Не каждое действие требует отдельной точки сохранения и отдельной проверки. Разница - в том, можно ли отменить действие одним нажатием прямо в интерфейсе или для отката нужна отдельная команда:
| Что меняешь | Нужна ли отдельная точка сохранения |
|---|---|
| Цвет кнопки, размер шрифта, текст на странице | Не обязательно - отменяется одним действием «Отменить» |
| Логика формы, отправка данных, работа с деньгами | Да, обязательно - ошибку здесь не всегда видно сразу |
| Порядок хранения записей о клиентах или заказах | Да, обязательно - и с двойной проверкой перед откатом |
| Подключение нового стороннего сервиса | Да - до подключения, чтобы можно было вернуться к состоянию «без него» |
Таблица прокручивается вбок →
Правило простое: чем труднее заметить поломку глазами и чем дороже её чинить постфактум, тем обязательнее точка сохранения перед правкой
Когда звать полную переделку вместо доработки
Иногда правильный ответ - не чинить очередную маленькую правку, а честно признать: дальше проще собрать заново, чем латать. Три признака, что дело идёт к этому:
Три признака, что пора не чинить, а пересобирать
- Одна и та же поломка возвращается третий раз подряд ты уже дважды откатывался к рабочей версии из-за похожей проблемы - это сигнал, что причина глубже одной правки
- Ты перестал понимать, что делает часть кода если правки накопились настолько, что даже прочитав файл целиком, не можешь сказать, зачем там тот или иной кусок - следующая правка вслепую опаснее прежних
- Откат перестаёт помогать ты вернулся к последней сохранённой копии, а проблема осталась - значит, поломка старше, чем твоя последняя точка сохранения, и нужен разбор с нуля, а не ещё один откат
В этих трёх случаях полезно начать новую, отдельно открытую сессию с ИИ, показать ему рабочую копию до всех правок и попросить пересобрать функцию с нуля, а не чинить нынешнюю версию - свежий взгляд без груза прежних правок часто находит более простое решение, чем десятая попытка исправить старое
Как всё это выглядит вместе на маленьком примере
Чтобы правила не оставались абстракцией, вот последовательность на одном маленьком проекте - той же простой странице со списком дел из прогона выше:
Пять действий подряд на маленьком проекте
- Собрал рабочую версию страница со списком из двух пунктов открывается и показывает оба пункта - это состояние проверено глазами
- Сохранил точку возврата командой, которая фиксирует текущее состояние с коротким описанием: «список дел показывает два пункта»
- Попросил одну правку «добавь третий пункт - полить цветы», ничего больше не менял
- Проверил результат сразу открыл страницу - все три пункта на месте, ничего не пропало
- Сохранил новую точку возврата с описанием того, что изменилось - теперь это новая точка, к которой можно вернуться при следующей неудачной правке
Полный вывод обеих команд сохранения приложен рядом со статьёй как есть, без сокращений - это то, что реально появилось на экране, а не пересказ того, что «наверное, сработало»
Куда идти дальше на этом же сайте
- Агент говорит «готово»: 4 шага, чтобы доделать до конца - как принять саму работу агента, если он отчитался «готово», а результат не виден. Эта статья - про следующий шаг: продукт уже принят и работает, вопрос в том, как его дорабатывать не ломая
- Как проверить код от ИИ, если не умеешь читать код: 7 проверок - семь конкретных проверок готового продукта руками, без чтения кода. Как проверить каждую доработку из этой статьи - там
- Вайбкодинг: что это простыми словами и как начать с нуля - с чего вообще начинается путь, если продукта ещё нет
- Как пользоваться Claude Code: установка и 9 шагов до проекта - если инструмент ещё не установлен
- Нейросеть пишет код: что умеет и где ломается - более широкий обзор цикла работы с нейросетью-программистом
- Безопасность автономных ИИ-агентов: 4 риска 2026 года - какие права давать агенту и что происходит при необратимых действиях
- Что делать после установки Claude Code: первые шаги - если инструмент уже стоит, но непонятно, куда двигаться
- ИИ-агенты: что это простыми словами и как собрать своего - с чего начинается разговор об автономных помощниках
- Мультиагентные системы простыми словами: 6 схем и 5 поломок - когда агентов в работе уже несколько
- Claude промпт-инженер: 7 формул точного запроса без воды - как формулировать одну узкую задачу вместо трёх сразу
- Скиллы для Claude: что это, как установить и 7 готовых под контент - готовые сценарии с чётким результатом вместо расплывчатой просьбы
- Настройка Claude Code бесплатно: запуск с нуля и выбор модели по ОЗУ - если нужно настроить инструмент под своё железо
- Лучший ИИ для вайб-кодинга: 4 инструмента в 2026 году - сравнение инструментов, если Claude Code ещё не выбор
- Cursor или Claude Code в 2026 году: разница в 6 раз на тесте - если выбираешь между двумя конкретными инструментами
- Бесплатный ИИ-агент для VS Code: 3 пути без оплаты в 2026 - бесплатные варианты того же класса инструментов
- Файл CLAUDE.md - как хранить постоянные правила проекта, которые видят все роли и не переспрашивать их каждый раз
- Цикл работы Claude - как помощник крутит задачу до конца, включая момент, когда сам считает её завершённой
- Инструменты Claude - чем агент вообще умеет пользоваться при правке твоего проекта
- Как выбрать курс вайбкодинга: 5 этапов и 6 красных флагов - если решаешь пойти учиться этому системно
- Claude Code: гайды по установке, работе и агентам - полный список моих статей про инструмент и агентов
Источники
Ниже страницы, открытые живьём при подготовке этой статьи 3 сентября 2026 года:
- Cortex, «Engineering in the Age of AI: 2026 Benchmark Report» - рост инцидентов на изменение на 23,5% и рост доли неудачных изменений примерно на 30% год к году - kusari.dev, разбор отчёта Cortex
- Deepak Ness, «Git and GitHub for Vibe Coders» - практика точки сохранения перед правкой ИИ и коммита сразу после рабочей фичи - deepakness.com, git for vibe coders
- Mark Chen, «Git for Vibe Coders: A Beginner's Survival Guide» - откат к предыдущему коммиту как страховка от правки, которая ломает рабочий код - medium.com, git for vibe coders survival guide
- Softr, «9 vibe coding best practices» - дисциплина маленьких изменений с проверкой между ними - softr.io, vibe coding best practices
- Anthropic, документация Claude Code, раздел про историю изменений и откат правок в рабочей сессии - code.claude.com, best practices
Памятка: доработал продукт на ИИ - что проверить, чтобы не сломать рабочее
Шесть строк, по которым проходит вся дисциплина доработки
Сохрани себе
- Перед каждой заметной правкой - точка сохранения: команда сохранения версии или копия папки с датой
- Одна просьба - одна конкретная правка, не список из трёх задач сразу
- После каждой правки - проверка глазами: то, что работало вчера, работает и сегодня
- Форма с деньгами и структура данных - точка сохранения обязательна всегда, без исключений
- Сломалось - откатывайся к сохранённой копии, а не проси чинить поверх сломанного
- Поломка вернулась третий раз - время не чинить, а пересобрать с нуля в новой сессии
Порог входа
Первая точка сохранения бесплатна, следующая привычка тоже
Точку сохранения, одну правку за раз и проверку сразу после - всё это можно начать применять на своём продукте уже сегодня, без единой новой установки
Три дня, бесплатно, доступ открывается сразу, ждать даты не нужно
Это заявка в мой закрытый канал, не оплата. Впускаю сразу, дальше бот в личке отдаёт путёвку на три дня
Частые вопросы
Что делать, если ИИ уже сломал рабочий продукт, а точки сохранения нет?
Попроси ИИ показать список всех изменений, которые он внёс за последнюю просьбу - большинство инструментов, включая Claude Code, хранят историю правок даже без явного сохранения командой. Дальше отменяешь только те изменения, что относятся к последней просьбе, а не всё подряд. На будущее - точка сохранения перед следующей же правкой, чтобы больше не оказаться в этой ситуации
Обязательно ли использовать git, если я вообще не программист?
Нет. Простое копирование папки проекта с датой в названии даёт ту же страховку - точку, к которой можно вернуться. Git удобнее на десятой правке, потому что не копит десятки папок, но для старта хватает и обычного копирования
Как понять, что правка была «слишком большой» и её стоило разбить?
Если после одной просьбы к ИИ ты не можешь быстро объяснить своими словами, что именно изменилось - просьба была слишком широкой. Хорошая правка укладывается в одно предложение: «добавил кнопку», «поправил цвет текста», «починил отправку формы». Если предложений нужно три - это были три разные задачи
Почему нельзя просто попросить ИИ «внимательнее» на следующий раз?
Потому что просьба «будь внимательнее» не создаёт новой проверки - ИИ не хранит между сессиями память о том, что именно нельзя трогать, если ты явно не показал это точкой сохранения и не разбил задачу на маленькие шаги. Работает не более строгая формулировка, а более узкая задача плюс проверка сразу после неё
Что делать, если после отката проблема всё равно осталась?
Значит поломка случилась раньше, чем твоя последняя точка сохранения. Откатись на одну точку назад, если она есть, и проверь снова. Если точек сохранения не было достаточно часто - это и есть повод завести привычку сохранять чаще, начиная с этой минуты