Честный взгляд без хайпа: что AI уже меняет в ежедневной работе разработчика, а где по-прежнему нужен человек с головой, опытом и ответственностью.

Кажется, про AI сейчас говорят либо слишком восторженно, либо слишком мрачно. В одном углу нам обещают, что разработчики вот-вот станут не нужны. В другом — что все это игрушка, которая пишет кривой код и уверенно придумывает факты. Как обычно, реальность где-то посередине, и она намного интереснее лозунгов.

Я не хочу писать очередной обзор инструментов в духе «топ-10 нейросетей для разработчика». Таких материалов и так хватает. Вместо этого хочу рассказать, как AI реально встроился в мою работу: где он экономит часы, где помогает не застревать, а где его ответы лучше сразу проверять с холодной головой.

Меня зовут Денис. Я SDET/AQA-инженер в Hoff Tech, занимаюсь автоматизацией, тестированием, нагрузочными историями и параллельно делаю свои пет-проекты. За последний год AI стал для меня не «магической кнопкой», а чем-то вроде очень быстрого напарника: он не принимает решения за меня, но сильно ускоряет путь от идеи до первого рабочего результата.

За это время я:

почти ежедневно использовал AI для кода, ревью, тестов, отчётов и разбора незнакомых проектов;
собрал данный блог с мини-CMS на Bun, TypeScript, Nuxt, Prisma и PostgreSQL — вечерами, без отдельной команды и без месяцев на раскачку;
написал AIVoice — десктопное приложение для голосового диктования на Tauri 2, React и Rust;
в рамках рабочих процессов реализовал единый дашборд для сквозной аналитики покрытия тестами и автотестами, который связывает данные из GitLab, TestOps, DocHub и других систем;
много раз использовал AI как черновой инструмент для нагрузочного тестирования: от анализа ТЗ до подготовки моков и данных.

И вот главный вывод, к которому я пришёл: AI не заменяет инженерное мышление. Но если мышление уже есть, он снимает огромное количество рутины и позволяет быстрее добираться до сути, хоть порой и с лишней когнитивной нагрузкой.

Что реально изменилось

Прототипирование стало быстрее и спокойнее

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

С AI этот этап стал заметно легче. Когда я делал блог, свободного времени было немного: несколько часов вечером, иногда кусок выходного. Без помощника такой проект легко растянулся бы на месяцы, потому что после работы не всегда есть силы вручную собирать очередной boilerplate. С AI я быстрее прошёл скучную часть и раньше дошёл до того, ради чего всё затевалось: структуры контента, админки, дизайна, публикаций, комментариев, локализации и нормального пользовательского опыта.

Важно: AI не «сделал блог за меня». Он не выбрал за меня архитектуру, не понял мои будущие планы, не взял на себя ответственность за безопасность и поддержку. Он просто помог быстрее собрать первые версии компонентов, подсказать варианты, накидать черновой код и убрать часть механической работы.

Это похоже на хорошую пару рук рядом. Ты говоришь: «Мне нужна форма, которая похожа на остальные формы в проекте, с такими-то полями и валидацией». Через минуту у тебя уже есть черновик. Не финальный идеальный код, но материал, с которым можно работать. И это очень меняет темп.

Code review стало менее утомительным

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

Раньше часть внимания уходила на механическое вычитывание. Сейчас первичный скрининг можно отдать AI: попросить найти потенциальные проблемы, подсветить подозрительные места, проверить читаемость, пройтись по граничным случаям. После этого я уже включаюсь как инженер: смотрю, верна ли логика, соответствует ли тест задаче, не сломается ли он от любого изменения UI или данных, сможет ли другой человек поддерживать его через полгода.

Самое приятное здесь не в том, что AI «делает ревью». Нет, ревью всё равно делаю я. Приятно то, что у меня остаётся больше сил на действительно важные вопросы. Не «забыл ли кто-то импорт удалить», а «проверяем ли мы вообще то поведение, ради которого этот тест написан».

Нагрузочное тестирование: меньше хаоса на старте

Один из самых полезных сценариев для меня — подготовка к нагрузочному тестированию. Представим обычную ситуацию: есть несколько микросервисов, есть ТЗ, есть понимание, что нужно проверить сквозной поток. Но чтобы запустить нормальный НТ, нужно разобраться в контрактах, данных, зависимостях, моках, уже существующих тестах и куче нюансов, которые не всегда аккуратно описаны в задаче.

Раньше старт такого процесса мог занимать день-два, а иногда и больше. Открываешь сервис, читаешь код, сверяешься с документацией, ищешь готовые тесты, пытаешься понять, какие данные нужны, где их взять и что должно вернуть окружение. Потом выясняется, что в ТЗ не хватает деталей, и нужно идти к аналитику или разработчику с уточняющими вопросами.

AI здесь не превращает сложную задачу в кнопку «сделать красиво». Но он отлично помогает собрать черновую карту местности. Например, можно дать ему ТЗ, куски кода сервиса и контекст по ожидаемому сценарию, а потом попросить:

выделить основные бизнес-потоки;
предложить набор тестовых данных;
набросать схему мока;
найти противоречия между ТЗ и кодом;
посмотреть, нет ли похожих нагрузочных тестов в соседнем проекте;
подготовить черновик K6-скрипта или подсказать, что нужно доработать в существующем.

Ключевое слово здесь — черновик. Если бездумно взять результат и отправить в работу, можно получить красивый, но бесполезный набор файлов. А если использовать AI как ускоритель анализа, то вместо нескольких дней раскачки можно за несколько часов получить понятную основу и уже руками довести её до рабочего состояния.

Быстрее входишь в незнакомый код и документацию

Есть ещё один сценарий, который звучит буднично, но экономит очень много энергии: «объясни, как здесь устроено X». Раньше, чтобы разобраться в новой библиотеке или внутреннем модуле, приходилось читать README, прыгать по файлам, искать похожие примеры и постепенно собирать картину.

Сейчас я часто начинаю с вопроса в контексте проекта: «Как в этой библиотеке сделать X, если на входе у меня уже есть Y?» Хороший AI-ассистент может не просто пересказать документацию, а показать путь именно под мою ситуацию. Потом я всё равно проверяю ответ в коде и документации, но вход становится быстрее.

Для меня это не замена чтения. Это способ быстрее понять, куда смотреть. Как если бы рядом сидел коллега, который говорит: «Начни вот с этого файла, потом посмотри этот метод, а вот здесь обычно ошибаются».

Отчёты перестали быть отдельной болью

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

Самая неприятная часть — начать. Ты уже всё понимаешь, но сидишь перед пустым документом и пытаешься написать первую фразу. AI хорошо снимает именно этот барьер. Я даю факты, метрики, выводы и прошу набросать структуру по заданному ранее шаблону. Потом редактирую, убираю лишнюю «канцелярщину», добавляю живые формулировки и проверяю, что выводы не стали слишком смелыми.

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

Инструменты, которые чаще всего у меня в ходу

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

GPT 5.x — код, ревью, отладка, объяснения, редактура, отчёты и сложные рассуждения;
Composer 2 — прототипирование фич, изменения в существующем проекте, работа с контекстом репозитория;
AI Voice — голосовой ввод и диктовка, особенно когда проще проговорить мысль, чем печатать её руками.

Отдельно отмечу: инструмент сам по себе не делает работу качественной. Одна и та же LLM может помочь собрать хороший модуль, а может нагенерировать уверенный мусор. Разница почти всегда в постановке задачи и проверке результата.

Где AI пока переоценивают

«AI заменит разработчиков»

На мой взгляд, нет. По крайней мере, не в том смысле, в котором это обычно продают в громких заголовках.

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

Можно сгенерировать API-клиент. Но кто решит, какой контракт будет удобен продукту через год? Можно попросить AI написать тесты. Но кто поймёт, что важный негативный сценарий вообще не описан в требованиях? Можно получить красивую архитектурную схему. Но кто будет отвечать, когда прод упадёт ночью?

AI отлично помогает там, где задачу можно хорошо описать и проверить. Но ответственность всё ещё остаётся и останется в ближайшие лет 5 у человека.

Автогенерация тестов без понимания продукта

AI неплохо генерирует очевидные сценарии. Если попросить «напиши тесты для регистрации», скорее всего, он предложит успешную регистрацию, невалидный email и короткий пароль. Это полезно, но это только верхушка.

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

Поэтому AI может помочь с каркасом тестов, но не должен становиться единственным источником тест-дизайна. Иначе получится много зелёных тестов, которые почти ничего не защищают.

Промптинг вместо исследования

Ещё один риск — начать путать быстрый ответ с настоящим исследованием. AI звучит уверенно даже тогда, когда не уверен. Он может красиво собрать текст, сгладить противоречия и выдать вывод, который выглядит убедительно, но не выдерживает проверки.

Поэтому я стараюсь относиться к ответам как к версии, а не как к факту. Особенно если речь про незнакомую область, свежие данные, безопасность, архитектурные решения или деньги. Чем важнее решение, тем меньше права у нас верить красивому тексту без проверки.

Неочевидный риск: эпистемологический долг

В обсуждениях вокруг AI-разработки всё чаще всплывает мысль, которую можно назвать эпистемологическим долгом. Если совсем просто: когда мы слишком часто заменяем собственное понимание ответом AI, мы как будто берём кредит у будущего себя.

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

Проблема не в том, что AI помогает думать быстрее. Проблема начинается там, где он думает вместо нас, а мы перестаём замечать эту подмену.

Я замечал это на себе. Если несколько дней подряд слишком активно отдавать AI отладку и не разбирать результат, мозг расслабляется. Появляется неприятная привычка: не строить гипотезу самому, а сразу спрашивать. В моменте это экономит время, но долг всё равно приходит. Когда AI ошибается или контекста не хватает, становится сложнее вернуться к нормальному инженерному анализу.

Поэтому я стараюсь держать простое правило: если AI предложил решение, я должен понять его настолько, чтобы объяснить другому человеку. Если не могу объяснить — значит, это ещё не моё решение, а просто сгенерированный текст.

Что не изменилось

На фоне всей этой скорости легко забыть, что основа профессии осталась прежней.

Архитектурные решения всё ещё принимает человек. AI может описать плюсы и минусы, но не знает всей истории продукта, команды и инфраструктуры.
Понимание пользователя нельзя сгенерировать из воздуха. Нужно знать, зачем человек приходит в продукт и какую боль он пытается закрыть.
Коммуникация никуда не делась. Требования, ревью, споры про подходы, объяснение решений стейкхолдерам — это всё ещё человеческая работа.
Ответственность тоже не делегируется. Если AI написал плохой код, а ты его принял, это уже твой код.

Для меня AI не отменяет профессию. Он просто поднимает планку. Теперь мало уметь писать код руками. Нужно ещё уметь ставить задачи, проверять результат, держать контекст и не терять собственное понимание.

Практические выводы

AI — ассистент, а не замена. Он особенно хорош там, где много рутины, повторов и черновой работы.
Качество ответа зависит от качества входа. Чем точнее контекст, ограничения и цель, тем полезнее результат.
Проверка важнее генерации. Сгенерировать сейчас легко. Понять, что это корректно, поддерживаемо и безопасно, — всё ещё инженерная работа.
AI ускоряет сильных, но может запутать невнимательных. Если не понимать область, можно очень быстро нагенерировать много красивых ошибок.
Лучший режим — сотрудничество. Человек формулирует задачу, задаёт направление, принимает решения и отвечает за результат. AI помогает быстрее пройти путь от пустого листа до рабочей версии.

Что я в итоге вынес

AI в 2026 году — это уже не игрушка и не «будущее когда-нибудь потом». Это нормальный рабочий инструмент, который можно встроить почти в любой инженерный процесс. Но магии в нём меньше, чем кажется со стороны.

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

Мой текущий подход простой: использовать AI активно, но не отдавать ему руль полностью. Пусть он пишет черновики, предлагает варианты, спорит, объясняет, ищет подозрительные места. А финальное решение всё равно должно проходить через человеческую голову.

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

Ссылки

AIVoice — десктопное голосовое диктование.
PersonalBlog — этот блог, собранный как личная площадка для заметок и экспериментов.
Cognitive Atrophy and Systemic Collapse in AI-Dependent Software Engineering — материал про риски чрезмерной зависимости от AI в инженерной работе.

Что даёт AI разработчику в 2026 году

Как мы дошли до вайбкодинга: эволюция ИИ-помощников в разработке

4 принципа Карпатого для эффективной работы с LLM