Привет, Хабр!

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

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

Раньше я часто начинала писать код «с коленки». Теперь сначала формулирую намерение: цель, ограничения, 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)


  1. ToxaBes
    19.09.2026 18:16

    Раньше я часто начинала писать код «с коленки».

    Первая цифра вашего года рождения 2.


    1. Dhwtj
      19.09.2026 18:16

      Тогда вторая ноль

      Капец я умный!


    1. QA_Shark_Ann Автор
      19.09.2026 18:16

      С дедукцией и математикой у вас отлично :) Но если серьезно, привычка сразу бросаться писать код — это проблема не года рождения, а отсутствия выстроенного процесса. Главный инсайт статьи в том, что внедрение жесткого пайплайна (намерение → спецификация) и перенос фокуса на сквозной контроль качества спасает архитектуру независимо от опыта или возраста разработчика.


      1. ToxaBes
        19.09.2026 18:16

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

        Вы не поняли, код пишут не "с коленки", а "на коленке". Это устойчивое выражение. В какой-то момент деградация образования добралась и до него. Именно поэтому я и предположил юный возраст.


  1. ken48
    19.09.2026 18:16

    Gpt-4o??? Это вы опоздали на пару лет


  1. SanyaZ7
    19.09.2026 18:16

    Не ясно почему в списке использованных значатся устаревшие неактуальные модели. Как по опыту использования в 2024 можно делать выводы в 2026? При этом указываются "последние несколько месяцев перед написанием статьи".


    1. Dhwtj
      19.09.2026 18:16

      Нейрослоп же


  1. Dhwtj
    19.09.2026 18:16

    Астрологи объявили месяц AI‑Disrupt PDLC neiroslop

    https://habr.com/ru/specials/1080998/ смотри темы.

    Милый чатик, напиши статью, чтобы выиграть конкурс


    1. QA_Shark_Ann Автор
      19.09.2026 18:16

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


      1. ToxaBes
        19.09.2026 18:16

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


    1. ToxaBes
      19.09.2026 18:16

      Милый чатик, напиши статью, чтобы выиграть конкурс

      Хорошо, у меня как раз накопились заметки.