AI‑Disrupt PDLC на практике: где ИИ реально ускоряет, а где создаёт иллюзию продуктивности (опыт на личных проектах)

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

Планирование — самый чистый выигрыш

Раньше я часто начинала писать код «с коленки». Теперь сначала формулирую намерение: цель, ограничения, edge-cases и требования к безопасности. Затем агент помогает подготовить спецификацию, acceptance criteria, декомпозицию, черновик архитектуры и список рисков.

После ручного ревью такой план занимает 30–60 минут вместо одного-двух вечеров. Здесь ускорение оказалось стабильным: агенты хорошо находят противоречия и забытые сценарии.

Генерация кода: быстро, но не бесплатно

В работе я использовала Cursor с Claude, GPT-4o и GigaCode, локальные Qwen2.5-Coder и DeepSeek-Coder через Ollama, а также LangGraph и OpenHands для более автономных задач.

На типовых задачах — CRUD, API-интеграциях, миграциях, тестах и рефакторинге — ускорение составляло примерно 2,5–4 раза. На новой бизнес-логике и архитектурных решениях — 1,3–1,8 раза. Иногда ИИ даже замедлял работу.

Главная иллюзия — ощущение, что агент написал 70–80% готового кода. После ревью, исправлений, интеграции и проверки качества значительная часть времени всё равно уходила на понимание результата. Просто вместо набора символов я занималась проверкой и исправлением.

Чаще всего встречались:

• несуществующие методы и API;

• код, который плохо вписывается в архитектуру проекта;

• пропущенные проверки и уязвимости;

• чрезмерно уверенные, но ошибочные объяснения.

Ревью и тестирование

В одиночной разработке нет полноценного code review, поэтому я использовала отдельный AI-ревьюер с правилами проекта, статический анализ, автотесты и property-based тестирование.

Unit-тесты агенты пишут неплохо, но сложные сценарии и e2e требуют значительного участия человека. Критичные участки — безопасность, архитектура и сложная бизнес-логика — я всегда просматриваю вручную.

Безопасность стала главным bottleneck

Даже в pet-проектах агенты регулярно предлагали небезопасные решения: SQL-инъекции, XSS, hard-coded секреты и некорректную обработку данных. Добавились и специфические риски: prompt injection через входные данные, утечки через логи агентов и supply-chain риски инструментов и зависимостей.

Я добавила security-checklist в skills агентов, ввела отдельный security-ревью и стала описывать требования безопасности уже на этапе спецификации. Для чувствительного кода использую локальные модели.

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

Что сработало, а что оказалось иллюзией

Сработало:

• подготовка спецификаций и планирование;

• типовой код и unit-тесты;

• исследование вариантов реализации;

• анализ и документирование существующего кода.

Иллюзия:

• рост скорости в несколько раз без учёта ревью;

• почти безошибочная работа агентов;

• отсутствие необходимости думать о безопасности в личных проектах.

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

Измерять стоит не скорость генерации, а время до рабочего, поддерживаемого и безопасного результата. Лучший эффект дают не отдельные промпты, а процесс: намерение → спецификация → реализация → тестирование → ревью.

Open-source-модели уже закрывают значительную часть повседневных задач, особенно при наличии хорошего контекста и инструментов. Но на сложных задачах закрытые модели пока часто выигрывают по качеству.

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