AI-Disrupt PDLC на практике: где ИИ реально ускоряет, а где создаёт иллюзию продуктивности (опыт на личных проектах)
Habr ·
Привет, Хабр! Последние месяцы я изучала современные ИИ-инструменты и проверяла их на собственных проектах. Мне было важно не просто генерировать код, а переосмыслить весь цикл разработки: от формулировки задачи до тестирования, ревью и проверки безопасности. Планирование — самый чистый выигрыш Раньше я часто начинала писать код «с коленки». Теперь сначала формулирую намерение: цель, ограничения, 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-тесты; исследование вариантов реализации; анализ и документирование существующего кода. Иллюзия: рост скорости в несколько раз без учёта ревью; почти безошибочная работа агентов; отсутствие необходимости думать о безопасности в проектах. Читать далее
Привет, Хабр! Последние месяцы я изучала современные ИИ-инструменты и проверяла их на собственных проектах. Мне было важно не просто генерировать код, а переосмыслить весь цикл разработки: от формулировки задачи до тестирования, ревью и проверки безопасности. Планирование — самый чистый выигрыш Раньше я часто начинала писать код «с коленки». Теперь сначала формулирую намерение: цель, ограничения, 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-тесты; исследование вариантов реализации; анализ и документирование существующего кода. Иллюзия: рост скорости в несколько раз без учёта ревью; почти безошибочная работа агентов; отсутствие необходимости думать о безопасности в проектах. Читать далее