Разработчица опубликовала на Habr разбор того, как ИИ-агенты меняют цикл разработки продукта (PDLC) на личных проектах. Она использовала Cursor с Claude, GPT-4o и GigaCode, локальные Qwen2.5-Coder и DeepSeek-Coder через Ollama, а также LangGraph и OpenHands для автономных задач. Вывод: ускорение есть, но оно неравномерно и требует перестройки процесса.
Самый чистый выигрыш — планирование. Вместо того чтобы сразу писать код, разработчица формулирует намерение: цель, ограничения, edge-cases и требования к безопасности. Затем агент готовит спецификацию, acceptance criteria, декомпозицию, черновик архитектуры и список рисков. После ручного ревью такой план занимает 30–60 минут вместо одного-двух вечеров. Агенты хорошо находят противоречия и забытые сценарии — это стабильный эффект.
| Тип задачи | Ускорение |
|---|---|
| CRUD, API-интеграции, миграции, тесты, рефакторинг | 2,5–4 раза |
| Новая бизнес-логика и архитектурные решения | 1,3–1,8 раза |
| Планирование (спецификация, acceptance criteria, декомпозиция) | 30–60 минут вместо 1–2 вечеров |
Генерация кода ускоряется, но не бесплатно. На типовых задачах — CRUD, API-интеграциях, миграциях, тестах и рефакторинге — ускорение составило примерно 2,5–4 раза. На новой бизнес-логике и архитектурных решениях — 1,3–1,8 раза. Иногда ИИ замедлял работу. Главная иллюзия — ощущение, что агент написал 70–80% готового кода. После ревью, исправлений, интеграции и проверки качества значительная часть времени уходила на понимание результата. Вместо набора символов разработчица занималась проверкой и исправлением.
На CRUD, API-интеграциях, миграциях и тестах ускорение достигает 2,5–4 раз, на новой бизнес-логике — 1,3–1,8 раза.
Чаще всего встречались несуществующие методы и API, код, плохо вписывающийся в архитектуру проекта, пропущенные проверки и уязвимости, а также чрезмерно уверенные, но ошибочные объяснения. В одиночной разработке нет полноценного code review, поэтому использовался отдельный ИИ-ревьюер с правилами проекта, статический анализ, автотесты и property-based тестирование. Unit-тесты агенты пишут неплохо, но сложные сценарии и e2e требуют значительного участия человека. Критичные участки — безопасность, архитектура и сложная бизнес-логика — всегда просматриваются вручную.
Безопасность стала главным bottleneck. Даже в pet-проектах агенты регулярно предлагали SQL-инъекции, XSS, hard-coded секреты и некорректную обработку данных. Добавились специфические риски: prompt injection через входные данные, утечки через логи агентов и supply-chain риски инструментов и зависимостей. Разработчица добавила security-checklist в skills агентов, ввела отдельный security-ревью и стала описывать требования безопасности уже на этапе спецификации. Для чувствительного кода используются локальные модели. Это снизило количество очевидных ошибок, но не отменило ручную проверку. Скорость генерации кода легко опережает скорость его контроля.
Что сработало: подготовка спецификаций и планирование, типовой код и unit-тесты, исследование вариантов реализации, анализ и документирование существующего кода. Что оказалось иллюзией: рост скорости в несколько раз без учёта ревью, почти безошибочная работа агентов, отсутствие необходимости думать о безопасности в личных проектах. ИИ меняет роль тестировщика и разработчика: меньше ручного кода, больше оркестрации агентов, владения качеством и безопасностью. Измерять стоит не скорость генерации, а время до рабочего, поддерживаемого и безопасного результата. Лучший эффект дают не отдельные промпты, а процесс: намерение → спецификация → реализация → тестирование → ревью. Open-source модели уже закрывают значительную часть повседневных задач, особенно при наличии хорошего контекста и инструментов. Но на сложных задачах закрытые модели пока часто выигрывают по качеству. Самый важный навык сейчас — не умение получить код от агента, а способность правильно поставить задачу и строго проверить результат.
