Разработка с ИИ
О разделе
Заголовок раздела «О разделе»Разработка — направление, где ИИ прижился раньше остальных и глубже встроен в ежедневную работу. Но «AI-ассистент» — это не один инструмент и не один сценарий. Раздел разделён на две части, которые нужно держать в голове отдельно:
- Возможности — что именно модель делает с кодом: дописывает строку, отвечает в чате, правит несколько файлов сразу, разбирается в незнакомой кодовой базе.
- Процесс — как встроить эти возможности в работу так, чтобы скорость не превратилась в долг: спецификация, тесты, ревью, границы автономии.
Смешивать их — типичная ошибка. Смена инструмента не исправляет процесс, а хороший процесс не спасает от инструмента, который не видит контекст проекта.
Три уровня взаимодействия
Заголовок раздела «Три уровня взаимодействия»| Уровень | Что происходит | Цена ошибки | Где разобрано |
|---|---|---|---|
| Автодополнение | Модель предлагает продолжение строки или блока прямо в редакторе | Низкая: предложение видно до принятия | Автодополнение и inline-правки |
| Диалог и правки | Модель по запросу меняет выбранный фрагмент, файл или несколько файлов | Средняя: нужен просмотр diff и проверка | Генерация кода и структурные правки |
| Агент | Модель сама ищет контекст, планирует, правит, запускает тесты и команды | Высокая: результат зависит от прав и проверок | Агентные системы |
Граница между вторым и третьим уровнем размыта: современные среды умеют и то, и другое. Важнее не название режима, а сколько шагов модель выполняет без человека и что её ограничивает — этот вопрос разбирает раздел Guardrails.
Возможности: что модель делает с кодом
Заголовок раздела «Возможности: что модель делает с кодом»- Автодополнение и inline-правки — fill-in-the-middle, ghost text, next-edit suggestions: почему это отдельный класс задач с жёстким бюджетом задержки.
- Генерация и структурные правки — от промпта к diff: многофайловые изменения, правки по AST и LSP, проверка перед применением.
- Понимание кодовой базы — индексация, поиск по символам, repo map и контекст-инжиниринг: почему агент «не видит» проект и что с этим делать.
- Ассистенты и среды — Cursor, GitHub Copilot, Claude Code, v0, Lovable и Bolt: чем отличаются харнессы при одной и той же модели.
Процесс: как встроить в работу
Заголовок раздела «Процесс: как встроить в работу»- SDLC и разработка с AI — жизненный цикл, роли человека и агента, место спецификации и проверок.
- Vibe coding — быстрый исследовательский цикл, условия перехода к поддерживаемому коду и экономика токенов.
- SDD: разработка по спецификации — спецификация как ориентир для планирования, реализации и приёмки.
- TDD: разработка через тесты — короткий цикл «тест — код — рефакторинг» с ассистентом.
Это не конкурирующие варианты. SDD задаёт, что строим; TDD проверяет поведение внутри реализации; vibe coding помогает быстро проверить гипотезу до формализации; SDLC связывает всё в этапы от требований до эксплуатации.
Пример: три скилла для SDD, TDD и AI-SDLC
Заголовок раздела «Пример: три скилла для SDD, TDD и AI-SDLC»dd-sdd — пример набора из трёх скиллов, который превращает эти практики в связанный рабочий процесс. Пакет разделяет постановку задачи, реализацию и независимую проверку:
| Скилл | Роль в цикле | Связь с практиками |
|---|---|---|
dd-discovery | Изучает состояние проекта, уточняет проблему и готовит RFC с границами, планом и критериями приёмки. | Discovery-трек Dual-Track Agile; SDD через спецификацию до начала реализации. |
dd-delivery | Реализует RFC, отмечает критерии, запускает тесты, добавляет инструкцию проверки и обновляет актуальные спеки. | Delivery-трек; этап реализации SDLC; тестирование по критериям спецификации — практическая опора для TDD-цикла. |
dd-code-review | Проверяет diff на баги, безопасность, архитектуру, соответствие спекам и тестам; выдаёт замечания без самостоятельного изменения кода. | Контроль качества и review перед выпуском в SDLC; проверка результата Delivery. |
Поток: Discovery оформляет RFC → Delivery реализует и проверяет критерии → Code Review оценивает изменения → результат и актуальные спеки возвращаются в следующий цикл. В репозитории предусмотрены активные RFC, архив RFC и docs/specs/, где хранится описание текущего поведения системы.
Что проверять в проекте
Заголовок раздела «Что проверять в проекте»- Видит ли инструмент проект. Автодополнение с одним файлом в контексте и агент с индексом репозитория дают разный результат на одной модели. См. Понимание кодовой базы.
- Кто запускает проверки. Пока тесты, типы и линтер не запускаются автоматически, «код сгенерирован» не значит «код работает».
- Какие права у агента. Запись в репозиторий, доступ к секретам, команды в shell — это отдельные решения, а не побочный эффект удобного инструмента.
- Остаются ли следы. Diff, план, лог проверок и причина изменения нужны не для отчётности, а чтобы разобрать инцидент через месяц.
Связанные материалы
Заголовок раздела «Связанные материалы»- Агентные системы — что должно быть в агенте, чтобы процесс на нём держался.
- Оценка качества — как проверять результат изменений, а не впечатление от них.
- Guardrails — ограничения на действия агента в репозитории.
- Контекст для агентов — какие файлы проекта агент читает перед работой.
Материалы и источники
Заголовок раздела «Материалы и источники»- Исходное видео об AI-driven SDLC
- Репозиторий dd-sdd
- AI developer tools: the 2026 guide — таксономия ассистентов, агентов и слоя retrieval поверх кода
- Addy Osmani. My LLM coding workflow going into 2026 — практика планирования и «context packing»