Экран 1 из 15. Учебный текст и практика сохранены полностью.
БАЗА GUIDE 04 / 20 · МАРШРУТ НОВИЧКА

Как проходить этот гайд, если ты вообще не программист

Читать сейчас?Да. Это обязательная привычка перед любой серьёзной задачей ИИ.
Внедрять сейчас?Да. Сформулируй результат, критерии готовности и доказательства до активного кодинга.
Зачем это знать?Без этого новичок легко принимает фразу ИИ «готово» за реальный результат.

Что сделать по шагам

  1. Одним предложением опиши полезный результат для пользователя.
  2. Запиши 3-7 критериев, на которые можно ответить да или нет.
  3. Определи, чем ты докажешь каждый критерий: тестом, ссылкой, логом, скриншотом или реальным сценарием.
Урок закрыт, когда: Есть PROJECT_BRIEF.md, понятные критерии готовности и способ доказать главный пользовательский сценарий.
Простой пример: Не «сделать бота», а «пользователь отправляет голосовое до 10 минут и получает структурированный отчёт; если файл плохой, видит понятную ошибку».

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

1 / 15
Хардкодинг PRO · Гайд №04

Как понять, что ИИ действительно закончил задачу

Практический стандарт приёмки AI-задач: как превратить «ИИ что-то сделал» в проверенный, воспроизводимый и готовый к использованию результат.

Павел Думбрао · практический материал для учеников
Критерии приёмкиОпределение готовностиMVPПроверка результата

Что ты должен уметь после гайда

1
Отделять написанный код от реально решённой задачи.
2
Формулировать критерии так, чтобы на них можно было ответить да / нет, а не «вроде нормально».
3
Ограничивать первую версию продукта и не разрешать ИИ бесконечно раздувать проект.
4
Требовать от ИИ-кодера доказательства результата: тесты, логи, работающий сценарий, ссылку или другой проверяемый артефакт.
Обложка гайда с Павлом
Показать полное оглавление гайда
2 / 15

15 учебных экранов · 9 схем · 3 практических промпта · 20 критериев проверки. Редакция 09.10.2026; интерфейсы инструментов могут меняться.

1. Почему ИИ говорит «готово», когда не готово

В вайбкодинге это происходит постоянно. Ты просишь ИИ создать функцию, он пишет код, создаёт файлы и через несколько минут сообщает: «Готово». Но код ещё может не запускаться, сценарий пользователя может быть не проверен, а после перезапуска сервера всё вообще может перестать работать.

Версия ИИ

  • написал код;
  • создал файлы;
  • не видит очевидной ошибки;
  • сообщил «готово».

Версия инженера

  • прошёл сценарий пользователя;
  • протестировал функцию;
  • увидел реальный результат;
  • может доказать, что всё работает.
Главное правило: слова ИИ не являются доказательством. Доказательство - это работающий сценарий, тест, лог, ссылка, скрин или фактический результат.
Ключевая мысльГотовность - не сообщение модели. Готовность - состояние системы, которое можно независимо проверить и повторить.

Четыре уровня «готово»

1
Код существует.
ИИ создал файлы или изменил проект. Это только начало, а не завершение.
2
Технически запускается.
Проект стартует без критической ошибки, зависимости на месте, сервис отвечает.
3
Пользователь получает ценность.
Человек проходит основной сценарий и получает именно тот результат, ради которого создавалась функция.
4
Результат можно воспроизвести.
После перезапуска, новой сессии или передачи другому человеку система продолжает работать предсказуемо.
Для курса Хардкодинг PRO задача считается закрытой только с уровня 3. Для боевого продукта стремимся к уровню 4.
Версия ИИ и версия инженера
3 / 15

2. Карта мышления: сначала результат, потом ИИ

Наша задача не научиться вручную писать код. Наша задача - научиться управлять процессом. Поэтому сначала формулируем результат, потом проектируем, только после этого отправляем исполнителя писать код.

1
Идея
Что мы хотим получить и какую проблему решить.
2
ChatGPT как архитектор
Уточняет задачу, исследует решения, задаёт вопросы.
3
Техническое задание
Фиксирует, что должно работать и как проверить.
4
Codex как исполнитель
Реализует задачу небольшими проверяемыми этапами.
5
Проверка и запуск
Мы принимаем не обещание, а доказанный результат.

Твоя роль

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

Роль ИИ

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

Разделяй роли: архитектор помогает сформулировать решение, исполнитель строит, тест проверяет, а финальное решение «принимаю / не принимаю» остаётся у владельца проекта.
Карта мышления подход через ИИ
4 / 15

3. Критерии приёмки

Критерии приёмки (Acceptance Criteria) - конкретные условия, по которым мы понимаем, что функция действительно работает.

Простой вопрос: что именно должно произойти, чтобы я сказал: «Да, эта функция работает»?
Telegram-ботПользователь написал → бот ответил → данные сохранились → ошибка обработана.
Сайт-визиткаОткрывается с телефона, понятно кто ты, кнопка Telegram работает, нет горизонтального скролла.
Hermes-ассистентСообщение отправлено → Hermes ответил → работает на VPS → продолжает работать после перезагрузки.
AI-менеджерИз 20 тестовых вопросов минимум 18 обработаны корректно, на неизвестные вопросы не фантазирует.
Запомни: проверяем не код. Проверяем результат.

Каким должен быть хороший критерий

Условие → действие → наблюдаемый результат

Критерий должен быть понятен человеку, который не участвовал в разработке. Если для проверки нужно «поверить разработчику», критерий написан плохо.

Плохо:
«Бот отвечает быстро».
«Сайт красивый».
«Память работает хорошо».

Это оценки, а не проверяемые условия.
Хорошо:
«После сообщения бот возвращает ответ и не зависает».
«На телефоне страница помещается по ширине, кнопки нажимаются».
«После сохранения факта ассистент может восстановить его в новой сессии».

Пять правил критериев приёмки

1
Наблюдаемость. Результат можно увидеть, измерить или воспроизвести.
2
Однозначность. Два человека не должны понимать критерий совершенно по-разному.
3
Связь с пользователем. Проверяем не красоту кода, а полезное поведение продукта.
4
Минимум лишнего. Критерий относится к текущей версии, а не ко всем будущим хотелкам.
5
Возможность ответить да / нет. Если ответ «ну почти», значит критерий надо уточнить.
Практический минимум: перед серьёзной задачей напиши 5-10 критериев. Этого достаточно, чтобы резко уменьшить хаос между тобой и AI-кодером.
Критерии приёмки на примере бота
5 / 15

4. Определение готовности

Определение готовности (критерии готовности) - общий чек-лист, после которого задачу действительно можно закрыть.

✓
Работает
Главный сценарий проходит от начала до конца.
✓
Протестировано
Результат проверен, а не просто написан.
✓
Сохранено
Рабочая версия зафиксирована в Git.
✓
Безопасно
Секреты не лежат в коде, критические риски понятны.
✓
Можно передать
Другой человек или ИИ поймёт, как проект запустить и продолжить.

Чем это отличается от критериев приёмки

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

Базовый стандарт Хардкодинг PRO

ФункциональностьОсновной пользовательский сценарий реально проходит от начала до конца.
ПроверкаЕсть конкретные результаты тестов, а не только сообщение ИИ «готово».
СохранностьРабочее состояние зафиксировано в Git или другим понятным способом.
БезопасностьСекреты не опубликованы, опасные действия контролируются, известные критические риски закрыты.
ПередаваемостьЕсть минимум документации: что это, как запустить, что проверено, что делать дальше.
Важно: критерии готовности не должен превращаться в бюрократию. Это короткий страховочный ремень, который не даёт тебе каждый раз заново выяснять, «а точно ли мы это закончили?».
Определение готовности
6 / 15

5. Минимально рабочий продукт

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

MVP = минимум функций, но не минимум качества. Одна функция должна быть доведена до рабочего результата.
Не MVP:
бот + оплата + CRM + RAG + Telethon + 8 моделей + аналитика + рефералка, при этом основной сценарий постоянно ломается.
MVP:
пользователь пишет тему → система создаёт хороший Telegram-пост → пользователь получает результат. Один сценарий, но он работает.

Почему ученики часто перегружают первый продукт

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

Сначала ценность → потом расширение

Парковка идей

Всё полезное, что приходит в голову во время разработки, не обязательно делать сейчас. Создай список «После MVP» и складывай туда идеи. Так ты не теряешь задумки, но сохраняешь фокус.

Минимально рабочий продукт
7 / 15

6. Основной успешный сценарий

Основной успешный сценарий - самый короткий путь пользователя от входа в продукт до получения ценности.

Пользователь → действие → система → полезный результат

Если этот путь ещё не работает, рано заниматься второстепенными экранами, сложной автоматизацией и красивыми дополнительными функциями.

Пример: AI-бот для клиентов

1
Клиент пишет вопрос.
Это понятная точка входа.
2
Система понимает запрос.
Находит нужную информацию или понимает, что ответа нет.
3
ИИ формирует ответ.
Ответ соответствует базе и правилам.
4
Клиент получает пользу.
Ответ пришёл, данные сохранены, следующий шаг понятен.
Вертикальный срез: лучше один полностью работающий путь через весь продукт, чем пять наполовину готовых модулей.
Основной успешный сценарий
8 / 15

7. Нестандартные ситуации

Нестандартные ситуации (Edge Cases) - случаи, когда пользователь или внешний сервис ведут себя не так, как мы ожидали.

Что может случиться

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

Что должен сделать продукт

  • заметить проблему;
  • не потерять данные;
  • показать понятную ошибку;
  • при необходимости повторить действие;
  • уведомить владельца;
  • восстановить работу.
Не надо закрывать все редкие случаи в первой версии. Сначала закрой критичные: потеря денег, данных, доступа и полный отказ основного сценария.
Нестандартные ситуации
9 / 15

8. Что считается доказательством результата

Главная привычка сильного вайбкодера: отделять заявление от доказательства. Фраза «я всё сделал» сама по себе ничего не подтверждает.

Слабое доказательство
ИИ написал «готово». Код выглядит логично. Файлы существуют.
Среднее доказательство
Команда запуска прошла, отдельная функция ответила, есть скрин одного шага.
Сильное доказательство
Основной сценарий пройден от начала до конца, тесты показывают PASS, результат увидел реальный пользователь.
Лучшее доказательство
Сценарий воспроизводится после перезапуска и в новой сессии, есть логи и понятный отчёт о проверке.

Как должен отчитываться AI-кодер

Что сделалКоротко перечислил изменения и затронутые компоненты.
Что проверилКаждый критерий приёмки отдельно.
Чем проверилТест, команда, реальный запрос, браузер, устройство или лог.
Что получилосьКонкретный результат: PASS / FAIL, код ответа, время, ссылка, сообщение.
Что не провереноПрямо обозначил неизвестные места вместо догадки.
Рабочий принцип: Заявление ≠ доказательство. Слова ИИ не равны факту.
10 / 15

9. Семь ошибок при приёмке работы ИИ

1
Верить слову «готово». Всегда требуй фактическую проверку.
2
Тестировать только идеальный сценарий. Проверь хотя бы основные ошибки.
3
Добавлять новые функции до завершения текущей. Сначала закрой одну версию.
4
Не фиксировать рабочее состояние. Перед следующим большим изменением нужен Git / checkpoint.
5
Путать красивый интерфейс с готовым продуктом. Ценность важнее макета.
6
Не определять, что сейчас не делаем. Без границ MVP бесконечно расширяется.
7
Не уметь объяснить результат своими словами. Если ты не понимаешь, что построено, образовательная задача ещё не закрыта.
11 / 15

10. Практика: сначала ChatGPT, потом Codex

Возьми свой реальный проект. Перед кодингом заставь ИИ помочь тебе сформулировать результат, критерии, границы первой версии и способ проверки.

Промпт для ChatGPT: проектирование

Перед тем как сказать ИИ делай

Промпт для Codex: реализация и доказательство

Шаблон PROJECT_BRIEF.md

12 / 15

11. Чек-лист самопроверки

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

А. Результат и фокус

Б. Критерии приёмки

В. Фактическая проверка

Г. Сохранность и передача

Как оценивать результат

18-20 галочек: задачу можно закрывать. 14-17: продукт уже работает, но есть технический долг. 13 и меньше: задача ещё не готова, даже если ИИ говорит обратное.

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

Финальная проверка

ИИ написал код, тесты не запускал, но уверенно сказал «готово». Задача закончена?

Нет. Код существует, но готовность не доказана. Нужен работающий сценарий и фактическая проверка.
13 / 15

Отмечено 0 из 20 пунктов самопроверки.

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

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

Результат → критерии → реализация → проверка → доказательство
Запомни: не верим словам ИИ. Принимаем работу по доказательствам.
14 / 15
Пройти финальную самопроверку
🧠 WIKI ЭТОГО ГАЙДА

Непонятные слова простыми словами

Не зубри определения. Вернись сюда, если встретил термин и забыл, что он означает.

Критерий приёмкиПростое условие, по которому можно ответить: задача сделана или нет.
Definition of DoneОбщий список того, что должно быть выполнено перед словами «готово».
EvidenceПроверяемое доказательство результата: ссылка, скриншот, тест, лог, файл или конкретное число.
Smoke testОчень быстрая проверка: проект вообще запускается и главный путь не сломан.
RegressionПовторная проверка старых функций после нового изменения.
MVPМинимальная версия продукта, которая уже даёт полезный результат реальному человеку.
Перед переходом дальше: Переходи дальше, когда сделал минимальную практику этого урока и можешь показать результат. Кнопка «Дальше» означает следующий учебный урок, а не обязанность внедрить каждую технологию.
15 / 15