Подходы к разработке: прототип, план и маленькие шаги
Выберите способ под вопрос
Одним запросом можно получить черновик приложения. Если нужно лишь понять, подходит ли идея, это полезный опыт. Если нужно сохранить пользовательские данные или изменить существующий проект, сначала определите поведение и способ проверки.
| Подход | Когда подходит | Что предъявить в конце |
|---|---|---|
| Быстрый прототип | Проверить идею или способ взаимодействия | Демонстрацию и список ограничений |
| Разработка по спецификации | Поведение уже можно описать | Соответствие критериям и результаты проверок |
| Проверка до реализации | Важен конкретный контракт | Тест, который отличает ошибку от исправления |
| Работа с существующим проектом | Нужно сохранить прежнее поведение | Узкое изменение и проверку затронутых сценариев |
Проверка до реализации часто называется TDD, когда разработка идёт короткими циклами: падающий тест, минимальное исправление, улучшение структуры. Новичок может поручить написание теста агенту, но должен понять, какой случай тест проверяет. Падающий тест из-за опечатки в импорте не доказывает отсутствие нужной функции.
Один законченный сценарий
Вместо «создай весь менеджер» сначала реализуйте добавление и чтение задачи после перезапуска. Этот шаг проходит через ввод, сохранение и чтение данных. Его часто называют вертикальным срезом: в нём есть весь путь одного действия, а не большой слой кода без пользовательского результата.
Рабочий цикл курса:
Прочитать текущее состояние → выбрать одно требование →
уточнить проверку → сделать узкое изменение →
запустить проверку → посмотреть diff → сохранить результат.После add переходите к done, затем к обработке ошибок. Не добавляйте параллельно интерфейс, авторизацию и миграции. Когда маленький шаг ломается, проще понять причину и восстановить состояние.
Как вести разговор при ошибке
Плохое продолжение: «Не работает, исправь всё». Полезное продолжение содержит команду, ожидаемое поведение и факт:
Команда add с названием из пробелов завершилась успешно.
Ожидалось: ненулевой код и неизменный файл данных.
Найди причину. Добавь проверку этого случая и исправь
только обработку названия. Остальные требования сохраняются.После двух одинаковых неудачных попыток прекратите слепые повторы. Попросите сформулировать разные гипотезы и выбрать опыт, который их различит. Например, если список пуст, проверьте, действительно ли запускалась программа с тем же --file, прежде чем менять сохранение.
Работа с чужим кодом
Сначала попросите найти входную точку и связанные проверки. Новый агент не обязан знать договорённости проекта. Не поручайте «упростить всё» одновременно с исправлением ошибки: большой diff затрудняет выяснение, какое изменение повлияло на поведение.
Если нужны новые зависимости, агент должен объяснить, чего не хватает стандартным инструментам, как будет проверяться установка и кто станет поддерживать зависимость. В нашем проекте достаточно стандартной библиотеки Python.
Самостоятельное задание
Разбейте SPEC.md на три последовательных шага. Для первого шага попросите агента назвать способ проверки, затем реализовать его. Запишите один случай, в котором пришлось уточнить исходный запрос. Сохраните diff и результат проверки до перехода ко второму шагу.
Критерии и разбор
Первый шаг уже даёт наблюдаемый результат, а его проверка не зависит от незавершённых функций. Полный комплект тестов может пока падать из-за done; это нужно явно записать. Не объявляйте весь проект готовым по успешной проверке только add.