Привет, Хабр!
Последние месяцы я изучала современные ИИ‑инструменты и проверяла их на собственных проектах. Мне было важно не просто генерировать код, а переосмыслить весь цикл разработки: от формулировки задачи до тестирования, ревью и проверки безопасности.
Планирование — самый чистый выигрыш
Раньше я часто начинала писать код «с коленки». Теперь сначала формулирую намерение: цель, ограничения, 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‑модели уже закрывают значительную часть повседневных задач, особенно при наличии хорошего контекста и инструментов. Но на сложных задачах закрытые модели пока часто выигрывают по качеству.
Самый важный навык сейчас — не умение получить код от агента, а способность правильно поставить задачу и строго проверить результат.
Комментарии (11)

Dhwtj
19.09.2026 18:16Астрологи объявили месяц AI‑Disrupt PDLC neiroslop
https://habr.com/ru/specials/1080998/ смотри темы.
Милый чатик, напиши статью, чтобы выиграть конкурс

QA_Shark_Ann Автор
19.09.2026 18:16Если бы этот текст действительно писал «милый чатик», он бы наверняка радостно отчитался, что ИИ заменит всех разработчиков уже к пятнице, а не разбирал бы подробно иллюзию продуктивности :) Суть статьи ровно в обратном: без глубокого вовлечения инженера — от выявления архитектурных проблем до контроля безопасности — голая кодогенерация быстро превращается в хаос. А участие в тематическом сезоне — просто хороший повод структурировать практический опыт и обсудить его с комьюнити.

ToxaBes
19.09.2026 18:16Вы все верно написали и правильно указали главный навык. Проблема в том, что это было актуально ранее и не является чем-то неизвестным для подавляющего большинства комментаторов. Это, буквально, база. Вы в ней разобрались, вы молодец, но отдельные абзацы вашей статьи устарели на 1-1.5 года.

ToxaBes
19.09.2026 18:16Милый чатик, напиши статью, чтобы выиграть конкурс
Хорошо, у меня как раз накопились заметки.
ToxaBes
Первая цифра вашего года рождения 2.
Dhwtj
Тогда вторая ноль
Капец я умный!
QA_Shark_Ann Автор
С дедукцией и математикой у вас отлично :) Но если серьезно, привычка сразу бросаться писать код — это проблема не года рождения, а отсутствия выстроенного процесса. Главный инсайт статьи в том, что внедрение жесткого пайплайна (намерение → спецификация) и перенос фокуса на сквозной контроль качества спасает архитектуру независимо от опыта или возраста разработчика.
ToxaBes
Вы не поняли, код пишут не "с коленки", а "на коленке". Это устойчивое выражение. В какой-то момент деградация образования добралась и до него. Именно поэтому я и предположил юный возраст.