Если вы, как и я, следите за новостями в мире разработки, то, возможно, слышали про нашумевшее исследование METR. То самое, в котором говорится, что использование ИИ-ассистентов снижает эффективность опытного разработчика почти на 20%. Для всех, кто считает хайп вокруг ИИ чем-то временным и более того, вредным, это исследование стало весьма сильным аргументом. Я не буду оспаривать эти выводы. Но что, если я предложу вам посмотреть на них с другой, совершенно неожиданной стороны и скажу, что этот минус можно превратить в огромный плюс, кратно увеличив свою производительность?
Вся наша индустрия сегодня разделилась на два лагеря. С одной стороны — оптимисты, которые верят, что будущее уже наступило, и готовы внедрять ИИ везде без оглядки на здравый смысл. С другой — скептики, которые убеждены, что нужно просто переждать бурю, потому что в моменте ИИ приносит больше вреда, чем пользы.
Моя позиция — где-то посередине. Я называю себя ИИ-реалистом. Я работаю с LLM с 2022 года, с самого их появления, и для меня это в первую очередь новый инструмент. Мощный, сложный, но всего лишь инструмент, который можно использовать с пользой, а можно — во вред. В этой статье я хочу поделиться квинтэссенцией своего опыта: как подходить к работе с ИИ-ассистентами, чтобы они действительно помогали, а не мешали. И это совсем не про модный нынче «вайб-кодинг», а скорее про инженерную культуру и осознанную разработку.
Но прежде чем мы перейдем к конкретным правилам и «граблям», давайте сделаем шаг назад. Чтобы понять, как правильно использовать новый инструмент, сперва нужно разобраться в его природе. А для этого нет ничего лучше, чем обратиться к историческим аналогиям. Это поможет нам понять, с чем мы на самом деле имеем дело.
Всё это уже было, но в другой обёртке
История сопротивления технологиям, которые, как кажется, отнимают у людей работу и обесценивают их навыки, стара как мир. Когда-то ремесленники с недоверием смотрели на мануфактуры, затем рабочие — на конвейерные линии Генри Форда, а позже инженеры — на станки с ЧПУ. Каждый раз звучали одни и те же опасения: машины заменят человека, а уникальное мастерство уступит место бездушной автоматизации.
Но для нас, разработчиков, есть аналогия гораздо ближе и понятнее — эволюция языков программирования.
Вспомните этот путь: от машинных кодов и ассемблера, где инженеры полностью контролировали каждый такт процессора, мы перешли к низкоуровневым языкам и компиляторам. Затем — к языкам высокого уровня, которые скрыли от нас управление памятью и другие сложные детали. Каждый такой переход был своего рода компромиссом. Мы сознательно жертвовали частью контроля и, возможно, пиковой производительностью. А взамен получали колоссальный выигрыш в скорости разработки и снижение порога входа в профессию.
Переход к разработке с ИИ-ассистентами — это просто следующий шаг на этом пути. И компромисс здесь точно такой же. Мы получаем возможность быстрее выводить продукты на рынок, но взамен сталкиваемся с риском ухудшения качества кода.
Я намеренно говорю «с риском», а не с гарантированным ухудшением. Потому что этим риском можно и нужно управлять. Так же, как мы научились писать эффективный код на высокоуровневых языках, мы можем научиться писать качественный код с помощью ИИ.
Два главных слова: «понимание» и «контроль»
Эти два слова — не просто абстрактные понятия. Это фундамент, на котором строится вся эффективная и безопасная работа с ИИ. Если вы не заложите его в основу своего подхода, любой, даже самый продвинутый ассистент, будет приносить больше вреда, чем пользы.
Давайте разберём, что именно я вкладываю в каждое из этих понятий.
Понимание
Это ваша подготовка. До того как вы написали хотя бы одну строку промпта, вы должны досконально разобраться в четырёх вещах:
- Понять, что нужно сделать. Звучит банально, но это критически важно. Если вы сами не можете чётко определить конечную цель и ожидаемый результат, вы получите его только по счастливой случайности. ИИ пока что не умеет читать мысли, он выполняет спецификацию — пусть и неформальную.
- Понять, как это лучше всего сделать. Вы должны иметь в голове как минимум один рабочий способ решения задачи — и в идеале не один. Если вы сами не представляете, как эту задачу решать, вы не сможете ни оценить предложенный ИИ код, ни понять, хороший ли он выбрал подход, ни проверить, не упустил ли он важные детали. Вы не можете эффективно ревьюить код, который сами не знали бы, как написать.
- Понять, как сформулировать задачу для ИИ. Это следующий уровень. Теперь вам нужно перевести своё видение в чёткую и недвусмысленную инструкцию для машины. Если ассистент вас не поймёт, он сгенерирует что-то, основанное на его собственной, часто неверной, интерпретации. И мы снова возвращаемся к пункту один — случайному результату.
- Понять, как вы будете проверять результат. Как вы убедитесь, что задача решена правильно? Будете писать юнит-тесты? Проводить ручное тестирование по заранее составленным кейсам? Или просто запустите и посмотрите, не упало ли? Критерии успеха нужно определить до начала работы, а не после того, как код уже сгенерирован.
Контроль
Это ваша работа в процессе и после. Если «понимание» — это подготовка, то «контроль» — это реализация и приёмка.
- Контроль хода решения. Не ждите финального результата, чтобы начать проверку. Используйте планы, todo-листы — любые инструменты, которые позволяют на раннем этапе увидеть, в правильном ли направлении движется ассистент. Если вы видите, что ИИ собирается «переписывать ядро Linux вместо рефакторинга ваших тестов», лучше остановить его сразу, а не разгребать последствия.
- Контроль итогового результата. Это привычный для любого инженера этап — ревью. Оцените качество кода, его архитектуру, проверьте покрытие corner-кейсов, проведите полноценное тестирование. Сгенерированный код — это не истина в последней инстанции, а черновик, который требует такой же строгой проверки, как и код, написанный джуном.
- Самоконтроль. Пожалуй, самое сложное. Это дисциплина, которая заставляет вас следовать первым двум правилам, даже когда лень. Именно здесь кроется главный соблазн — скатиться в «ИИ, сделай мне хорошо» или понадеяться, что «ИИ сам как-нибудь разберётся». Поверьте, не разберётся.
Мы с вами инженеры. И наша работа всегда строилась на одной простой парадигме: спланировал, решил, проконтролировал. При работе с ИИ эта парадигма не меняется. Она лишь становится ещё важнее.
Где ИИ — друг, а где — враг
Принципы понимания и контроля — это наш компас. Теперь давайте нанесём на карту основные типы задач, чтобы видеть, где нас ждёт твёрдая почва, а где — болото, полное граблей. Я выделяю три ключевых сценария, с которыми сталкивается каждый, кто начинает использовать ИИ-ассистентов.
Автоматизация рутины
Начнём с самого популярного и, пожалуй, самого коварного мифа: «ИИ заберёт на себя всю рутину, а мы будем заниматься чистым творчеством». Это действительно эталонный стереотип, особенно для работодателя. Но если слепо ему поверить, можно потратить на исправление кода ИИ гораздо больше времени, чем на ручное выполнение задачи.
Представьте, что вам нужно отрефакторить сотню однотипных тестов. Соблазн скормить их все ассистенту в одном промпте огромен. Но почему же так делать всё-таки не стоит? С ростом объёма задачи и количества повторений раздувается контекст модели. Это приводит к появлению артефактов, галлюцинациям и той самой излишней креативности, когда ассистент внезапно решает, что ему виднее, и начинает переписывать что-то совершенно постороннее, или, проще говоря галлюцинировать.
Как правильно? ИИ на самом деле хорошо автоматизирует рутину, но в малых дозах. Он отлично повторит единожды выполненное вами решение в трёх, четырёх, может, пяти других местах. Если же вам нужно больше — разбивайте большую задачу на несколько мелких, сбрасывая контекст. Если нужно сильно больше — придётся писать скрипты. Кстати, написать такой скрипт, у которого на борту будет свой ИИ, тоже можно с помощью ассистента, но это уже другая история.
Сложная бизнес-логика
Теперь перейдём к зоне очевидной опасности. Всем известно, насколько рискованно доверять ИИ написание критически важного кода. Как вам такая новость: «В марте 2025 года платёжный шлюз, созданный с помощью вайб-кодинга, из-за неадекватной валидации входных данных одобрил мошеннические транзакции на $2M». Это яркий пример того, к чему приводит слепое доверие.
Самый опасный промпт — тот, в котором вы просите ассистента подумать за вас. Это не делегирование задачи, а делегирование вашего инженерного мышления.
Казалось бы, вывод прост: не подпускать ИИ к бизнес-логике. Но это лишает нас очень эффективных сценариев использования. На самом деле, этот антипаттерн превращается в мощный инструмент, если мы возвращаемся к нашим главным принципам.
ИИ отлично кодирует сложную логику, но только ту, которая уже придумана и детально описана вами. Если у вас есть структурированные бизнес-требования, продуманная архитектура, документация с прописанными user stories и методиками тестирования — то есть цельное видение итогового решения, — ассистент сможет блестяще его реализовать. Он сгенерирует скелет, который вы затем сможете эффективно наполнить кодом. ИИ хорошо справляется с относительно небольшими, но сложными и структурированными задачами — отчасти потому, что у модели ограничен контекст, а отчасти потому, что у нас самих ограничен ментальный контекст, и мы редко способны удержать в голове по-настоящему большую систему целиком.
Безопасные и эффективные задачи
Наконец, мы добрались до зелёной зоны — территории, на которой могут спокойно работать даже те, кто уже наступил на все возможные грабли. Это задачи, которые обладают одним из двух признаков: либо их результат очень легко и быстро проверить, либо цена ошибки в них крайне низка.
Что сюда входит?
- Написание бойлерплейт-кода.
- Генерация сложных структур классов по готовому архитектурному описанию.
- Мелкий, атомарный рефакторинг.
- Написание клиентов и адаптеров к какому-либо API.
- Создание утилит и вспомогательных скриптов для автоматизации.
В этих случаях ассистент становится вашим идеальным помощником. Вы либо сразу видите, если что-то пошло не так, либо потенциальный баг не принесёт серьёзного вреда, и вы спокойно его поправите.
Разумеется, эти три категории не покрывают все возможные задачи. Но они дают хорошее представление о том, как выбирать, что делегировать ИИ, а что — оставить себе. И это понимание напрямую подводит нас к самому интересному — к тому, как меняется роль разработчика и как на самом деле победить те самые «минус 19% эффективности».
Как превратить минус в плюс
Итак, мы вернулись к тому, с чего начали, — к исследованию METR и тем самым минус 19% эффективности. Как же победить эту математику, если даже на подходящих задачах мы работаем медленнее?
Ответ прост: нужно изменить не инструмент, а сам подход к работе и способ измерения продуктивности. Проблема не в том, что ИИ замедляет нас на одной конкретной задаче. Проблема в том, что мы по-прежнему мыслим категориями одной задачи.
Именно здесь и кроется разгадка. С появлением ИИ-ассистентов наша роль меняется. Мы перестаём быть просто исполнителями. Каждый из нас получает возможность стать руководителем своей собственной, пусть и виртуальной, команды. В вашем распоряжении оказываются ИИ-джуны, ИИ-аналитики, ИИ-тестировщики и ИИ-архитекторы. И чтобы этим всем эффективно управлять, вам неизбежно приходится осваивать навыки тимлида и менеджера. На мой взгляд, до 80% успеха в решении задачи с помощью ИИ зависит именно от нашей подготовки и умения управлять этим процессом.
Этот сдвиг в мышлении требует новой культуры работы, которая сводится к двум простым действиям:
- Декомпозируйте. Если перед вами стоит большая и сложная задача, которую вы не можете целиком и однозначно описать для ИИ, — разбейте её на ряд мелких, понятных и контролируемых подзадач. Продолжайте дробить до тех пор, пока каждая отдельная задача не будет полностью соответствовать правилам «понимания» и «контроля».
- Распределяйте. А вот это — ключевой момент. Как только у вас появляются такие атомарные задачи, позвольте ИИ их решать. Но не сидите и не ждите, пока он закончит. Пока он работает над первой задачей, позвольте ему начать решать вторую. А сами в это время можете заняться третьей — той, что требует исключительно вашего, человеческого, интеллекта.
Так мы переходим от последовательного выполнения задач к параллельному. Это тренируемый навык, и зависит он только от вашей способности переключать контекст. Для меня, например, комфортно вести два-три таких потока одновременно. Со временем будет больше.
Продуктивность разработчика будущего измеряется не скоростью написания кода, а пропускной способностью его сознания — умением эффективно управлять несколькими потоками задач одновременно.
И вот теперь мы можем по-новому взглянуть на ту самую формулу эффективности.
𝐸ии>Eчел ∀ 𝑛 > 1,𝑛 Э N
Понятно, что такая формула — это намеренное упрощение, чтобы проиллюстрировать саму идею. Более честная математика выглядит так: наша общая производительность, то есть произведение количества задач (n) на нашу эффективность с ИИ (Е_ии), должна превысить производительность разработчика без ИИ (Е_чел).
Другими словами, количество параллельных потоков n должно быть достаточным, чтобы компенсировать потери в эффективности на каждой отдельной задаче. Если, условно, ассистент замедляет вас на 20%, то для выхода в ноль вам уже нужно вести две задачи одновременно. А чтобы получить ощутимый выигрыш — три и более.
Это ограничение подхода, но оно лишь подчёркивает главную мысль: дело не в скорости набора кода, а в умении эффективно управлять потоком задач.
Разработчик с ИИ, решающий несколько задач параллельно, в итоге оказывается эффективнее, чем разработчик без ИИ, сфокусированный лишь на одной. Вы превращаетесь в человека-команду, человека-отдел. И это полностью меняет правила игры.
Конечно, пытливый ум заметит, что этот подход требует достаточно хороших навыков работы с ИИ, чтобы не терять слишком много эффективности в контексте одной задачи. И это действительно так. Что, впрочем, лишний раз доказывает тот факт, что ИИ — просто новый эффективный инструмент, требующий освоения, а не волшебная кнопка «сделать красиво».
AI-assisted разработка, а не вайб-кодинг
В конечном счёте, ИИ — это не замена инженеру. Это новый инструмент, который мы можем использовать для повышения своей эффективности. Но чтобы это произошло, нам самим придётся измениться.
Ключевыми навыками разработчика в этой новой реальности становятся не столько умение писать код, сколько умение декомпозировать задачи, составлять для них чёткое техническое задание и критически оценивать полученный результат. Каждому из нас придётся освоить немного от профессий менеджера и тимлида, чтобы эффективно управлять своим новым арсеналом.
Сегодня наша задача — не отрицать наступившее будущее и не верить слепо во всемогущество ИИ. Наша задача — быть реалистами. Использовать те возможности, которые технология даёт нам здесь и сейчас, и при этом чётко осознавать её ограничения.
Именно в этом и заключается разница между хаотичным «вайб-кодингом» и профессиональной, AI-ассистированной разработкой. Первое — это игра в рулетку, где вы надеетесь на удачу. Второе — это осознанный инженерный процесс, построенный на понимании и контроле. И только он ведёт к настоящему росту производительности.
