AI Coding

Links:

Test-Driven Development (TDD)

Полезен «красно-зелёный TDD»: то есть стоит не просто «сначала написать все тесты», а действовать по такому циклу:

  • Новый тест сначала должен падать (иначе что он проверяет?)
  • Затем требуется сделать минимальное изменение кода, чтобы тест начал проходить.
  • А дальше надо рефакторить, превращая код из «просто срабатывающего» в «полноценный». Пример промта:
Build a Python function to extract headers from a markdown string. Use red/green TDD.

❗ИИ нельзя позволять менять тесты (если считает это необходимым, то должен объяснить причину). А на случай, если это всё-таки произойдёт, в CI нужен hook, который блокирует PR с такими изменениями.

Spec-Driven Development (SDD)

Всё значимое требуется фиксировать. При этом можно быстро проверять гипотезы на практике и подстраиваться на ходу: “Сделай тут тремя разными способами, а мы сравним результаты “вживую” и выберем”.

Экономия контекста и токенов при чтениях

Краткий и точный контекст - это самое важное. Нужно давать агенту ровно ту часть системы, которая нужна для конкретного изменения.

  • Формулировать задачу узко: измени только валидацию в этом методе, работай в пределах этих двух файлов;
  • Структура проекта понятна и предсказуема: предсказуемые названия файлов, понятное разделение по слоям, внятные README.md;
  • Карта проекта и ограничения: где находится нужный модуль, что считается точкой входа, где лежит бизнес-логика, а где тесты или вспомогательные части. И можно сразу уточнять, какая часть карты актуальна для текущей задачи: какой модуль трогать, какие директории релевантны, а где не нужно ничего менять;
  • Фиксировать архитектурные правила отдельно: важные инварианты вроде «этот слой не ходит напрямую в БД», «этот модуль не импортирует этот пакет» или «новую логику добавляем только через такой паттерн» агенту лучше знать заранее;
  • Разделять поиск, понимание и изменение: сначала дать агенту задачу поиска релевантных файлов и посмотреть, не “увело” ли его. Затем задачу понимания: что именно в них отвечает за нужное поведение. “Если агент плохо справляется с задачей - попробуй её декомпозировать”.

Выбор стека: типизация и “стандартизация”

Cтатическая типизация позволяет поймать ряд ошибок ИИ. Для LLM “удобнее”, когда что-то часто встречалось в обучающем датасете. Если на GitHub есть тысячи “Тетрисов” на JavaScript, то агенту будет легко сделать ещё один. Хуже обстоят дела с малоизвестными вещами и с совсем новыми, вышедшими уже после даты «knowledge cutoff» ИИ-модели.

Подход к Git

Todo

Риск-менеджмент

Todo

Понимание ИИ

Todo

Понимание программирования

Todo

Обучение программированию

Todo