Книги по программированию

Beyond
Vibe Coding:
Leveraging Your Experience in the Age of
AI-Assisted Coding

AddyOsmani

VIBE CODING
Программирование с помощью
искусственного интеллекта

Эдди Османи

УДКОО4.891
ББК32.973.26-018.2:32.813
0-74

Beyond Vibe Coding: Leveraging Уour Experience in the Age of AI-Assisted Coding
AddyOsmani
© 2026 "Astana lnternational PuЬlishing" Authorized

Russian translation of the English edition of
Beyond Vibe Coding ISBN 9798341634756
© 2025 AddyOsmani. This translation is puЬlished and sold Ьу permission ofO'Reilly Media, lnc.,
which owns or controls а11 rights to puЬlish and sell the same.

Османи, Эдди.
0-74
Vibe Coding: программирование с помощью искусственного интеллекта/ Эдди
Османи: [перевод с английского О. Перфильева]. - Алматы : Астана иностранная
пресса, 2026. - 320 с. - (O'Reilly. Книги по программированию).
ISBN 978-601-12-9040-1

Книга «Vibe Coding: Программирование с помощью искусственного интеллекта»
посвящена современным подходам к разработке программного обеспечения с использовани­
ем ИИ-инструментов. Автор показывает, как меняется роль разработчика в условиях автома­
тизации написания кода и какие навыки становятся ключевыми в новой парадигме.
В издании рассматриваются методы постановки задач для ИИ, оценки и доработки
сгенерированного кода, а также интеграции отдельных решений в целостные программные
системы. Особое внимание уделено практическим аспектам взаимодействия с ИИ и построе­
нию эффективных рабочих процессов.

УДКОО4.891
ББК 32.973.26-018.2:32.813

ISBN 978-601-12-9040-1

© Перфильев О.И., перевод на русский язык, 2026
© Издание на русском языке, оформление.
ТОО «Издательство «Астана иностранная пресса», 2026

Барлык; к;ук;ык;тар к;орrаман. Бул кiтапты басып шы,арушыны� рук;сатынсыз онлайн немесе кез келген
баск;а жолмен сканерлеу, жуктеп алу немесе за�сыз тарату за� бойынша жазаланады / Все права
защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме с
помощью каких-либо электронных или механических средств, включая изготовление фотокопий,
аудиозапись, репродукцию или любой иной способ, или систем поиска и хранения информации без
письменного разрешения издателя.

Предисловие ....................................................................................................... 9
Для кого предназначена эта книга ... .
..... 9
Ожидания
11
Используемые в этой книге условные обозначения .
13
O'Reilly Online Learning .
. . .. . .
. . ................................. 14

Часть 1
Основы
Глава 1. Введение: что такое вайб-кодинг?
Спектр ИИ-кодирования: от вайб-кодинга до разработки с помощью

ии .

17
18

'''' 30
Чтение между строк: программирование с намерением
Производительность, доступность и меняющаяся природа
"35
программирования
Краткий обзор инструментов: становление экосистемы ......................... ''' 38
Модели ИИ: современный ландшафт генерации кода ............................. .... 46
.... 48
Основные модели
., ... 51
Выбор модели в зависимости от задачи
. 52
Преимущества и ограничения вайб-кодинга: нюансы
. 63
Итоги и дальнейшие шаги

Глава 2. Искусство составления запросов: эффективный
''' 65
способ общения с ИИ
. 66
Основы промпт-инжиниринга ...
Конкретность и ясность: как формулировать запросы, которые
68
работают
. 70
Итеративное уточнение: цикл обратной связи с ИИ
Сравнение двух запросов
"74
Техники запросов: набор инструментов
.. . 77
эффективного взаимодействия
Продвинутый промпт-инжиниринг: сочетание техник
и сложные случаи
. 90
Итоги и дальнейшие шаги ................................................................................ 95

Часть 11
Практика работы с ИИ
Глава 3. Проблема 70%: как работать с ИИ по-настоящему ........................ ..... 99
Как разработчики используют ИИ на самом деле
.......................... 101
Золотые правила вайб-кодинга
110
Итоги и дальнейшие шаги
113
Глава 4. За пределами 70%: максимальное раскрытие человеческого
потенциала
Sеniоr-программисты и разработчики: расширяйте свой опыт работы

сии .............

.......................

114
115
118
126

Мiddlе-разработчики: адаптируйтесь и специализируйтесь
Младшие разработчики: двигайтесь к успеху вместе с ИИ
Развивайте навыки работы с запросами
и инструментами (осознанно) .. ................................................................... 129
132
Итоги и дальнейшие шаги
Глава 5. Анализ сгенерированного кода: код-ревью, доработка,
ответственность
От замысла к реализации: как понять написанный ИИ-код ...
«Решение большинства»: «самое распространённое» не значит
«самое подходящее» .
Читаемость кода и его структура:
шаблоны и потенциальные проблемы
Стратегии отладки: поиск и исправление ошибок
Рефакторинг как способ поддержки кода:
превращаем код ИИ в свой
Важный этап тестирования: модульные, интеграционные и сквозные
тесты ... .................
Итоги и дальнейшие шаги

143
145

Глава 6. Прототипирование с использованием ИИ:
инструменты и техники ......
Быстрое прототипирование с ИИ-ассистентами .
ИИ-инструменты прототипирования
От концепции к прототипу: итеративная доработка
Эволюция прототипа на пути к производству
Проблемы, характерные для прототипирования с помощью ИИ
Итоги и дальнейшие шаги

147
147
149
151
155
159
161

6 1 Оглавление

135
135
137
138
140
142

162
Глава 7. Создание веб-приложений с помощью ИИ
Настройка проекта: создание каркаса с помощью ИИ ............................... 162
Проектирование и интеграция баз данных
173
Полностековая интеграция: объединение фронтенда и бэкенда
176
Тестирование и валидация веб-приложений, созданных
с помощью ии
.................. ................... 181
Удачные примеры создания веб-проектов с помощью ИИ ..............
184
Итоги и дальнейшие шаги
186
Часть 111
Доверие и автономия
Глава 8. Безопасность, поддерживаемость и надёжность ............................... 191
Распространённые проблемы безопасности
в сгенерированном ИИ коде ......................................................................... 192
Аудит безопасности
199
Ручной код-ревью с акцентом на безопасность
..... 201
Создание эффективных тестовых фреймворков
... 205
для сгенерированных ИИ систем
.. 210
Оптимизация производительности .
... 214
Поддерживаемость кодовых баз, составляемых с помощью ИИ
................... 220
Стратегии код-ревью
Лучшие практические рекомендации по надёжному развёртыванию ..... 223
.................... 228
Итоги и дальнейшие шаги
Глава 9. Этические вопросы вайб-кодинга ............. ...................................... ... 229
Размышления по поводу интеллектуальной собственности ..................... 230
Прозрачность и признание авторства .
... 237
... 239
Предвзятость (дискриминация) и справедливость
243
Золотые правила ответственного использования ИИ
. 249
Итоги и дальнейшие шаги
Глава 10. А втономные агенты фонового программирования
250
От напарников к автономным агентам: что такое агенты фонового
программирования ...
. ............................. 250
Как работают автономные агенты
........................
..... 252
Сравнение фоновых агентов и ИИ-ассистентов в IDE
.. 256
Объединение нескольких ИИ-моделей для максимального эффекта ...... 259
Основные автономные агенты для написания кода
Проблемы и ограничения
.. .... .. .. ...... . .. ..... . 266
Оглавление

1

7

Лучшие методы эффективного использования ИИ-агентов
для программирования
Итоги и дальнейшие шаги
Глава 11. Не просто генерация кода:
что стоит ожидать от ИИ в будущем
ИИ в тестировании, отладке и сопровождении
Дизайн и персонализация пользовательского опыта
Эволюция проджект-менеджмента с помощью ИИ
Как автономные агенты изменят сферу разработки ПО
Будущее языков программирования и возможность разработки
на основе естественного языка
Как вайб-кодинг меняет индустрию
Итоги и дальнейшие шаги

... 268
... 271
...... 272
272
... 275
...... 278
282
.. 288
.... 292
... 294

Об авторе ..................................................................... ................................... 298
Оформление книги ... ... ................. .......... ....................................... . ... ... ..... ... . 299
Алфавитный указатель .............. ................................... ............. . . ....... ........... 300

Предисловие
Мы переживаем эпоху глубоких перемен в сфере программного обеспечения.
Так называемый профессиональный вайб-кодинг, то есть процесс совместной
с ИИ разработки программного обеспечения (ПО), превращает разработчиков
из технических «ремесленников» в своего рода «визионеров» и «архитекторов»
продукции.
Но что же такое, собственно говоря, вайб-кодинг? Под этим модным терми­
ном подразумевается использование возможностей ИИ (искусственного интел­
лекта), выполняющего основную рутинную работу по написанию кода, благода­
ря чему разработчики получают возможность сосредоточиться больше на идеях,
дизайне и решении высокоуровневых задач. В этом смысле вайб-кодинг можно
назвать импровизацией или созданием кода «по наитию», с опорой скорее на не­
кие «идеи», а не на технические детали. Как метко заметил Андрей Карпатый
(https:!/oreil.ly/7bn We), это сродни ощущению, когда «забываешь, что код вообще
существует», и просто создаёшь, то есть описываешь, что тебе нужно, а о подроб­
ностях реализации заботится ИИ. Такой процесс может привести к многократ­
ному росту производительности и обещает не только воплотить в реальность
мечту о пресловутом «!Ох-инженере» (то есть разработчике ПО с десятикрат­
ной продуктивностью), но и превратить её в концепц11ю «lООх-продуктивности»
(https:!!oreil.ly!SUGID).

Для кого предназначена эта книга
Эта книга ориентируется на три основные аудитории. Первая - это опытные
разработчики и технические руководители, желающие многократно увеличить
свой вклад в разработку ПО. Если вы занимаетесь этим уже на протяжении мно­
гих лет и понимаете всю важность автоматизации повторяющихся задач, эта
книга покажет вам, как можно поручить рутину ИИ, а самим перейти к роли
архитектора и стратега. Вы узнаете, как работать быстрее, не жертвуя своими
сформированными за годы карьеры стандартами качества.
Вторая аудитория - разработчики ПО, мыслящие в категориях продукта,
для которых код - это скорее средство, а не конечная цель. Если вас раздража­
ет разрыв между концепцией и её реализацией, то вайб-кодинг поможет вам
Предисловие

1

9

в значительной степени сократить эту дистанцию. Вы узнаете, как можно быстро
создавать прототипы и выпускать продукцию, на создание которых при тради­
ционных методах ушли бы месяцы.
И здесь стоит упомянуть о том, что показалось мне в ИИ-инструментах наи­
более парадоксальным: опытным разработчикам они помогают больше, чем но­
вичкам. Такой вывод кажется нелогичным: разве ИИ не должен «демократизировать» создание кода?
В реальности же ИИ походит на некоего очень старательного джуна в вашей
команде. Он умеет быстро писать код, но требует постоянного контроля и ис­
правлений. Чем больше вы знаете, тем лучше можете им руководить.
Отсюда возникает то, что я называю парадоксом знания: опытные инженеры
и разработчики пользуются ИИ для ускорения того, что они уже знают, тогда как
начинающие пытаются пользоваться им, чтобы научиться что-то делать, и ре­
зультаты радикально отличаются.
Я лично видел, как сеньоры пользуются ИИ для следующих задач:
- быстрое создание прототипов для уже понятных идей;
- быстрая реализация замысла, который можно затем развивать;
- анализ альтернативных методов решения известных проблем;
- автоматизация рутинных задач.
В то же время новички, решившие доверить свою работу ИИ, часто:
- находят некорректные или устаревшие решения задач;
- упускают важные аспекты безопасности и производительности;
- с трудом выполняют отладку сгенерированного ИИ кода;
- создают уязвимые системы, принцип работы которых сами до конца
не понимают.
Третья аудитория этой книги - менеджеры и технические руководители, вне­
дряющие ИИ-инструменты в своих коллективах и производственных процес­
сах. Вы узнаете, как заниматься организацией, как оценивать квалификацию
сотрудников и поддерживать качество продукции в эпоху, когда один разра­
ботчик может делать то, что раньше поручали целой команде. Описанные здесь
стратегии помогут вам перейти на новый уровень, сохранив прежнюю культу­
ру разработки.
Чего здесь вы не найдёте, так это вводного курса по программированию. Не­
смотря на то что ИИ повышает доступность программирования, работа с ним
всё равно требует опыта и умения принимать обоснованные решения. Считай­
те, что перед вами продвинутое руководство для тех, кто готов выйти за рамки
традиционного программирования и перейти к новой парадигме создания ПО.
10

Предисловие

Ожидания
В этой книге говорится о том, как меняется роль разработчиков, которые пере­
ходят от непосредственного создания кода к «инженерии продукта». При этом
они в своём общении с ИИ руководствуются субъективными «человеческими»
соображениями, ориентируясь на качество, архитектуру и потребности поль­
зователей. Мы по-прежнему ценим творческий подход, системное мышление
и эмпатию, благодаря которым абстрактная «рабочая программа» превращает­
ся в отличный продукт. ИИ не заменяет нас; при условии разумного его исполь­
зования он усиливает наши положительные качества.
В первой части я рассуждаю о том, в каких областях особенно заметна эф­
фективность вайб-кодинга: это создание новых продуктов, прототипирование
функций, генерация стандартных СRUD-приложений или интеграция кода. Что
касается этих задач, то для них скорость и стандартизация важнее глубокой оригинальности. В то же время я упоминаю и сферы, в которых следует соблюдать
осторожность: реализация по-настоящему сложных, низкоуровневых или но­
вых алгоритмов, в которых искусственный интеллект может ошибаться. При­
знав текущие ограничения ИИ, мы избежим разочарований и неудач, ведь мно­
гое в нашей работе по-прежнему зависит от человеческой изобретательности.
Ключевым звеном всего процесса остаётся человеческий фактор. Мы следим
за правильностью архитектуры, находим сложные баги и оцениваем качество
кода не только по принципу «работает/ не работает». Ещё важнее наша ориента­
ция на пользователя, что до сих пор недоступно для ИИ. Именно мы делаем так,
чтобы ПО не только работало, но и было полезным и.удобным для пользовате­
лей. Короче говоря, разработчики становятся кураторами и редакторами выда­
ваемого ИИ-кода, согласующими этот код с реальными потребностями и под­
держивающими высокие стандарты.
Во второй части рассматриваются практические аспекты вайб-кодинга с от­
дельным вниманием к внедрению новых рабочих процессов. Методы вро­
де «не исправляй, а перегенерируй» напоминают нам, что не стоит застревать
на ошибках и что генерировать код заново порой бывает быстрее, чем занимать­
ся его отладкой. Параллельные запросы помогают решать задачи с нескольких
сторон одновременно. Чтобы не увязнуть в болоте хаоса, нужно найти баланс
между быстрыми итерациями и последующей доработкой. Такие практиче­
ские особенности, как модульная структура кода ИИ, тщательное тестирование
и итеративное улучшение, помогают поддерживать чистоту и устойчивость ко­
довой базы несмотря на высокую скорость разработки.
По мере масштабирования проектов приходится управлять ускоренным по­
током кода и обслуживать потенциальный технический долг. ИИ легко может
Предисловие

11

выдать целую кучу кода, которая быстро забьёт под завязку любой репозито­
рий; поддерживать код в работоспособном и адекватном состоянии помогают
только дисциплина и правильные практические методы (при предположитель­
ном рефакторинге с помощью того же ИИ). Что касается кадровых вопросов,
то мы поговорим о том, как нанимать и обучать разработчиков, которые умеют
работать с ИИ-инструментами, умеют приспосабливаться к текущим условиям и применять на практике свои навыки системного проектирования. Также
мы научимся определять моменты, когда стоит возвращаться к традиционным
подходам - например, при долгосрочной поддержке продукта или во время ра­
боты с критически важными системами, для которых надёжность важнее ско­
рости.
Третья часть посвящена безопасности и надёжности, этическим вопросам,
а также инструментам, благодаря которым вайб-кодингом можно заниматься
уже сегодня; среди них - IDE с поддержкой ИИ, такие как Cursor и Windsurf,
интегрированные с моделями Anthropic, Google Gemini и OpenAI, знающие всю
кодовую базу пользователей и помогающие на каждом этапе. Умение обращать­
ся с этими инструментами и моделями (вариациями Claude для разных задач,
ChatGPT для общих вопросов и ответов) входит в набор необходимых навыков
современного разработчика. У каждого инструмента имеются свои сильные сто­
роны: Cursor лучше подходит для интерактивного редактирования, Windsurf для задач с большим контекстом, чат-интерфейсы - для мозгового штурма и по­
иска ошибок и т. д.
В будущем, насколько мне кажется, появятся ещё более абстрактные способы
создания ПО (вайб-дизайн посредством GUI, то есть графического интерфейса,
или высокоуровневых интерфейсов), которые уменьшат зависимость от универ­
сальных библиотек. ИИ будет генерировать индивидуализированный код, а не­
которое ПО будет даже развиваться самостоятельно на основе обратной связи
от ИИ. В этом будущем успех в сфере программирования будет во многом за­
висеть от творческих аспектов, от человеческого умения распределять ресурсы
и использовать сетевые возможности, потому что писать код станет проще, без
необходимости заниматься рутинными и требующими одной лишь усидчивости
задачами. Благодаря повсеместному распространению ИИ возникнут новые па­
радигмы пользовательского опыта, от разговорных интерфейсов до адаптивных
пользовательских интерфейсов и тому подобного.
Во всём этом выделяется одна ключевая идея: слияние сильных сторон че­
ловека и ИИ. Ни одна сторона по отдельности не обладает такой мощью и та­
кими возможностями, как они вместе. ИИ - это скорость, огромный объём
знаний и отсутствие усталости. Человек - это осознанный выбор направле­
ния, глубина анализа, понимание ценности. Оптимальный рабочий процесс
12

Предисловие

будущего - это симбиоз; метафорически его можно представить как совмест­
ную работу мастера-ремесленника и сверхспособноrо подмастерья, который
мгновенно подносит любой инструмент или справку. При этом создавать по­
настоящему ценный и выдающийся продукт по-прежнему умеет только мастер.
Если вы разработчик, читающий эту книгу, зн�йте - настало время осво­
ить эти новые инструменты и парадигмы. Книга поможет вам попробовать ИИ
в роли программиста-ассистента для следующего проекта, научит вас разби­
вать задачи на обрабатываемые ИИ части и развить навык формулировки за­
просов и проверки результатов. Вместе с тем она призывает вас ещё сильнее
полагаться на то, что действительно делает вас такими ценными и уникальны­
ми, а именно на способность проектировать системы, понимать пользовате­
лей и принимать решения, благодаря которым ПО будет лучше соответство­
вать реальности.

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

Курсив
Используется для новых терминов, URL, адресов электронной почты, имён
файлов и расширений файлов.

Моноwиринный wрифт

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

Предупреждение или предостережение.
�

Предисловие 1

13

O'Reilly Online Learning
На протяжении более 40 лет O'Reilly Media даёт знания и навыки в области тех­
нологий и бизнеса, а также предлагает материалы, помогающие компаниям до­
биваться успеха.
Наша уникальная сеть экспертов и новаторов делится своим опытом и знания­
ми в книгах, статьях и на нашей онлайн-платформе обучения. Онлайн-платформа
O'Reilly предоставляет по запросу доступ к живым курсам, углублённым учебным
программам, интерактивным средам программирования, а также обширной кол­
лекции текстов и видео от O'Reilly и более чем 200 других издателей. Дополнитель­
ная информация указана на странице по адресу https://oreilly.com.

Как с нами связаться
Все касающиеся этой книги вопросы и комментарии направляйте издателю:
O'Reilly Media, Inc.
141 Stony Circle, Suite 195
Santa Rosa, СА 95401
800-889-8969 (США и Канада)
707-829-7019 (международные и местные звонки)
707-829-0104 (факс)
support@oreilly.com
https:/!www. oreilly. сот/about!contact.html
У этой книги есть своя веб-страница, на которой публикуются исправления,
примеры и дополнительная информация: https://oreil.ly!BeyondVibeCoding
Новости и информацию о наших книгах и курсах можно найти по адресу
https://oreilly. сот

ЧАСТЬ 1

Основы

ГЛАВА 1

Введение: что такое вайб-кодинг?
ИИ меняет сам способ создания программного обеспечения тем, что предлагает но­
вые парадигмы программирования, от свободной формулировки запросов до струк­
турированной помощи. Представьте, что для создания какой-то программы вам
не нужно долго и подробно расписывать все инструкции согласно правилам того или
иного языка программирования; вы просто описываете нужное вам поведение про­
граммы - почти так же, как если бы, например, общались с коллегой, - а ИИ прев­
ращает ваши идеи в рабочий код. В этом и заключается суть так называемого вайб­
кодинга с акцентом на запросы и исследование, с формулировками на естественном
языке, с ожиданием того, что все возможные пробелы будут заполнены большой язы­
ковой моделью (LLM, Large Language Mode[). Термин «вайб-кодинг» совсем недавно
придумал пионер ИИ-разработки Андрей Карпатый (https://oreil.ly/OtбCR), описав­
ший новый способ программирования, при котором разработчики «полно­
стью отдаются вайбам» ИИ-помощника («вайб» от англ. vibe - «вибрация, дух,
атмосфера, интуиция», по-русски это можно было бы передать примерно как
«программирование на расслабоне», «интуитивное программирование» и т. д.).
В этой книге я постараюсь подробнее рассмотреп:?, что же этот вайб-кодинг
означает для профессиональных разработчиков и как он соотносится с тем, что
я называю «разработкой с помощью ИИ» (AI-assisted engineering), или «инже­
нерным подходом при помощи ИИ», то есть с более формализованным процес­
сом «дополненного программирования» (augmented coding process). Я расскажу,
как меняется роль разработчика в эпоху ИИ, какие инструменты и рабочие про­
цессы могут максимизировать эффективность разработчиков, как ИИ работа­
ет с кодовой базой и как решать возникающие при этом уникальные проблемы.
Я также отмечу области, в которых вайб-кодинг особенно продуктивен и где он
связан с трудностями; я затрону тему баланса между быстротой генерации кода
со стороны ИИ и осознанным контролем со стороны человека. В итоге у вас
должно сложиться ясное представление о том, как в своей практике програм­
мирования ответственно и эффективно пользоваться пресловутыми вайбами
(интуицией, ощущениями, идеями) - так, чтобы не просто выдавать как можно
больше кода на максимальной скорости, а чтобы стать более креативным и про­
дуктивным разработчиком программного обеспечения в эпоху ИИ.
Глава 1. Введение: что такое вайб-кодинг?

17

В этой главе мы рассмотрим трансформацию роли разработчика: переход
от написания детальных инструкций для машин к сотрудничеству с ИИ посред­
ством выражения намерений (см. иллюстрацию 1.1). Мы выясним, почему так
важен этот вайб-сдвиг в программировании, как он работает на высоком уров­
не и какие он порождает возможности и проблемы.

Намерение
Разработчик

Код
Иллюстрация 1.1. Схематическое представление программирования с на­
мерением. Разработчик предлагает высокоуровневую спецификацию («наме­
рение»), а ИИ переводит её в код. Так можно образно передать идею перехо­
да от построчного написания кода к его генерации на более высоком уровне

Спектр ИИ-кодирования: от вайб-кодинга
до разработки с помощью ИИ
За последний год я с любопытством наблюдал за тем, насколько по-разному ис­
пользуют ИИ в своём рабочем процессе разработчики, особенно среднего и вы­
сокого уровня. На одном конце спектра находится вайб-кодинг, а на другом то, что я называю разработкой с помощью ИИ. Под этим я подразумеваю более
организованную интеграцию ИИ во весь процесс разработки ПО на всех этапах,
от проектирования до тестирования, в рамках чётко обозначенных ограниче­
ний. Оба подхода ориентированы на мощь ИИ, но их цели, аудитория и ожида­
ния радикально отличаются. В этой книге я анализирую эти две крайности и их
роль в современной веб-разработке.

Вайб-кодинг: программирование посредством диалога
Что касается вайб-кодинга, то мощные LLM (большие языковые модели)
здесь можно рассматривать как своеобразных партнёров по разработке, беру­
щих на себя тяжёлый труд по генерации кода и позволяющих программистам
18

1

Часть 1. Основы

сосредотачиваться на более высокоуровневых задачах. Как было отмечено в од­
ной из статей Business Insider (https://oreil.lylnvcFW), под вайб-кодингом «подра­
зумевается использование ИИ-инструментов... для выполнения тяжёлой рабо­
ты по созданию кода в целях ускорения разработки программного обеспечения».
По словам генерального директора NVIDIA ДженсенаХуанга, благодаря ИИ «са­
мым популярным новым языком программирования» стал английский, а не Java
или Python. Вместо того чтобы вручную прописывать каждую функцию и ис­
правлять каждую ошибку, люди просто взаимодействуют с искусственным ин­
теллектом на естественном языке - описывают функционал, рассматривают
предлагаемые решения и вносят правки в созданный ИИ-код.
Такой подход ознаменовал собой резкий сдвиг от традиционного програм­
мирования к программированию с опорой на ИИ. Классический подход требу­
ет тщательного планирования, тщательного соблюдения правил синтаксиса и за­
частую кропотливой отладки. Вайб-кодинг же полностью меняет устоявшийся
сценарий: «Это вообще не программирование, я просто смотрю, что-то говорю,
копирую и вставляю, и это по большей части работает», - шутливо замечает
Карпатый в статье Business Insider, указывая, насколько удачно ИИ превраща­
ет высокоуровневые инструкции в рабочий код при минимальном вмешатель­
стве пользователя.
Разработчики переходят от написания детальных инструкций для компью­
тера к управлению результатом с помощью ИИ. В качестве примера Карпатый
описывает (https:!!oreil.ly!КiбiJ), как он создавал веб-приложение, постоянно
принимая предложения ИИ: «Я всегда нажимаю Принять всё и больше не читаю диффы ... Всплывающие сообщения об ошибках}I просто копирую и вставляю в чат... Когда ИИ в некоторых случаях не может исправить баг, я просто
придумываю какой-нибудь вариант без него или прошу ИИ внести случайные
изменения, пока баг не исчезнет». Так код «разрастаетсю> до объёмов, каких
сам программист обычно никогда бы не написал, но благодаря итерациям за­
просов и исправлений проект быстро оформляется в единое целое. Вайб-ко­
динг, по сути, рассматривает «кодинг», то есть процесс написания кода, как
интерактивный диалог с ИИ-партнёром, а не усердное составление инструкций
на формальном языке с соблюдением синтаксиса и с расписыванием тестовых
ситуаций в одиночку. Он ориентируется на скорость и исследование, его цель получить рабочее решение с минимальными затратами.
Вайб-кодинг можно назвать порождением нескольких удачно встретившихся
друг с другом тенденций. Во-первых, это поразительное повышение эффектив­
ности современных генерирующих и исправляющих код ИИ-помощников (та­
ких как Codex и ChatGPT компании Open AI, Claude компании Anthropic и др.).
В той же публикации Карпатый отмечает, что такое «стало возможным, потому
Глава 1. Введение: что такое вайб-кодинг?

19

что LLM ... становятся чрезвычайно хорошими» - они проанализировали ог­
ромные объёмы кода с GitHub и научились выдавать правдоподобные решения
для множества задач.
Во-вторых, появились новые инструменты разработки, органично включа­
ющие эти модели в рабочий процесс программирования (о них будет сказано
чуть позже). И наконец, меняется мышление разработчиков и растёт их дове­
рие к ИИ, берущему на себя всё больше задач. Это уже не просто «автодополне­
ние на стероидах», это передача на усмотрение ИИ целых функций или файлов.
На практике вайб-кодинг часто воспринимается как наличие бесконечного чис­
ла усердных «джунов», готовых реализовать что угодно - только работающих
со скоростью облачных вычислений.
Одна из самых многообещающих перспектив вайб-кодинга - это резкий ска­
чок производительности. Его восторженные адепты утверждают, что могут со­
здавать функционал или прототипы в десять или даже в сто раз быстрее, чем
раньше. Например, инженер Джон Хустье из Codeium (разработчик редактора
Windsurf) пишет: «Зачем быть !Ох-программистом, если можно стать 100х-про­
граммистом?» (https://oreil.ly!_nfZ,n), намекая, что при выборе правильной IDE
с интегрированным ИИ можно достичь поистине потрясающей продуктивно­
сти. Такие инструменты, как Windsurf (IDE с поддержкой ИИ), «могут радикаль­
но ускорить разработку и помочь достичь продуктивности порядка l00x». Воз­
можно, коэффициент l00x - это крайний случай, но об огромном ускорении
говорят даже более консервативные исследования.
Сегодня разработчики могут за считаные секунды генерировать шаблонный
код, мгновенно исправлять ошибки и даже поручать ИИ писать тесты или до­
кументацию, сокращая рабочее время с нескольких дней до нескольких часов.
Один-единственный разработчик, освобождённый от необходимости вручную
набирать код и вооружённый искусственным интеллектом, способен за выход­
ные создать прототип полнофункционального приложения, тогда как рань­
ше у небольшой команды на это уходило несколько недель. И это не просто
хайп на волне популярности; как я отмечал в благе Pragmatic Engineer в янва­
ре 2025 года (https://oreil.ly!khEfs), опросы показывают, что 75% разработчиков
уже интегрировали в свои рабочие процессы ИИ в той или иной форме, а мно­
гие компании сообщают о двукратном или трёхкратном росте скорости разра­
ботки. В общем, ИИ-помощники превращают мифического « 1Ох-программиста»
во вполне реальный (и достижимый) феномен «lООх-программиста».
Чтобы понять всю революционность этого процесса, рассмотрим конкрет­
ный пример. Допустим, некий разработчик хочет создать простой веб-инстру­
мент, подсчитывающий количество слов в расшифровке подкаста и приблизи тельно оценивающий время на прочтение этого документа. Вместо того чтобы
20

Часть 1. Основы

начинать писать код с нуля, разработчик открывает среду разработки с инте­
грацией ИИ и описывает свою идею. По этому описанию ИИ за несколько ми­
нут создаёт рабочий прототип. Затем разработчик говорит: «Сделай счётчики
статистики яркими и добавь возможность экспорта в PDF», а ИИ соответству­
ющим образом обновляет код. В итоге один клик, и за десять минут получает­
ся вполне функциональный инструмент. Это реальный сценарий (о чём пишет
сам разработчик, пользующийся ИИ Replit, в статье, опубликованной по адресу
https:!loreil.ly!guqFZ), показывающий, что вайб-кодинг действительно позволяет
экстремально быстро разрабатывать программы на основе последовательных
высокоуровневых запросов. Точно так же в процесс разработки ПО вовлека­
ются и неспециалисты: в той же статье упоминается уволенный маркетолог, ко­
торый с помощью ИИ-ассистента создал 100 простых веб-инструментов, сум­
марно вышедших в топ на Product Hunt. Когда порог входа для создания ПО
опускается настолько низко, то речь идёт уже не о росте продуктивности опыт­
ных разработчиков - речь идёт о том, что фактически расширяется сам круг
людей, которые вообще могут заниматься разработкой программного обеспе­
чения.
Однако у вайб-кодинга есть и серьёзные оговорки. Так как многое при этом
отдаётся на усмотрение ИИ, в итоге может получиться код, «работающий» в иде­
альном сценарии, но скрывающий внутри себя целое минное поле багов и пло­
хих решений. Без чёткого плана и ограничений большая языковая модель мо­
жет сгенерировать программу без нормальной обработки ошибок, без проверок
безопасности и без возможности масштабирования. На практике сгенерирован­
ный искусственным интеллектом код часто оказывается «колоссом на глиняных
ногах»: внешне он выглядит надёжно, но содержит ·внутри себя скрытые про­
блемы, проявляющиеся только при реальном использовании. Я сам видел, как
разработчик буквально на вайбе с рекордной скоростью собирал полнофункциовальный продукт, а позже выяснялось, что код этого продукта неэффективен
и плохо поддерживается. Такого рода «карточный домик» легко разваливается
под реальной нагрузкой.
Представим, что вы просите ИИ «сделать систему аутентификации пользо­
вателей». ИИ быстро выдаёт рабочий инструмент идентификации, но при этом
использует упрощённый метод шифрования или библиотеку с известными уяз­
вимостями. Опытные разработчики понимают, что предлагать пользователям
такой продукт рискованно - работающий код должен быть понятным и вызывать доверие. Как выразился один эксперт (https:!loreil.ly!ppXCJ): «Полагать­
ся в создании рабочей кодовой базы на ИИ очень рискованно. Нам, как инже­
нерам ПО, по долгу службы очень часто приходится поддерживать и развивать
существующие системы, для которых качество кода и его понятность играют
Глава 1. Введение: что такое вайб-кодинг?

21

критически важную роль». Вайб-кодинг же в своих крайних проявлениях не даёт
никаких гарантий качества.
Ещё одна проблема заключается в том, что вайб-кодинг по сути обесценивает
предварительное планирование. В традиционной разработке ПО большое вни­
мание уделяется продуманному планированию: выбор моделей данных и под­
ходящих шаблонов программирования, анализ хотя бы минимального технического задания. Вайб-кодинг же переворачивает процесс с ног на голову: он
начинает без опорной конструкции («каркаса») и сразу переходит к реализации
посредством подсказок (промптов). В результате процесс разработки получает­
ся непоследовательным, с перепрыгиванием с одного на другое. В итоге можно
загнать себя в угол - например, ИИ выберет метод управления состоянием или
библиотеку, которые вы не собирались использовать, и вам придётся либо упор­
но намекать на нужные варианты, подталкивая его в нужном направлении, либо
смириться с его выбором. Без первоначальных набросков архитектура может
получиться крайне шаткой и бессистемной. Для быстрых прототипов это допу­
стимо, но для крупной базы, для которой важна согласованность, это проблема.
Следует отметить, что сам по себе вайб-кодинг не плох. По сути, его появле­
ние - это продолжение текущего процесса демократизации программирования.
Он снижает порог входа в сферу создания ПО, примерно так же, как это в своё
время сделали платформы визуальной разработки или скриптовые языки. Мо­
тивированный неспециалист с чёткой идеей потенциально может создать не­
сложное приложение, опираясь лишь на одни вайбы. Для опытных же разра­
ботчиков вайб-кодинг может стать мощным инструментом мозгового штурма,
в чём-то подобным псевдокоду, но с мгновенным результатом, который можно
запустить и проверить. Я часто напоминаю разработчикам (и себе самому), что
«вайб-кодинг - это не оправдание низкого качества». Он должен находиться
в начале решения, а не в его конце.

Разработка с помощью ИИ: разработка с ИИ-партнёром
На противоположном конце спектра располагается подход, который я называю
разработкой с помощью ИИ - более структурированный и методичный способ
разработки ПО, когда ИИ на каждом этапе выступает в роли помощника, или
«второго пилота». Разработчик же при этом сохраняет ведущую роль, не поки­
дая место первого пилота. Этот способ подразумевает использование ИИ на про­
тяжении всего жизненного цикла разработки ПО (SDLC, Software Development
Lifecycle): интеллектуальное автодополнение, чат, миграция кода, исправление
ошибок, генерация тестов, а также частичная (функции, модули, компоненты)
и полная генерация кода (см. иллюстрацию 1.2).
22

Часть 1. Основы

Вы начинаете с плана (пусть даже минимального), в котором намечаете,
что именно нужно создать, заранее устанавливая ограничения и критерии от­
бора. Затем вы при необходимости подключаете ИИ-инструменты для более
быстрой реализации некоторых частей этого плана или для улучшения их ре­
зультатов. В отличие от ориентированного на запросы вайб-кодинrа, такой
способ можно назвать «разработкой с опорой на предварительное планирова­
ние» с поддержкой ИИ. План может быть оформлен как небольшой документ
с требованиями к продукту (PRD, Product Requirements Document) для опреде­
лённоrо функционала или даже как простой чек-лист задач. Ключевое разли­
чие здесь в том, что работа изначально строится на чётком замысле и ограни­
чениях; ИИ получает свободу действий только после того, как сформулирован
план действий.
Разработчик создаёт
план/спецификацию

--+

Разработчик задаёт
ИИ промпт (целевой)

�

�

ИИ генерирует
фрагмент кода

Разработчик
просматривает его,
и процесс повторяется

1

---+
�

�

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

Представим разработчика на React, которому нужно создать новый интер­
активный компонент в виде дашборда. Выбрав разработку с помощью ИИ, он
мог бы начать с формулировки нужного функционала компонента и его API.
Компонент «дашборд» показывает список аналитических карточек, поддер­
живает фильтрацию по дате и имеет кнопки обновления и экспорта. Он дол­
жен загружать данные согласно нашему API ( с соответствующей обработ­
кой ошибок) и соответствовать по дизайну нашему стилю.
Глава 1. Введение: что такое вайб-кодинг?

1

23

По сути, это описание представляет собой спецификацию. Разработчик мо­
жет даже схематически нарисовать модель данных или перечислить уже суще­
ствующие функциональные элементы, которые можно было бы включить в этот
разрабатываемый компонент. И только после этого он привлекает ИИ: например, пользуется IDE с ИИ или с ассистентом для генерации каркаса будущего
компонента на основе имеющегося описания. ИИ может предложить начальную
реализацию компонента React с заглушками для загрузки данных и обработчиков событий. Так как разработчик предоставил ИИ чёткие инструкции, вывод
будет с большей вероятностью соответствовать требованиям проекта (напри­
мер, подразумевать определённые системные классы или использовать коррект­
ные конечные точки API). Код не становится для разработчика сюрпризом; он
представляет собой результат хорошо сформулированного запроса.
Разработка с помощью ИИ не ограничивается генерацией кода одного компо­
нента. ИИ привлекается на всех этапах жизненного пути разработки, но в кон­
тролируемом формате. Для рутинных задач можно использовать инструменты
ИИ-автодополнения, например GitHub Copilot, который по мере набора пока­
зывает возможные следующие строки кода и экономит время при реализации
распространённых шаблонов (паттернов) проектирования. Например, при на­
писании модульных тестов ИИ-ассистент может автоматически предлагать про­
верочные утверждения (assertions) на основе имени функции. Говоря о тестах,
ИИ можно использовать для генерации тестовых сценариев после реализации
функции; для этого можно будет включить в запрос спецификацию компонен­
та или код для обработки граничных случаев, которые стоит проверять. Смысл
здесь в том, чтобы «дополнять» работу программиста, а не заменять его. Вы по­
прежнему продумываете логику и проверяете корректность работы кода; ИИ
просто берёт на себя часть рутинной работы.
Что касается миграции кода или рефакторинга, то ИИ может стать здесь настоя­
щим спасением. Представьте, что вам нужно преобразовать компонент React на ос­
нове классов в современный функциональный компонент с хуками. Вместо того
чтобы делать всё вручную, можно попросить ИИ-ассистента трансформировать
код или хотя бы наметить последовательность шагов для его трансформации. При
хорошем представлении о старых и новых шаблонах языковая модель может сге­
нерировать черновой вариант рефакторинга, который вы затем будете проверять
и дорабатывать. Такой структурированный подход к ИИ позволяет решать чётко
определённые задачи (например, «сделай миграцию этого кода с Redux на API React
Context») и выполнять их одну за другой, вместо того чтобы надеяться на какой-то
вменяемый общий результат по расплывчатому запросу «сделай что-нибудь».
Самый же впечатляющий способ программирования с помощью ИИ - это,
по всей видимости, генерация полноценного мини-приложения или функции
24

Часть 1. Основы

на основе подробной спецификации. В настоящее время существует несколько
инструментов, позволяющих вводить описание приложения, нечто вроде миниPRD, и получать работающую кодовую базу или работающий прототип. Напри­
мер, разработчик может предоставить спецификацию в запросе вида:
приложение to-do list («список дел») с фронтендом на React и бэкендом
на Node.js, с поддержкой аутентификации пользователей и обновлений в ре­
альном времени.
ИИ-инструмент при этом создаст каркас проекта, сгенерирует ключевые ком­
поненты и настроит схему базы данных.
И это не волшебство, это ускоренная версия того, что любой добросовест­
ный разработчик сделал бы в начале нового проекта (создание каталогов, вы­
бор библиотек, написание шаблонного кода). Здесь важно, что креативность ИИ
ограничена рамками, заданными в спецификации. В результате получается ми­
нимально жизнеспособный продукт (MVP, Minimum Viahle Product), соответст­
вующий предоставленным требованиям. Опытный разработчик, разумеется,
не будет считать его готовым к рабочей среде после первой же генерации, а будет
рассматривать его как черновик. Разработчик запускает приложение, пишет или
переделывает тесты для проверки каждой функции, проверят код на наличие не­
соответствий или небезопасных настроек и при необходимости дорабатывает
его. Короче говоря, он занимается тем же, чем занимался и раньше; он исполь­
зует свой опыт и применяет своё мастерство, только с многократным ускорени­
ем благодаря способностям ИИ, который генерирует_ большие фрагменты кода
по предоставленным спецификациям.
Цели разработки с помощью ИИ отличаются от целей вайб-кодинrа. Главное
здесь не в том, чтобы просто быстро получить работающий код, а в более эффек­
тивном создании высококачественного кода. Речь идёт о повышении продуктив­
ности при сохранении (или даже улучшении) надёжности результата. Команда
разработчиков, использующая в своей работе подход с помощью ИИ, с полным
правом может утверждать: «Мы собираемся реализовать эту функцию в два раза
быстрее, но без какого бы то ни было снижения наших стандартов качества».
Сторонники такого подхода (разработки с помощью ИИ) - это, как прави­
ло, профессиональные разработчики и коллективы с устоявшимися процессами
(код-ревью, тестирование, конвейер развёртывания), от которых они не готовы
отказываться. Это разработчики среднего и старшего уровня, которые рассма­
тривают ИИ как новый мощный инструмент в своём арсенале, а не как замену
этому арсеналу. Они, скорее всего, уже видели, к чему приводит сокращение про­
цессов, и потому ценят методы работы, сохраняющие поддерживаемость кода.
Глава 1. Введение: что такое вайб-кодинг? 1 25

(Для сравнения: среди адептов собственно вайб-кодинга много разработчиков­
одиночек, нацеленных на быстрое создание демонстрационной версии; ориенти­
рованных на продукцию специалистов с некоторыми знаниями из сферы про­
граммирования и даже программистов, которых можно назвать относительными
новичками и которые используют ИИ для компенсации пробелов в своём опыте.)
Разработка с помощью ИИ предполагает, что контроль над решениями
остаётся за человеком, а ИИ предлагает эти решения или ускоряет генерацию
возможных вариантов. Первостепенное внимание уделяется качеству кода, про­
изводительности и надёжности, поэтому каждый сгенерированный ИИ фраг­
мент кода подвергается такому же строгому анализу, как если бы его написал
начинающий разработчик. Относитесь к ИИ как к своему стажёру, а не как к за­
мене этого стажёра. Ему можно делегировать задачи, но вы обязаны проверять
его работу. Точно так же, как вы не стали бы без код-ревью принимать код, на­
писанный стажёром-человеком, так и не стоит без ревью принимать и включать
в работающее ПО код, написанный ИИ. Благодаря такому подходу в программи­
ровании удаётся сохранять приоритет строгости и методичности.

Разный склад ума, разные ожидания
Вайб-кодинг и разработка с помощью ИИ - это два разных подхода. Вайб-ко­
динг строится «сверху вниз», при этом отталкиваются от некой начальной идеи,
которая реализуется в процессе взаимодействия человека с ИИ. Процесс этот
похож на джазовую импровизацию с минимальной структурой, но с большим
пространством для творческих вариаций, когда форма мелодии складывается
по ходу исполнения. Разработка с помощью ИИ - это систематичный и итера­
тивный подход; она больше напоминает классические пьесы, в основе которых
лежит тема или мотив (ваши требования), а мелодия методично развивается
с некоторыми вариациями (предложениями со стороны ИИ) в рамках записан­
ной на бумаге партитуры. В обоих случаях получается «музыка», но процессы,
как и их результаты, различны.
Для разработчиков middle- и senior-ypoвня главное - это ожидания от каждо­
го подхода. В случае с вайб-кодингом будьте готовы к сюрпризам. ИИ может пока­
зать вам решение, которое вы сами никогда не написали бы - возможно, он вос­
пользуется другой библиотекой или шаблоном программирования, с которыми
вы не слишком знакомы. Привлекательность вайб-кодинга отчасти заключается
именно в таких сюрпризах, в возможности поучиться на их примере или быстро
справиться с рутинной задачей. Но также нужно быть готовым к сбоям и ошибкам.
Энтузиасты вайб-кодинга должны помнить, что ответственность за самый слож­
ный финальный этап остаётся за ними. Волшебство реально, но не всесильно.
26

Часть 1. Основы

Что же касается разработки с поддержкой ИИ, то она подразумевает более
взвешенные и, пожалуй, более реалистичные ожидания для долгосрочных про­
ектов. Разработчики рассчитывают на то, что ИИ сэкономит их время и, воз­
можно, подскажет одно-два решения, но не сделает за них всю работу. Хороший
программист с ИИ-помощником в рамках более крупного проекта может даже
воспользоваться некоторыми приёмами вайб-кодинга. Например, при реализа­
ции хорошо задокументированного проекта он может ненадолго переключиться
в вайб-режим и сказать: «ИИ, сгенерируй быструю вспомогательную функцию
для форматирования этих дат», после чего тут же вернуться в программистский
режим, проверить эту функцию и интегрировать её. Суть здесь в том, что ИИ это работающий под вашим руководством сотрудник. Вы поручаете искусствен­
ному интеллекту задачи, в которых он силён (шаблонный, повторяющийся код,
общие реализации), а всё остальное выполняете сами (критическая логика, ин­
теграция, финальное ревью).
В этом случае среди ожиданий разработчиков - повышение продуктивности,
сокращение количества механических ошибок (например, ИИ с меньшей вероят­
ностью допустит опечатку в имени переменной) и, возможно, расширение общего
пространства потенциальных решений (ИИ может предложить алгоритм, о кото­
ром вы не подумали). Но также не стоит забывать и о том, что вам придётся по­
тратить время на проверку этих решений. Отладка кода, созданного с помощью
ИИ, - это всё та же отладка: вы запускаете тесты и при необходимости проходи­
те в отладчике по строкам кода. Разница лишь в том, что вам придётся занимать­
ся отладкой кода, написанного для вас искусственным интеллектом, а многие ещё
к этому не привыкли. Более подробно об этом будет ск_азано в главе 5.
Цели этих двух подходов подчёркивают их фундаментальное различие:
вайб-кодинг ориентирован на скорость в ближайшей перспективе, тогда как
разработка с помощью ИИ ориентируется на постоянное повышение скорости
и на надёжность. Вайб-кодер может сказать: «Мне нужно рабочее приложение
к вечеру, чтобы проверить идею». Программист, использующий в своей рабо­
те помощь ИИ, скажет: «Мне нужно быстро создать эту функцию, но она долж­
на быть достаточно надёжной для того, чтобы оставаться в нашей кодовой базе
годамИ>). Первый доволен, если код в принципе работает, второй же заботится
о чистоте кода, которым будут пользоваться другие.
Эти различия естественным путём привлекают разные аудитории. Менее
опытные разработчики или специалисты вне сферы программирования скло­
няются к вайб-кодингу, поскольку он снижает порог для входа и даёт мгновен­
ный результат. Я встречал продакт-менеджеров и дизайнеров, которые экспери­
ментировали с кодом посредством вайб-промптов и получали готовые решения,
воспринимая ИИ как своего рода супермощную платформу Stack Overflow.
Глава 1. Введение: что такое вайб-кодинг?

27

С другой стороны, опытные разработчики и коллективы программистов чаще
выбирают разработку с помощью ИИ. Им уже приходилось сталкиваться в сво­
ей практике с неряшливо написанным кодом, и потому они исходят из принципа: «будем делать правильно, пусть даже и с ускоряющими дело новыми инстру­
ментами». Они прикладывают чуть больше усилий на старте (пишут мини-РRD,
настраивают структуру проекта), но получают более надёжные и перспектив­
ные результаты.

Как найти своё место в спектре
Возникает соблазн спросить: какой подход лучше? Правда в том, что вайб-ко­
динr и разработка с помощью ИИ - не взаимоисключающие категории; они
представляют два полюса спектра, тогда как в реальных рабочих процессах ча­
сто сочетаются элементы обоих. В начале проекта разработчик может ненадол го заняться вайб-кодинrом и сделать какие-то наброски, после чего переклю­
читься в режим технического программиста для закрепления результата. Либо
он может в целом придерживаться разработки с помощью ИИ, но иногда - для
какого-нибудь шаблонного скрипта или одноразового прототипа - перейти
к вайб-кодинrу и посмотреть, что получится. Главное при этом - осознавать
слабые и сильные стороны обоих подходов и пользоваться тем, что лучше соот­
ветствует конкретному контексту.
Воспринимайте вайб-кодинr как скоростной разведывательный вездеход, ко­
торый быстро сворачивает с проторённой дороги и отлично подходит для ис­
следования местности. Разработка с помощью ИИ больше похожа на надёжный
поезд, едущий по рельсам: для этого сначала нужно проложить железную дорогу
(составить план), но это более надёжный вариант, который с большей вероятно­
стью приведёт вас к цели, и вам не придётся с беспокойством озираться по сто­
ронам, оказавшись в незнакомом месте. Разработчики middle- и senior-ypoвня
должны уметь управлять обоими «транспортными средствами», но их выбор
зависит от задачи. Если ваша цель - это быстрая реализация какой-то концеп ции или быстрое создание прототипа (например, на хакатоне или при провер­
ке жизнеспособности идей), то вайб-кодинr сможет придать вам нужное уско­
рение. Главное потом - упорядочить код, предназначенный для последующего
использования. Если же ваша цель - создание поддерживаемого функционала
в профессиональном проекте, то разработка с помощью ИИ позволяет избежать
появления в вашей кодовой базе некоего фрагмента кода в виде «чёрноrо ящика», принцип работы которого никто не понимает.
Любопытно, что по мере опыта работы с ИИ разработчики часто естест­
венным образом смещаются по спектру от вайб-кодинrа в сторону разработки
28

Часть 1. Основы

с помощью ИИ. Поначалу новые впечатления восхищают, и осознание того, что
можно по одному запросу получать целые куски кода, завораживает - в конце
концов, кому не хотелось бы вот так запросто, «простым разговором», создавать
рабочее приложение?
Но после восторга медового месяца включается практическое мышление. Раз­
работчики начинают осознавать, что в каких-то областях ИИ действительно хо­
рош, а в каких-то не очень. Они учатся разделять задачи и подавать их искусственному интеллекту по частям, вместо того чтобы пытаться получить готовое решение
целиком. По сути, они переходят от роли «мастеров художественного промпта»
к роли дирижёра оркестра. Они по-прежнему используют творческий потенциал
ИИ, но уверенной рукой задают ему темп и указывают нужное направление, что­
бы он следовал чётко прописанной партитуре. Я в своей практике тоже стал на­
много более осознанно формулировать запросы: я часто пишу небольшие фраг­
менты псевдокода или комментариев и прошу ИИ дописать их, вместо того чтобы
задавать расплывчатые вопросы, допускающие широкое толкование. Так я поль­
зуюсь гибкостью вайб-кодинга, но в рамках контролируемой мною структуры.
Стоит отметить, что инструменты тоже развиваются и уже покрывают весь
спектр подходов. С одной стороны, имеются чат-интерфейсы и ориентирован­
ные на естественный язык среды, предназначенные специально для вайб-кодин­
га, причём сам код вы даже не увидите, пока не попросите показать его. С дру­
гой стороны, привычные IDE обрастают ИИ-функциями, которые гармонично
встраиваются в традиционный процесс разработки: это и предлагающие улуч­
шения ИИ-линтеры, и генераторы документации с объяснением кода, и боты дпя
систем контроля версий, самостоятельно создающие �ул-реквест в репозиторий
и предлагающие правки для ревью. Такие инструменты поддерживают техниче­
ский программистский настрой, потому что применяются в рамках обычного
цикла разработки (редактирование, ревью, тестирование и т. д.), но с привлече­
нием возможностей ИИ.
Со временем, с появлением ещё более удачных практических сценариев, гра­
ница между вайб-кодингом и разработкой с помощью ИИ может размыться. Воз­
можно, то, что сегодня считается вайбом, обрастёт дополнительными ограниче­
ниями и правилами, а то, что кажется «строгим техническим подходом», станет
более гибким. В представляемом мною идеальном будущем мы свободно переме­
щаемся по всему этому спектру: мы вместе с ИИ исследуем новые идеи и ищем но­
вые решения, но возвращаемся к жёстким техническим принципам, когда нужно
довести продукт до надёжного состояния и отправить его пользователям.
В широком спектре подходов отражена эволюция нашей работы с ИИ-инструментами. В настоящее время, по мере того как мы совершенствуем методы
взаимодействия с ИИ (будь то быстрый вайб-кодинг или структурированный
Глава 1. Введение: что такое вайб-кодинг?

29

рабочий процесс), трансформация фундаментальных основ программирования
продолжается, и мы продолжаем её осмысливать. Меняется сама природа про­
граммирования. Мы отходим от традиционной парадигмы, согласно которой
разработчики должны переводить свои идеи в чётко выраженные инструкции,
и движемся к будущему, где можно будет выражать свои намерения напрямую,
а ИИ возьмёт на себя роль переводчика этих намерений на язык кода.
Сдвиг этот бросает вызов самым базовым представлениям о том, что значит
быть программистом. На протяжении нескольких поколений нас ценили как лю­
дей, способных мыслить как машины - разбивать задачи на отдельные логиче­
ские части, подходящие для их выполнения компьютером. Но что произойдёт,
когда машины научатся понимать, что мы действителыю хотим, а не просто то,
что мы приказываем им делать� Тут и выходит на передний план программиро­
вание с намерением - не просто новый инструмент или техника, а концепция,
предлагающая фундаментальное переосмысление роли разработчика.

Чтение между строк: программирование
с намерением
На протяжении нескольких десятков лет под программированием понимали со­
ставление инструкций в виде строк кода, которые объясняли компьютеру, как он
должен что-то сделать. Программист-человек должен был прописывать каждую
функцию, каждый цикл или каждое условие. Но программирование с намере­
нием меняет правила игры. Вместо того чтобы заниматься реализацией на низ­
ком уровне, разработчик сосредотачивается на результате или на цели, то есть
на том, что должна сделать программа. Человек выражает это намерение описательно (часто на естественном языке), а ИИ-система уже сама выполняет ра­
боту по составлению кода.
Можно представить это и так: традиционное программирование - это со­
ставление подробной инструкции, а программирование с намерением - это ука­
зание пункта назначения проводнику, который самостоятельно прокладывает
лучший маршрут. Сосредотачиваясь на цели, а не на маршруте, разработчики
переходят на более высокий уровень абстракции.
Такой подход нельзя назвать таким уж новым - различные инструменты визуальноrо программирования, платформы-конструкторы и генераторы кода уже
давно обещают повысить уровень абстракции, но именно сегодняшние достижения в области ИИ наконец-то предлагают практические способы превраще­
ния составленных на естественном языке описаний сложного поведения в ра­
ботающий код.
30

Часть 1. Основы

Эпоха промптов: от инструкций к описаниям
Центральное место в этом сдвиге парадигмы занимает такой скромный элемент,
как промпт. Промпт - это запрос или вопрос, который задают ИИ-системе,
чтобы та сгенерировала код. По сути, это описание того, что должна делать про­
грамма, а не описание, как это надо сделать. Ощущается это совсем иначе, чем
составление кода. Например, вместо того чтобы вруч ную писать цикл парсинга
файла, можно задать следующий промпт.
Прочитай этот СSV-файл и извлеки email-aдpeca всех пользователей стар­
ше 18 лет.
ИИ попытается сгенерировать код, соответствующий этому описанию.
Почему это происходит именно сейчас? Правила игры изменил стремительный
прогресс больших языковых моделей (LLM), обуч енных на огромных массивах
кода и текста на естественном языке. Эти модели научились понимать промпты,
описывающие поведение программы, и создавать на их основе реальный код, реа­
лизующий такое поведение. Иными словами, они выявили закономерности в опи­
саниях задач и научились переводить эти закономерности в работающий код.
В результате всё чаще наблюдается сценарий, когда разработчики описыва­
ют функционал и логику на естественном языке или на псевдокоде, поручая ру­
тинную работу по написанию синтаксически правильного кода искусственному
интеллекту. Промпт становится нашей новой единицей мышления, лаконично
выраженным намерением. Мы перешли от модели, когда компьютеру говорят:
«Сделай Х, потом У, потом Z», к модели, когда говорят: «Мне нужно, чтобы про­
грамма делала Х, У и Z», а подробностями занимается ИИ.
Важно отметить, что умение составлять хороший промпт - это само по себе
отдельный навык (который мы детально разберём в главе 3). Из-за плохо сформу­
лированного, нечёткого промпта ИИ генерирует некорректный или неэффектив­
ный код, точно так же как нечётко сформулированное требование сбивает с тол­
ку программиста-человека. Чем точнее вы выражаете своё намерение в промпте,
тем лучше получ енный результат соответствует вашим требованиям. Именно по­
этому многие называют умение писать промпты новой грамотой программистов.

Как это работает: итеративный цикл и роль ИИ в генерации кода
Так как же обычное описание на естественном языке превращается в реально
работающий код? Всё волшебство кроется в умении больших языковых моде­
лей интерпретировать контекст и генерировать текст.
Глава 1. Введение: что такое вайб-кодинг?

31

Под словом большая в термине «большая языковая модель» (LLM, Large
Language Model) подразумевается количество её параметров (внутренней кон­
фигурации), часто исчисляемое миллиардами и более. Именно такое огромное
количество параметров позволяет ей выявлять сложные закономерности как
в естественных языках, так и в языках программирования. Большие языковые
модели были обучены на публичных репозиториях кода, форумах, документа­
ции и сайтах вопросов и ответов, благодаря чему изучили синтаксис языков про­
граммирования и освоили семантику кода, используемого для решения задач.
Взаимодействуя с ИИ-ассистентом, вы подключаетесь к этой обширной усвоен­
ной моделью базе данных. Объясним это простыми словами.
Как ИИ понимает запрос
Когда вы задаёте запрос (например, «Сгенерируй функцию, которая про­
веряет, является ли число простым»), ИИ-модель анализирует текст этого
запроса. Современные модели Google, OpenAI и Anthropic были обучены
на бесчисленных образцах естественного языка и кода, поэтому они пони­
мают, что вы хотели сказать, на основании выявленных закономерностей.
По сути, ИИ пытается предсказать наиболее вероятное завершение выска­
зывания в форме имеющего смысл кода.
Как ИИ использует контекст
Помимо однострочного запроса (промпта), ИИ-системы часто учитывают
и дополнительный контекст. Например, если вы работаете в IDE с ИИ-помощ­
ником, модель также может учитывать содержимое текущего файла, ваш стиль
написания кода, комментарии и даже связанные файлы. Весь этот контекст по­
могает ИИ сгенерировать код, соответствующий вашему проекту. Учёт контек­
ста похож на ситуацию, когда разработчик-человек читает разные фрагменты
уже существующего кода и документацию, чтобы понять, что делать дальше.
Как ИИ генерирует код
Поняв ваше намерение (или, по крайней мере, как можно точнее догадав­
шись о нём), модель приступает к генерации кода. Технически она делает
это токен за токеном (токен - это часть слова или символ), применяя ве­
роятности, усвоенные во время её обучения. Нужно отметить, что модель
не «мыслит» в привычном понимании этого слова; у неё нет компилятора
или среды выполнения для проверки кода. Она просто очень хорошо умеет
продолжать текст так, чтобы в результате с очень высокой вероятностью по­
лучался корректный код, потому что через неё пропустили огромное число
примеров такого кода. Если промпт чётко сформулирован, а контекст ясен,
32

Часть 1. Основы

сгенерированный моделью код может оказаться на удивление точным и даже
соответствовать лучшим образцам, имевшимся в наборе её обучающих данных.
Проверка кода человеком
Важно заметить, что ИИ не запустит и не внедрит ваше предложение за вас.
В итоге ответственность за программу лежит на вас. Вы проверяете сгенери­
рованный код, тестируете его и можете принять или не принять предложен­
ный вариант. Во многих случаях ИИ может по запросу также объяснять код
или изменять его. Роль ИИ похожа на роль помощника, который составляет
для вас черновик кода, но вы, как разработчик, принимаете окончательное
решение и отвечаете за соответствие кода требованиям проекта.
Что действительно впечатляет, так это то, что весь процесс занимает счи­
таные секунды. Если описать его схематично, то происходит следующее: ваше
описание (промпт) обрабатывается неким механизмом предсказания (большой
языковой моделью), который с какой-то вероятностью выдаёт соответсвующий
этому описанию код. Хотя «под капотом» модели скрывается сложная матема­
тика, воплощенная в слоях нейросетей, на пользовательском уровне это почти
неотличимо от общения с экспертом, который мгновенно вспоминает, как реа­
лизовать практически что угодно.
Один из важнейших аспектов вайб-кодинга (программирования с намерени­
ем), о котором следует помнить всегда, - это то, что он представляет собой ите­
ративный процесс сотрудничества между человеком и ИИ. Недостаточно про­
сто составить один идеальный промпт, после чего м?жно было бы откинуться
на спинку кресла и отдыхать, пока ИИ будет писать вместо вас полноценную
и безупречную программу. В реальности вы вступаете в диалог, вовлекаетесь
в цикл обратной связи, постепенно превращающий расплывчатую идею в рабо­
чий и доведённый до ума код.
Вот как примерно выглядит типичный цикл.
Шаг 1. Вы описываете, что хотите получить
Это ваш первоначальный промпт, или запрос. Например:
Напиши функцию расчёта ежемесячного платежа по кредиту на основе пер­
воначальной суммы, процентной ставки и срока.
Шаг 2. ИИ предлагает первоначальное решение
ИИ генерирует код для этой функции, включая параметры и формулу расчёта
платежей. Он может даже добавить комментарии с объяснением формулы.
Глава 1. Введение: что такое вайб-кодинг?

33

Шаг 3. Вы проверяете результат и тестируете его
Вы просматриваете код. Логичен ли он? Учитывает ли он граничные слу­
чаи? Вы быстро тестируете один из таких случаев: что будет, если процент­
ная ставка равна нулю? Что при этом делает код? Допустим, он обрабатывает
этот случай не очень хорошо.
Шаг 4. Вы уточняете запрос и правите код
Если код неидеален (а часто он и не бывает идеальным с первого раза), вы его
дорабатываете. Возможно, вам придётся ещё раз обратиться к ИИ («Дорабо­
тай функцию, чтобы она корректно обрабатывала ставку в ноль процентов»)
или править код самостоятельно, а если что-то непонятно, вы говорите ИИ:
«Объясни эту часть». Уточнения помогают устранить любые недопонимания.
Шаг 5. ИИ дорабатывает решение
На основе вашего отзыва или нового промпта ИИ корректирует код. Теперь
функция учитывает нулевую процентную ставку и корректно её обрабатывает.
Шаг 6. Повторение по мере необходимости
Цикл продолжается до тех пор, пока не будет получен удовлетворительный
результат. Возможно, следующим шагом вы попросите ИИ сгенерировать
также и модульные тесты для этой функции, чтобы убедиться в её коррект­
ной работе. После генерации тестов вы запускаете их для проверки.
Такое взаимодействие очень похоже на программирование в паре, где один
партнёр - это человек, а другой - ИИ-ассистент. Человек задаёт направление
и руководствуется требованиями высокого уровня, в то время как ИИ предла­
гает решения, пишет шаблонный код и ускоряет рутину. По отдельности ни тот
ни другой не столь эффективны в решении сложных задач: ИИ полагается на че­
ловека в том, что касается постановки целей и проверки, а человек для ускоре­
ния процесса перекладывает часть работы на ИИ.
Важно понимать, что итеративный процесс - это не только исправление оши­
бок, но и развитие решения. Начать можно с довольно общего промпта, а затем
постепенно уточнять намерение по мере анализа сгенерированного ИИ-кода.
Такой сценарий работы поощряет эксперименты. В случае неудачной первой
попытки вы почти не теряете времени - достаточно просто уточнить промпт
или поправить код и попробовать сгенерировать его снова. В традиционном
программировании бывает жалко выбрасывать модули, на которые были по­
трачены время и силы, но, если код генерирует ИИ, цена фальстарта невелика,
и это подталкивает к экспериментам и исследованиям различных вариантов.
34

Часть 1. Основы

Производительность, доступность и меняющаяся
природа программирования

Почему же программирование с намерением так важно? Переход к нему влечёт
за собой несколько существенных последствий.
Повышение продуктивности разработчика
Пожалуй, самое очевидное преимущество - это скорость. Когда ИИ берёт
на себя рутинную задачу, разработчики выполняют задачи быстрее. Стан­
дартный код, на ручное создание которого ранее уходили часы (напри­
мер, настройка моделей баз данных, конечных точек API или скриптов для
очистки данных), теперь создаётся за считаные минуты. Это подтверждают
первые исследования ИИ-ассистентов в кодировании: разработчики, поль­
зующиеся такими инструментами, как GitHub Copilot, выполняют задачи
значительно быстрее. Согласно одному из исследований, использование
Copilot сокращает время выполнения задачи на 55%. Умножив этот показа­
тель на все задачи проекта, получим примерное представление о будущем,
когда циклы разработки ПО значительно сократятся и команды смогут ра­
ботать быстрее.
Удержание разработчиков в «потоке»
Помимо выигрыша в скорости, у схемы программирования с намерением
есть и психологическое преимущество. Работа над шаблонным кодом или
попытки разобраться в синтаксисе нарушают «потрк» и ход мыслей програм­
миста. Когда ИИ берёт на себя многие из этих отвлекающих факторов, раз­
работчики лучше сосредотачиваются на решаемой задаче. Многие пользо­
ватели (https:!!oreil.ly/inQHR) сообщают, что когда они работают с помощью
ИИ, то их меньше утомляют рутинные задачи и они больше фокусируются
на творческой стороне программирования и на проектных аспектах. Иными словами, такая схема работы делает программирование более приятным
и снимает с плеч разработчика груз рутины, что, в свою очередь, повышает
качество результата (более довольный программист чаще пишет более каче­
ственный код).
Снижение порога входа в профессию
Традиционно программирование требовало хороших знаний синтаксиса того
или иного языка и особенностей различных библиотек и фреймворков. Про­
граммирование с намерением снизило эти требования, потому что часть на­
грузки перекладывается на ИИ. Новичку теперь вовсе не обязательно знать,
Глава 1. Введение: что такое вайб-кодинг?

1

35

с помощью какой команды открывается файл или какие параметры нуж­
ны для функции построения графика; если он сумеет правильно описать
свои пожелания, ИИ вспомнит все эти детали за него. Но это вовсе не зна­
чит, что любой неподготовленный человек без специальных знаний смо­
жет создавать сложные системы (вам по-прежнему нужно понимать, как
устроены программы и как они работают), это только значит, что получать
полезные результаты становится проще. Уже не кажется таким уж фанта­
стическим предположение о том, что эксперты в других областях (напри­
мер, биологи или экономисты) смогут написать прототипы нужных для
них инструментов, даже не будучи профессиональными разработчиками
ПО. В этом смысле программирование становится более доступным для
тех, у кого есть идеи и намерения, но нет специализированных навыков
написания кода.
Изменение ролей и навыков разработчика
По мере того как ИИ берёт на себя всё больше задач по генерации кода, роль
разработчика-человека трансформируется. Навыки архитектурного проек­
тирования, декомпозиции задачи и проверки кода становятся ещё важнее.
Программисты всё больше времени тратят не на прописывание синтаксиче­
ских конструкций, а на формулировку задачи, то есть на то, что нужно де­
лать, и на объяснение причин, почему код работает (или не работает). Суть
самого «умения программировать» смещается в сторону «умения заставлять
ИИ писать код». Наблюдается демократизация определённых аспектов раз­
работки ПО, и вместе с тем повышается уровень, на котором работают про­
фессионалы. По всей видимости, стоит ожидать появления новых методов
разработки, ориентирующихся на эффективное руководство искусственным
интеллектом (я затрону эту тему в главе 3 и буду возвращаться к ней на про­
тяжении всей книги).
Продуктивность и креативность
Любопытно, что по мере того, как ИИ берёт на себя всё больше рутин­
ной работы, разработчики сосредотачиваются на задачах более высокого
уровня - на улучшении пользовательского опыта, на исследовании но­
вых идей или на анализе сложных алгоритмических проблем, с которыми
ИИ справляется недостаточно хорошо. В идеале ИИ повышает продук­
тивность работы с 80% повторяющегося кода, освобождая наше внима­
ние для оставшихся «творческих» 20%. Тем самым он меняет наше рас­
пределение усилий.

36

Часть 1. Основы

Тем не менее не всё так уж радужно. Новый стиль разработки не лишён сво­
их проблем и недостатков.
Доверие и корректность
Можно ли во всём доверять ИИ? Если не проверять каждую строку, то суще­
ствует риск, что в коде останутся незамеченные ошибки. Разработчики долж­
ны тщательно тестировать и проверять код, созданный искусственным ин­
теллектом. Ответственность за корректность, надёжность и эффективность
результата лежит на человеке. Слепо доверять ИИ рискованно, и мы ещё по­
говорим об этом.
Утрата низкоуровневых навыков
Если вы постоянно доверяете всю рутину ИИ, то не утратите ли вы часть
своих навыков, не разучитесь ли вы писать код с нуля или находить глубо­
ко скрытые ошибки? Это похоже на ситуацию с калькуляторами, из-за кото­
рых ослабевают арифметические навыки. Разработчикам придётся осознан­
но поддерживать баланс между удобством работы и тем, чтобы не забывать
основы своей профессии.
Перемены на рынке труда
По мере распространения программирования с намерением в индустрии,
по всей видимости, станут цениться не те навыки, что ценятся сейчас. Потреб­
ность в специалистах, которые просто быстро пишут шаблонный код, умень­
шится, а спрос на тех, кто умеет проектировать сист_емы, интегрировать компо­
ненты и проверять корректность кода, наоборот, вырастет. Может измениться
и сам характер работы разработчиков: всё больше задач по реализации будет
брать на себя ИИ, а человеку останутся проектирование и контроль.

Кроме того, один из ключевых факторов вайб-кодинга - это размер так на­
зываемого окна контекста. Самое большое окно контекста среди всех моделей
ИИ сейчас у нейросети Gemini, что может радикально менять работу с крупны­
ми проектами. Некоторые модели уже поддерживают контекст свыше миллиона
токенов, что позволяет им удерживать в памяти целые приложения. Разработ­
чики могут передавать ИИ весь код проекта целиком, чтобы модель получила
общее представление о нём.
К этим преимуществам и недостаткам мы ещё вернёмся в конце главы.
Но прежде познакомимся с инструментами, благодаря которым стало возмож­
ным работать по-новому.

Глава 1. Введение: что такое вайб-кодинг?

37

Краткий обзор инструментов: становление
экосистемы
Вайб-кодинг можно воспринимать как своего рода философию, но эта фило­
софия стала возможной благодаря новому поколению инструментов на базе
ИИ. Опытным разработчикам, желающим освоить рабочий процесс в новом
стиле, будет полезно ознакомиться с основными платформами и моделями,
от которых зависит эффективность разработки с помощью ИИ.
В этом разделе вкратце описываются основные инструменты из арсенала по­
следователя вайб-кодинга. Среди них - Visual Studio Code (VSCode) с его рас­
тущей экосистемой ИИ-функций и расширений; IDE нового поколения с ин­
теграцией ИИ, такие как Cursor и Windsurf, а также большие языковые модели,
такие как Claude (в её различных версиях) и ChatGPТ. В этом разделе не затра­
гиваются фоновые агенты по написанию кода, но они подробно обсуждаются
в главе 10.
Вам вовсе не нужно запоминать наизусть какие-то конкретные названия ин­
струментов или функции, потому что индустрия развивается стремительными
темпами и на смену текущим могут прийти другие. Главное - это получить пред­
ставление о типах возможных решений.

VSCode + Copilot: интегрированная платформа для И И-разработки
от Microsoft
VSCode (https:/!code.visualstudio.com) превратился из самого популярного в мире
текстового редактора кода в полноценную платформу разработки с помощью
ИИ благодаря глубокой интеграции с GitHub Copilot. Такая трансформация от­
ражает поддерживаемую компанией Microsoft концепцию; согласно этой концепции ИИ-функции должны присутствовать в знакомой миллионам разработ­
чиков среде VSCode, которой они уже пользуются ежедневно.
GitHub Copilot - это ИИ-ассистент для написания кода, интегрированный
в VSCode. Он даёт подсказки, объясняет и автоматически генерирует фрагмен­
ты кода на основе запросов на естественном языке и контекста существующе­
го кода. Особенность этой интеграции - органичное включение ИИ-функций
в рабочее окружение; Copilot - это не просто дополнение, а естественное рас­
ширение самого редактора.
В своей основе ИИ-функции VSCode поддерживают три главные модели
взаимодействия. Во-первых, это встроенное автодополнение кода, когда Copilot
предлагает подсказки прямо в процессе набора, начиная с дополнения отдельной

38 1 Часть 1. Основы

строки и заканчивая полными реализациями функций. По мере набора кода
всплывают предложения в виде «призрачного текста», которые можно принять
целиком по клавише ТаЬ или частично по словам.
Во-вторых, это чат-интерфейс, доступный через боковую панель, где можно
обсуждать с ИИ-помощником код, задавать ему вопросы или просить сгенери­
ровать конкретные реализации. В-третьих - что, вероятно, можно назвать са­
мой мощной моделью взаимодействия - это режим агента, вызывающего раз­
личные инструменты для доступа к растущему набору возможностей внутри
Visual Studio. После того как задана цель, агент пошагово выбирает различные
инструменты и пользуется ими. Он может анализировать кодовую базу, предла­
гать правки нескольких файлов подряд, выполнять команды в терминале, реагировать на ошибки сборки и циклически самостоятельно исправлять себя, пока
задача не будет выполнена.
Чем особенно хороша реализации Copilot в VSCode, так это её поддержкой
протокола МСР (Model Context Protocol, «протокол контекста модели»). МСР это стандарт, благодаря которому ИИ-модели находят внешние инструменты,
приложения и источники данных для последующего взаимодействия с ними.
Поддержка этого протокола означает, что Copilot в VSCode может подключать­
ся к базам данным, вызывать API, получать доступ к документации и интегри­
роваться в экосистему разработки. Например, при включённом МСР-сервере
GitHub можно сказать: «Создай отчёт для каждого из багов, которые мы об­
суждали», и Copilot напрямую обратится к API GitHub, чтобы создать эти за­
дачи. Благодаря такой расширяемости и поддержке МСР Copilot становится уже
не просто генератором кода, а превращается в полнор;енного ассистента разра­
ботчика, понимающего не только код, но и весь рабочий процесс.
Чтобы извлечь всю пользу от Copilot в VSCode в профессиональной разра­
ботке, стоит для начала изучить разные режимы взаимодействия в зависимости
от сложности задачи. Для простого автодополнения и рефакторинга достаточно
всплывающих предложений и мерцающего значка ошибок - по щелчку по нему
ИИ автоматически исправляет ошибки.
Для более сложных задач можно переключиться в режим агента, открыв па­
нель чата и выбрав в выпадающем списке пункт Agent. Режим агента оптимизи­
рован для автономных правок сразу в нескольких файлах проекта. Особенно он
полезен для задач, требующих не только внесений изменений в код, но и вызова
инструментов или выполнения команд в терминале. Сочетание привычного интерфейса VSCode и растущих возможностей Copilot делает их связку привлека­
тельным вариантом для команд, которые хотят получать ИИ-помощь корпора­
тивного уровня и не менять при этом устоявшуюся среду разработки.

Глава 1. Введение: что такое вайб-кодинг?

39

VSCode + Cline: открытый автономный агент для
программирования с открытым исходным кодом
Прежде чем рассматривать специализированные IDE с ИИ, стоит обратить
внимание на Cline (https:!!cline.bot) (ранее Claude Dev), превращающий VSCode
в мощную среду разработки с поддержкой ИИ. В отличие от Copilot (инстру­
мента, разработанного Microsoft), Cline строится на несколько иной филосо­
фии - это скорее не интегрированный ассистент, а автономный агент, умею­
щий выполнять сложные, многоэтапные задачи разработки от начала до конца.
Это расширение с открытым исходным кодом добавляет в VSCode возможно­
сти, зачастую превосходящие те, что имеются в проприетарных ИИ-редакторах,
и при этом сохраняет привычные для пользователей VSCode гибкость с расширяемостью.
Что действительно отличает Cline от других инструментов, так это по-на­
стоящему «агентский» подход к разработке ПО. Когда ему дают высокоуров­
невую команду, например: «Создай REST API для управления пользователями
с аутентификаций», он не ограничивается генерацией шаблонного кода, а ана­
лизирует структуру проекта, планирует реализацию в разных файлах, создаёт
корректную иерархию папок, устанавливает необходимые зависимости и даже
запускает тесты для проверки реализации. На протяжении всего процесса Cline
поддерживает прозрачность своего поведения, показывая разработчику каждое
запланированное действие - создание и изменение файлов, ввод команд в тер­
минале - и позволяя тому одобрить или изменить каждый шаг. Такой подход
с участием человека в цикле обеспечивает оптимальный баланс между автома­
тизацией и контролем; в результате разработчики пользуются всеми возможно­
стями ИИ, не опасаясь нарушить целостность своей кодовой базы.
Технические возможности Cline выходят далеко за рамки простой генерации
кода. Он может пользоваться автоматизацией браузера для изучения докумен­
тации API, заниматься отладкой кода с отслеживанием цепочек сложных оши­
бок, а также взаимодействовать с внешними сервисами при помощи МСР. При
отладке можно скопировать и вставить сообщение об ошибке, и Cline проследит
по вашему коду источник проблемы, предложит исправление, реализует его и до­
бавит соответствующую обработку ошибок для предотвращения аналогичных
ситуаций в будущем. Интеграция с МСР позволяет Cline подключаться к базе
данных и получать представление о схеме перед генерацией запросов, работать
с инструментами управления проектами для согласования реализации с требо­
ваниями, а также взаимодействовать с любым другим совместимым с МСР сер­
висом. Такая расширяемость превращает Cline из генератора кода в полноцен­
ного партнёра по разработке, понимающего всю вашу техническую экосистему.
40 1 Часть 1. Основы

Командам Cline предлагает несколько весомых преимуществ. Так как это
проект с открытым исходным кодом, разработчики одной команды могут про­
сматривать его код, вносить улучшения или создавать ветки под свои нужды, что
особенно важно для организаций с особыми требованиями в области безопас­
ности или корпоративных стандартов. Он поддерживает нескольких поставщи­
ков ИИ-моделей, включая Claude от Anthropic, модели OpenAI, Google Gemini
и даже локальные модели с помощью платформы Ollama, так что его можно гиб­
ко настраивать с учётом производительности, стоимости или требований к раз­
мещению данных.
Для повышения эффективности Cline лучше формировать подробные запро­
сы с учётом контекста проекта и его ограничений, перед внесением изменений
пользоваться возможностями анализа всей кодовой базы и задействовать итера­
ционный подход к разработке. После реализации какого-то функционала Cline
может сразу же протестировать его, а разработчики могут попросить внести до­
полнения, и всё это в рамках одного и того же контекста диалога. Благодаря со­
четанию устоявшейся экосистемы VSCode и автономных возможностей Cline
команды получают мощное, гибкое и экономически выгодное средство разра­
ботки с помощью ИИ с сохранением всех своих привычных инструментов и ра­
бочих процессов.

Cursor: редактор кода на основе ИИ
Один из ведущих инструментов вайб-кодинга - это IDE Cursor на основе ИИ, по­
лучивший популярность среди разработчиков, предп<?читающих более плавный
и непрерывный процесс работы над кодом. По сути, это ориентированный на ИИ
редактор кода (фактический форк VS Code), в котором инструменты генерации
и анализа кода на базе современных моделей встроены прямо в рабочую среду.
Этот редактор с официальным определением The AI Code Editor ( «ИИ редактор кода») разработан специально для того, чтобы можно было писать
и править код с помощью инструкций на естественном языке. Например, мож­
но выделить какую-нибудь функцию и попросить Cursor «оптимизировать эту
функцию» или «добавить в этом месте обработчик», и он мгновенно предложит
свой вариант. Cursor учитывает контекст проекта; он индексирует кодовую базу
и понимает структуру файлов, поэтому его предложения гораздо релевантнее
обычного автодополнения.
Возможности LLM в IDE Cursor интегрированы непосредственно в интер­
фейс редактора. Это своего рода ChatGPT, но со знанием вашей кодовой базы.
С технической стороны Cursor задействует продвинутые языковые мо­
дели ( чаще всего Claude от Anthropic или модели OpenAI, в зависимости
Глава 1. Введение: что такое вайб-кодинг? 1 41

от конфигурации). В редакторе предусмотрена боковая панель чата, в которой
можно обсуждать код, а также режим Composer для многоэтапной генерации
кода. В своих экспериментах с вайб-кодингом наряду с моделью Sonnet режим
Composer использовал сам Андрей Карпатый (https://oreil.ly/aFqAO). Такая на­
стройка позволяла ему буквально «разговаривать» с редактором (посредством
голосового ввода с помощью SuperWhisper), получая код, который затем можно
было применить или отправить на доработку.
Cursor может не только генерировать код, но и по инструкции редактировать
существующий. Например, можно задать следующий запрос:
Ты можешь упростить переключение сертификатов в транспортном слу­
шателе?
Cursor поймёт, что речь идёт о текущем коде, и предложит правки для со­
ответствующего файла или прочитает данные из связанных файлов, например
из markdown-фaйлa со спецификациями (см. иллюстрацию 1.3). В бесплатной
версии правки чаще всего показываются в чате в виде diff для одобрения; в про­
фессиональной версии изменения могут применяться к рабочей области авто­
матически.

___
--,_
��
1:,_
.,.._
о­
_·-­
..··­
.. _
,

-

+ о ф •.
!lrC)pav4!s' !'1- �Dtlt.WJ.jsx >.1
i-,ort iw,ct, ( UUSt•te, u$el!H11e1, 11t.eC8\\INlck} ft'OII 'r.act';

)

!•�

7
а

�rt
111,
...:�J.ce": 11 Мd 1't1"°""1eC"°"tts
laport { to,e1ehvor1te:) frOII • •• /1erv1ce:s/80\'leS<trv1ce';
соnн 18fd8иUr\• 'llttps://iNQe.�.DIJJl1/p/w78t': // Lн�r � tor aet•ili" �,.
con,1,t.ctflcl\llerlМ9t• '/p\1�tiнr.pt19';
//St.p\e,·O'Oj>C>Мnttctllf1111\•y9•n•·•s
con1tGtonretadoe•((��н ... ,
cspan .,ty1t--H ьо,..,, ·1� sotic! "-t:C', llo.-Wr118dilts: 'Нрх', 1)8dd1r,g: '1,2n e.n•,
..,91мt1gм: ••·""'• f(lnt$1Je, ••·••• •НЧ'\..,., '1.nlt�-Ыot�·. ur,tnlottOII: ••.s.t••)}

Addu.dittl<lnNtiontalhis-�

--·

r1!8'1pyouldcfc,atWonnltiontottwmcмedМ8ill�
fi1'81.,181"'8dledllhl�m!М8�\IOмe ...
J,/1!-spoil'IIS_...,....WJdllllrllddttмcмt

НO,,,!'tllctcl1h.lllc1fofltor.&ehcиtilllfomlltlon8'1Cf\lPOlle
tlle��1o�il.1'1Ndlh8t811
APt___,.tottмfnCl'IIIIIММll:81nt:

о.-

0�.jlon
Ф-._,
••.conflg.)I

16

""
""
",.

fllll(tl0/1 МOvieDetlHsl{ sesstcm, кcount Н {
const!-1e, se�ieJ•useSt1te-!nvH!:
const l!sfa"Orit•, 1etI1f1worlt11 " uиSt•t•(f•lu);
(Otltt lt1t8<11N;i, tttLClldUtgl •11seSt•tt!t�J;
tonst l,rrror, 1.-frror! •ult5tltt!milt);
ton1t { II0"11rtc1} • 111.,..г-о; 11 6-!t 11111vie 1D fr0111 !Мt
Cll'ttt"8\litete• u1.....,1g1t•!I;
const fttd'Oet1HIAl!Clrrt0r1tt'St•tus • 11иС1\\Ьк11{1s�"' 11 - {
if \'IIO"teJcl) return;
••tLNdi"9(trtotl;
иtfrr11r(n,;lH;

,,,,

Now-l'tl�lhl�COftlPOМf'ltioi.tdlltld
0.-etit>;.

S�-'i' V'I<')

(-t6et11U•..,_11t9flll\W1110etl1\1(0IOYi•lll};
ИtROvll\118111\1)1

11

cl: 1/1 �

·�1'м"�"

1f\м1sliil&I�){

r:::zllllj(:·;;;�'7J

Иллюстрация 1.3. Интерфейс Cursor, IDE нового поколения
с интегрированным ИИ. С помощью такого инструмента можно
буквально «оставить окно редактора открытым, сходить
за кофе и, вернувшись, увидеть полностью готовый функционал».
Продуктивность при этом возрастает экспоненциально
42

Часть 1. Основы

111111111

В профессиональном рабочем процессе лучше всего проявляет себя систем­
ный подход к возможностям Cursor. Для начала откройте в Cursor чат и опишите
нужную вам функцию или исправление, например: «Добавь форму входа пользо­
вателей с вводом email и пароля, с проверкой данных и сообщениями об ошиб­
ках)). Cursor сгенерирует черновой вариант соответствующего кода (в виде новых
файлов или изменённых существующих) в черновом виде. Эти изменения мож­
но просмотреть (появляется diff или предварительный просмотр) и по нажатию
кнопки «Применить)) объединить их с вашей кодовой базой. Многие разработ­
чики используют цикл вида «запрос➔ проверка➔ применить)). Если предложен­
ное решение неидеально, можно уточнить запрос (например: «Для стилизации
формы используй Tailwind CSS))) или просто попросить Cursor исправить най­
денные ошибки («Обработай теперь случай, когда email уже зарегистрирован))).
По сути, это диалог пользователя с редактором, продолжающийся до тех пор,
пока результат не станет удовлетворительным.
Cursor также отлично справляется с анализом ошибок и логов. Сообщения
об ошибках или трассировке можно вставить в чат, чтобы ИИ выявил пробле­
му и предложил решение. В результате отладка превращается в совместный про­
цесс: вместо того чтобы вручную искать решение на Google или Stack Overflow,
разработчик обращается к ИИ Cursor, который во многих случаях точно ука­
зывает на проблему и даже пишет патч. При этом, естественно, следует прояв­
лять предусмотрительность и проверять предложенные исправления, так как
ИИ не всегда срабатывает идеально с первого раза.
Вот вам ещё один совет: пользуйтесь умением Cursor одновременно учи­
тывать контекст нескольких файлов. Можно выбрать. нужные вам файлы или
указать в запросе проект, и при генерации кода ИИ учтёт всю кодовую базу. За­
прос может звучать так: «Добавь конечную точку API в бэкенде для поддержки
формы входа и свяжи его с только что созданной фронтенд-формой)). Cursor
запомнит написанный фронтенд-код и поможет сформировать соответствую­
щую логику бэкенда. Учёт контекста всего проекта даёт принципиальное пре­
имущество над прежними ассистентами, которые работали лишь с отдельны­
ми файлами.
Подводя итог, можно сказать, что Cursor - это своего рода ИИ-партнёр
и коллега, доступный круглосуточно в окне IDE. Общение с ним интуитивно
понятно (так как с ним общаются на естественном языке), и он может исправ­
лять ваш код непосредственно. Чем чаще вы разбиваете задачу на куски и даё­
те помощнику чётко сформулированные запросы, тем больше вы успеваете сде­
лать за короткий промежуток времени. Особенно удобен Cursor в итеративной
разработке: вы пишете часть кода, запускаете и смотрите на результат, просите
Cursor подкорректировать или дополнить код, после чего повторяете процесс.
Глава 1. Введение: что такое вайб-кодинг?

1

43

Windsurf: IDE с поддержкой ИИ и с полной индексацией
КОДОВОЙ базы
Ещё один перспективный инструмент в арсенале вайб-кодера - это среда разра­
ботки Windsurf с поддержкой ИИ, выводящая работу по написанию кода на но­
вый уровень. Это продукт компании Codeium (https://windsurfcom), который вы­
деляется тем, что индексирует всю кодовую базу проекта и использует методы
извлечения данных для предоставления ИИ релевантного кода по мере разра­
ботки. На практике это означает, что Windsurf отлично справляется с крупны­
ми проектами, в которых запрос может касаться множества файлов. В основе
его работы лежит подход под названием генерация, дополненная поиском (RAG,_
Retrieval-Augmented Generation); по сути, это означает, что редактор ищет нуж­
ные части кода, добавляет их в контекст ИИ, и ИИ предлагает решения, согла­
сованные с уже существующим кодом.
Как это выглядит для разработчика? Допустим, вы новичок в проекте и вам
нужно добавить функционал в крупную кодовую базу. Вы можете задать Windsurf
следующий вопрос на естественном языке:
Где в кодовой базе обрабатывается логика аутентификации пользователей?
Инструмент просканирует индекс и укажет нужный файл или даже функцию.
Затем можно открыть чат (в Windsurf он называется видом Cascade и вызывает­
ся сочетанием клавиш Cmd + L) и ввести:
Добавь в процесс входа двухфакторную аутентификацию по телефону.
Так как Windsurf учитывает контекст вашей логики аутентификации, он сге­
нерирует изменения, охватывающие сразу несколько файлов (база данных, API,
фронтенд); при этом он будет принимать обоснованные решения, согласован­
ные со структурой всей вашей системы.
В режиме Write редактор Windsurfсамостоятельно вносит многие правки вместо
вас и автоматически создаёт новые файлы или редактирует существующие, а не про­
сто показывает diff в боковой панели. Такое его поведение существенно экономит
время: вместо того чтобы копировать и вставлять фрагменты кода, вы просто на­
блюдаете за развитием проекта. Будучи уверенным в результате, Windsurf старает­
ся действовать от вашего имени и тем самым ведёт себя как автономный младший
разработчик, реализующий функции по всей кодовой базе. (По сравнению с этим
философия Cursor более консервативна, и Cursor запрашивает подтверждение, хотя
в профессиональной версии тоже есть функция «автоприменение».)
44

1

Часть 1. Основы

Чтобы эффективно использовать Windsurf, полезно понимать его сильные
стороны.
Вопросы и ответы по кодовой базе
Вопросы по кодовой базе можно задавать на обычном языке, и это почти как соб­
ственный Stack Overflow для проекта. Особенно это удобно для крупных легаси­
проектов, в которых поиск порой занимает целые часы. Windsurf же извлекает
данные из индексированного кода и находит ответы за считаные секунды.
Предложения с учётом глобального контекста
Так как редактор предоставляет ИИ-модели релевантные файлы, Windsurf
отлично справляется с задачами вроде «Сделай рефакторинг модуля пла­
тежей с использованием новой утилиты логирования», так как учитывает
и контекст модуля платежей, и контекст самой утилиты.
Режимы работы
Windsurf имеет несколько режимов (Autocomplete, Chat, Command и уже
упоминавшийся Cascade - «автодополнение», «чат», «команды» и «каскад»).
Cascade - это своего рода суперчат с учётом более широкого контекста. В ре­
жиме Write («записать» внутри чата) изменения применяются автоматически.
Вы, как ведущий программист, сами решаете, какую степень автономии пре­
доставить своему помощнику.
Что касается командной работы, то Windsurf инт�грируется в ежедневный
процесс разработки примерно так же, как Cursor. При выборе между ними не­
которые разработчики предпочитают Windsurf за скорость и автономию (они
отмечают, что, по ощущениям, он быстрее генерирует код и применяет изме­
нения) и за удобство работы с очень крупными проектами с помощью индек­
сации. С другой стороны, пользователям VSCode интерфейс Cursor может ка­
заться привычнее. Но не обязательно выбирать только лишь один инструмент,
и многие разработчики пользуются несколькими; в команде же один из них вы­
бирают в качестве стандарта.
В целом Windsurf - отличный инструмент, если вам нужен ИИ-помощник
в написании кода, который перед генерацией обязательно постарается «озна­
комиться с документацией и кодом». Благодаря проверке информации вероят­
ность галлюцинаций в функциях или неправильно именованных переменных
снижается. Для максимальной эффективности давайте ему чёткие инструкции
и используйте для крупных задач режим Write; вместе с тем небольшие, но важ­
ные правки можно выполнять в более контролируемом режиме. Не следует
Глава 1. Введение: что такое вайб-кодинг?

45

забывать, что все внесённые изменения (инструмент их покажет), особенно ка­
сающиеся критически важного кода, обязательно следует проверять, ведь, не­
смотря на всю свою сообразительность, Windsurf далеко не безошибочен. При
разумном использовании он похож на сверхинтеллектуальную IDE, которая зна­
ет весь ваш проект и реализует идеи по всей кодовой базе, тем самым значитель­
но увеличивая вашу продуктивность.

Модели ИИ: современный ландшафт генерации кода
В последнее время ситуация в сфере ИИ-разработки резко изменилась с появле­
нием множества мощных ИИ-моделей, конкурирующих за внимание разработ­
чиков, и среди них в первую очередь стоит упомянуть модели семейств Claude,
Gemini и OpenAI. Если раньше на рынке мог доминировать какой-то один круп­
ный игрок, то сегодня экосистема предлагает широкий выбор вариантов, каж­
дый со своими сильными сторонами и сценариями использования.

Категории моделей
Современные модели для работы с кодом обычно делятся на несколько катего­
рий по своему подходу и по своим сильным сторонам.
С оптимизированной скоростью
Эти модели делают ставку на быстрые ответы и подходят для автодополне­
ния в реальном времени с быстрыми итерациями. Они, как правило, обеспе­
чивают низкую задержку при генерации ценой чуть меньшей точности для
сложных задач.
С глубоким рассуждением
Эти модели тратят больше времени на «продумывание» задачи и потому от­
лично подходят для сложной отладки, архитектурных решений и многоша­
гового анализа. Модели с продвинутыми возможностями рассуждения могут
разбивать сложные задачи по исправлению ошибок на части.
Мультимодальные тяжеловесы
Некоторые модели умеют работать не только с кодом и текстом, но и с изо­
бражениями, схемами и даже видео. Особенно это полезно для обработки визуальной документации или задач, связанных с пользовательским интерфей­
сом или пользовательским опытом.
46

Часть 1. Основы

Открытые альтернативы
Модель DeepSeek выделяется тем, что предлагает уровень возможностей ИИ,
сопоставимый с закрытыми моделями, но не требует оплаты или регистра­
ции. При этом ей может недоставать некоторых возможностей, например ге­
нерации изображений или веб-поиска 1 •

Выбор подходящей для задачи модели
Опытные разработчики теперь не ищут какую-то одну «лучшую» модель, а под­
бирают их для конкретных задач.
- Для быстрого прототипирования и общей работы с кодом хорошо под­
ходят модели с оптимизированной скоростью и с поддержкой многих
языков.
- Для сложной отладки и проектирования сложных систем стоит выбирать
модели с глубоким рассуждением, методически прорабатывающие логику.
- Для работы с крупными кодовыми базами стоит выбирать модели с об­
ширными контекстными окнами, которые могут держать в фокусе весь
проект.
- Для команд с ограниченным бюджетом отличное соотношение цены
и возможностей предлагают открытые модели, не требующие платной
подписки.
Сегодня многие инструменты поддерживают сразу несколько моделей ИИ,
включая варианты OpenAI, Claude, Gemini, а также ёобственные модели. Раз­
работчики могут переключаться между ними в зависимости от текущей задачи.

Практические советы для работы с любой моделью
Есть ряд практических приёмов, стабильно улучшающих результаты независимо
от выбранной модели. Во-первых, предоставляйте большой контекст. Не огра­
ничивайтесь просьбой написать «функцию для обработки платежей». Лучше
указать модели данных, существующие шаблоны кода, способы обработки оши­
бок и любые специфические требования. Чем больше предоставлено контекста,
тем точнее результат впишется в вашу кодовую базу.
Большинство современных моделей хорошо справляются с ревью сгенери­
рованного ими же кода. Получив код, можно попросить модель проверить его
на потенциальные проблемы, предложить улучшения или объяснить, как она
1

В последнее время в DeepSeek появилась возможность веб-поиска. - Прим. перев.

Глава 1. Введение: что такое вайб-кодинг? 1 47

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

Основные модели
Ландшафт ИИ-кодирования меняется ежемесячно, и новые модели регулярно
бросают вызов устоявшимся лидерам. В результате интенсивной конкуренции
разработчики получают выгоду в виде беспрецедентного выбора возможностей.
Главное - не стараться найти «идеальную» модель, а понять, как пользоваться
сильными сторонами любого доступного инструмента.
В настоящее время многие команды используют комбинированную схему:
для рутинных задач привлекают быстрые модели, для сложных задач - мощные,
а для конкретных областей, таких как оптимизация баз данных или фронтенд­
разработка, задействуют специализированные модели. Некоторые IDE даже по­
зволяют гладко переключаться между моделями посреди выполнения одной
и той же задачи.
Для ускорения рабочего процесса важно иметь представление об имеющих­
ся возможностях и применять их стратегически.

Google Gemini: мулыимодальный тяжеловес
Семейство моделей Google Gemini (https://gemini.google.com) благодаря изначаль­
но встроенной в них мультимодальности представляет собой фундаментальный
сдвиг в развитии инструментов разработки с помощью ИИ. В отличие от мо­
делей, которые изначально обучались в основном на тексте и примерах кода,
Gemini проектировали так, чтобы она одинаково эффективно понимала и обра­
батывала текст, программный код, изображения, видео и другие форматы данных. Как следствие, это исключительно мощный инструмент для современных
рабочих процессов, в которых визуальный контекст не менее важен, чем тек­
стовая информация.
48

1

Часть 1. Основы

Мультимодальные возможности Gemini особенно полезны в веб-разработке.
Можно показать нейросети скриншот макета, и она сгенерирует его с точностью
до отдельных пикселей и с сохранением визуального стиля. Модель отлично по­
нимает графики, диаграммы и элементы интерфейса, что делает её идеальным
помощником при переводе визуального дизайна в рабочий код. Её способности
выходят далеко за рамки простого распознавания изображений: Gemini умеет
рассуждать о визуальных элементах, выявлять шаблоны в дизайне и поддерживать эстетическую целостность всего проекта.
Широкие возможности для разработчиков предоставляет интеграция Gemini
в популярные редакторы (VSCode, Cursor, Windsurf) и плагины, такие как Cline
и Code Assist. Пользоваться преимуществами такой интеграции могут как от­
дельные специалисты, так и целые команды. Можно создавать пользовательские
группы для повторяющихся задач, устанавливать общие правила для генерации
любых фрагментов кода и поддерживать единые стандарты больших кодовых
баз. Щедрый бесплатный тариф делает модель доступной для студентов, люби­
телей и стартапов, а корпоративные функции поддерживают сложные органи­
зационные требования.
Что действительно выделяет Gemini на фоне других инструментов кодиро­
вания, так это её способность глубокого анализа задач с сохранением практиче­
ской скорости работы. Модель может чередовать быстрые ответы для простых
задач и ответы с более продуманным рассуждением для сложных, адаптируясь
под каждую конкретную задачу. Такая её гибкость в сочетании с возможностя­
ми обработки визуальных данных делает эту модель особенно полезной для пол­
ноценной стековой разработки, для которой одинако�о важны и логика бэкен­
да, и эстетика фронтенда.

Claude: рассуждающий виртуоз
Основные особенности семейства моделей Claude от компании Anthropic
(https://anthropic.com!claude), важные для работы с кодом, - это прозрачность
и способность к глубоким рассуждениям. Модели семейства Claude, особенно
Sonnet, зарекомендовали себя как исключительно эффективный инструмент для
выполнения сложных задач программирования, требующих тщательного анализа и пошагового решения проблем. Отличительные черты Claude - это способ­
ность демонстрировать процесс своего мышления, благодаря чему разработчики
могут следить за рассуждениями и проверять логику перед внедрением решений.
Функция Artifact меняет всю парадигму разработки ПО и написания кода с по­
мощью ИИ. Вместо того чтобы просто показывать код в чате, Claude создаёт от­
дельное рабочее пространство, где код можно в реальном времени просматривать,
Глава 1. Введение: что такое вайб-кодинг?

49

редактировать и выполнять предварительное ревью. Эта интерактивная сре­
да особенно полезна для фронтенд-разработки, визуализации данных и любых
других сценариев, в которых мгновенная визуальная обратная связь ускоряет
рабочий процесс. Разработчики могут итеративно разрабатывать дизайн, те­
стировать функционал и уточнять реализации прямо в рамках одного диалога.
Claude показывает выдающиеся результаты в реальных тестах на разработку
ПО, стабильно занимая лидирующие позиции в таких задачах, как исправление
ошибок, реализация функций и рефакторинг кода. Её сила заключается не толь­
ко в генерации кода, но и в том, что она охватывает более широкий контекст
программных проектов. Claude может анализировать существующие кодовые
базы, выявлять шаблоны и антипаттерны, предлагать архитектурные улуч ше­
ния и поддерживать установленный стиль кодирования. Благодаря этому ней­
росеть незаменима как для новых проектов, так и для поддержки легаси-систем.
Возможности по управлению памятью и контекстом позволяют модели на­
капливать знания в ходе продолжительных сессий программирования. При ра­
боте над крупными проектами Claude извлекает и сохраняет ключевую инфор­
мацию о структуре кодовой базы, архитектурных решениях и специфических
шаблонах проекта. Благодаря накопленному опыту она предоставляет всё более
релевантные и относящиеся к контексту рекомендации, в результате чего со­
здаётся ощущение, что перед вами не какой-то статичный ассистент без памя­
ти, а настоящий член команды, постепенно знакомящийся с проектом и осваи­
вающийся в нём.

ChatGPT: разносторонний компаньон по кодированию
ChatGPT (https://oreil.ly!hZdNC) зарекомендовал себя среди ИИ-помощников как
своего рода «швейцарский нож», ценимый не за специализированные функции,
а за выдающуюся универсальность и обширную базу знаний. Он занимает в ар­
сенале разработчика поистине уникальное место. Если другие модели интегри­
руются прямо в IDE или специализированные среды разработки, ChatGPT все­
гда остаётся доступным консультантом по программированию, и разработчики
держат его окно открытым в браузере на протяжении всего рабочего дня.
Диалоговый интерфейс ChatGPT делает его особенно полезным для иссле­
дования различных способов решения той или иной задачи или для обучения.
Разработчики регулярно используют его для отладки по методу «резинового
утёнка»: вставляют в окно чата проблемный код и в ходе диалога обдумыва­
ют решение проблемы. Широкое обучение позволяет модели распознавать ша­
блоны практически во всех языках программирования, фреймворках и распро­
странённых инструментах. Благодаря своей обширной базе знаний ChatGPT
50 1 Часть 1. Основы

предоставляет релевантные ответы, идёт ли речь об отладке регулярного выражения, о редкой ошибке или о документации незнакомой программисту биб­
лиотеки.
Сила ChatGPT заключается в преодолении разрыва между намерением че­
ловека и реализацией кода. Он отлично справляется с двунаправленным перево­
дом - преобразует описания на естественном языке в рабочий код и объясняет
сложный код простым и понятным языком.
Умение анализировать и генерировать текст на естественном языке делает
ChatGPT незаменимым для работы с документацией, для код-ревью и для пе­
редачи знаний внутри коллектива. Разработчики могут вставлять в чат незна­
комые фрагменты кода и получ ать в ответ объяснение принципа их работы;
либо же они могут описать нужное им поведение и получить реализацию в виде
кода согласно разным парадигмам программирования.
Универсальность модели распространяется за пределы традиционных язы­
ков программирования и охватывает файлы конфигурации, скрипты, форматы
данных и предметно-ориентированные языки. Если специализированные ин­
струменты хорошо справляются в своей узкой области, то ChatGPT может пред­
лагать помочь по всему спектру задач разработки ПО. Такая широта применения
делает эту модель особенно полезной при работе на стыке разных технологий
или при решении задач, охватывающих несколько областей. Умение поддержи­
вать контекст на протяжении длительных бесед позволяет разработчикам иссле­
довать сложные проблемы и уточнять решение с помощью диалога.

Выбор модели в зависимости от задачи
Появление доступных мощных ИИ-помощников в сфере написания кода озна­
меновало собой принципиальный сдвиг в практике разработки ПО. Успешные
разработчики не рассматривают их как конкурирующие варианты, а понимают,
что каждое семейство моделей обладает своими уникальными сильными сторо­
нами, полезными для разных аспектов процесса разработки. Google Gemini пре­
восходна там, где важен визуальный контекст и мультимодальное понимание,
особенно в области пользовательского интерфейса и пользовательского опыта,
а также для работы со спецификациями дизайна. Claude от компании Anthropic
хорошо показывает себя в задачах, требующих глубокого рассуждения, сложно­
го рефакторинга и прозрачного подхода к решению проблем. Семейство моде­
лей OpenAI обеспечивает непревзойдённую универсальность и обширную базу
знаний, что делает их идеальными для обучения, отладки и решения задач, охва­
тывающих несколько областей.
Глава 1. Введение: что такое вайб-кодинг? 1 51

Многие команды разработки сейчас используют портфельный подход, при­
меняя разные модели для разных задач в рамках одного проекта. В типичном
рабочем процессе можно задействовать Gemini для создания реализации ма­
кета дизайна, Claude - для сложных архитектурных решений и код-ревью,
а ChatGPT - для общего решения проблем и работы с документацией. Такой
мультимодельный подход максимально повышает продуктивность и позволяет
воспользоваться сильными сторонами каждого конкретного инструмента в за­
висимости от типа задачи.
По мере эволюции этих моделей эффективная разработка с помощью ИИ всё
чаще будет подразумевать не выбор одной «лучшей» модели, а координацию не­
скольких ИИ-ассистентов, ускоряющих и улучшающих все этапы жизненного
цикла разработки ПО.
Это молодая, быстро меняющаяся экосистема. Каждые несколько месяцев
на сцене появляются новые игроки и новые возможности. Главный вывод за­
ключается в том, что для повышения качества программирования не обязатель­
но создавать собственный ИИ с нуля, поскольку для этого уже существует мно­
жество инструментов. В этой книге я буду рассматривать различные платформы
и показывать, как они вписываются в рабочий процесс вайб-кодинга.

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

Идеальные сценарии вайб-кодинга
Точно так же, как определённые архитектуры подходят для тех или иных конкретных задач, у вайб-кодинга в сфере разработки ПО имеются свои «зоны эф­
фективности».
Разработка продукта с нуля
Вайб-кодинг меняет правила игры для запуска совершенно нового проекта. По­
пуляризированная Питером Тилем концепция «от нуля к единице» (zero to опе)
означает создание чего-то нового с нуля. С помощью ИИ можно почти мгновен но перейти от пустого холста к рабочему прототипу. Вам нужно сделать ранее
52

Часть 1. Основы

не существовавшее веб-приложение? За одну интенсивную сессию генерации
с помощью запросов можно получить шаблонный код для фронтенда, бэкенда,
схемы базы данных и даже скриптов развёртывания. Этот сценарий идеально
подходит для стартапов или хакатонов, где цель - быстро проверить идею. Вме­
сто того чтобы тратить на настройку «каркаса» проекта (всего повторяющегося
кода) недели, можно поручить её ИИ, который справится за минуты.
Многие разработчики рассказывали, как с помощью ИИ-партнёра создавали
минимально жизнеспособный продукт (MVP, Minimum ViaЬle Product) за выход­
ные, что ранее заняло бы месяц работы в одиночку. Быстрое воплощение идеи
в рабочем продукте позволяет гораздо раньше начать тестирование с пользова­
телями или заинтересованными сторонами. ИИ хорошо справляется с рутинными задачами (настройка маршрутизации, базовые компоненты пользователь­
ского интерфейса, стандартные СRUD-операции), освобождая разработчика,
который посвящает больше времени уникальным аспектам продукта.
Но когда MVP развивается и дело движется к релизу (продакшену), сценарий
работы следует изменить. На более поздних стадиях важнее становится разра­
ботка с помощью ИИ. Вайб-кодинr помогает быстро проверить идею, но мас­
штабирование требует более обдуманного подхода. На этих стадиях понадо­
бится рефакторинr сгенерированного кода с корректной обработкой ошибок,
полноценное покрытие тестами и установка чётких архитектурных границ. Пе­
реход от прототипа к продукту - естественный этап эволюции от исследова­
тельской свободы вайб-кодинrа к структурной дисциплине «инженерии». Опыт­
ные команды понимают, когда наступает переломный момент, корректируют
свою работу с ИИ, сохраняя скорость разработки и <:1дновременно вводя необ­
ходимые для устойчивого развития ограничения и правила.
Прототипирование функций и СRUD-приложений
Значительная часть разработки ПО, особенно в бизнес-приложениях, так или
иначе связана с CRUD - созданием, чтением, обновлением и удалением данных.
Создание такого функционала - шаблонная работа, в которой ИИ исключитель­
но хорош, поскольку он обуч ался на бесчисленном количестве примеров. Если
вам, допустим, нужно добавить в свою систему новый модуль «Склад» с СRUD­
экранами под ваше API, для этого прекрасно подойдёт вайб-кодинr. Так можно
генерировать миграцию баз данных, ОRМ-модели, конечные точки API- и UI­
формы (формы пользовательского интерфейса) с валидацией - по сути, весь
стек - практически без ошибок, потому что эти паттерны очень часто встреча­
ются в обучающих данных. Даже если для вашего приложения установлены ка­
кие-то специфические правила, их можно указать в запросе и получить хороший
черновой вариант. В результате скучная задача, которая ранее занимала неделю,
Глава 1. Введение: что такое вайб-кодинг? 1 53

превращается в полдня печати запросов и тестирования. Почти полностью мож­
но положиться на ИИ и в разработке внутренних инструментов или админист­
ративных панелей (которые, по сути, представляют собой большие СRUD-при­
ложения), обычно простых, но отнимающих много времени.
Инженерный же подход становится критически важен, когда СRUD-опера­
ции подразумевают сложную бизнес-логику, правила валидации данных или
интеграцию с существующими системами. Вайб-кодинг позволяет быстро сге­
нерировать базовую структуру, но инженерная работа с помощью ИИ гаранти­
рует корректную обработку граничных случаев вроде конкурентных обновле­
ний, обеспечивает целостность связей и следует устоявшимся корпоративным
паттернам. Например, с помощью вайб-кодинга можно сгенерировать перво­
начальный каркас CRUD, а затем в инженерном режиме реализовывать специ­
фичные для предметной области правила, такие как уведомления о пороговых
значениях запасов, логика распределения между складами или интеграция с су­
ществующими системами аутентификации и авторизации. Главное в том, что­
бы понимать, когда переходить от быстрой реализации к тщательной доработке.

Связующий код и интеграция
Вам нужно интегрировать два сервиса или API? Обычно для этого приходится
изучать документацию и писать код для преобразования данных из одного фор­
мата в другой. Модели ИИ часто обучаются на АРI-документации и на приме­
рах кода, а это значит, что они могут ускорить работу по интеграции. Попросите
ChatGPT показать, как вызвать API Сервиса А из Языка В, и он с очень большой
вероятностью сгенерирует код с правильными конечными точками и, возмож­
но, даже с примером аутентификации. Объединять несколько систем (например,
подключать платёжный шлюз к системе заказов или интегрировать сторонний
SDK аналитики) становится проще, когда ИИ предлагает шаблонный код и ва­
рианты обработки граничных случаев. Особенно это верно для паттернов ин­
теграции.

Использование современных фреймворков
ИИ-ассистенты по коду фактически «прочитали» документацию ко всем по­
пулярным фреймворкам: React, Angular, Django, Rails, Node/Express, Flutter и дру­
гим. Это значит, что при работе с известными фреймворками ИИ сгенерирует
идиоматический код. Например, он вполне способен создать новый Rеасt-ком­
понент с хуками и управлением состоянием или новую Djаngо-модель с правиль­
ным admin-клaccoм и сериализатором.
Преимущество вайб-кодинга в том, что вам не нужно запоминать каждую ме­
лочь - все пробелы заполнит ИИ. Особенно хорошо вайб-кодинг показывает
54

1

Часть 1. Основы

себя в таких современных задачах веб-разработки, как генерация HTML/JSX
с правильными классами или подключение конечных точек контроллеров, по­
тому что ИИ-модели видели подобные задачи бесчисленное множество раз. Это
всё равно что иметь под рукой эксперта по фреймворку, который пишет шаблонный код, пока вы занимаетесь специфическим функционалом.
Генерация повторяющегося кода
Иногда приходится создавать большое количество однотипного кода (например,
множество похожих конечных точек или классов для каждого типа в какой-ли­
бо схеме). Для человека это утомительно и чревато ошибками. ИИ же, напротив,
прекрасно работает с повторяющимися структурами: достаточно показать ему
один-два примера, чтобы он всё остальное написал в таком же стиле. Массовая
генерация кода экономит уйму времени. Например, если нужно написать классы
моделей данных для 50 типов записей, то достаточно будет показать ИИ образец
и попросить его сгенерировать по этому шаблону классы для всех 50 типов. Он,
скорее всего, сделает это безупречно за считаные секунды. В итоге удаётся избе­
жать целого дня монотонной работы.
Когда отдавать приоритет разработке с помощью ИИ
В определённых сценариях вайб-кодинг показывает себя отлично, но в других
становится незаменимой разработка с помощью ИИ ( «инженерный подход»).
Зная, в каких именно ситуациях лучше предпочесть тот или иной метод работы,
разработчики смогут с самого начала выбрать нужный подход и тем самым из­
бежать дорогих переделок или накопления технического долга.
Разработка с помощью ИИ, например, лучше подходит для реализации слож­
ных алгоритмов. Когда речь заходит о сложных структурах данных, реализации
чувствительных к производительности алгоритмов или решении новых вычис­
лительных задач, то большую роль начинает играть точный контроль над каж­
дым аспектом реализации.
В таких ситуациях ИИ выступает не в роли генератора кода, а, скорее, в роли
осведомлённого помощника. Его можно попросить объяснить алгоритм или
проверить корректность реализации, но в любом случае программист сохраняет прямой контроль над архитектурой и над решениями по оптимизации. ИИ
помогает обдумывать проблемы, а не решать их целиком.
Критически важные системы требуют строгого подхода с самого начала. Финансовые транзакции, медицинские приложения, инфраструктура безопасно­
сти и другие сферы, в которых очень высока ответственность, не могут позво­
лить себе экспериментальный характер вайб-кодинга. В этих контекстах каждая
строка кода не только требует тщательной проверки и тестирования, но и часто
Глава 1. Введение: что такое вайб-кодинг?

55

должна соответствовать определённым нормативным требованиям. ИИ помо­
гает программистам тем, что предлагает полезные практические варианты, вы­
являет потенциальные уязвимости и позволяет соблюдать стандарты, но жёст­
кий контроль над реализацией сохраняется за разработчиком.
Цена ошибки в таких системах намного перевешивает любые преимущества,
которые даёт быстрая генерация. Особую сложность представляет собой инте­
грация с легаси-системами, для которых крайне важна инженерная дисциплина.
При работе с кодовыми базами многолетней давности, проприетарными прото­
колами или системами с большим техническим долгом, применяя шаблонный
подход вайб-кодинга, с большой вероятностью можно допустить ошибку. Эти
сценарии требуют глубокого понимания существующих ограничений, тщатель­
ного планирования точек интеграции и методичного рефакторинга. ИИ может
помочь, объясняя паттерны легаси-кода или предлагая стратегии модерниза­
ции, но сама реализация требует такой точности, которую обеспечивает только
структурный инженерный подход.
Ещё одна область, в которой инженерный подход показывает себя лучше
вайб-кодинга, - это оптимизация производительности. Да, ИИ способен бы­
стро сгенерировать работающий код, но он редко выдаёт оптимальные решения
для фрагментов, критически важных с точки зрения производительности. Та­
кие задачи, как управление памятью, оптимизация работы с кешем, параллель­
ная обработка и снижение задержек требуют глубокого понимания аппаратуры,
операционных систем и алгоритмической сложности. Здесь ИИ лучше исполняет роль помощника в исследованиях, то есть помогает изучить техники оптимизации или сравнить разные подходы, но решение о том, какой подход приме­
нить, уже осознанно принимает человек.
В описанных сценариях задачам соответствуют такие сильные стороны ИИ,
как быстрота и умение распознавать шаблоны. Вайб-кодинг, по сути, особенно
хорош там, где речь идёт о давно освоенной территории в программировании
(например, CRUD или типичные структуры веб-приложений), а также там, где
важны быстрые итерации с методом проб и ошибок (прототипы, новые идеи).
Это всё равно что иметь в партнёрах младшего разработчика, который прочитал весь GitHub и мгновенно вспоминает, как обычно принято решать ту или
иную задачу, а после пишет код, который нужно будет просмотреть и исправить.
В этом случае он невероятно ускоряет общий прогресс.

Когда переходить от одного метода к другому
Искусство современной разработки с помощью ИИ заключается не в выборе
какого-то одного подхода вместо другого, а в умении вовремя переключаться
между ними. Опытные разработчики интуитивно определяют такие моменты,
56

Часть 1. Основы

требующие перехода от одной стратегии к другой. Начинаете работу над новой
функцией? Тогда стоит начать с вайб-кодинга, чтобы быстро изучить возможные
варианты. Вы заметили, что код усложняется или затрагивает критичные под­
системы? Пора переходить к инженерному режиму. Нужен прототип для демон­
страции клиенту? Его поможет быстро создать вайб-кодинг. Нужно расширить
этот прототип до готовой к использованию системы? Здесь уже потребуется ин­
женерная строгость. Именно такая гибкость, то есть способность плавно пере­
ходить от быстрого исследования к аккуратному построению, и служит отличительной чертой по-настоящему эффективных специалистов по работе с ИИ. Они
понимают, что вайб-кодинг и разработка с помощью ИИ - это взаимодополня­
ющие инструменты, подходящие для разных стадий жизненного цикла разра­
ботки. Цель не в том, чтобы выбрать какой-то один подход, а в том, чтобы стра­
тегически использовать оба, поддерживая скорость и качество на протяжении
всего процесса создания ПО.

С чем ИИ ещё не справляется
Какие бы впечатляющие результаты ни показывали современные ИИ-модели,
это никоим образом не волшебство и не магия. До сих пор существуют клас­
сы задач, с которыми ИИ справляется с большим трудом и которые часто тре­
буют надзора со стороны человека или использования традиционных приёмов
разработки. Зная о существующих ограничениях, вы будете правильно оцени­
вать предполагаемую помощь ИИ и понимать, в каких случаях стоит опираться
на ИИ, а в каких лучше полагаться на свои собственные.силы.
Среди тех сфер, где возможности ИИ ограничены, стоит упомянуть следу­
ющие.
Крайне сложные системы
Когда ИИ приходится иметь дело с очень сложными алгоритмами или принципиально новыми задачами, с которыми он до этого, скорее всего, не стал­
кивался, он может выдавать ненадёжные результаты. Такие задачи, как ре­
ализация нового алгоритма из недавно опубликованной исследовательской
статьи или разработка компилятора или высококонкурентной системы, тре­
буют хорошего знания логики, настоящего понимания проблемы и зачастую
творческого озарения. ИИ может попытаться решить задачу, но, скорее все­
го, допустит мелкие, но критические ошибки.
В таких сферах склонность ИИ к тому, чтобы писать «примерно правиль­
ный, но не совершенно правильный код», приводит к долгой череде попы­
ток и неудач. Как будет подробно сказано в главах 3 и 4, особенно тяжело
Глава 1. Введение: что такое вайб-кодинг?

57

ИИ даются последние 30% точности. Это связано с проблемой, называемой
мною «проблемой 70%»: ИИ быстро доводит решение до приемлемого уровня,
но не может преодолеть последний участок перед финишем. Опытный разра­
ботчик может воспользоваться ИИ для генерации костяка решения или реа­
лизации вспомогательных функций, но ключевую логику для таких сложных
задач луч ше писать самим.
Низкоуровневая оптимизация и системное программирование
Современные модели ИИ в основном обучены на высокоуровневых языках
и абстракциях. Когда речь заходит о низкоуровневой работе с битами, об оп­
тимизации кода на языке С для конкретного микроконтроллера или о гене­
рации векторных SIМD-инструкций, вряд ли стоит полагаться на ИИ - вы­
данный им код может оказаться не то чтобы не совсем оптимизированным,
но даже некорректным на уровне аппаратуры.
То же самое касается задач вроде управления памятью или работы с реаль­
ным временем, ИИ не понимает по-настоящему эти аспекты (не моделирует
кеш CPU у себя в «голове))). Поэтому критически важный с точки зрения про­
изводительности код нужно либо принимать от ИИ с осторожностью, тща­
тельно тестируя его предложения, либо писать эти части вручную. Тем не ме­
нее ИИ всё ещё может оказать помощь, показав шаблон для начала работы
или объяснив какие-то особенности ассемблера, но слепо доверять ему в та­
ких сценариях нельзя.
Уникальные или нишевые фреймворки
Когда дело касается совсем нового или малоизвестного фреймворка, которо­
го не существовало на момент обучения ИИ, он, разумеется, об этом не знает.
В таких случаях ИИ может прибегнуть к обобщению или выдать код, вы­
глядящий корректно, но в действительности вызывающий несуществующие
функции (галлюцинации) или ориентированный на устаревшую версию API.
Например, после выхода новой версии веб-фреймворка с критическими из­
менениями ИИ не учтёт эти изменения и сгенерирует код для старой версии.
В таких случаях приходится опираться на документацию и при необходимо­
сти обучать ИИ на лету, передавая ему в запросе контекст из документации.
Креативный дизайн UI/UX
Если попросить ИИ спроектировать какой-нибудь совершенно новый поль­
зовательский интерфейс или опыт взаимодействия с пользователем, то он
вряд ли справится с такой творческой задачей. ИИ умеет генерировать
код для известных шаблонов UI (например, для стандартной формы или
58

Часть 1. Основы

дашборда), но без опоры на аналоги он вряд ли выдаст что-то по-настояще­
му свежее и вдохновляющее. Чаще всего он просто комбинирует знакомые
компоненты, так что люди-дизайнеры и фронтенд-разработчики в этой сфе­
ре по-прежнему востребованы. Что касается именно кода, то ИИ может бы­
стро создать стандартный интерфейс, но, чтобы этот интерфейс ощущался
уникальным, ИИ нужно будет давать дополнительные инструкции либо до­
рабатывать интерфейс вручную.
Интерпретация намерений и требований
ИИ сталкивается с трудностями, когда ему точно не объясняют, что нуж­
но сделать, или когда инструкции противоречивы. Он не понимает по-на­
стоящему конечную цель, а ориентируется только на то, что ему сообщили.
В ответ на расплывчатые запросы («сделать хорошо» - что это вообще зна­
чит?) ИИ может неправильно угадать ваши намерения и неверно расставить
приоритеты (например, отдать предпочтение памяти вместо скорости). Люди
лучше догадываются о намерениях, особенно в общении с нетехническими
специалистами. ИИ также может неверно интерпретировать инструкции,
особенно в контексте какой-то специфической предметной области (напри­
мер, в сфере бизнеса). В результате он может сгенерировать решение, которое
будет логически корректно, но которое не решит реальную задачу, потому что
в процессе «перевода с человеческого языка на язык машины)) утратился ка­
кой-то важный нюанс.
Вот вам хороший пример, в котором объединены �се указанные выше за­
мечания. Представьте, что вы разрабатываете новый ЗD-графический движок
(сложная система) на Rust (системный уровень, критично по производительно­
сти). У вас есть новые алгоритмы рендеринга (уникальные задачи). ИИ может
помочь с шаблонным кодом, но основная работа по ядру системы остаётся за че­
ловеком с его интеллектом. ИИ может настроить окно и базовый цикл ренде­
ринга (обычные задачи), но для реализации уникальной задачи придётся писать
код по старинке, разве что с некоторой помощью со стороны ИИ, который бу­
дет предлагать решения в виде псевдокода. Если же попросить его оптимизиро­
вать горячий цикл на ассемблере, то придётся проверять каждую инструкцию.
ИИ также не понимает по-настоящему, что такое принимать решения, ведь,
в конце концов, он занимается только сопоставлением паттернов. Если ваша за­
дача требует некоего озарения, ИИ будет просто раз за разом предлагать сомни­
тельные фрагменты кода, которые проблему не решат. Тут-то и выходит на пер­
вый план человеческий взгляд на мир, способность человека к абстрактному
мышлению и его опыт. И уже потом, проявив свои творческие способности
Глава 1. Введение: что такое вайб-кодинг?

59

и придумав какой-нибудь необычный вариант, вы сможете воспользоваться
искусственным интеллектом для быстрой реализации своих идей.
Понимая, в чём заключаются сильные и слабые стороны вайб-кодинга, вы
сможете применять его методы в подходящих для этого ситуациях. ИИ лучше
всего показывает себя в тех областях, в которых он силён (известные шаблоны),
а работу, требующую творческого осмысления, лучше оставить за человеком.
Будьте готовы принять ответственность на себя в тех-сферах, в которых ИИ тра­
диционно испытывает трудности. Например, внимательно проверяйте любой
код, связанный с безопасностью, так как решение от ИИ может упустить из виду
кое-какие граничные случаи.
Пользуйтесь ИИ для расширения человеческих возможностей: пусть искус­
ственный интеллект возьмёт на себя объём или «ширину» (большое количест­
во кода, шаблонные конструкции), а вы сосредоточьтесь на «глубине» (слож­
ная логика, архитектура). Воспринимайте его как эффективного помощника
в некоторых областях и не бойтесь брать управление в свои руки на сложных
участках. В таком подходе сочетаются сильные стороны обоих участников,
и он даёт наилучший результат. Научившись определять ситуации, в которых
лучше воспользоваться ИИ и в которых лучше положиться на человеческий
опыт, вы повысите свои навыки разработчика в соответствии с требования­
ми новой эпохи.
Каждая новая технология имеет свои преимущества и свои ограничения.
Как бы мы ни восхищались ростом продуктивности и креативности, который
даёт разработка с помощью ИИ, важно осознавать её ограничения и необходи­
мость идти на какие-то компромиссы в некоторых случаях. Среди основных пре­
имуществ можно назвать следующие.
Ускорение циклов разработки
В проектах быстрее происходит переход от концепции к прототипу, а от него
к готовому продукту. ИИ может мгновенно создать каркас (например, ша­
блон для нового проекта), благодаря чему у разработчиков появляется боль­
ше времени на продумывание уникальных частей приложения.
Улучшенное прототипирование и экспериментирование
Так как цена эксперимента низка (достаточно описать ИИ, что вы хотите, что­
бы быстро получить черновой вариант), у разработчиков появляется больше
свободы для креативности. В рамках одной и той же задачи можно создать
несколько прототипов, задавая ИИ различные запросы, а затем выбрать луч­
ший вариант. Такой итеративный процесс подталкивает к более креативным
решениям.
60

Часть 1. Основы

Знания под рукой

Большие языковые модели обучены на обширных корпусах знаний по про­
граммированию. Они часто «знают» не слишком распространённые API или
способы решения ошибок. На практике ИИ может предлагать варианты, о ко­
торых разработчики могли и не вспомнить, и в результате повышается каче­
ство решения задач.

Последовательность и стандартизация
В командной среде ИИ-ассистенты помогают поддерживать общие стандар­
ты, генерируя код в едином стиле. Достаточно настроить ИИ с учётом принятых в том или ином коллективе правил, как он гарантированно будет со­
блюдать их в своём коде. ИИ-модели создают идиоматический код чаще даже
без явного обучения (потому что они уже обучены на миллионах примеров).
В результате снижаются затраты на код-ревью, так как функции в коде вы­
глядят знакомо и изначально соответствуют общепринятым соглашениям.
Среди ограничений и недостатков, которые следует учитывать, стоит назвать
следующие.

Нестабильное качество вывода

Эти модели не безошибочны. Они могут создавать код, который выглядит
правильным, но содержит незаметные ошибки или неэффективные реше­
ния. Модели могут использовать какой-нибудь старый метод, потому что
в их обучающих данных было много примеров старого кода. Вы, как разра­
ботчик, должны постоянно оставаться начеку. Точно так же, как вы не ста­
ли бы бездумно копировать код из Интернета, не понимая, как он устроен,
так и не стоит во всём безоговорочно доверять ИИ. Во второй части этой
книги мы обсудим методы тщательной валидации сгенерированного ИИ-ко­
да и его тестирования.

Неоднозначность запросов выражается в неоднозначности кода
Если запрос недостаточно точен, ИИ приходится угадывать замысел челове­
ка, и он при этом может ошибиться. Например, если вы попросите его «от­
сортировать список имён», ИИ может по умолчанию отсортировать список
в алфавитном порядке, тогда как вы имели в виду что-то другое (напри­
мер, сортировку по длине имени). Без уточнения ИИ не поймёт, что именно
от него требуется, поэтому такое важное значение приобретает точность за­
просов (тема главы 2), и вам нужно научиться заранее предусматривать, ка­
кие подробности включать в свой запрос.
Глава 1. Введение: что такое вайб-кодинг?

61

Развитие зависимости от ИИ и ухудшение навыков
Если новые разработчики будут постоянно полагаться на ИИ, то смогут ли
они развить в себе надлежащие навыки написания и отладки кода? Смогут ли
они как следует понять алгоритмы? Подобно тому, как постоянное исполь­
зование GPS может ухудшить навыки ориентирования, так при постоянном
использовании ИИ существует риск ухудшения навыков программирования.
Поэтому так важно пользоваться ИИ как инструментом обучения (анализи­
ровать предлагаемый им вариант и задавать вопросы, почему он написан так,
а не иначе); для сохранения базовых навыков имеет смысл время от времени
практиковаться в написании кода без ИИ.
Вопросы конфиденциальности и безопасности
Облачные инструменты написания кода с помощью ИИ часто подразумева­
ют отправку кода (который может быть проприетарным или конфиденци­
альным) на сторонние сервисы для анализа. Компании должны учитывать
этот момент. Многие инструменты решают эту проблему тем, что предла­
гают модели для локальной установки или утверждают, что не сохраняют
присылаемый им код, но вопрос остаётся актуальным. Также существует
риск, что ИИ случайно сгенерирует код, очень похожий на фрагмент сво­
их обучающих данных, распространяемых по открытой лицензии (вроде
GPL). Хотя это маловероятно (для предотвращения дословного воспроиз­
ведения длинных фрагментов существуют специальные меры), но всё рав­
но перед интеграцией кода нужно обязательно проверять код и понимать,
что делает ИИ. Вопросы безопасности и надёжности подробно рассматриваются в главе 8.
Смещение (предвзятость) в выводе ИИ
Код, выдаваемый ИИ-моделями, может отражать присутствующие в их об­
учающих данных смещения. В частности, такое явление, как смещение (или
предвзятость, Ьias), может проявляться и в безобидных вещах - например,
модель предпочитает определённые имена переменных, - и в более серьёз­
ных - например, в том, что модель часто задаёт специфические атрибуты
пользователей. Модель, например, может постоянно использовать имена foo/
bar для имён переменных в примерах (поскольку такие имена были во мно­
жестве обучающих примеров) или устанавливать локаль (языковой и регио­
нальный стандарт) пользователя без его совета. Обычно для генерации кода
это не критично по сравнению с другими сценариями использования ИИ,
но стоит иметь в виду такой факт. Более деликатный момент заключается
в том, что ИИ может выбирать решения, которые встречались ему чаще, даже
62

Часть 1. Основы

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

Итоги и дальнейшие шаги
Смена вектора в сторону программирования с намерением открывает огромный
потенциал для ускорения разработки, повышения её доступности и в целом уве­
личения удовольствия от процесса. Но для реализации потенциала важно осоз­
навать особенности новой динамики и понимать принципы эффективного взаи­
модействия с искусственным интеллектом проверки выдаваемых им результатов
и ответственной интеграции ИИ в процесс разработки.
На основании практической работы с такими инструментами, а также на ос­
новании наблюдений за множеством проектов, я считаю, что лучший способ ис­
пользования ИИ - это сочетание творческого настроя (вайба) со строгой ин­
женерной дисциплиной. Предлагаемые ИИ эксперименты со смелыми идеями
и быстрое создание черновых вариантов - это ставшие доступными нам новые
сверхспособности. Но их стоит контролировать с помощью накопленной за де­
сятилетия мудрости, подсказывающей, что нельзя забывать о планировании, те­
стировании и осознании того, что делаешь.
Тщательно найденный баланс поможет нам воспользоваться преимущества­
ми обоих миров. Все мы хотим, чтобы можно было быстрее создавать потенциально более креативное ПО, но оно должно оставаться надёжным, удобным
в поддержке и способным к развитию. Именно так мы развиваем своё мастерство
Глава 1. Введение: что такое вайб-кодинг?

63

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

ГЛАВА 2

Искусство составления запросов:
эффективный способ общения с ИИ
Запросы, или промпты, в мире вайб-кодинга - это своего рода «новый исход­
ный код».
Качество генерируемого ИИ кода напрямую зависит от того, как вы сообщае­
те ему свои намерения. Умение составлять хороший запрос - это одновременно
искусство и наука, часто называемая промпт-инжинирингом (prompt engineering).
В этой главе описываются приёмы, позволяющие работать с ИИ-ассистентом
максимально эффективно. Мы начнём с основ, с объяснения, почему так важ­
ны запросы, а затем перейдём к практическим советам, к техникам запросов,
от простых до продвинутых. Освоив мастерство составления эффективных
промптов с их итеративной доработкой (иллюстрация 2.1), вы научитесь быст­
рее работать с ИИ и получать от него более точные результаты.

Глава 2. Искусство составления запросов: эффективный способ общения с ИИ

1

65

Запрос
Сгенерируй на Python функцию
суммирования массива

: Запрос

ОтветИИ
add uni.t tests
def suР1_аггау(агг}:
гetuгn SUPl(aгг)

Добавь
ОтветИИ
модульные
тесты (unit tests) de.f test sul'I аггау()

...

asseгt
3, ·4,
asseгt
asseгt

SUl'l_aггay[l, 2]'
5]) == 15
sul'l_aггay (]] = е
sul'l_aггay [7] = 7,,

о

Иллюстрация 2.1. Чат-бот, помогающий написать код. Разра­
ботчик и ИИ ведут диалог: разработчик формулирует инструк­
ции или задаёт вопросы (запросы, промпты), а ИИ в ответ пишет
код или даёт пояснения. Эффективное взаимодействие с ИИ дости­
гается за счёт хорошо продуманных и составленных запросов

Основы промпт-инжиниринга
Если вайб-кодинг - это диалог между разработчиком и моделью ИИ, то промпт­
инжиниринг (формулировка запросов) - это навык перевода своих намерений
на язык ИИ, позволяющий получать лучшие результаты. Удачно составленный
промпт, или запрос, - это зачастую главное условие корректного решения, не­
удачный же промпт повышает вероятность нерелевантного или ошибочного от­
вета. Овладев мастерством промпт-инжиниринга, вы научитесь плодотворно
общаться с ИИ, заставлять его учитывать контекст и направлять его к нужно­
му результату, если первый ответ окажется недостаточно удовлетворительным.
66

1

Часть 1. Основы

Программируя с ИИ, вы фактически программируете посредством ИИ, ис­
пользуя естественный язык. Запросы в данном случае можно воспринимать как
высокоуровневый язык программирования, который ИИ-интерпретатор пере­
водит в реальный код. И точно так же как вывод компилятора зависит от каче­
ства исходного кода, так и вывод ИИ зависит от качества запросов.
Почему же запросы так важны? Дело в том, что большие языковые моде­
ли (LLM) не умеют читать мысли. Они только реагируют на то, что им задали.
Нечётко или плохо сформулированные запросы на входе приводят к нерелевант­
ному или некорректному коду на выходе, тогда как хорошо сформулированный
запрос позволяет получить точный результат уже после первой попытки. При
традиционном подходе к программированию специалист тратит время на ана­
лиз алгоритмов и написание кода; при вайб-кодинrе он тратит время на обду­
мывание запросов, с помощью которых собирается донести свои требования
до ИИ. Здесь мы наблюдаем сдвиг в осмыслении самого понятия «писать код)):
вместо самой функции можно создать абзац с описанием этой функции, но по­
прежнему следует придерживаться ясности и логичности.
Воспринимайте запросы как своего рода рабочую документацию или поль­
зовательские истории для очень педантичного и понимающего всё буквально
младшего программиста - того, который делает всё чётко по документации
(и ничего более) и обладает обширными знаниями, но не умеет строить свои
собственные предположения о том, что выходит за границы известных ему ша­
блонов. Если ваши запросы можно интерпретировать неоднозначно, ИИ порой
заполняет пробелы неожиданным для вас образом. Получается, умение общать­
ся с ИИ становится таким же важным, каким некогда с;италось изучение сии таксиса языка программирования.
Чётко сформулированные запросы важны ещё по одной причине - они га­
рантируют воспроизводимость результатов с учётом возможных изменений.
Если у вас получится составить запрос, который гарантированно генерирует
хороший код для определённоrо шаблона или конкретной задачи, то этот за­
прос станет ценной частью знаний (почти как сниппет или шаблон). Этот за­
прос можно сохранить и использовать его в аналогичном контексте. Коллеги­
разработчики могут делиться примерами удачных запросов, подобно тому как
они делятся эффективными приёмами программирования или фрагментами
кода.
Наконец, по мере улучшения моделей и их интеграции они предполагают
всё более сложные сценарии взаимодействия. Умение составлять хорошие пром­
пты научит вас быстро приспосабливаться к ситуации и откроет для вас новые
возможности. Некоторые усовершенствованные системы, например, в качестве
контекста для модели позволяют прикреплять к запросу обширные инструкции
Глава 2. Искусство составления запросов: эффективный способ общения с ИИ 1 67

или даже целые справочные документы. Важно иметь представление о таких
возможностях и уметь пользоваться ими.
Итак, воспринимайте искусство составления запросов как новый обязатель­
ный навык. В каком-то смысле промптинг - это и есть программирование. Глав­
ное отличие от традиционного программирования заключается только в том, что
вы пользуетесь естественным языком (например, английским), который ИИ затем
преобразует в код. Но вы всё равно должны соблюдать чёткость формулировок,
логичность рассуждений и предусматривать в своём описании граничные случаи.

Конкретность и ясность: как формулировать запросы,
которые работают
Одно из золотых правил промпт-инжиниринга (которое я подробнее рассма­
триваю в главе 3) - это конкретность и ясность формулировки намерения. В от­
личие от человека, ИИ не умеет догадываться, он воспринимает только те сло­
ва, которые ему предоставляют в явно выраженной форме. Распространённая
ошибка - дать ИИ слишком общий запрос вроде «Сделай веб-сайт» и ожидать
от него волшебного результата. ИИ работает гораздо эффективнее, когда ему
предлагают что-то конкретное.
Всегда исходите из предположения, что он не знает о вашем проекте ниче­
го, кроме того, что вы ему рассказали. Упоминайте все релевантные детали, та­
кие как язык программирования, фреймворк и библиотеки, а также конкрет­
ную функцию или сниппет. При выводе ошибки указывайте точное сообщение
об ошибке и опишите, что должен делать код. Любая неясность или возможность
неправильного толкования может привести к нежелательным результатам.
Например, вместо «Напиши функцию сортировки» можно сформулировать
запрос так:
Напиши на Python функцию сортировки клиентов sort_by_lastname
(customers), которая принимает список записей о клиентов (каждая запись
содержит поля first_name с именем и last_name с фамилией) и возвращает
список, отсортированный по last_name в алфавитном порядке. Добавь крат­
кую строку документации (docstring) и обработай случай, когда фамилии
отсутствуют, считая их пустыми строками.
Этот промпт задаёт чёткие установки относительно языка (Python), име­
ни и назначения функции, структуры входных данных, ключа сортировки, до­
полнительных требований (docstring) и граничного случая. С очень большой
68 1 Часть 1. Основы

вероятностью ИИ выдаст именно то, что вам нужно, или очень близкий к же­
ланному результат. Представьте, что вы составитель спецификаций: чем точнее
вы сформулируете задачу, тем меньше догадок придётся делать ИИ и тем мень­
ше правок потребуется в дальнейшем.
Среди стратегий конкретности стоит упомянуть следующие.
Упоминание языка или среды
Если вам нужен пример на JavaScript, попросите: «Напиши функцию
на JavaScript ... », а не просто «Напиши функцию...» Если вы ориентируетесь
на конкретный фреймворк или конкретную версию, упомяните об этом (до­
бавьте: «с использованием React Hooks ...» или «на Python З ...»).
Уточнение объёма вывода
Нужна вам только функция или вы хотите получить целый файл или мо­
дуль? Модуль с тестами? Тогда добавьте в запросе: «Покажи только реализа­
цию функции» или «Напиши полностью исполняемый скрипт»; эти запросы
дадут разные результаты.
Упоминание требований и ограничений
В примере с авторизацией указывали длину пароля и количество попыток.
Подумайте, какие могут быть граничные случаи и ограничения в вашем слу­
чае, и включите их в запрос. Если код должен быть оптимизирован по произ­
водительности или если он подразумевает определённый алгоритм, укажите
и это: «С O(n) по времени и 0(1) по памяти» или «С использованием бинар­
ного поиска».
Отсутствие многозначных слов (местоимений)
Не используйте слова вроде «это», «его» и т. д., если из контекста неясно,
к чему они могут относиться. Вместо «Обработай это и верни результат» луч­
ше написать: «Обработай массив и верни результирующий массив».
Указание желаемого формата вывода
В зависимости от того, нужен ли вам только код, код с комментариями или
объяснение, добавьте: «Только код, без объяснений» или «Напиши код с крат­
ким комментарием для каждого шага».
Чётко сформулированный запрос - путь к успеху. Если вы заметили, что
вам приходится слишком часто исправлять ответы ИИ, подумайте, насколько
вы чётко и ясно формулируете свои запросы.
Глава 2. Искусство составления запросов: эффективный способ общения с ИИ

69

Вот чего делать не стоит.

Не пишите целый роман
Многословные запросы с нерелевантной информацией сбивают модель с толку
или заставляют её сосредоточиться не на том, на чём нужно. Будьте лаконичны,
но не упускайте ничего важного в своём описании. Например, если речь идёт
о коде, необязательно писать в начале: «Ты программист мирового класса ... » (не­
которые так делают, когда просят совета ChatGPT в какой-то области, но для про­
граммирования такое уточнение часто бывает излишним и добавляет шума).
Не надейтесь на то, что ИИ сам правильно додумает детали
Упомяните все важные для вас детали (например, потокобезопасность, об­
работку специальных символов и т. д.). Иначе заранее настройтесь на то, что
ИИ не учтёт всех деталей.
Не используйте слишком «творческие», общие запросы, если вам нужен конкрет­
ный результат
Например, фраза «Напиши какой-нибудь код для анализа данных» оставляет
простор для интерпретаций со стороны ИИ. Вместо этого уточните:
Рассчитай среднее значение и стандартное отклонение для списка чисел.
Итак, вкратце вот вам главный совет: пишите именно то, что имеете в виду.
Чем больше ИИ «знает» о том, что вы от него требуете, тем лучше. Если вам при­
ходится исправлять ответы ИИ по несколько раз, подумайте, как вы могли бы
сформулировать свою мысль яснее.

Итеративное уточнение: цикл обратной связи с ИИ
Но даже с чётко сформулированными запросами не всегда удаётся получать иде­
альный ответ с первой же попытки. Воспринимайте взаимодействие с ИИ как
диалог или итеративный процесс разработки. Это тот самый цикл обратной свя­
зи, о котором я упоминал в главе 1.
Всегда осматривайте выдаваемый ИИ-код критическим взглядом - точно
так же, как если бы его написал человек. Соответствует ли он требованиям? Если
нет, определите, чего не хватает или что не так. Затем задайте уточняющий за­
прос. Это можно сделать в окне диалога или в окне редактора, просто написав
новый комментарий, на который ответит ИИ.
70 1 Часть 1. Основы

Предоставляя обратную связь, вы подталкиваете ИИ в нужном для вас на­
правлении. В каком-то смысле вы обучаете его по ходу дела для своей конкрет­
ной задачи. Продвинутый промпт-инжиниринг строится по циклу, похожему
на тот, что изображён на иллюстрации 2.2: запрос➔вывод ИИ➔анализ➔уточ­
нение запроса➔вывод ИИ➔... и так далее, пока не будет получен удовлетвори­
тельный результат. При этом на каждой итерации полезно вносить относительно
небольшие изменения; если же слишком радикально переделать запрос, то мо­
гут пропасть некоторые хорошие части предыдущего вывода.

Запрос
Уточнение
запроса
�

о

ВыводИИ

Анал.-з

До удовлетворительного результата

Иллюстрация 2.2. Цикл продвинутого промпт-инжиниринга
Например, вы задаёте такой запрос:
Напиши функцию, принимающую список целых чисел и возвращающую
их сумму.
ИИ возвращает функцию, но из кода следует, что список не должен быть пу­
стым, а пустые списки обрабатываются плохо. Вы уточняете:
Выглядит неплохо, но измени её, пожалуйста, так, чтобы она возвращала О
для пустого списка.
ИИ соответствующим образом обновляет функцию. Так вам не пришлось на­
чинать диалог с нуля, вы просто попросили ИИ подкорректировать код. ИИ уже
работал в контексте предыдущего кода, который он выдал.
Если вы используете встроенного помощника, уточнение может выглядеть как
редактирование кода и написание комментариев вроде# T0D0: обработать пу­
стой список; после этого ИИ может обратить на них внимание и исправить код.
Другой способ уточнения - предоставление в следующем запросе допол нительной информации. Предположим, вы задали такой запрос: «Отсортируй
Глава 2. Искусство составления запросов: эффективный способ общения с ИИ

1

71

список имён», и ИИ вывел код с учётом регистра, а вам нужен был вариант без
учёта регистра. Вы переформулируете свой запрос так:
Отсортируй список имён без учёта регистра.
Или даже так:
Предыдущий код сортирует с учётом регистра. Измени его так, чтобы он
не учитывал регистр.
При отладке более сложных логических ошибок (когда не отображается яв­
ное сообщение об ошибке, но вывод неправильный) можно попросить ИИ прой­
тись по выполнению кода шаг за шагом. Например:
Пройди по этой функции построчно и отслеживай значение total на каждом
шаге. Оно накапливается неверно - где логика даёт сбой?
Это пример промпта для отладки по методу «резинового утёнка»: вы, по сути,
просите ИИ симулировать процесс отладки, который мог бы выполнить чело­
век, читающий код или выполняющий его в отладчике.
Поскольку ИИ описывает состояние на каждом шаге, такие запросы часто
выявляют скрытые проблемы, например переменные, которые не сбрасываются,
или некорректную условную логику. Если вы подозреваете, что ошибка кроется
в какой-то конкретной части кода, можно сосредоточиться на ней:
Объясните, что делает здесь вызов фильтра и не исключает ли он больше
элементов, чем должен.
Если вы попросите ИИ объяснить поведение кода, то ошибка может всплыть
в ходе объяснения.
После объяснения часто бывает полезно напрямую попросить то, что вам
нужно:
Что могло вызвать эту проблему и как её решить?
Так вы попросите ИИ одновременно и диагностировать проблему, и пред­
ложить решение. Если первый ответ ИИ неясен или полезен лишь частично,
не стесняйтесь задать уточняющий вопрос:

72

Часть 1. Основы

Я понял объяснение. Можешь показать, как именно исправить код? На­
пиши, пожалуйста, исправленный код.
В чате ИИ отслеживает историю диалога и может написать исправленный
код сразу же. Если вы пользуетесь встроенным инструментом вроде Copilot
в VSCode или Cursor без чата, то можно написать комментарии над рассматриваемым фрагментом кода:
// BUG: возвращает NaN, исправь эту функцию и посмотри автодополнение.
В целом в интерактивном чате даются более полные объяснения.
Вот вам другой вариант последующего запроса. Если ИИ предложил исправ­
ление, но вы не понимаете его, спросите:
Можешь объяснить, почему это изменение решает проблему?
Так вы учитесь на примере ошибок и проверяете корректность рассужде­
ний ии.
Большие языковые модели прекрасно реагируют на примеры и исправления.
Если вы отметите места, требующие исправлений, или приведёте краткий при­
мер, ИИ это учтёт:
Если на входе[], функция должна вернуть О, но сейчас возникает ошибка.
Такой итеративный процесс совершенно нормальная практика. Попытка
втиснуть все детали в один запрос зачастую бывает гораздо менее эффективной,
чем несколько циклов «вопрос - ответ)). Пользуйтесь возможностью диалога.
Не теряйте терпение и в своей обратной связи придерживайтесь конкретики.
Вместо того чтобы писать: «Нет, это неправильно)), лучше сказать, что именно
неправильно или чего вы хотите:
Этот код некорректно обрабатывает отрицательные числа. При суммирова­
нии они должны считаться как О.
Если ИИ отвлекается от темы, можно направить его обратно в нужное русло.
Иногда бывает проще сформулировать запрос заново или радикально изменить
его, чем пытаться исправить неправильный результат. Руководствуйтесь здра­
вым смыслом. Если из ответа ИИ следует, что он вас совершенно неправильно
понял, задайте вопрос с нуля.
Глава 2. Искусство составления запросов: эффективный способ общения с ИИ

73

По мере уточнения можно понять, как ИИ истолковал ваш первый запрос,
и это знание поможет вам впоследствии составлять более эффективные за­
просы. Например, вас может посетить такая мысль: «Ага, так под "системой ав­
торизации" он имел в виду весь пользовательский интерфейс. В следующий раз
нужно уточнять, что имеется в виду только бэкенд».
Воспринимайте этот процесс итераций как отладку кода: если ответ ИИ не­
верен, баг может крыться не в самом коде, а в вашем запросе. Подобно тому, как
вы при некорректных результатах проверяете и исправляете код, в случаях, ко­
гда ИИ генерирует неожиданный или неправильный ответ, нужно уточнять за­
просы. Диалог с ИИ - это своего рода сессия отладки, при которой диалог по­
могает найти и исправить проблему.

Сравнение двух запросов
Представьте, что у вас имеется простая функция на Node.js, которая должна пре­
образовывать массив объектов пользователей в объект-словарь по ID пользова­
теля. Но она выдаёт ошибку. Вот проблемный код:
// Проблемная функция: преобразует массив пользователей в словарь по ID
function мapUsersByid(users) {
const userMap = {};
for (let i = 0; i <= users.length; i++) {
// Примечание: использование <= выходит за пределы массива
на последней итерации
const user = users[i];
userMap[user.id] = user;
}

return userMap;
}

// Пример использования:
const result = мapUsersByid([{id: 1, nаме: "Alice"}]);

Эта функция должна проходить по массиву пользователей и создавать объект, где
ключи - это ID пользователей. Однако в ней имеется баг: вместо i. < users. length
в цикле указано условие i. <= users. length. На последней итерации users [ i.] при­
нимает значение undefi.ned, что приводит к ошибке выполнения (например, при
попытке обратиться к свойству i.d у undefi.ned). Рассмотрим, как ИИ-ассистент мо­
жет отреагировать на два разных запроса по этой проблеме (см. иллюстрацию 2.3).
74

1

Часть 1. Основы

Общий/неверный
код

Точный код

0

fог (i.nt t=e;
i. < n; ++i.)"
{

Общий/неверный
код

Точный код

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

Плохой запрос
Вот пример плохого запроса:
Почему моя функция mapUsersByld не работает?
Ответ ИИ на плохой запрос (вымышленный):
Без дополнительной информации сказать трудно. Вы уверены, что функ­
ция вызывается с корректным массивом пользователей? Возможно, массив
users пуст или не является массивом, что мешает выполнению цикла. Так­
же может быть ошибка при присвоении свойства в userMap. Убедитесь, что
у каждого пользователя имеется свойство id. Также сбой может случиться,
если users принимает значение undefined или null.
Ответ этот довольно расплывчатый. В запросе не упоминались никакие по­
дробности, кроме имени функции, поэтому ИИ назвал самые общие возможные
причины («Возможно, массив пуст или это не массив», «Убедитесь, что у каждо­
го пользователя есть ID»). Фактический баг выявлен не был.
Глава 2. Искусство составления запросов: эффективный способ общения с ИИ

1

75

Это типичный ответ на недостаточно уточнённый вопрос - модель лишь по­
вторяет общие советы по отладке. Для разработчика они почти не несут никакой
пользы. Получив запрос без контекста и конкретных деталей, ИИ, по сути, вы­
даёт эквивалент столь распространённой среди специалистов шуточной фразы:
«А вы не пробовали выключить и включить снова?»

Улучшенный запрос
Попробуем теперь так:
У меня есть написанная на JavaScript функция 111apUsersByid, которая долж­
на преобразовывать массив объектов пользователей в объект (map), где
ключи - это ID пользователей. Но при выполнении возникает ошибка.
Например, при передаче [{i.d: 1, na111e: "Аli.ce"}] я получаю сообще­
ние об ошибке TypeError: Cannot read property 'i.d' of undefi.ned.
Вот код функции:
functton �apUsersByld(users) {
const userMap = {};
for (let t = 0; t <= users.length; t++) {
const user = users[t];
userMap[user.td] = user;
}

}

return userMap;

Функция должна вернуть {" 1" : {i.d: 1, na111e: "Аli.ce"}}. В чём ошибка
и как её исправить?
Ответ ИИ на улучшенный промпт (вымышленный):
Ошибка Cannot read property 'i.d' of undefi.ned указывает на то, что
в какой-то момент user принимает значение undefi.ned, и при попытке до­
ступа к user. i.d возникает ошибка. Если взглянуть на ваш цикл, проблема
заключается в границах: в нём указано условие i. <= users. length. Если
users. length равно 1 (то есть в массиве один пользователь), цикл выполня­
ется с i. = 0 и i. = 1. Когда i. = 1, users[1] принимает значение undefi.ned,
так как единственный индекс массива - это 0. Таким образом, на этой ите­
рации user становится undefi.ned, и попытка доступа к user. i.d вызыва­
ет TypeError.
76

Часть 1. Основы

Исправить пример можно, изменив условие цикла на i. < users. length,
чтобы i. принимало значения от 0 до users. length-1. Например:
for (let i. = 0; i. < users.length; i.++) {
const user = users[i.];
userMap[user.i.d] = user;
}

Теперь i. будет равно 0 для первого (и единственного) элемента, после чего
цикл завершится. Благодаря этому изменению функция больше не столк­
нётся со значением undefi.ned и будет работать как ожидалось, возвращая
для данного входного массива результат: {" 1" : {i.d: 1, nal'1e: "Аli.ce"}}
В этом ответе ИИ прямо указывает на ошибку ( <= в условии цикла) и объ­
ясняет, почему это приводит к появлению значения undefi.ned. Затем он пока­
зывает правильное решение с корректным условием (i. < users. length), ко­
торое подтверждается ожидаемым результатом. Улучшенный промпт сработал,
потому что он был сформулирован согласно перечисленным выше принципам:
в нём был указан язык (JavaScript), описана цель функции, вставлено точное со­
общение об ошибке и предоставлен пример входных данных, а также показан
сам фрагмент кода. Все эти подробности позволили ИИ точно определить про­
блему и предложить корректное исправление.
Обратите внимание на то, как ИИ воспользовался сообщением об ошиб­
ке как подсказкой для того, чтобы сосредоточиться на границах цикла. Так це­
левой промпт помог ИИ заняться настоящим решением проблемы и сымити ровать мышление занимающегося отладкой человека: «Откуда может взяться
undefined� Вероятно, из индексации цикла». Это наглядная демонстрация поль­
зы подробных промптов.

Техники запросов: набор инструментов эффективного
взаимодействия
Перейдём теперь к конкретным техникам, которые могут резко повысить эффек­
тивность ваших запросов. Это своего рода шаблоны, или «рецепты», помогаю­
щие, когда простой инструкции недостаточно или когда нужно направить ИИ
в определённую сторону. Освоив эти приёмы, вы с уверенностью будете работать
в различных сценариях: давать указания на обычном языке, приводить примеры,
просить ИИ структурировать или объяснить вывод, задавать ему определённую
Глава 2. Искусство составления запросов: эффективный способ общения с ИИ

1

77

роль или переключать в другой «режим мышления». Все эти приёмы помогают
точнее контролировать результат.
Техники запросов, или промптинrа, не исключают друг друга, и при решении
сложных задач их часто приходится сочетать.

Небольшое замечание о стиле
Во время использования этих техник при общении с ИИ быва­
ет полезно придерживаться определённоrо тона. Многие мо­
дели хорошо реагируют на вежливые или нейтральные фор­
мулировки. Вовсе не обязательно прибегать к архаичным или
чрезмерно официальным выражениям. Лучше всего работает
прямой, спокойный тон: «Сделай, пожалуйста, то-то и то-то»
или «Давай сделаем ...» Например, в приёме «цепочка рассу­
ждений» (СоТ ) часто используется фраза «Рассуждай пошаrо­
ВО>> - современные модели вроде GPT-4 воспринимают её как
сигнал показывать промежуточные рассуждения.

Метод нулевого обучения (Zero-Shot Prompting)
Метод нулевого обучения (Zero-shot prompting) - это просьба что-то сделать без
предоставления примеров и без дополнительных указаний помимо самой инструкции. По сути, это ситуация, когда модель решает задачу, имея «ноль» (zero)
примеров.
Когда использовать: самый обычный сценарий, когда вы просто формулиру­
ете то, что вам нужно, на простом естественном языке. Если задача стандартная
и запрос сформулирован чётко, этого обычно бывает достаточно.
Пример:
Напиши на Python функцию, которая проверяет, является ли число про­
стым.
Это и есть запрос без примеров. Модель, скорее всего, напишет функцию для
проверки числа с использованием цикла или перебора делителей.
Плюсы: это быстрый метод с опорой на знания модели. Современные модели
на удивление хорошо справляются без всяких примеров со многими стандарт­
ными задачами программирования ( такими как определение простого числа,
сортировка или обработка строк).

78 1 Часть 1. Основы

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

Обучение с одним или несколькими примерами (One-Shot и Few­
Shot Prompting}
Обучение с одним примером ( One-shot) - это запрос, в котором приводится один
пример того, что вам нужно (ввод и желаемый результат); запрос с нескольки­
ми примерами (Few-shot) - это запрос, в начале которого приводится несколь­
ко примеров (обычно от двух до пяти), после чего модель просят выполнить за­
дачу с новыми входными данными.
Это всё равно что сказать модели: «Посмотри, как я решаю один случай. Те­
перь ты сделай так же».
Когда испот,зовать: такой стиль полезен, когда вы не уверены в том, что фор­
мат ответа будет в точности таким, какой вам нужен, или когда задача немного
нестандартна. Примеры помогают уменьшить неоднозначность.
Пример (с одним примером): допустим, вы используете язык или стиль, с ко­
торым модель не слишком часто сталкивалась. Допустим, вам нужен фрагмент
псевдокода в каком-то конкретном формате. Запрос может выглядеть так:
Преобразуй следующие инструкции с естественного (английского) языка
в псевдокод в стиле Python.
Пример инструкции: «Вычисли факториал числа n».
Пример псевдокода:
function factorial(n):
if n <= 1:
return 1
else:
return n * factorial(n-1)

Инструкция: "Найди наибольwее число в списке"
Псевдокод:
Глава 2. Искусство составления запросов: эффективный способ общения с ИИ 1 79

Здесь показан один пример (вычисления факториала) и нужный формат. Те­
перь модель с большей вероятностью создаст псевдокод для нахождения наи большего числа в аналогичном формате (с функцией и с логикой if/else или ци­
кла, если это потребуется).
Пример (с несколькими примерами): допустим, вы хотите, чтобы ИИ восполь­
зовался определённым алгоритмом. В таком случае в качестве подсказки можно
дать ему небольшой пример работы этого алгоритма или, если у задачи несколь­
ко верных ответов, но вы предпочитаете какой-то конкретный, можно показать
подходящие ответы.
Запрос с несколькими примерами особенно эффективен, когда ответ должен
быть каким-то образом отформатирован.
Преобразуй следующие фрагменты текста на английском языке в SQL-запро­
сы. \Nl."Get All Employees Hired After 2020" ➔ Select * From Employees Where
Hire_Date > '2020-0l-0l';\N2. "List Customer Names Who Made А Purchase In
The Last Month'' ➔ Select Name From Customers Join Purchases On ... Where
Purchase_Date > ...;\NЗ. "Count Of Products That Are Out OfStock'' ➔
Здесь предоставлены два примера преобразования фраз на английском языке в формальные запросы к базе данных, и ИИ, следуя этому шаблону, с боль­
шой вероятностью преобразует последнюю фразу в нужный формат. Запросы
с несколькими примерами бывают полезными и в тех случаях, когда речь идёт
о программном коде. Покажите ИИ пару примеров в нужном вам формате, а за­
тем попросите создать фрагмент кода в этом же формате. Это своего рода мини­
набор обуч ающих данных, задаваемый непосредственно в запросе.
Плюсы: можно получать вывод, оформленный в специфическом стиле.
Этот же приём помогает справиться с задачами, требующими соблюдения како­
го-то определённого шаблона, или с однотипными повторяющимися задачами.

Окно контекста
Термин окно контекста означает максимальный объём тек­
ста (измеряемый в токенах), который языковая модель мо­
жет обрабатывать в рамках одного сеанса взаимодействия,
включая запросы и генерируемые ответы. Это ограничивающий фактор современных ИИ-моделей - при превышении
определённого порога модель уже не может обрабатывать до­
полнительную информацию. Всё, что вы включаете в запрос
(инструкции, примеры, данные), должно вместе с ответом по­
мещаться в этот фиксированный объём.

80

1

Часть 1. Основы

Минусы: примеры делают запрос длиннее (что расходует окно контекста).
В случае с большими или сложными примерами такой метод может израсходо­
вать значительную долю «памяти» модели. Но один-два небольших примера это, как правило, нормально.
Совет: если вы хотите, чтобы модель строго придерживалась какой-то опре­
делённой структуры, то примеры почти гарантируют соответствие ответа этой
структуре. Так вы, скорее всего, сразу получите ответ в нужном вам виде, и его
не придётся переделывать.

Цепочка рассуждений (Chain-of-Thought)
Цепочка рассуждений (СоТ, Chain-of-1hought) - это метод запроса, при котором
ИИ предлагают рассуждать логически, шаг за шагом, прежде чем будет сформу­
лирован окончательный ответ. Другими словами, модель просят разбить зада­
чу на части.
Когда использовать: этот метод полезен для сложных задач, требующих рас­
суждений и многошаговых вычислений, а ещё когда есть риск, что модель оши­
бётся, если сразу перейдёт к ответу. Он также подходит, если вам нужно полу­
чить объяснение в выводе.

Комбинаторика
Комбинаторика - это область математики, связанная с под­
счётом, расположением и выбором объектов согласно задан­
ным правилам или ограничениям. Среди типичных задач вычисление количества перестановок (или размещений, когда
важен порядок), сочетаний (когда порядок не важен) и других
комбинаций элементов. Ключевая формулировка здесь - это
«n из k» (записывается, как C(n, k) или nCk), то есть количе­
ство способов выбрать k элементов из n элементов, вычисля­
емое по формуле n!/(k!(n-k)!). Подобные вычисления часто
используются в задачах по вероятностям, статистике и дис­
кретной математике.
Пример: вместо того чтобы просто попросить решить задачу по комбинато­
рике (https://oreil.lylvIЗVS): «Сколько перестановок 4 элементов можно сделать
из 12 элементов?» или «перестановка 4 по 12» («What is 12 choose 4?»), можно
спросить:

Реши пошаrово задачу о количестве перестановок 4 элементов из 12, С(12,4).
Глава 2. Искусаво составления запросов: эффективный способ общения с ИИ 1 81

Модель в таком случае распишет более подробно:
4 из 12 это 12!/(4!*8!)

= ... =

495

В программировании метод СоТ пригождается для сложных алгоритмиче­
ских задач. Можно попробовать такой запрос:
Объясни пошагово, как объединить два отсортированных списка, а затем
напиши код на Python.
Модель сначала набросает план вроде:
Воспользуемся двумя указателями в головах списков; будем сравнивать эле­
менты, добавлять меньший в результирующий список и сдвигать соответ­
ствующий указатель и так далее ...
Затем модель покажет код. Ход рассуждений помогает ей удостовериться
в верности решения.
Ещё один сценарий использования этого метода - отладка или объяснение
вывода:
Пошагово разбери логику проверки, является ли число 19 простым, затем
покажи результат.
Модель может последовательно расписать процесс деления на простые чис­
ла, а затем прийти к выводу:
19 - простое число.
Плюсы: повышается корректность решения задач, требующих рассужде­
ний. Некоторые исследования (https:!/oreil.ly/t7jlF) говорят, что просьба «думать
вслух» иногда улучшает результаты моделей. Кроме того, человек видит, как рас­
суждает модель, и его доверие к ней повышается, или же он может поучиться
на её рассуждениях.
Минусы: вывод становится длиннее (что может быть нежелательно для ито­
гового кода). Кроме того, некоторые интерфейсы (например, в виде автодопол­
нения кода) не рассчитаны на отображение логических рассуждений отдельно
от кода. Эта техника более распространена в сценариях взаимодействия в чате
или вида «вопрос - ответ». Но можно дать модели инструкцию включить
82

Часть 1. Основы

рассуждения в код в виде комментариев и в результате получить тщательно за­
документированный код.

Ролевые запросы (Role Prompting)
Ролевые запросы (Role Prompitng), также ролевой промптинr, - это техника за­
просов, при которой пользователь просит ИИ сыграть определённую роль или
изобразить некую личность, что повлияет на характер ответов модели.
Когда использовать: этот метод полезен, когда нужно повлиять на стиль, де­
тализацию ответа или получить ответ с какой-то определённой точки зрения.
Например, ИИ, играющий роль «эксперта», может дать более подробное реше­
ние или предоставить больше объяснений, тогда как «новичок» будет объяснять
элементарные понятия.
Примеры
- Ты преподаватель языка Python. Объясни следующий код, а затем переде­
лай его, чтобы он более соответствовал духу Python.
- Ты аналитик по безопасности. Вот фрагмент кода. Найди в нём возмож­
ные уязвимости.
- Представь, что ты линтер, проверяющий код на несоответствие стилю.

Эти роли могут в очень большой степени изменить ответ модели. Например,
в роли аналитика по безопасности ИИ обратит внимание на аспекты, которые он
обычно не упомянул бы (валидация данных, безопасные практики кодирования
или потенциальные уязвимости). Роль преподавателя заставит его давать более
понятные объяснения и исходить в своих ответах из того, что пользователь мо­
жет не знать самых элементарных вещей.
Что касается программного кода, то перед основным запросом можно задать
следующую роль:
Ты опытный программист на С++ с глубокими знаниями в области оптими­
зации, который инструктирует младшего разработчика.
В ответах ИИ будет, скорее всего, показывать более продвинутые возможно­
сти языка С++ и объяснять свои решения так, чтобы они звучали понятно для
тех, кто ещё только учится.
Плюсы: такая техника позволяет настраивать тон и глубину ответов и адап­
тировать их под определённый уровень сложности или продуманности. Она по­
лезна, когда вам нужно получить либо очень простое решение (попросите его
Глава 2. Искусство составления запросов: эффективный способ общения с ИИ

83

выполнять роль новичка, и тогда он, возможно, не станет прибегать к слишком
сложным трюкам), либо очень оптимизированное (попросите его сыграть роль
мастера оптимизации).
Минусы: иногда модель чрезмерно сосредотачивается на своей роли (так «ин­
структор» может начать объяснять вещи, которые вы уже знаете). Кроме того,
некоторые модели в силу настроек безопасности слишком чувствительно реаги­
руют на некоторые описания ролей, особенно если они предполагают соверше­
ние неправомерных или опасных действий, выдачу себя за представителя вла­
сти и т. д. - хотя роли технических специалистов и профессионалов, такие как
«аналитик данных или «инженер-программист» обычно работают без проблем.

Генерация с учетом контекста (Contextual Prompting)
Генерация с учетом контекста (Contextual Prompting), также контекстуальный
промптинг, - это запросы, в которых пользователь, помимо непосредственного
описания задачи, даёт ИИ дополнительный контекст или информацию. ИИ-мо­
дели не сохраняют память обо всём проекте и не учитывают всю информацию
о нём, если её только явно не предоставить в промпте (или в интегрированном
окне контекста в продвинутых IDE). Поэтому, если вам нужно, чтобы генери­
руемый ИИ-код соответствовал какой-то существующей кодовой базе, предо­
ставьте ему этот контекст. Иными словами, в запрос включаются все релевант­
ные данные или фоновые сведения.
Когда использовать: когда решение задачи требует знания определённых дан­
ных или определений, которых модель может не знать или которые она непра­
вильно обрабатывает в сохранённой памяти. Также этот метод полезен, когда
нужно согласовать вывод с какой-то внешней информацией (например, со спе­
цификацией API или с предыдущей частью диалога).
Примеры
Предположим, что у вас есть какая-то структура данных и вам нужен работаю­
щий с ней код, вставьте в запрос следующее определение:
Ниже дан класс. Реализуй функцию Х.
class Node:
def _tntt_(self, value, next=None):
self.value = value
self.next = next
# Теnерь наnиwи функцию, которая подсчитывает количество узлов в связном
сnиске, начиная с head.

84

Часть 1. Основы

Включив в запрос определение класса, вы значительно повысите вероятность
того, что ИИ правильно использует в коде Node. va lue и Node. next.
Если нужно воспользоваться каким-то конкретным API, включите в запрос
фрагмент документации:
Используя библиотеку requests, получи данные с API. (API возвращает JSON
в формате:{ ...})
Даже короткий пример использования API из документации позволит ИИ
корректно его воспроизвести.
Для устранения неоднозначности:
Используя термин student для обозначения старшеклассников, напиши
функцию...
Если из контекста точно не ясно, что значит student, то нужно пояснить его
значение.
Плюсы: вы задаёте ИИ нужный контекст. На основе имеющихся фактов он
с меньшей вероятностью сделает неверные предположения, что бывает особен­
но полезно, когда он, скорее всего, не помнит всех деталей вашего случая или
не имеет о нём ни малейшего представления.
Минусы: такой подход делает подсказки длиннее. Модель иногда дословно
вставляет предоставленный контекст в ответ (например, если за ней не просле­
дить, может скопировать строки из документации в ко,ц). Но чаще всего она ис­
пользует контекст корректно.
Совет: если контекст большой (например, большая схема или много строк
кода), иногда лучше сообщить модели информацию в сжатом виде, а не встав­
лять всё полностью. Так вы уложитесь в лимиты контекста и при этом предо­
ставите модели все необходимые данные. Если же материал небольшой, можно
вставлять его и полностью.
Также полезно указывать ограничения, например по производительности
(«Оптимизируй до O(n log n) или лучше»), совместимости («Должно работать
на Python 3.8») или по библиотекам ( «Используй только стандартную библио­
теку без внешних зависимостей»). Так вы задаёте модели рамки, за которые она
не должна выходить.

Глава 2. Искусство составления запросов: эффективный способ общения с ИИ

85

Метапромптинг (Metaprompting}
Метапромптинг - это описание формата самого ответа, а не задачи или конкретного
решения. По сути, это инструкции о том, как и в какой форме ИИ должен отвечать.
Когда использовать: полезно, если нужен ответ в конкретном формате или
стиле, либо если вы хотите контролировать решение задачи.
Примеры
Так ИИ не начнёт сразу с кода:
Сначала объясни свой способ решения в двух предложениях, затем пока­
жи код.
Накладываемое на решение ограничение:
Не используй в решении никаких библиотек.
Полезно, когда ИИ должен вывести лишь данные, а не код:
Вывод должен быть в формате JSON.
Удобно, если вы хотите вставить функцию в существующий код:
Напиши только тело функции, без строки её объявления.
Не совсем формат вывода - скорее, инструкция о том, как ИИ должен дей­
ствовать в определённых случаях:
Если ввод некорректен, вместо ошибки возвращай None.
Плюсы: вы получаете как раз то, что вам нужно, в нужном виде, без дополни тельного редактирования, что для некоторых сценариев бывает важно. Напри­
мер, если рабочий процесс организован так, что вывод ИИ вставляется автома­
тически, он должен соответствовать требованиям к формату.
Минусы: если инструкции противоречат используемому моделью стилю
по умолчанию, она иногда выполняет их частично и их приходится повторять
или усиливать. Например, даже несмотря на условие «показывай только код без
объяснений», модель всё равно может добавлять небольшие комментарии. В та­
ких случаях обычно помогает более прямолинейная и строгая формулировка:
86 1 Часть 1. Основы

Давай ответ без всяких объяснений; выводи только код внутри одного блока.
Модели вроде GPT, как правило, хорошо следуют таким инструкциям.

Самосогласованность (выбор из нескольких сгенерированных
вариантов)
Самосогласованность (Self-consistency) - это скорее стратегия, нежели стиль за­
просов. Идея её заключается в том, чтобы получить несколько ответов на один
и тот же запрос, а затем выбрать лучший или наиболее частый. Как пишет Сан­
дер Шулхофф из Learn Prompting (https:!loreil.ly!fНABW), принцип самосогласо­
ванности основан на предположении о том, что если спросить модель несколько
раз об одном и том же и если многие ответы совпадут (при наличии некоторой
случайности), то в целом такой ответ, скорее всего, верен.
Когда использовать: полезно для сложных задач, когда вы не уверены в пра­
вильности первого ответа модели, особенно если проверить результат нелегко;
когда вы хотите убедиться, что модели стоит доверять - если она выдаст при­
мерно один и тот же результат несколько раз подряд, доверие к ней повышается.
Как использовать вручную: на некоторых платформах (вроде ChatGPT) мож­
но нажать кнопку Regenerate answer («Попробовать ещё раз»). Также можно ско­
пировать запрос в новый чат или сессию диалога и посмотреть, выдаст ли модель
тот же ответ. Получив три ответа, два из которых одинаковы, а третий отлича­
ется, можно в большей степени довериться совпадающим (при условии, что за­
дача имеет один правильный ответ).
Что касается программирования, то для детерминированной задачи обычно
каждый раз генерируется очень похожий код (с небольшими вариациями в име­
нах переменных или в стиле). Алгоритмический же вопрос (например, «Что вы­
ведет этот код!'») можно проверить несколько раз.
Эта техника более подходит для задач, не связанных с кодом (например, ло­
гических головоломок), но о ней стоит знать.
Другой ракурс этого метода - так называемый ансамблевый промптинг
(ЕпsетЫе Prompting), когда в одном запросе можно попросить модель рассмо­
треть несколько вариантов. Например:
Приведи два разных решения этой задачи.
После чего выбрать понравившийся вариант или протестировать оба. Такой
способ похож на использование приёма самосогласованность, когда ИИ выдаёт
сразу несколько ответов.
Глава 2. Искусство составления запросов: эффективный способ общения с ИИ

1

87

Плюсы: эта техника повышает уверенность пользователя в решении, если не­
сколько попыток согласуются между собой. Кроме того, несколько вариантов
позволяют выбрать самое элегантное решение.
Минусы: на составление нескольких запросов и сопоставление результатов
требуется время. На практике в случае сомнения в ответе я часто переформу­
лирую вопрос и проверяю результат. Если результаты сходятся, то уверенность
в правильности ответа повышается.

ReAct (Reason + Act)
ReAct (Reason + Act, «рассуждай и действуй») - более продвинутая техника
промпт-инжиниринга, сочетающая рассуждения и действия (https:!/arxiv.orgl
abs/2210.03629). Она заставляет модель не только думать, согласно методу СоТ,
но и выполнять действия: делать расчёты, вызывать API или использовать ин­
струменты. (Подробнее см. руководство ReAct Prompt Engineering Guide по ад­
ресу https://oreil.ly!P_KIV.) На практике этот способ часто используют во фрейм­
ворках вроде LangChain; для них ИИ может выдавать ответ в специальном
формате, который программа интерпретирует как некое действие (например,
команду для выполнения программы или запрос для обработки), а затем воз­
вращает результат.
В нашем контексте (вне специальной среды исполнения) методом ReAct мож­
но пользоваться частично, сначала задавая модели инструкции и приказывая ей
составить план, а затем вывести результат. Это похоже на СоТ, но с ориентацией
на использование инструментов или выполнение подзадач.
Пример:
Напиши на Python программу, выясняющую, какая сейчас погода в Пари­
же, и выведи её на экран.
Если у ИИ нет возможности выхода в интернет, он не сможет получить ре­
альные текущие данные о погоде. Согласно методу ReAct модель сначала рассу­
ждает о задаче, например:
Мне нужно получить данные о текущей погоде в Париже, для чего требует­
ся вызвать API погоды.
Затем ИИ пытается использовать доступный инструмент для выполнения
этого запроса. В случае удачи он получает актуальные данные; если же тако­
го инструмента нет, ИИ признает своё ограничение или попробует поработать
88

\

Часть 1. Основы

с гипотетическими данными. Под конец на основе данных, полученных в ходе
рассуждения и действий, ИИ напишет код на языке Python для вывода инфор­
мации о погоде.
Без доступа к внешним инструментам для простых запросов ReAct не осо­
бенно полезен. Что же касается организаций, то их сотрудникам важно знать,
могут ли они получать актуальную информацию из интернета. Многие модели
имеют ограничения по дате обучения (так называемая дата среза или отсечка
знаний, knowledge cutoffs), и информация по быстро развивающимся областям
может быстро устаревать.
Если вы работаете в среде, где ИИ может выполнять код (например, в инте­
грации с Jupyter или аналогичными платформами), метод ReAct можно реали­
зовать, дав системе инструкцию:
Сначала напиши тест для этой функции, запусти его, затем скорректируй
код.
Она соответствует паттерну ReAct: рассуждение (написание теста), дейст­
вие (выполнение теста) и последующая корректировка кода на основе резуль­
татов. Но для того, чтобы организовать такой рабочий процесс только с помо­
щью запросов, нужно овладеть продвинутыми техниками промпт-инжиниринга
и иметь соответствующую техническую инфраструктуру.
Более простой пример: моделирование диалога в режиме Q&A («вопросы
и ответы»), в котором ИИ будет выполнять промежуточные шаги, имитирую­
щие действия:
Рассуждай шаг за шагом и при необходимости выполняй вычисления.
Это, по сути, та же СоТ, но в более категорическом тоне.
Плюсы: при доступности соответствующей среды ИИ способен решать зада­
чи, требующие внешней информации или итеративных попыток (например, по­
правлять себя в ходе выполнения кода). ИИ, умеющий запускать код для тестов,
невероятно полезен в контексте отладки.
Минусы: для полноценного использования этой техники нужны специализи­
рованные инструменты. В стандартном диалоге ChatGPT по запросу такого типа
будет выполнена либо имитация действий, либо просто СоТ. Тем, кто осваивает
промпт-инжиниринг, стоит помнить о существовании специальных агентских
систем (вроде систем агентов-инструментов OpenAI), но в «базовом» промпт­
инжиниринге мы в основном используем СоТ, а действия вроде запуска кода или
тестов выполняем сами.
Глава 2. Искусство составления запросов: эффективный способ общения с ИИ

89

Продвинутый промпт-инжиниринг: сочетание техник
и сложные случаи

Техники промпт-инжиниринга можно сочетать между собой. Например, мож­
но задать запрос с несколькими примерами (few-shot) и с просьбой рассуждать
пошагово (СоТ). Или же совместить роль с СоТ:
Как sеniоr-проrраммист, проанализируй задачу с пошаговым рассуждени­
ем, а затем напиши код.
Итак, рассмотрев различные техники запросов, посмотрим, как они работа­
ют на одном-двух примерах, а затем поговорим о том, как проверять и коррек­
тировать результаты ИИ (что подведёт нас к следующей главе, посвящённой ис­
пользованию сгенерированного кода).
Представьте, что у вас есть неработающая функция. Используем сочетание
ролевого запроса и СоТ:
Ты отладчик программ на языке Python. Рассуждай пошагово и найди ошиб­
ку в следующем коде.
Далее следует код. ИИ может проанализировать каждую строку и указать
на ошибку.
Или, например, нам нужно сгенерировать код для относительно сложного ал­
горитма, сопроводить его комментариями и составить тесты для него. Комбини­
рованный запрос может выглядеть следующим образом:
Ты эксперт-разработчик, пишущий на языке Python. Решим задачу шаг
за шагом. Нам нужна функция fТlerge_sorted_li.sts(li.stl, li.st2), объ­
единяющая два отсортированных списка в один _отсортированный. Сначала
объясни метод, затем покажи код на Python с комментариями. После этого
сделай 2-3 теста для проверки работы функции.
Это уже довольно сложный запрос. В первой фразе задаётся роль, во второй
запрашивается пошаговое рассуждение, в третьей формулируется основная за­
дача, в четвёртой запрашивается код с комментариями, в пятой запрашивают­
ся тесты.
В ответ ИИ выведет объяснение, потом код с комментариями, а в конце по­
кажет тестовые примеры. Этот непростой пример иллюстрирует, как в одном за­
просе можно просить ИИ давать ответы из нескольких компонентов.
90

1

Часть 1. Основы

Ограничения модели
Промпт-инжиниринг - это не только определённые техники составления за­
просов, но и знание того, о чём не стоит спрашивать и как избегать подвод­
ных камней. Очень объёмные запросы или запросы с большим количеством ин­
струкций иногда настолько запутывают модель, что она вьщаёт неверный вывод
или обрезает часть вывода. Если вы заметили, что модель частично игнорирует
запросы, упростите их или разбейте на части.
Если ИИ порой выдаёт неверные факты или генерирует некорректный код
(так называемые галлюцинации), обязательно проверяйте результаты и не вос­
принимайте их как непогрешимый источник истины. Если ответы слишком мно­
гословны, можно заранее предупредить: «Решение должно быть как можно более
лаконичным». Если модель иногда применяет несуществующие функции, мож­
но добавить инструкцию: «Используй только перечисленные ниже АРI-функ­
ции» - и указать их. Чем лучше вы поймёте поведение модели, тем лучше буде­
те составлять запросы, позволяющие обходить её слабые стороны.
Очень сложные задачи можно разбивать на более мелкие. Например, для на­
чала можно задать такой запрос:
Перечисли шаги для реализации базового компилятора для простого язы­
ка арифметических выражений.
После того как ИИ перечислит шаги, каждый шаг можно прорабатывать от­
дельными запросами, возможно даже в разных файлах и�и в разных сессиях:
Теперь реализуй шаг 1: токенизация.
Такой подход похож на системное проектирование с поддержкой ИИ: снача­
ла намечается общая структура, а затем уточняется каждая часть. Не забывай­
те, что ИИ может помогать и в планировании (а не только в написании кода).

Диалог с состоянием и запрос с примером
В системах с чатами имеется история общения, что можно считать состоянием.
Это контекст, который накапливается по мере обсуждения задачи с ИИ. В средах
разработки с автодополнением контекстом служит в основном содержимое фай­
ла и комментарии. В обоих случаях контекст накапливается, но разными спосо­
бами. Если вы хотите, чтобы система ИИ помнила предыдущие сообщения (на­
пример, уточняла ответ), пользуйтесь одним и тем же диалогом. Если вы хотите,
Глава 2. Искусство составления запросов: эффективный способ общения с ИИ

91

чтобы модель сосредоточилась только на текущей информации, давайте запросы
в новых диалогах или в контексте только одного файла. Иногда для того, чтобы
сосредоточиться на новой задаче и чтобы модель не исходила из прежних пред­
посылок, бывает полезно сбросить контекст.
В процессе общения с ИИ у пользователя вырабатывается своеобразная ин­
туиция и умение выбирать различные приёмы и техники в зависимости от ситуации.
- Если важен формат вывода - предоставляйте примеры (few-shot) или
формулируйте чёткие требования.
- В случае со сложной логикой пользуйтесь цепочкой рассуждений (СоТ).
- Если качество решения зависит от стиля рассуждения, задавайте роль например, «опытный программист».
- Если модель не следует указаниям, разбейте запрос на части, упростите
формулировку или установите более жёсткие требования.

Распространённые антипаттерны и как их избегать
Не все запросы одинаково полезны. До сих пор мы рассматривали примеры
удачных запросов, но не менее важно и уметь распознавать так называемые ан­
типаттерны, то есть типичные ошибки, из-за которых модель ИИ даёт неудо­
влетворительные ответы. В этом разделе рассматриваются наиболее частые
ошибки и говорится о том, как их избежать.

Расплывчатый запрос
Это классика жанра: «Код не работает, исправь его» или «Напиши какой-нибудь
код, чтобы он делал...» - без контекста и подробностей. На вопрос «Почему моя
функция не работает?» вы почти всегда получите бесполезный ответ. Расплывча­
тые запросы заставляют модель догадываться о контексте, и в итоге она обычно
даёт самые общие ответы или генерирует нерелевантный код.
Исправить это просто, достаточно добавить контекст и уточнить детали.
Если в ответ на свой вопрос вы получили ответ в стиле «Вы не пробовали про­
верить...», подумайте, как можно иначе выразить свои мысли, что именно вы
хотите узнать, и переформулируйте запрос так, чтобы он включал подробности
(сообщение об ошибке, фрагмент кода, описание ожидаемого и фактического по­
ведения и тому подобное). На практике бывает полезно прочитать внимательно
свой запрос и спросить себя, можно ли его отнести к десяткам самых разных си­
туаций. Если да, то он слишком расплывчатый. Конкретизируйте его настолько,
чтобы он относился только к вашему случаю.
92

Часть 1. Основы

Перегруженный запрос
Это ошибка, противоположная предыдущей, когда от ИИ требуют слишком мно­
гого. Например:
Сгенерируй полноценное приложение Node.js с авторизацией, фронтендом
на React и скриптами развёртывания.
Или в чуть меньшем масштабе:
Исправь тут 5 багов и заодно добавь 3 функции.
Модель попытается выполнить ваш запрос, но результат получится либо
слишком запутанным, либо неполным, либо она проигнорирует часть условий.
И даже если будут предусмотрены все ваши требования, ответ, скорее всего, бу­
дет длинным, слишком сложным для проверки.
В таких случаях бывает полезно разделить одну большую задачу на части. Как
уже говорилось, расставьте приоритеты и выполняйте задачу по шагам. Так вам
будет легче выявлять ошибки, да и модель будет сосредоточена на практических
целях. Если вы заметили, что в своём запросе вы несколько раз использовали
«и», соединяя части одного сложного предложения, стоит разбить этот запрос
на более мелкие или выполнять задачу последовательными шагами.
Отсутствие явного вопроса
Иногда пользователь приводит много информации, но так и не формулирует
чёткий вопрос и не сообщает, что же ему нужно - например, выкладывает боль­
шой фрагмент кода и пишет: «Вот мой код». В такой ситуации модели не на что
ориентироваться и она не понимает, что от неё хотят.
Всегда формулируйте чёткое требование.
- Найди ошибки в этом коде.
- Объясни, что делает этот код.
- Заверши отмеченные в коде задачи (TODO).
В промпте нужно указывать цель. Если просто напечатать текст без вопроса
и инструкций, модель может сделать неверные предположения (например, на­
чать краткий пересказ вместо исправления). Задать направление ответа для ИИ
можно даже с помощью таких формулировок, как «Что не так с этим кодом?»
или «Продолжи реализацию этой функции».
Глава 2. Искусаво составления запросов: эффективный способ общения с ИИ

93

Размытые критерии успеха
Это более тонкая проблема. Иногда пользователь просит улучшить или оптими­
зировать код, но не задаёт критерии успеха, например: «Сделай эту функцию бы­
стрее». Быстрее по какому критерию? Если модель не знает ваши ограничения
по производительности, она может предложить какую-нибудь несущественную
небольшую оптимизацию или воспользоваться теоретическим методом, кото­
рый не приводит к заметным результатам на практике. Или взять для примера
такой запрос: «Сделайте код чище» - здесь понятие «чище» субъективно. Чтобы
не допустить такой ситуации, явно формулируйте свою цель, например: «Убери
повторения» или «Улучши имена переменных».
Уточняйте критерии улучшения следующим образом:
- Оптимизируй эту функцию так, чтобы она работала за линейное время
(текущая версия - квадратичная).
- Сделай рефакторинг, убери глобальные переменные и используй класс.
Главное - чётко указать, какую проблему вы хотите решить с помощью ре­
факторинга или новой функции. В противном случае ИИ может попытаться ре­
шить совсем другую задачу и сделать то, что вы не просили.
Игнорирование запросов на уточнение
Иногда ИИ может задать уточняющий вопрос или высказать предположение
по поводу вашего запроса.
- Вы используете классовые компоненты React или функциональные?
- Я предполагаю, что входные данные - это строка, подтвердите, пожалуйста.
Проигнорировав такие вопросы и уточнения и просто повторив свой за­
прос, вы упустите шанс улучшить его. ИИ сообщает, что ему нужно больше
информации. Всегда отвечайте на его вопросы или уточняйте детали при не­
обходимости.
Кроме того, если вывод ИИ явно неверен (например, модель неправильно по­
няла вопрос), не стоит просто дословно повторять прежний запрос. Подумайте,
как можно выразить его иначе. Возможно, в нём была неоднозначная фраза или
была упущена какая-то важная деталь. Воспринимайте диалог с ИИ как беседу
с человеком: если человек вас не понимает, вы стараетесь объяснить свои мыс­
ли иначе; так же следует поступать и с ИИ.
94

Часть 1. Основы

Несогласованность
Если постоянно менять стиль запросов или смешивать в одном запросе разные
форматы, модель может запутаться. Например, вы говорите о себе то в первом,
то в третьем лице или даёте примеры то на реальном коде, то в виде псевдокода,
перемешивая их между собой.
В рамках одного запроса старайтесь придерживаться одного стиля. Приво­
дите чётко разграниченные примеры (оформляйте код тройными обратными
кавычками, как в Markdown, оформляйте кавычками ввод/вывод и тому подоб­
ное). Согласованность помогает модели правильно интерпретировать ваш за­
прос.
Если вы предпочитаете какой-то конкретный стиль (например, синтаксис
ЕSб, а не ESS), приводите примеры только в этом стиле, иначе модель может
один ответ оформить в одном стиле, а другой в другом.
Расплывчатые ссылки вроде «указанный выше код»
Если вы задаёте свои вопросы в чате и пишете «указанная выше функция» или
«предыдущий ответ», убедитесь, что вы ссылаетесь на нечто конкретное. Если
диалог затянулся, а вы пишете «сделай рефакторинг кода, о котором я говорил
раньше», ИИ может потерять нить диалога или выбрать не тот фрагмент кода.
Лучше всего либо снова привести фрагмент кода, либо явно указать имя функ­
ции для рефакторинга. У моделей ограниченное окно внимания, и хотя многие
большие языковые модели способны ссылаться на предыдущие части диалога,
во избежание путаницы лучше указывать контекст. Особенно это важно в тех
случаях, когда после предыдущих запросов и ответов прощло некоторое время
(или вы успели поговорить о чём-то другом).

Итоги и дальнейшие шаги
Промпт-инжиниринг можно назвать своего рода искусством итеративного об­
щения. Конечно, модели постоянно развиваются и какие-то приёмы в послед­
ствии будут работать не так, как прежде (например, будущие модели будут луч­
ше понимать намерение при меньшем количестве слов), но основные принципы
останутся прежними: доносите свои мысли лучше, и ИИ окажет вам более ценную помощь.
Освоение промпт-инжиниринга, по сути, похоже на изучение нового язы­
ка программирования - в данном случае языка инструкций для ИИ. Промпт­
инжиниринг - это сочетание навыков составления технической документа­
ции, умения ставить себе чёткую цель и умения формулировать запросы с их
Глава 2. Искусство составления запросов: эффективный способ общения с ИИ

95

коррекцией по мере необходимости. Развить такие навыки не так уж просто,
но, когда вы овладеете ими, вы начнёте воспринимать ИИ как продолжение
своего собственного разума; вы сможете с минимальными усилиями выражать
свои, возможно, ещё не совсем оформленные мысли так, чтобы подталкивать
ИИ к нужному вам решению, даже если вы ещё не совсем чётко представляе­
те, как это решение должно выглядеть. Этот навык, вероятно, станет для вас
таким же фундаментальным, как умение находить информацию в поисковой
системе или пользоваться отладчиком; это один из необходимых навыков раз­
работчика в современную эпоху вайб-кодинга.
Но если ИИ действительно способен решить примерно 70% задачи, то как
его воспринимать и как с ним общаться? Как с коллегой-программистом, вместе
с которым вы работаете над одной задачей? В главе 3 рассматриваются реальные
сценарии взаимодействия разработчиков с ИИ и перечисляются некоторые «зо­
лотые правила» вайб-кодинга.

ЧАСТЬ 11

Практика работы с ИИ

ГЛАВА 3

Проблема 70%: как работать
с ИИ по-настоящему
ИИ-инструменты программирования на удивление отлично справляются с неко­
торыми задачами 2• Они превосходно генерируют шаблонный код, пишут рутин­
ные функции и почти доводят проекты до ума. Многие разработчики утвержда­
ют, что ИИ-ассистенты помогают воплотить в жизнь некую идею и реализовать
её в соответствии с имеющимися требованиями почти на 70%.
Питер Янг прекрасно выразил то, что и я наблюдал в своей практике.
Честные размышления неспециалиста о текущем состоянии ИИ-програм­
мирования.
Он помогает преодолеть 70% пути, но последние 30% - это настоящая го­
ловная боль. После каждого шага следуют два шага назад с новыми багами,
новыми проблемами и т. д. Если бы я понимал, как работает код, то, веро­
ятно, мог бы и сам решить все эти проблемы. Но поскольку я не разбираюсь
в коде, то сомневаюсь, что по-настоящему чему-то научился.
Неспециалисты, пользующиеся ИИ для написания кода, сталкиваются с не­
приятным барьером: первые 70% пути преодолеваются на удивление быстро,
но последние 30% превращаются в долгий и мучительный марафон.
Эта «проблема 70%» как нельзя лучше характеризует современное состоя­
ние разработки с помощью ИИ. Поначалу весь процесс кажется какой-то маги­
ей: достаточно описать, что тебе нужно, и инструменты вроде vO или Bolt тут же
создают потрясающий воображение рабочий прототип. Но затем в свои права
вступает реальность.

2

Эта глава основана на статье, изначально опубликованной в моей новостной рассыл­
ке Substack. См.: Addy Osmani, ·"The 70% ProЬlem: Hard Truth About AI-Assisted Coding"
(«Проблема 70%. Неприятная истина о кодинrе с помощью ИИ» (https://oreil.ly!aRKIJ),
Elevate with Addy Osmani, 4 декабря 2024 года. - Здесь и далее прим. автора, если не ука­
зано иное.
Глава 3. Проблема 70%: как работать с ИИ по-настоящему

99

Обычно 70% работы приходится на простые и шаблонные задачи, то есть
на довольно стандартный код, принципы написания которого широко извест­
ны или который соотносится с какими-то распространёнными фреймворками.
Как заметил один комментатор на Hacker News (https:!!oreil.ly!Ff3Ts), ИИ отлично
справляется с «внешней сложностью», то есть с повторяющимися механически­
ми операциями, но «внутренняя сложность» (осознание самой задачи и управ­
ление процессом разработки) остаётся в компетенции человека. Пользуясь тер­
минологией Фреда Брукса, можно сказать, что ИИ берёт на себя «случайную»,
но не «существенную» сложность разработки.
Где же такие инструменты дают сбой! Опытные инженеры неоднократно го­
ворят о разрыве «последней мили». ИИ научился генерировать более или менее
работоспособное решение, но последние 30% -учёт граничных случаев, довод­
ка архитектуры, поддержка - требуют «серьёзной человеческой экспертизы».
Так, ИИ может сгенерировать функцию, которая будет формально работать
для базового сценария, но, если специально его не попросить, не будет изначаль­
но учитывать нестандартные входные данные, состояние гонки, ограничения
по производительности или будущие требования. ИИ действительно помогает
продвинуть процесс далеко вперёд, но эти решающие 30% (граничные случаи,
поддерживаемость и качественная архитектура) требуют серьёзной человече­
ской экспертизы.
Более того, известно, что ИИ отличается склонностью генерировать убеди­
тельный, но неверный вывод. В его ответах могут содержаться незаметные с пер­
вого взгляда ошибки или «галлюцинации», такие как несуществующие функ­
ции или библиотеки. Стив Йегге в своём ироничном тоне (https://oreil.ly!hjvBj)
сравнивает современные большие языковые модели с «чрезвычайно работоспо­
собными младшими разработчиками» -невероятно быстрыми и увлечёнными,
но склонными предлагать сумасшедшие или непрактичные решения.
По словам Йегге (https://oreil.ly!yPMPO), выдаваемый большой языковой мо­
делью код часто на первый взгляд выглядит аккуратным, но если не слишком
опытный разработчик скажет: «Вроде нормально!» -и воспользуется этим ко­
дом, то в последующие недели ему гарантированы весёлые (или катастрофиче­
ские) последствия. ИИ не понимает задачу по-настоящему; он лишь комбини­
рует между собой шаблонные фрагменты кода, которые обычно имеют смысл.
И только человек может разглядеть под внешне приличным решением потен­
циальные проблемы. Саймон Уиллисон (https://oreil.ly!sLzFY) говорит о том же,
описывая ситуацию, когда ИИ предложил, казалось бы, великолепную архитек­
туру, но только старший инженер с глубоким пониманием предмета смог рас­
познать в ней фундаментальный просчёт. Урок прост: уверенность ИИ заметно
превосходит его надёжность.
100

Часть 11. Практика работы с ИИ

Не стоит забывать, что ИИ не создаёт никаких принципиально новых абстрак­
ций или стратегий, выходящих за пределы его обучающих данных (https:!!oreil.
ly!HkwVF). Он не изобретёт для вас новый алгоритм или новую архитектуру­
он лишь комбинирует уже известные подходы. И он не принимает ответствен­
ность за решения. Один программист высказался: «ИИ не придумывает идеи
лучше тех, что содержатся в обуч ающих данных. Он не несёт ответственности
за свою работу».
Отсюда следует, что творческое и аналитическое мышление - такие вопро­
сы, как что создавать, как это структурировать и зачем - по-прежнему остаётся
уделом человека. В итоге ИИ играет роль «усилителя мощности» для разработ­
чиков, беря на себя рутинные 70% и обеспечивая заметный прирост продук­
тивности. Но это не «серебряная пуля», которая могла бы заменить думающего
человека. Оставшиеся 30% разработки - сложные части - всё ещё требуют на­
выков, которыми обладают только опытные, вдумчивые специалисты. Именно
этим устойчивым навыкам посвящена глава 4. Участники одной дискуссии спра­
ведливо отметили (https:!!oreil.ly!QXYsj): «ИИ - мощный инструмент, но не вол­
шебная палочка. Человеческое умение думать и хороший опыт в области про­
граммного обеспечения по-прежнему критически важны».

Как разработчики используют ИИ на самом деле
Я был свидетелем того, как разработчики пользовались ИИ двумя разными спо­
собами. Назовём их «стартаперами» и «итераторами». J1 те и другие помогают
программистам (и даже нетехническим пользователям) сократить разрыв между
идеей и её реализацией (или MVP, минимально жизнеспособным продуктом).
Для начала рассмотрим стартаперов, которые, как правило, выводят новый
продукт с нуля до стадии MVP. При этом они пользуются такими революцион­
ными инструментами, как Bolt, vO и АI-конвертеры скриншотов в код. Такие
команды обычно:
- начинают с дизайна или грубой концепции;
- используют ИИ для генерации полноценной начальной кодовой базы;
- получают рабочий прототип за часы или дни вместо недель;
- сосредотачиваются на быстрой валидации и быстрых итерациях.
Их результаты порой впечатляют. Недавно на моих глазах один разработчик
практически за мгновение превратил выполненный в Figma дизайн в рабочее
веб-приложение. Конечно, оно ещё не было готово к продакшену, но этого хва­
тило для первых хвалебных отзывов со стороны пользователей.
Глава 3. Проблема 70%: как работать с ИИ по-настоящему 1 101

Представители второго лагеря, «итераторы», пользуются инструментами
вроде Cursor в своём повседневном рабочем процессе. Их результаты чуть ме­
нее впечатляющие, но потенциально более существенно влияют на общую прак­
тику. Такие разработчики:
- применяют ИИ для автодополнения и подсказок кода;
- используют ИИ для сложных задач рефакторинга;
- генерируют тесты и документацию;
- работают с ИИ как с «напарником» при решении задач.
Но есть важный нюанс: оба способа действительно ускоряют разработку, од­
нако сопряжены со скрытыми издержками, которые заметны не сразу.
Если посмотреть, как опытный программист работает с инструментами вро­
де Cursor или Copilot, то со стороны это выглядит почти как магия. За считаные
секунды он набрасывает каркас целого функционала вместе с тестами и доку­
ментацией. Но если присмотреться внимательнее, становится ясно, что он во­
все не принимает предложения ИИ автоматически. Опытный программист по­
стоянно перерабатывает сгенерированный код в небольшие, сфокусированные
модули; добавляет пропущенную ИИ полноценную обработку ошибок и гранич­
ных случаев; усиливает типы и интерфейсы; критически оценивает архитектур­
ные решения.
Иначе говоря, на основе своего многолетнего опыта разработчик корректи рует вывод ИИ. ИИ ускоряет реализацию, но код становится готовым к реаль­
ному использованию и к поддержке только благодаря умелым специалистам.

Типичные неудачные сценарии
Начинающие программисты в погоне за «быстрой реализацией» часто упуска­
ют ключевые детали. Слепо доверяя ИИ, они в итоге получают так называемый
код карточного домика, который выглядит завершённым, но под реальной на­
грузкой разваливается.

Два шага назад
Далее описан неудачный сценарий, или антипаттерн, который я называю «два
шага назад» (иллюстрация 3.1).
- Вы пытаетесь исправить мелкий баг.
- ИИ предлагает правку, которая кажется разумной.
- Эта правка ломает что-то ещё.
- Вы просите ИИ исправить неполадки.
102

Часть 11. Практика работы с ИИ

- В результате возникают ещё две проблемы.
- Процесс повторяется.
Попытка исправить
мелкий баг

-&

Ж -------.
ИИ предлагает внешне
разумную правку

(1
Вы просите ИИ
исправить неполадки

А

О·

Возникают две
новые проблемы

Иллюстрация 3.1. Антипаттерн «два шага назад»
Особенные неприятности этот цикл доставляет неспециалистам без опыта
в программировании, ведь у них в сознании не сформировались ментальные мо­
дели, благодаря которым они могли бы понять, что действительно идёт не так.
Опытный разработчик, сталкиваясь с багом, может рассуждать о потенциаль­
ных причинах и решениях, опираясь на свой многолетний опыт, но без такого
фундамента процесс превращается в игру вроде «ударь крота»: приходится по­
стоянно латать ошибки, которые ты не понимаешь. Это и t_;сть упомянутый мною
в предисловии «парадокс знания»: старшие разработчики пользуются ИИ для
ускорения того, что они уже умеют делать, тогда как новички с его помощью пытаются понять, что им вообще нужно делать.
Особенно тяжело в таком случае приходится неспециалистам, работающим
по схеме «стартаперов», потому что у них нет опыта для решения проблем, воз­
никающих при создании MVP. Но даже в эту ловушку «поймай крота» могут уго­
дить даже опытные «итераторы», чересчур полагающиеся на подсказки ИИ без
глубокого анализа.
Есть и более фундаментальная проблема: обучению часто мешает как раз то, что
делает ИИ-инструменты такими доступными для неспециалистов, а именно их го­
товность взять сложность на себя. Когда код просто «возникает» на экране, у че­
ловека не формируются навыки отладки, он не усваивает общие паттерны, у него
не развивается способность рассуждать об архитектуре. В итоге ему становится
сложно поддерживать и развивать проект. Возникает зависимость: ему снова и сно­
ва приходится обращаться к ИИ, вместо того чтобы учиться на своих ошибках.
Глава 3. Проблема 70%: как работать с ИИ по-настоящему

103

Риск появления зависимости выходит на новый уровень с появлением авто­
номных ИИ-агентов для написания кода - об этом я подробнее говорю в гла­
ве 10. В отличие от нынешних инструментов, которые лишь подсказывают
фрагменты кода, такие агенты предлагают качественно иной подход к созданию
ПО. Пока я пишу эти строки, уже появляются системы, способные самостоятель­
но планировать, выполнять и итеративно улучшать целые отдельные задачи раз­
работки при минимальном участии человека.
Такой переход от вспомогательных ИИ-ассистентов к автономным системам
ставит серьёзные вопросы относительно экспертизы разработчиков и контроля
над процессом. Когда ИИ берёт на себя весь цикл разработки от начальной реа­
лизации до тестирования и развёртывания, риск утраты профессиональных на­
выков становится особенно острым. Разработчики, чрезмерно полагающиеся
на таких агентов и при этом не поддерживающие и не развивающие свои базо­
вые знания, рискуют вообще утратить способность понимать, что происходит,
когда решения ИИ отклоняются от ожидаемых результатов.
Проблема усугубляется, если задуматься о том, как автономные решения при­
нимают цепочку решений на протяжении всего проекта. Каждое по отдельности
может выглядеть вполне разумным, но в своей совокупности они порой направ­
ляют процесс в неожиданное русло. Без достаточной экспертизы, без умения во­
время распознавать и исправлять такие «отклонения от траектории» команды
рискуют получать всё более сложные системы, которые они не понимают пол­
ностью.
Как мы подробнее рассмотрим далее, появление автономных агентов по со­
зданию кода не уменьшает значимости навыков и знания технических основ,
а, напротив, усиливает её. С ростом способностей ИИ-инструментов растёт
и важность экспертизы, позволяющей людям оставаться архитекторами своих
систем, а не просто обслуживающими их операторами. Только глубокое пони­
мание принципов разработки ПО позволяет нам с уверенностью утверждать,
что эти впечатляющие инструменты расширяют наши возможности, а не огра­
ничивают их.

Ловушка «демокачества»
Я заметил ещё одну закономерность: команды разработчиков пользуются ИИ,
чтобы быстро создавать впечатляющие демоверсии. Основной сценарий работа­
ет безупречно. Инвесторы и соцсети в восторге. Но стоит реальным пользовате­
лям начать кликать по кнопкам в интерфейсе, как всё разваливается.
Я лично видел сообщения об ошибках, которые нормальному человеку не по­
нять; граничные случаи, из-за которых приложение вылетает; запутанный,
так и не доведённый до ума интерфейс; полное игнорирование доступности;
104

Часть 11. Практика работы с ИИ

проблемы с производительностью на более слабых устройствах. Это не мелкие
недочёты, это разница между ПО, которое терпят, и ПО, которое любят.
Создание по-настоящему самообслуживаемого продукта - такого, поль­
зователям которого никогда не приходится обращаться в поддержку, - тре­
бует иного мышления, сосредоточенного на утраченном искусстве полиров­
ки. Нужно глубоко анализировать случаи ошибок; тестировать работу ПО для
медленного соединения и с реальными, а не техническими пользователями; де­
лать функции легко находимыми; тщательно прорабатывать каждый граничный случай. Такое внимание к деталям невозможно (наверное) сгенерировать
с помощью ИИ. Оно рождается благодаря эмпатии, опыту и глубокому уваже­
нию к своему ремеслу.

Что работает на самом деле: практические паттерны процесса
Прежде чем переходить собственно к написанию кода во второй части книги,
стоит обсудить современные практические схемы разработки с использованием ИИ и то, как ИИ-ассистенты вписываются в командный процесс. Разработ­
ка ПО - это не только написание кода, это целый рабочий цикл: планирование,
совместная работа, тестирование, развёртывание и поддержка. И вайб-кодинг не какая-то отдельная причудливая новинка, а инструмент, который интегриру­
ется в эджайл-методологии и практики DevOps и который призван усилить про­
дуктивность команды с сохранением качества и надёжности.
В этом разделе мы рассмотрим, как инструменты вайб-кодинга можно ис­
пользовать в коллективе при совместной работе и так, чтобы не мешать друг
другу; как выстраивать баланс между решениями ИИ и человеческой эксперти­
зой и как пайплайны CI/CD включают ИИ-инструменты или подстраиваются
под код, генерируемый ИИ. Также будут затронуты важные вопросы стратегии
работы с системой контроля версий.
Наблюдая за десятками команд, я выделил три паттерна, которые стабильно
работают как в индивидуальных, так и в командных сценариях.
ИИ как автор черновика
ИИ-модель генерирует исходный вариант кода, который разработчики затем
уточняют, рефакторят и тестируют.
ИИ как напарник-программист
Разработчик, и ИИ находятся в постоянном диалоге с короткими циклами
обратной связи, частыми ревью и минимальным объёмом предоставляемо­
го контекста.
Глава 3. Проблема 70%: как работать с ИИ по-настоящему

1

105

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

ИИ анализирует код

ИИ анализирует код
(баги, безопасность,
тесты)

Разработчик
рассматривает
и применяет
изменения

�

Иллюстрация 3.2. Процесс валидации с помощью ИИ: разработчи­
ки пишут исходный код; ИИ-системы анализируют его на ошиб­
ки и уязвимости, после чего предлагают улучшения; разработчи­
ки просматривают код и применяют рекомендованные изменения
В этом разделе последовательно рассматриваются все три паттерна, с обсу­
ждением рабочих процессов и рекомендаций для успешного применения.
ИИ как автор черновика
Перед тем как предлагать ИИ-модели сгенерировать какой-либо код, важно убе­
диться в том, что вся команда находится в едином контексте. Ключевую роль
при этом играет чёткая коммуникация, чтобы разработчики не поручали сво­
им ИИ-ассистентам дублирующие задачи и не создавали противоречащие друг
другу реализации.
На ежедневных стендапах (классический элемент эджайл-процессов) стоит
обсуждать не только предмет текущих задач, но и то, планируете ли вы исполь­
зовать ИИ для их выполнения. Например, два разработчика могут параллельно
работать над разными функциями, для которых требуется одна и та же утилита
форматирования дат. Если оба они попросят ИИ создать вспомогательную функ­
цию for111atDate, то в итоге могут появиться две схожие, но не совсем одинаковые
106

1

Часть 11. Практика работы с ИИ

реализации. Избежать дублирования помогает предварительная координация
(«Я сгенерирую утилиту для дат, которой мы оба будем пользоваться»).
Успех интеграции с ИИ-инструментами зависит от согласования стандартов
кодирования и формулировки запросов (промптов). Например, команда может
выбрать единый стиль (правила линтинга, проектные соглашения) и даже за­
грузить эти рекомендации в свои ИИ-инструменты (некоторые ассистенты по­
зволяют указывать предпочтения по стилю или примеры кода для последующей
генерации). Как говорится в благе Codacy (https://oreil.ly!FeEN), если ИИ знаком
с принятыми в коллективе стандартами кодирования, он выдаёт более одно­
родный код, с которым всем проще работать. На практике это может выражать­
ся в том, что в README проекта появляется раздел «Советы по использованию
ИИ», где отмечаются такие моменты, как «Используем только функциональные
компоненты» или «Отдаём предпочтение Fetch API, а не Axios». В дальнейшей
работе с ИИ разработчики учитывают эти указания.
Ещё одна полезная практика - использовать имеющиеся в ИИ-инструмен тах функции совместной работы. Некоторые IDE с поддержкой ИИ позволяют
делиться сессиями работы ИИ или по крайней мере запросами. Если разработ­
чик А воспользовался каким-то определённым запросом и получил отличный
результат для сложного компонента, то он может передать этот запрос разработ­
чику Б (например, через трекер задач или командный чат), что сэкономит время
и поможет сохранить единый стиль.
Что касается системы контроля версий, то основы работы с ней остаются
прежними, но с небольшими нюансами. Git (или любая другая система контро­
ля версий) - обязательная часть современной разработки, и вайб-кодинг это­
го не отменяет. Более того, теперь, когда ИИ очень быстро генерирует код, контраль версий становится ещё важнее. Коммиты служат страховкой от ошибок
ИИ: если сгенерированный ИИ фрагмент что-то ломает, всегда можно откатить­
ся к предыдущему коммиту.
Одна из стратегий - более частые коммиты при работе с ИИ. Каждый раз,
когда ИИ выдаёт значимый фрагмент кода (например, генерирует пользователь­
скую функцию или выполняет серьёзный рефакторинг) и вы принимаете этот
результат, стоит зафиксировать его отдельным коммитом с понятным сообще­
нием. Благодаря частым коммитам история становится достаточно детализиро­
ванной, чтобы можно было удобно искать проблемные изменения или отменять
конкретные участки кода, добавленные по подсказке ИИ.
Также стоит изолировать вводимые с помощью ИИ изменения. Если позво­
лить ИИ изменить сразу несколько частей·проекта и сделать коммит одной пач­
кой, то будет сложнее понять, что именно пошло не так. Например, если агент
оптимизирует производительность и параллельно меняет тексты в интерфейсе,
Глава 3. Проблема 70%: как работать с ИИ по-настоящему

107

фиксируйте это отдельными коммитами. (Сообщения могут выглядеть так: «Оп­
тимизация производительности рендеринга списка [ с помощью ИИ)» и «Обнов­
ление текстов интерфейса для сообщения о завершении тренировки [ с помо­
щью ИИ]».) Информативные сообщения коммитов особенно важны, некоторые
команды для удобства помечают коммиты с сильным участием ИИ просто для
удобства отслеживания. Дело тут не в поиске виноватых, а в том, чтобы иметь
представление об источнике изменений: пометка «(ИИ]» сообщает рецензен­
ту, что код желательно проверять внимательнее и с учётом граничных случаев.
В целом работу с ИИ стоит рассматривать как обычную часть командной раз­
работки, когда коллеги делятся опытом, удачными приёмами и предупреждениями о том, чего лучше не делать (например: «Copilot предлагает устаревшую биб­
лиотеку для Х, поэтому будьте внимательны»).
Ключевые элементы этого паттерна - ревью и доработка. Разработчики
вручную просматривают и рефакторят код для обеспечения модульности, до­
бавляют полноценную обработку ошибок, пишут подробные тесты и документируют важные решения по мере уточнения кода. Подробнее эти процессы раз­
бираются в следующей главе.
ИИ как напарник-программист
Традиционное парное программирование подразумевает сотрудничество двух че­
ловек за одной рабочей станцией. С появлением ИИ возник гибридный подход,
когда один разработчик работает вместе с ИИ-ассистентом. Сочетание челове­
ческой интуиции и скорости машины даёт особенно плодотворные результаты.
В паре «человек - ИИ» разработчик взаимодействует с ИИ, получая предло­
жения по коду, просматривая их и уточняя результаты. ИИ используется для бы­
строго выполнения рутинных задач, таких как написание шаблонного кода или
генерация тестов, с сохранением контроля над качеством и релевантностью кода.
Например, при интеграции новой библиотеки разработчик может попро­
сить ИИ сгенерировать исходный код интеграции. Затем разработчик проверя­
ет предложения ИИ, для подтверждения корректности сверяясь с официальной
документацией. Этот процесс не только ускоряет разработку, но и способствует
освоению знаний, поскольку разработчику приходится одновременно общать­
ся с ИИ и изучать особенности библиотеки.
Сравним этот паттерн с традиционным парным программированием «чело­
век - человек»:
- Пара «человек - ИИ» обеспечивает быструю генерацию кода и эффек­
тивно справляется с рутинными задачами. Особенно полезна такая схема
для разработчиков-одиночек или при ограниченных ресурсах команды.
108

Часть 11. Практика работы с ИИ

- Пара «человек - человек» эффективна в сценариях со сложными задача­
ми, где важную роль играют понимание и совместный мозговой штурм.
Эта схема помогает разделять ответственность и повышает общую осве­
домлённость о коде.
Оба подхода имеют свои сильные стороны, а выбор между ними зависит
от сложности проекта, доступных ресурсов и конкретных целей разработки.
Лучшие практики парного программирования с ИИ
Максимально воспользоваться всеми преимуществами разработки с помощью
ИИ помогают следующие рекомендации.
Для разных задач начинайте разные сессии
Разные сессии помогают сохранить ясность контекста и релевантность пред­
лагаемых ИИ решений конкретной задаче.
Формулируйте запросы чётко и лаконично
Чётко сформулированные и ясные инструкции повышают качество ответов ИИ.
Чаще просматривайте изменения и делайте коммиты
Регулярные интеграция и тестирование сгенерированного ИИ кода позволя­
ют быстрее выявлять возможные проблемы и поддерживать динамику про­
екта.
Поддерживайте короткие циклы обратной связи
Постоянно анализируйте вклад ИИ, по мере необходимости корректируя или
уточняя его, - так вы будете направлять ИИ в нужное русло и улучшать его
предложения.

ИИ как валидатор
ИИ способен не только генерировать код, но и выполнять роль ценного валидатора, помогающего рецензировать код и обеспечивать качество. ИИ-инстру­
менты могут анализировать код на предмет потенциальных ошибок, уязвимо­
стей и соответствия лучшим практикам. Например, платформы вроде DeepCode
и Snyk с функцией ИИ-проверки кода выявляют такие проблемы, как отсут­
ствие санитизации входных данных или небезопасные конфигурации, предо­
ставляя конкретные рекомендации прямо в среде разработки. Платформы типа
Qodo и TestGPT автоматически генерируют тестовые случаи с широким покры­
тием и снижением ручной нагрузки. Многие ИИ-инструменты также помогают
Глава 3. Проблема 70%: как работать с ИИ по-настоящему

1

109

отслеживать производительность приложений, выявляя аномалии, которые мо­
гут указывать на скрытые проблемы.
Интеграция АI-валидаторов в рабочий процесс разработки позволяет коман­
дам повышать качество кода, снижать вероятность дефектов и обеспечивать
соблюдение стандартов безопасности. Такой проактивный подход дополняет
контроль со стороны человека, что повышает надёжность и устойчивость ПО.
Эти инструменты повышают эффективность QА-процессов, беря на себя рутин­
ные и трудоёмкие задачи, что позволяет тестировщикам сосредоточиться на бо­
лее сложных и тонких аспектах обеспечения качества.
Интеграция ИИ в процессразработки, будь то в роли напарника-программиста
или валидатора, открывает возможности для повышения продуктивности и ка­
чества кода. Продуманное использование этих инструментов позволяет разра­
ботчикам сочетать сильные стороны как человеческого, так и искусственного
интеллекта.
Максимально воспользоваться всеми возможностями ИИ и человека в сфе­
ре QA помогают следующие рекомендации.
- Используйте ИИ для первичной оценки и предварительного сканирова­
ния, выявляющего очевидные проблемы.
- В критически важных случаях ( таких как сложный функционал, пользо­
вательский опыт и присущие ИИ ограничения) отдавайте приоритет ре­
вью со стороны человека.
- Создавайте среду непрерывного сотрудничества, когда ИИ-инструмен­
ты и тестировщики-люди работают в тандеме, с постоянными циклами
обратной связи для улучшения как производительности ИИ, так и каче­
ства человеческих решений.

Золотые правила вайб-кодинга
Несмотря на то что вайб-кодинг предлагает беспрецедентную скорость и твор­
ческую свободу в разработке ПО, сама его гибкость требует структурированного
подхода; только благодаря продуманной структуре можно обеспечить стабиль­
ное качество и слаженную работу команды. Без чётких принципов, уравновешивающих творческий поиск с инженерной дисциплиной, разработка с помощью
ИИ в силу её стремительного и интуитивного характера может быстро скатить­
ся в хаос.
Описанные ниже «золотые правила» выработаны на основе коллективного
опыта команд, успешно интегрировавших вайб-кодинг в свои рабочие процессы.
110

Часть 11. Практика работы с ИИ

В этих правилах отражены ценные уроки, и они говорят о том, в каких зада­
чах ИИ проявляет себя лучше всего, где он допускает ошибки и почему на всех
этапах важен контроль со стороны человека. Эти принципы ни в коем случае
не ограничивают творческую свободу; это лишь рамки, в которых коллекти вы могут уверенно экспериментировать и одновременно соблюдать стандар­
ты, необходимые для создания полностью готового к эксплуатации программного продукта.
Правила охватывают три ключевых аспекта вайб-кодинга: взаимодействие
человека и ИИ, интеграция сгенерированного ИИ кода в существующие систе­
мы и формирование командных практик, поддерживающих устойчивую разра­
ботку с помощью ИИ. Перечисленные ниже рекомендации помогут командам
воспользоваться всеми преимуществами вайб-кодинга и при этом избежать рас­
пространённых ловушек, ведущих к техническому долгу, уязвимостям или не­
удобным в поддержке кодовым базам.
Чётко и ясно формулируйте, что вам нужно
При взаимодействии с ИИ чётко формулируйте свои требования, задачи
и ожидаемые результаты. Точные запросы дают точные результаты.
Всегда проверяйте, соответствует ли вывод ИИ вашей цели
Сгенерированный ИИ код всегда нужно проверять на соответствие первона­
чальной цели. Перед тем как принимать его, убедитесь в его функционально­
сти, логике и релевантности.
Относитесь к ИИ как к младшему разработчику (за действиями которого по­
стоянно наблюдают)
Воспринимайте сгенерированный ИИ код черновым вариантом, требующим
вашего пристального внимания. Давайте обратную связь, уточняйте вывод
и следите за его качеством и корректностью.
Используйте ИИ для расширения своих возможностей, а не для замены своего ин­
теллекта
Пользуйтесь ИИ для автоматизации рутинных или сложных задач, но всегда
оставайтесь активным участником в решении проблем и принятии решений.
Перед генерацией кода договоритесь с коллегами
До того как приступать к работе с помощью ИИ, договоритесь с коллегами
по команде о стандартах, ожиданиях и практических сценариях использо­
вания.
Глава 3. Проблема 70%: как работать с ИИ по-настоящему

111

Обсуждайте с коллегами помощь ИИ как обычную часть рабочего процесса
Регулярно обсуждайте с коллегами опыт работы с ИИ, найденные удачные
решения и ошибки. Воспринимайте ИИ как один из инструментов коллек­
тивного роста.
Изолируйте изменения, внесённые с помощью ИИ, как отдельные коммиты в Git
В системе контроля версий чётко обозначайте изменения, сделанные с помо­
щью ИИ, и отделяйте их от других для упрощения код-ревью, откатов и от­
слеживания.
Проследите за тем, чтобы весь код проходил через ревью, независимо от его ав­
торства
Все изменения, будь то написанные человеком или ИИ, должны проходить
через ревью. Единые стандарты, применимые ко всем частям кода, повыша­
ют его качество и делают его более понятным всем членам команды.
Не выполняйте слияние кода, который не понимаете
Никогда не интегрируйте сгенерированный ИИ-код, пока не разберётесь
в его функциональности и последствиях. Понимание - залог поддержки
и безопасности.
Не забывайте о документации, комментариях и ADR
Чётко документируйте предпосылки, функциональность, контекст генерируемого ИИ-кода. Хорошая документация помогает поддерживать ясность
и снижает будущий технический долг.
Делитесь эффективными запросами и используйте их повторно
Запоминайте запросы (промпты), дающие качественные результаты. Состав­
ляйте репозиторий проверенных запросов для ускорения работы и для её со­
гласованности.
Регулярно анализируйте свои действия
Периодически пересматривайте и уточняйте детали рабочего процесса с ис­
пользованием ИИ. На основе предыдущего опыта составляйте рекоменда­
ции для будущей работы.
Следуя этим золотым правилам, команда может эффективно использовать
ИИ с повышением продуктивности при сохранении прозрачности, качества
и контроля.
112

Часть 11. Практика работы с ИИ

Итоги и дальнейшие шаги
Текущее состояние разработки с помощью ИИ можно охарактеризовать как
«проблему 70%»: эти инструменты отлично справляются с генерацией шаблон­
ного и рутинного кода, но плохо справляются с оставшимися 30%, охватываю­
щими граничные случаи, архитектурные решения и готовность к эксплуатации.
Мы выделили два основных сценария использования ИИ; приверженцы одно­
го - это стартаперы, быстро создающие минимально жизнеспособный продукт;
приверженцы другого - «итераторы», интегрирующие ИИ-инструменты в свои
ежедневные рабочие процессы. Также мы перечислили типичные ошибки, такие
как антипаттерн «два шага назад» и «ловушка демокачества)) , когда впечатляю­
щие прототипы не выдерживают проверки в реальных условиях.
Выделены три проверенных паттерна рабочего процесса: ИИ как автор чер­
новика (сначала генерация, затем уточнение); ИИ как напарник-программист
(непрерывное сотрудничество); ИИ как валидатор (человек пишет код, ИИ ана­
лизирует). Были сформулированы «золотые правила)) вайб-кодинга, задающие
ключевые ориентиры и подчёркивающие важность чёткой коммуникации, тща­
тельной проверки, командной координации и обязательного понимания всего
кода перед его включением в основную ветку.
Индивидуальным разработчикам лучше выбрать какой-то один паттерн ра­
бочего процесса и систематически его опробовать в своей повседневной прак­
тике с одновременным соблюдением указанных золотых правил. Вместо того
чтобы конкурировать с ИИ в написании кода, постарайтесь развить в себе опи­
санные в главе 4 навыки системного дизайна, отладки и поддержки архитектуры.
Что касается командной работы, то рекомендуется устанавливать стандар­
ты использования ИИ, создавать общие репозитории эффективных запросов
и интегрировать приёмы разработки с помощью ИИ в существующие эджайл­
практики. Регулярный обмен знаниями об успехах и ошибках поможет избежать
типичных ловушек и максимально воспользоваться всеми преимуществами ИИ.
С развитием автономных ИИ-агентов роль человека сместится в сторону ар­
хитектурного контроля и стратегических решений. В следующей главе говорит­
ся о том, как максимально раскрыть эту незаменимую человеческую составляю­
щую, которая поможет программистам на всех уровнях не конкурировать со всё
более мощными ИИ-системами, а эффективно сотрудничать с ними.

ГЛАВА 4

За пределами 70%: максимальное
раскрытие человеческого потенциала
Итак, как уже было сказано, ИИ-ассистенты, такие как Cursor, Cline, Copilot
и Windsurf, изменили процесс разработки, взяв на себя большую часть рутинной
работы и шаблонного кода, на долю чего в общей сложности приходится примерно 70% 3• Но что насчёт пресловутых оставшихся 30%, определяющих разни­
цу между «сырьrм» кодом и кодом, готовым к использованию в реальных условиях? На их долю приходятся самые сложные задачи: анализ сложных требований,
проектирование поддерживаемых систем, обработка граничных случаев и обес­
печение корректности кода. Иными словами, пусть ИИ и способен генерировать
код, но зачастую ему недостаёт инженерного подхода.
Размышляя о десятилетиях технологических изменений, Тим О'Райли
(https://oreil.ly!BYrNh) напоминает, что каждый этап автоматизации менял спо­
соб программирования, но не отменял необходимость в квалифицированных
разработчиках. Нам не грозит «конец программирования»; скорее, нас ожида­
ет «конец программирования в том виде, в котором мы его знаем сегодня». Это
значит, что роль разработчиковэволюционирует, но не исчезнет.
Главная задача современных инженеров-программистов состоит в том, что­
бы пользоваться искусственным интеллектом для того, что он делает лучше
всего (первые 70%), и одновременно развивать в себе навыки и овладевать зна­
ниями, необходимыми для оставшихся 30%. Вэтой главе мы рассмотрим мне­
ния экспертов и постараемся выяснить, какие человеческие навыки остаются
ключевыми. Мы поговорим о том, на что должны ориентироваться старшие
специалисты и разработчики среднего уровня и в какие навыки должны ин­
вестировать новички, чтобы быть востребованными и успешно развиваться
вэпоху ИИ.

3

114

Эта глава основана на двух статьях, которые я впервые опубликовал в своей новостной
рассылке Elevate with Addy Osmani на Substack: Addy Osmani, "Beyond the 70%: Maximizing
the Нитап 30% ofAI-Assisted Coding" (13 марта 2025 г.) иAddy Osmani, "Future-Proofing Your
Software Engineering Career" (23 декабря 2024 г.).
Часть 11. Практика работы с ИИ

Итак, цель этой главы - дать практические рекомендации по максимально­
му освоению тех самых 30% работы, с которыми ИИ пока не справляется, с конкретными практическими выводами для программистов всех уровней.

Sеniоr-программисты и разработчики: расширяйте
свой опыт работы с ИИ
Если вы sеniоr-программист, то рассматривайте ИИ-инструменты для програм­
мирования как возможность увеличить свой вклад - при условии, что вы пра­
вильно пользуетесь своим опытом. Опытные разработчики обычно обладают
глубокими знаниями в конкретной предметной области, интуицией, подсказывающей им, что могло пойти не так, и умением принимать стратегические высо­
котехнические решения.
Эти сильные стороны как раз и помогают справиться с теми пресловутыми 30% работы, которые оказываются не по силам ИИ. В этом разделе говорит­
ся о том, как опытные разработчики могут воспользоваться своими знаниями
и повысить свою ценность как профессионалов.

Будьте архитектором и главным редактором
Пока ИИ занят генерацией чернового кода, вы сосредотачиваетесь на проек­
тировании и корректировке результатов работы ИИ. Как предполагает Стив
Йегге (https:l!oreil.ly!QtJ7), в будущем мы, возможно, стан�м свидетелями сдви­
га, когда командам будут требоваться «лишь старшие специалисты, которые
а) описывают задачи и формулируют запросы и 6) проверяют полученный ре­
зультат на точность и корректность». Настройтесь на такое будущее. У вас, как
у опытных разработчиков, есть все необходимые навыки, чтобы переводить
все сложные требования заказчиков на язык запросов или технических специ­
фикаций для ИИ-ассистента, а затем критическим взглядом оценивать каждую
строку сгенерированного им кода. По сути, это то же программирование с на­
парником: пусть ИИ и фантастически быстро печатает, но мозгом всего про­
цесса остаётесь вы.
Во время код-ревью поддерживайте высокие стандарты: следите за тем, что­
бы код соответствовал требованиям вашей организации по качеству, безопас­
ности и производительности. Играя одновременно и роль архитектора, и роль
редактора, вы контролируете процесс и не даёте «потоку ревью» захлестнуть
вас. (Важное предупреждение: если младшие сотрудники просто передают вам
сырой код, сгенерированный ИИ, настаивайте на том, чтобы первую проверку
Глава 4. За пределами 70%: максимальное раскрытие человеческого потенциала

115

этоrо кода они выполняли самостоятельно и чтобы ответственность за работо­
способность кода не лежала исключительно на вас).

Пользуйтесь ИИ как ускорителем для масштабных инициатив
Инженеры-проrраммисты сеньор-уровня часто берутся за большие проекты или
сложный рефакторинr, с которыми джуны не справятся в одиночку. Выполнить
такие крупные задачи rораздо быстрее поможет ИИ, берущий на себя всю ру­
тину или исследующий различные возможности под вашим руководством. Для
такоrо стиля работы Йerre ввёл термин «чат-ориентированное проrраммирова­
ние» (СНОР, Chat-Oriented Programming) (https://oreil.ly!QtJ7), то есть «проrрам­
мирование через итеративное уточнение промптов», при котором ИИ выпол­
няет роль коллеrи. СНОР помоrает старшим специалистам ставить перед собой
более амбициозные цели.
ИИ позволяет значительно упростить проверку, стоит ли проект времени
и инвестиций, ведь то, что раньше занимало дни, теперь можно сделать за часы.
Старшие разработчики моrут очень быстро оценить свои силы и попробовать
себя в тех проектах, которые раньше казались им недостижимыми или слишком
оторванными от реальности.
Главное при этом оставаться у руля: лично вы решаете, какими инструмен­
тами или схемами рабочеrо процесса пользоваться и как именно интеrрировать
результаты в единое целое. Ваш опыт позволяет вам фильтровать все предложе­
ния ИИ, отсеивать некачественные и неподходящие и оставлять только разум­
ные и соответствующие вашим целям.

Выполняйте роль наставника и регулятора стандартов
Ещё одна роль старших специалистов - это роль наставников менее опытных
членов команды, обучающих их лучшим, проверенным на практике методам ра­
боты с ИИ. Вы, скорее всеrо, на своём опыте испытали все ловушки и наткну­
лись на разные подводные камни, которые моrут не заметить младшие сотруд­
ники. Вы не понаслышке знаете, что такое утечки памяти, ошибки на единицу
или состояние rонки.
Так как теперь младшие сотрудники моrут потенциально rенерировать код
с помощью ИИ, важно научить их самостоятельно проверять и тестировать та­
кой код. Показывайте на своём примере, как выполнять тщательное тестирова­
ние, и всячески подчёркивайте необходимость проверки результатов, получен­
ных от машин. Некоторые орrанизации (в том числе и юридические фирмы)
ввели правила, соrласно которым если кто-то воспользовался ИИ для rенерации
116 1

Часть 11. Практика работы с ИИ

кода или написания текста, он должен формально указать на этот факт и про­
верить результаты сам, а не надеяться на то, что возможные ошибки найдут
старшие коллеги.
Вам, как старшему специалисту, стоит устанавливать в команде правила, со­
гласно которым пользоваться ИИ можно, но, как говорится, осторожно. Обучив
своих подчинённых искусству анализа и тестирования кода, вы снимете с себя
часть нагрузки по контролю, а ваши коллеги быстрее разовьют в себе навыки,
помогающие справляться с пресловутыми 30% работы.

Продолжайте получать новый опыт и новые знания
Сейчас, как никогда ранее, важен ваш богатый опыт и знание широкого контек­
ста. Старшие специалисты, как правило, помнят, почему в их компании что-то
устроено определённым образом или почему в их отрасли что-то принято делать
так, а не иначе. Такая экспертиза помогает им выявлять ошибки в выводе ИИ,
которые остаются незаметными для новичков.
Продолжайте получать знания в своей предметной области - например,
следите за текущими потребностями бизнеса, анализируйте обратную связь
от пользователей или изучайте относящиеся к разработке ПО правила и нор­
мативные требования. Искусственный интеллект не учтёт все эти особенности,
если ему о них не сообщить прямо. Наилучшие результаты получаются только
в сочетании скорости ИИ с обширными знаниями.
Кроме того, пользуйтесь своей интуицией, направляя процесс работы с по­
мощью ИИ в нужное русло. Например, если вы понимаете, что быстрая правка
кода в будущем грозит обернуться проблемами, то вы можете поручить ИИ ге­
нерировать более обоснованные и устойчивые решения. Доверяйте своим ин­
стинктам, отточенным за годы профессионального развития, - если фрагмент
кода кажется вам подозрительным или слишком идеальным для реально рабо­
тающего кода, постарайтесь проанализировать его тщательнее. В девяти из деся­
ти раз ваша интуиция поможет вам выявить то, что ИИ не учёл. Умение предви­
деть далекоидущие последствия, связанные с кодом, - это отличительная черта
старших инженеров. Не позволяйте удобным ИИ-инструментам притупить этот
ваш навык, применяйте его ко всему, что выдаёт ИИ.

Оттачивайте свои социальные навыки и навыки лидера
Теперь, когда часть работы по написанию берёт на себя искусственный ин­
теллект, старшие разработчики могут уделять больше внимания и сил чело­
веческой стороне программирования и разработки: общению с акционерами
Глава 4. За пределами 70%: максимальное раскрытие человеческого потенциала 1

117

и заинтересованными сторонами, проектным совещаниям и принятию реше­
ний, связывающих технологии с бизнес-стратегией. Как отмечают Тим О'Райли
с коллегами (https:!/oreil.ly!rЫKm), по мере упрощения рутинных задач ценность
смещается в сторону умения ставить цели и координировать работу сложных
систем.
Именно старшие инженеры чаще всего координируют работу и видят общую
картину. Не отказывайтесь от этой роли. Разрабатывайте архитектурные дорожные карты, оценивайте различные инструменты (ИИ или другие), формулируйте
внутренние правила использования ИИ и написания кода. Это задачи, с которы­
ми ИИ не справится, потому что они требуют опыта, человеческой способности
рассуждать и часто умения выстраивать консенсус между командами. Выпол­
няя свою роль лидера, вы становитесь не просто «генератором кода» (которого
легко заменит очередной инструмент), а незаменимым техническим руководи­
телем, задающим общее направление всей команде.
Короче говоря, продолжайте делать то, что у опытных разработчиков полу­
чается лучше всего: видеть лес за деревьями. ИИ помогает нарубить куда боль­
ше деревьев, чем обычный топор, но кто-то всё равно должен решать, какие
именно деревья рубить и как построить из нарубленных брёвен прочный дом.
Ваш здравый смысл, проницательность, ваше стратегическое мышление и уме­
ние выполнять роль наставника сейчас важны как никогда. При поддержке ИИ
старший специалист может быть на порядок продуктивнее того, кто не поль­
зуется современными средствами, но по-настоящему выигрывает тот, кто де­
лает ставку на свои человеческие сильные стороны, а не просто пускает про­
цесс на самотёк.
Как высказался один пользователь Reddit (https://oreil.ly!HulC9), «ИИ - это
множитель программирования», который «значительно повышает продуктив­
ность старших программистов». Эффект множителя реален, но помните, что ум­
ножается именно ваша экспертиза. Не забывайте о ней в процессе разработки.

Мiddlе-разработчики: адаптируйтесь
и специализируйтесь
Что касается специалистов среднего уровня, то им, пожалуй, сейчас приходит­
ся тяжелее всего. В последнее время всё активнее автоматизируются те задачи,
которые занимали большую часть их времени, - реализация функционала, со­
ставление тестов, отладка несложных проблем.
Но это не значит, что прошло время специалистов среднего уровня, это зна­
чит, что планка уровня повышается. Фокус смещается от простого написания
118 1 Часть 11. Практика работы с ИИ

кода к профессиональному росту и экспертизе, о чём и пойдёт речь в следую­
щих разделах.

Учитесь интегрировать системы и определять их границы
По мере усложнения систем критически важным становится умение понимать
их суть и умение вычленять из них отдельные компоненты. В эту сферу входят
дизайн API, схемы событий и модели данных - всё, что требует внимательно­
го учёта бизнес-требований и гибкости (способности приспосабливаться к раз­
ным условиям). Повышайте и углубляйте свои знания в области компьютерных
наук, в частности в следующих дисциплинах:
- структуры данных и алгоритмы;
- принципы распределённых систем;
- внутреннее устройство баз данных и оптимизация запросов;
- сетевые протоколы и безопасность.
Эти знания помогут вам лучше понимать, к каким последствиям может при­
вести сгенерированный ИИ-код, а также помогут принимать более взвешенные
архитектурные решения.
Научитесь также работать с граничными случаями и неоднозначностью. В ре­
альном ПО часто встречаются нестандартные сценарии, и требования к нему
часто меняются. По умолчанию ИИ генерирует стандартное решение, так что
задача разработчика - задавать вопросы типа «А что будет, если ...?» и целена­
правленно исследовать слабые места.
Среди важных навыков стоит отметить критическое мышление и умение ду­
мать наперёд, анализировать граничные случаи и прогнозировать сбои, прора­
батывая их на уровне кода или дизайна. Помимо прочего, это означает умение
предусматривать нулевые входные данные (null), сетевые сбои, нетипичные дей­
ствия пользователя и интеграцию с другими системами.

Повышайте свои знания в предметной области
Знание бизнес-контекста или среды, в которой работает пользователь, позволя­
ет выявлять граничные случаи, о которых универсальный ИИ не имеет никако­
го представления. Опытные специалисты же всегда учитывают эти сценарии.
Старайтесь систематически тестировать граничные случаи и проверять различ ные предположения. Постарайтесь освоить сложные сферы, в которых решаю­
щую роль по-прежнему играет человеческий фактор. К таким сферам относят­
ся следующие:
Глава 4. За пределами 70%: максимальное раскрытие человеческого потенциала

119

- финансовые системы с нормативными требованиями;
- медицинские системы с жёсткими требованиями к конфиденциальности;
- системы реального времени со строгими требованиями к производительности;
- инфраструктура машинного обучения.
К таким областям, специфичным для разработки ПО, относятся, помимо
прочих, фронтенд- и бэкенд-разработка, разработка для мобильных устройств,
DevOps и инженерия безопасности. Экспертные знания в предметной области
дают контекст, которого недостаёт современным ИИ-инструментам, и помога­
ют принимать более взвешенные решения о том, где и как применять эти ин­
струменты.

Освойте оптимизацию производительности и DevOps
Большие языковые модели способны оптимизировать код на базовом уров­
не, но для того чтобы выявлять и устранять проблемы с производительностью
на уровне всей системы, нужно хорош@ понимать работу всей системы, от ша­
блонов запросов к базе данных до стратегий рендеринга на фронтенде. По мере
дальнейшей автоматизации создания кода возрастает ценность понимания ра­
боты той или иной системы в реальной среде.
Ориентируйтесь на следующие области:
- мониторинг и наблюдаемость (observability);
- профилирование и оптимизация производительности;
- практики безопасности и соответствие требованиям (compliance);
- управление затратами и их оптимизация.

Уделяйте особое внимание код-ревью и его качеству
По мере того как код всё чаще генерируется с помощью ИИ, на первый план вы­
ходит умение тщательно проверять и тестировать этот код. Как замечает Йегге
(https://oreil.ly!Qt/7), «всем придётся относиться к тестированию и код-ревью го­
раздо серьёзнее». Относитесь к сгенерированному ИИ коду так же, как к результа­
ту работы младшего разработчика - именно вы должны находить баги, уязвимо­
сти и неаккуратные реализации. Отсюда следует, что вы должны развивать свои
навыки модульного тестирования, интеграционного тестирования и отладки.
Умение писать хорошие тесты поможет вам разбираться в спецификациях
и понимать, насколько корректен созданный код. Разумнее всего изначально счи­
тать не прошедший проверку код не работающим. Да, ИИ часто выдаёт рабочий,
120 1 Часть 11. Практика работы с ИИ

но неоптимальный код, и пользоваться им бывает можно только после нескольких
итераций и исправлений. Тому есть несколько причин, в том числе и тот факт, что
модели обучались на множестве самых разных примеров, далеко не все из которых
соответствуют лучшим образцам из практики программирования.
Тренируйте «тестовое мышление»: проверяйте каждый критически важный
логический путь, применяйте статистический анализ и линтеры, не стесняйтесь
переписывать предложенный ИИ код, если он недотягивает до ваших стандар­
тов качества. Даже если вы придерживаетесь описанного в предыдущей главе
паттерна «ИИ как валидатор», вы не должны отдавать контроль качества цели­
ком на откуп ИИ, ведь именно в этой сфере важнее всего проявляет себя фак­
тор человеческой добросовестности. Когда ПО работает не так, как ожидается,
решающую роль играют реальные навыки диагностики и исправления ситуа­
ции. ИИ может помогать с отладкой (например, предлагать вероятные причи­
ны сбоя), но он не понимает по-настоящему контекст, в котором работает ваше
приложение. В отличие от искусственного интеллекта люди-тестировщики обла­
дают предметными знаниями и знают, чего ожидают пользователи, - и имен­
но этих знаний пока что недостаёт ИИ. Эти знания критично важны при оцен­
ке значимости и влияния потенциальных проблем. Диагностика сложных багов
часто требует творческого подхода и умения учитывать широкий спектр факто­
ров - а ведь это, по сути, человеческие навыки. Что же касается оценки этиче­
ских аспектов ПО, таких как понятие «справедливости» и «доступности», то это
и вовсе исключительная сфера человека.
Умение логически выявлять сложную ошибку - воспроизвести её, изолиро­
вать причину, понять задействованные системы (ОС, базы данных, библиоте­
ки) - это навык инженерного программиста, который будет востребован всегда.
Он подразумевает уверенное знание основ (как работают память и состояние,
проблемы параллелизма и тому подобное), которое начинающие разработчики
должны получ ать на практике. Пользуйтесь ИИ как помощником (который мо­
жет давать пояснения к сообщениям об ошибках или предлагать исправления),
но не полагайтесь на него бездумно. Выдающихся разработчиков от средних от­
личает навык методичного поиска неисправностей и умение применять базовые
принципы отладки. Регулярно применяя этот навык и это умение, вы создаё­
те своеобразный цикл обратной связи; занимаясь отладкой кода, написанного
ИИ, вы учитесь лучше формулировать запросы и избегать банальных шаблонов.

Учитесь мыслить системно
Программные проекты - это не просто набор отдельных задач по написанию
кода; проекты существуют в более широком контексте, который охватывает
Глава 4. За пределами 70%: максимальное раскрытие человеческого потенциала

121

потребности пользователей, сроки, унаследованный код, принятые в команде
правила и соглашения. ИИ сам по себе не понимает общей картины и не знаком
с ней, он не знает историю проекта, не знает причин, по которым принимались
те или иные решения (если только всё это явно не указать в запросе, что часто
бывает непрактично). Контекст этот должны привносить люди.
С этой точки зрения навык, который будет оставаться востребованным, это системное мышление, то есть понимание того, как изменения одной части
системы влияют на другие, как именно ПО служит бизнес-целям и как все эле­
менты взаимосвязаны между собой 4. Взгляд на проект как на целое помогает
расставить приоритеты и правильно пользоваться выдаваемыми ИИ решения­
ми. Например, если ИИ предложит некий лайфхак, противоречащий требованиям или внутренним стандартам компании, знающий контекст человек сразу же
заметит несоответствие этого решения общей картине. Старайтесь изучать пре­
дысторию проектов и читать документацию, развивая своё представление о системе в целом и о том, что допустимо, а что нет.

Адаптируйтесь, не переставайте учиться
Под конец стоит отметить такой метанавык, как умение осваивать новые ин­
струменты и адаптироваться к переменам. Сфера разработки с помощью ИИ
стремительно развивается, и на передовой будут оставаться специалисты, ко­
торые не ленятся осваивать новые для себя области знания, особенно связан­
ные с искусственным интеллектом. Тим О'Рейли пишет (https://oreil.ly!BYrNh),
что наибольший прирост продуктивности получат разработчики, «стремящи­
еся осваивать новые навыки». Инвестируйте время и средства в основательное
изучение основ, интересуйтесь новыми методиками - это поможет вам пользо­
ваться ИИ как инструментом, не впадая в зависимость от него.
Главное здесь - поиск баланса; пользуйтесь ИИ для собственного роста,
но иногда практикуйтесь работать и без него, чтобы не забыть основы, чтобы
глубже понять какие-то фундаментальные принципы и чтобы поддерживать
на должной высоте свои навыки программирования (некоторые разработчики
периодически проводят так называемый ИИ-детокс (https://oreil.ly!XFPqu). Ко­
роче говоря, будьте программистом, который учится постоянно - это навык,
гарантирующий востребованность в любое время.
4

122

Подробнее о системном мышлении говорится в книгах Donella Н. Meadows, Тhinking in
Systems: А Primer, 2nd edition (Rizzoli, 2008); и Peter М. Senge, Тhе Fifth Discipline: Тhе Art
and Practice of the Learning Organization (Crown, 2010).

Часть 11. Практика работы с ИИ

Оттачивайте навыки кросс-функциональной коммуникации
По мере сокращения времени на реализацию особую ценность приобретает уме­
ние переводить бизнес-требования в технические решения. Всё более востребо­
ванными становятся специалисты, умеющие эффективно общаться с менедже­
рами продукции, дизайнерами и другими заинтересованными сторонами. Здесь
ключевые области для развития следующие:
- сбор и анализ требований;
- составление технической документации;
- планирование проекта и оценка сроков;
- руководство коллективом и наставничество.

Осваивайте системный дизайн и архитектуру
Вместо того чтобы тратить дни на реализацию какой-нибудь очередной функ­
ции, инженеры среднего уровня могут потратить это время на проектирование
устойчивых систем, которые будут надёжно работать при масштабировании
и корректно обрабатывать сбои. Для этого, конечно, нужно иметь представле­
ние о принципах построения распределённых систем, о внутреннем устройстве
баз данных и об облачной инфраструктуре - всё это сферы, в которых большие
языковые модели пока что не слишком компетентны.
Учитесь на практике проектировать системы, решающие реальные зада­
чи в масштабируемой среде. Эти навыки не утратят свою ценность и останут­
ся востребованными, независимо от способа генерации кода, потому что для
них нужно понимать бизнес-требования и иметь представление об инженерных
компромиссах.
Проектировать связную систему невозможно без знания компромиссов,
ограничений и «большой картины», а такое знание выходит за рамки написа­
ния нескольких функций. ИИ может сгенерировать код, но он не сможет авто­
матически подобрать лучшую архитектуру для сложной задачи.
Представление об общей архитектуре - о том, как взаимодействуют компо­
ненты, как данные проходят через систему, как обеспечивается масштабируе­
мость и безопасность - относится к тем пресловутым 30%, для которых необ­
ходимо человеческое понимание. Сюда входит следующее:
- стратегии балансировки нагрузки и кеширования;
- партиционирование и репликация;
- виды отказов и процедуры восстановления;
- оптимизация затрат и управление ресурсами.

Глава 4. За пределами 70%: максимальное раскрытие человеческого потенциала

1

123

Sеniоr-разработчики давно отточили этот навык, а инженеры-программисты
среднего и младшего уровня должны активно его развивать. Осмысляйте задачу
исходя из паттернов и принципов (например, разделения ответственности и мо­
дульности) - они помогают обеспечить долгосрочную поддержку сгенериро­
ванного ИИ решения. Помните, что надёжная архитектура не возникает сама
собой, она требует опытной руки человека.

Пользуйтесь ИИ!
Не стоит избегать помощи ИИ - он должен стать неотъемлемой частью вашего
рабочего процесса, и сопротивляться этому бесполезно. Вот некоторые из прак­
тических сценариев такого взаимодействия:
- создание каркаса для первоначальной структуры кода;
- быстрое создание прототипов для проверки идей;
- парное программирование для ускорения отладки и решения задач;
- предложения по оптимизации и альтернативным подходам;
- обработка повторяющихся паттернов кода, когда человек-разработчик
сосредоточен на архитектуре и дизайне.

Осваивайте UI- и UХ-дизайн
Набирает популярность мнение, что разработчикам среднего уровня просто
«пора уходить» - якобы чисто инженерные навыки программистов устарева­
ют, потому что детали реализации возьмёт на себя ИИ. Мнение это преувели­
чено, но дискуссия о важности навыков за пределами собственно инженерных
(таких как дизайн) заслуживает внимания. В показательном обмене мнениями
в декабре 2024 года пользователь @fchollet писал:
Скоро мы окажемся в мире, где вычислительные мощности на этапе тести­
рования можно будет превращать в компетентность - впервые в истории
ПО предельные издержки станут критически важны.
На что пользователь @garrytan ответил:
На следующем этапе на первый план выйдут UX, дизайн и реальная пре­
данность ремеслу.
Я сказал бы так: «Делайте то, что действительно нужно людям. Для этого уже
недостаточно умения просто писать код. Великолепный программный продукт
124

Часть 11. Практика работы с ИИ

создают люди, обладающие широким спектром навыков и отлично разбираю­
щиеся одновременно в нескольких областях».
Успех в области разработки ПО всегда зависел от чего-то большего, чем
простое знание того или иного языка программирования. В настоящее время
не то чтобы меняется роль инженерных навыков (которые якобы «умирают»),
но, скорее, снижается барьер простой реализации. В результате повышается
роль умения рассуждать и повышается важность дизайн-мышления.
Подумайте, что делает успешными такие приложения, как Figma, Notion или
VSCode. Дело не только в техническом совершенстве, дело в глубоком понима­
нии потребностей пользователей, рабочих процессов и проблемных мест. А по­
нимание это обусловлено следующими факторами:
- мышление в духе UХ-дизайна;
- глубокое знание предметной области;
- понимание человеческой психологии и человеческого поведения;
- системный дизайн с учётом производительности, надёжности и масштабируемости;
- соответствие бизнес-модели.
Отличные инженеры-программисты всегда были не просто составителями
кода. Они были специалистами, умеющими решать проблемы, понимающими
как технические ограничения, так и человеческие потребности. По мере того
как ИИ упрощает процесс реализации и делает его менее трудоёмким, на пер­
вый план выходит целостное мышление.
Но это не значит, что каждый инженер-программист до_лжен становиться UХ­
дизайнером. Речь идёт о развитии мышления, ориентированного на продукт,
и о более эффективном взаимодействии с дизайнерами и продакт-менеджерами.
Речь идёт о том, чтобы больше думать о пользователях, лучше понимать их пси­
хологию и поведение, а также о том, чтобы учиться принимать технические ре­
шения, ориентированные на пользовательский опыт. Вы уже достигли опре­
делённого уровня технической экспертизы - теперь пора уравновесить её
внимательным отношением к потребностям пользователя.
@garrytan в своей публикации продолжает:
На следующем этапе на первый план выйдут UX, дизайн и реальная пре­
данность ремеслу.
Я сказал бы так: «Делайте то, что действительно нужно людям. Програм­
мирование и код перестанут быть ограничивающим фактором. Великолепный
программный продукт создают люди, обладающие широким спектром навыков
Глава 4. За пределами 70%: максимальное раскрытие человеческого потенциала

125

и отлично разбирающиеся одновременно в нескольких областях». [Похоже, ав­
тор здесь дублировал один из предыдущих фрагментов текста. - Прим. перев.]
Будущее - за инженерами, которые умеют наводить мосты между человече­
скими потребностями и техническими решениями, либо развивая собственное
дизайнерское мышление, либо выстраивая более эффективное сотрудничество
с профессиональными дизайнерами.

Младшие разработчики: двигайтесь к успеху
вместе с ИИ
Если вы младший или менее опытный разработчик, то, вероятно, с приходом
ИИ испытываете смесь восторга и тревоги. И действительно, подумать только:
ИИ сегодня пишет такой код, который вы пока не умеете писать самостоятель­
но, и вы на его примерах можете многому научиться. В то же время вокруг всё
чаще говорят о «смерти младших разработчиков» (https://oreil.ly!QtJ7) и о том,
что позиции начального уровня находятся под угрозой. Но, вопреки распро­
странённым спекуляциям, ИИ действительно меняет ситуацию на старте карь­
еры, но младшие разработчики от этого вовсе не становятся ненужными.
Вам нужно активно развивать навыки, повышающие вашу ценность по срав­
нению с ИИ. Традиционный путь обучения через реализацию простых СRUD­
приложений и элементарного функционала будет меняться по мере всё большей
автоматизации этих задач.
Рассмотрим типичную задачу младшего разработчика: реализацию нового
эндпойнта (конечной точки) API по установленным образцам. Раньше на вы­
полнение подобной задачи уходил целый день составления кода и тестирования.
С помощью же ИИ время реализации может сократиться до часа, но решающи­
ми здесь становятся следующие навыки:
- достаточно глубокое понимание архитектуры текущей системы, позволя­
ющее правильно формулировать требования;
- анализ сгенерированного кода на предмет безопасности и граничных слу­
чаев;
- обеспечение согласованности реализации с уже принятыми шаблонами;
- составление полноценных тестов, проверяющих бизнес-логику.
Эти навыки невозможно освоить только по руководствам или с помощью
удачно составленных запросов, они формируются в ходе практической работы
с продакшен-системами и благодаря наставничеству со стороны старших спе­
циалистов.
126

1

Часть 11. Практика работы с ИИ

Эволюция процесса разработки не только бросает вызов новичкам, но и от­
крывает новые возможности. Планка для низкоуровневых позиций действи тельно может повыситься; для эффективной оценки и валидации сгенерирован­
ного ИИ кода понадобятся более фундаментальные знания. С другой стороны,
у младших специалистов появится шанс раньше приступить к более интерес­
ным задачам.
Вот как можно повышать свои навыки, чтобы уверенно попасть в преслову­
тые 30%.

Изучайте основы (узнавайте «почему»)
В настоящее время очень соблазнительно отдать все рутинные вопросы на усмо­
трение ИИ и обращаться к нему по каждому незначительному поводу ( «Как
сделать это на Python?))), не вникая в фундаментальные концепции. Сопротив­
ляйтесь этому искушению. Пользуйтесь ИИ как наставником, а не только как
автоматом, выдающим готовые ответы. Увидев фрагмент очередного сгенери­
рованного кода, спросите ИИ, почему он выбрал именно такой вариант, или по­
просите объяснить каждую строку.
Убедитесь, что вы понимаете такие концепции, как структуры данных, ал­
горитмы, управление памятью и параллелизм, не полагаясь полностью на ИИ.
Прочные знания важны по очевидной причине: когда вывод ИИ ошибочен или
неполон, вы на основании этих знаний должны заметить ошибки и исправить
их. Если совсем не анализировать созданный ИИ код, можно ничего не усвоить
и замедлить своё развитие. Читайте документацию, пиши.:ге небольшие програм­
мы с нуля и повышайте свои базовые знания. Так вы создадите прочный фунда­
мент, который послужит вам надёжной основой при любой смене инструментов.

Тренируйтесь решать задачи и выполнять отладку без опоры на ИИ
Для того чтобы развить в себе уверенность, иногда нужно действовать самосто­
ятельно. Многие разработчики советуют время от времени устраивать «разгру­
зочные дни без ИИ)) или иным образом периодически ограничивать его помощь.
Так вы убедитесь, что умеете выполнять задачи и решать проблемы, полагаясь
только на собственные навыки, что очень важно для предотвращения их дегра­
дации. Вам придётся тщательно продумывать логику задачи, что, в свою очередь,
улучшит ваши навыки работы с ИИ, потому что вы сможете формулировать бо­
лее продуманные запросы и направлять его в нужное русло.
Сталкиваясь с ошибкой в сгенерированном ИИ-коде, постарайтесь сначала
исправить её самостоятельно и только потом просите искусственный интеллект
Глава 4. За пределами 70%: максимальное раскрытие человеческого потенциала

127

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

Сосредоточьтесь на тестировании и проверке (верификации)
Одна из лучших привычек начинающего разработчика - это составление тестов
для своего кода, что особенно важно, когда код генерирует ИИ.
Не воспринимайте выданный большой языковой моделью фрагмент кода как
истину в последней инстанции и всегда ставьте его под сомнение. Составляй­
те модульные тесты или вручную тестируйте код на соответствие требованиям,
проверяйте, обрабатывает ли он граничные случаи. Так вы не только научитесь
выявлять ошибки в сгенерированном ИИ-коде, но и приучитесь заранее пони­
мать, какой код будет корректным, а какой нет.
Для составления тестов можно привлекать ИИ, но определять цель тестиро­
вания должны вы. Совет Йегге (https://oreil.ly!QtJ7) касается серьёзного отноше­
ния к тестированию и код-ревью на всех уровнях. Если вы возьмёте в привычку
тщательно проверять свою работу (с ИИ или без), старшие коллеги станут вам
больше доверять, и им не будет казаться, что вы просто «подсовываете» им код
сомнительного качества.
Рассматривайте тестирование как неотъемлемую часть практического про­
цесса разработки, а не как вспомогательную и второстепенную задачу. Освой­
те фреймворки для тестирования, изучайте методы ручного тестирования и системного воспроизведения багов. Эти навыки не только позволят вам войти
в пресловутые 30%, но и помогут понять, как код работает на самом деле.
Помните: если вы обнаружили баг в сгенерированном ИИ коде, то это зна­
чит, что вы сделали то, что не получилось у ИИ, и тем самым повысили свою
ценность.

Думайте о поддержке кода
Младшие разработчики часто нацелены на то, чтобы просто написать сколько­
нибудь работающий код. Но в эпоху ИИ базовую рабочую версию создать очень
легко - с этим как раз справляется искусственный интеллект. Сложнее сделать
код читаемым, поддерживаемым и аккуратным, на чём вам и стоит сосредото­
читься.
128

1

Часть 11. Практика работы с ИИ

Повышайте свою «насмотренность», анализируя код с хорошей структурой
и написанный в хорошем стиле. Сравнивайте вывод ИИ с известными вам луч­
шими образцами; если код ИИ кажется вам неаккуратным или слишком слож­
ным, не поленитесь сделать рефакторинr. Например, если LLM выдала функцию
на 50 строк, которая делает слишком много всего, разделите её на несколько функ­
ций поменьше. Если имена переменных ни о чём не говорят, переименуйте их.
Представьте, что вы делаете код-ревью напарника - постарайтесь улучшить
код ИИ так, чтобы его не стыдно было показать вашим коллегам. Так вы повы­
сите свой навык проектирования. Со временем вы начнёте лучше формулиро­
вать запросы к ИИ с указанием нужного вам стиля и получать более чистый код
и приятно оформленный код. Другие специалисты, которые будут работать с ва­
шим кодом через несколько месяцев или даже лет, скажут вам спасибо. Этим вы
докажете, что не только думаете о том, чтобы получить какой-нибудь, лишь бы
он работал, но и мыслите в категориях инженерного программирования. Под­
держка кода, его сопровождаемость - именно та область человеческой компе­
тенции, что входит в 30%, поэтому уделяйте ей внимание с самого начала сво­
ей карьеры.

Развивайте навыки работы с запросами
и инструментами (осознанно)
Никто не отрицает, что промпт-инжиниринr, то есть умение эффективно взаи­
модействовать с ИИ-инструментами - это весьма пол_езный навык. Вам, как
младшему разработчику, стоит научиться правильно формулировать запросы
для ИИ, предоставлять ему необходимый контекст и итеративно улучшать пром­
пты для получения более качественного результата (для этого неплохо было бы
начать с освоения приёмов, описанных в главе 2). Эти новые навыки могут вы­
делить вас на фоне других (в настоящее время их не до конца освоили даже мно­
гие опытные разработчики). Но не забывайте, что умение формулировать хоро­
шие запросы часто зависит от того, насколько хорошо вы понимаете суть задачи.
Если у вас не получается добиться от ИИ нужного результата, то, возможно, вам
для начала нужно самим разобраться в вопросе. Воспринимайте неудачи как по­
вод к действию.
Одна из стратегий - до того, как просить ИИ решить задачу, описать воз­
можное её решение на простом естественном языке. Также экспериментируйте
с разными ИИ-инструментами (Copilot, Claude и др.), чтобы понять их сильные
и слабые стороны. Чем увереннее вы будете владеть этими ассистентами, тем
продуктивнее будет ваша работа. Но никогда не воспринимайте их результат как
Глава 4. За пределами 70%: максимальное раскрытие человеческого потенциала

129

нечто непогрешимое. Рассматривайте ИИ как своего рода усовершенствованную
версию Stack Overflow: как помощника, а не как авторитет.
С помощью ИИ можно также заниматься небольшими личными проектами,
проверяя границы своего мастерства («Получится ли у меня сделать с помощью
ИИ простое веб-приложение?»). Такой опыт научит вас интегрировать ИИ-ин­
струменты в рабочий процесс, а это очень ценный навык для команды. Только
старайтесь чередовать периоды работы с ИИ с периодами отдыха от него, как
говорилось ранее.

Обращайтесь за советами и обратной связью
И наконец, ещё один навык, который поможет вам уверенно освоиться в но­
вой эпохе - это умение обращаться за помощью и получать обратную связь.
ИИ не обидится, если вы просто проигнорируете его совет, но ваши коллеги
и ваши наставники крайне полезны для вашего профессионального роста, осо­
бенно когда речь идёт о «гибких навыках», навыках лидерства, коммуникации
и ориентации в офисной среде.
Не стесняйтесь спрашивать у опытных разработчиков, почему они предпочли одно решение другому, особенно если оно отличается от того, что предложил
ИИ. Обсуждайте архитектурные решения и компромиссы с более опытными
коллегами - такие разговоры научат вас думать как думают опытные инжене­
ры и дадут вам бесценный опыт. Во время код-ревью особое внимание уделяйте
комментариям кода, который вы написали с помощью ИИ. Если рецензент ска­
жет, например, что какая-то функция «не потокобезопасна» или что «данное ре­
шение создаст проблемы с масштабированием», постарайтесь вникнуть в суть
проблемы. Это именно те аспекты, которые порой упускает из виду ИИ, и важ­
но научиться их замечать. Со временем у вас сформируется свой обязательный
список вопросов к генерируемому ИИ-коду.
Также старайтесь искать возможность поработать в паре с кем-нибудь (пусть
даже удалённо). Особенно вам повезёт, если вашим напарником будет опытный
разработчик, пользующийся в своей работе помощью ИИ, - вы увидите, как
он формулирует запросы и корректирует ответы. Но ещё важнее, что вы буде­
те наблюдать за тем, как он общается с коллегами, как обсуждает различные во­
просы и чувствует нюансы командных отношений. Будьте открыты к критике,
пользуйтесь любым поводом поучиться у старших коллег, и со временем вы на­
учитесь не только лучше работать с помощью ИИ, но и выполнять задачи, под­
властные исключительно человеку. С опытом приходит и мудрость, и благода­
ря ей вы превратитесь из «очередного кодера)) в ценного специалиста, которому
найдётся место в любом коллективе.
130

Часть 11. Практика работы с ИИ

Общайтесь и сотрудничайте
Разработка программного обеспечения - это командный вид деятельности. ИИ
не ходит на совещания (и слава богу), поэтому людям по-прежнему приходится
общаться друг с другом: уточнять требования, обсуждать компромиссы и коор­
динировать работу. Сильные коммуникативные навыки сохраняют свою цен ность и в новую эпоху. Тренируйтесь задавать правильные вопросы и чётко фор­
мулировать задачи и цели как для коллег, так и для искусственного интеллекта.
Любопытно, что формулировка запросов к ИИ - это сама по себе форма
коммуникации, которая требует умения точно выражать свои мысли. Умение
это напрямую связано с таким базовым программистским навыком, как анализ
5
требований • Если вы сумели сформулировать ясный запрос или ясную специ­
фикацию, то вы действительно продумали задачу.
Кроме того, ИИ ещё не может заменить человека в таких сферах, как обмен зна­
ниями, написание документации и ревью. По мере того как разработчики будут всё
чаще работать «вместе» с ИИ, умение решать именно нужные задачи будет только
возрастать. Один из намечающихся трендов заключается в том, что разработчи­
ки чаще сосредотачиваются на обсуждении архитектуры верхнего уровня (часто
с участием ИИ) и на координации задач, фактически беря на себя роль «дирижёра»,
а для дирижёров особенно важны коммуникативные и лидерские навыки.

Смените мысленный настрой: от потребления к созиданию
Стоит подчеркнуть, что в эпоху ИИ младшим разработчикам особенно важно
изменить свой подход к работе и перейти от простого потребления готовых ре­
шений к формированию собственной модели понимания. Раньше для реализа­
ции нужного функционала приходилось продираться через объёмную докумен­
тацию; теперь ИИ буквально выдаёт решение «на блюдечке)). Но если вы просто
соглашаетесь с ним (ограничиваясь простой операций «скопировать и вста­
вить))), ваш рост будет минимальным.
Вместо простого копирования и вставки воспринимайте каждое предло­
женное ИИ решение как учебный сценарий. Разберите решение, поэкспериментируйте с ним и подумайте, как бы вы могли прийти к нему самостоятель­
но. Относясь к результатам работы ИИ не как к окончательным ответам, а как
к интерактивному учебному материалу, вы развиваетесь как профессионал и как
личность. В таком режиме ИИ не ограничивает рост, а ускоряет его.
5 Подробнее об этом см. Mark Richards and Neal Ford, Fundamentals ofSoftware Architecture,
2nd edition (O'Reilly, 2025); и Mark Richards, Neal Ford, and Raju Gandhi, Head First Software
Architecture (O'Reilly, 2024).

Глава 4. За пределами 70%: максимальное раскрытие человеческого потенциала

1 З1

Многие эксперты считают, что ИИ не только потенциально сокращает потреб­
ность в джуниор-разработчиках внутри больших команд, но и повышает планку
для того, чтобы называться джуниор-разработчиком. Эта роль смещается в сто­
рону специалиста, который умеет эффективно работать с ИИ и быстро повышает
свою ценность. Привив себе описанные в этом разделе привычки, вы выделитесь
на фоне общей массы джуниоров не как человек, который просто может делать
то же, что и ИИ (таких кандидатов у любой компании навалом), а как надёжный
и разбирающийся в своей сфере специалист, нацеленный на постоянное улучше­
ние качества своей работы, а это черта будущего старшего разработчика.

Итоги и дальнейшие шаги
Для того чтобы преуспеть в мире разработки с помощью ИИ, программисты
на всех уровнях должны сделать ставку на устойчивые навыки и практики, ко­
торые ИИ пока не способен воспроизвести. Эти навыки и умения сохранят свою
значимость независимо от того, насколько продвинутыми станут наши инстру­
менты. В частности, стоит сосредоточиться на следующем:
- повышение квалификации в области проектирования систем и архитек­
туры;
- развитие системного мышления и контекстного понимания общей кар­
тины;
- оттачивание навыков критического мышления, решения проблем и стратегического предвидения;
- повышение квалификации в специализированных предметных областях;
- код-ревью, тестирование, отладка и обеспечение качества;
- улучшение навыков коммуникации и совместной работы;
- адаптация к изменениям;
- непрерывное обучение: сохранение прочного фундамента при одновременном освоении новых навыков и обновлении знаний;
- использование ИИ.
Именно эти навыки определяют преимущество человека в программной ин­
женерии. Они долговечны, потому что не обесцениваются с выходом очередно­
го фреймворка или сменой инструментов; более того, рост роли ИИ только усиливает их значимость. Как утверждает Саймон Уиллисон (https://oreil.ly!SF307),
помощь ИИ на практике повышает ценность сильных навыков программиро­
вания, а не снижает её, поскольку специалисты с глубокой экспертизой умеют
извлекать из этих инструментов несоизмеримо больший эффект.
132

Часть 11. Практика работы с ИИ

Мощная машина в неумелых руках потенциально опасна или бесполезна,
но в умелых руках она способна преобразить мир. В эпоху ИИ работа опытного
инженера-программиста похожа на полёт опытного пилота с усовершенствован­
ным автопилотом; да, самолёт может теперь летать быстрее и дальше, но имен­
но пилот по-прежнему ведёт самолёт сквозь зоны турбулентности и отвечает
за безопасную посадку.
Программная инженерия всегда была областью непрерывных изменений от ассемблера к языкам высокого уровня, от локальных серверов к облакам,
а теперь от ручного кодирования к разработке с помощью ИИ. Каждый такой
скачок автоматизировал какую-то часть задач, и каждый раз разработчики адап­
тировались и находили для себя ещё больше задач. В ответ на замечание Тима
О'Райли (https://oreil.ly/BYrNh) один из комментаторов на Hacker News написал
(https:!/oreil.ly!OewGO), что инновации в прошлом «почти всегда повышали объ­
ём работ и увеличивали количество возможностей» для разработчиков. Нынеш­
ний взлёт ИИ - не исключение. Он не делает разработчиков ненужными, он
просто переопределяет набор навыков, необходимых для достижения успеха.
Рутинные 70% связанных с программированием задач становятся проще, но тем
более ценными становятся специалисты, способные взять на себя сложные 30%.
Чтобы максимально реализовать свой потенциал в этих 30%, стоит сосре­
доточиться на «вечных» инженерных навыках, таких как глубокое понимание
задач, проектирование чистых решений, тщательная проверка кода на качест­
во, а также умение учитывать ожидания пользователей и контекст. Опытные
программисты получают от ИИ больше пользы именно потому, что умеют им
управлять и знают, что делать, когда он ошибается или выдаёт некачественный
результат. Специалисты, обладающие нужными навыками, в работе с ИИ пре­
восходят тех, у кого нет этих навыков, или тех, кто имеет эти навыки, но не поль­
зуется ИИ. Более того, среди экспертов распространяется мнение (https://oreil.
ly!Sgfvc) о том, что ИИ - это инструмент для подготовленных специалистов
и что «LLM - это мощные инструменты для опытных пользователей». Отсю­
да следует, что задача каждого из нас - стать таким «опытным пользователем»,
повышая свою квалификацию и умение пользоваться этими новыми инстру­
ментами.
В конечном счёте создание ПО - это не просто создание работающего кода.
Это создание кода, который будет хорошо работать в реальной среде на протя­
жении длительного времени и при изменяющихся требованиях. Современные
модели ИИ помогают писать код, но пока не гарантируют, что он будет коррект­
но работать во всех случаях. Это задача разработчика.
Активно развивая описанные выше навыки, старшие разработчики про­
должат занимать лидирующие позиции и внедрять инновации; разработчики
Глава 4. За пределами 70%: максимальное раскрытие человеческого потенциала

133

среднего уровня - повышать свою экспертизу, а младшие разработчики двигаться к мастерству. ИИ будет брать на себя всё больше рутинной работы,
но «сырой» результат сможет превратиться во что-то по-настоящему ценное
именно благодаря человеческой креативности, интуиции и осознанному подхо­
ду к задачам. ИИ - мощный инструмент, но решающую роль играет способ, ка­
ким им пользуются. Полезные практические наработки, здравый смысл и готов­
ность постоянно учиться никогда не потеряют своей актуальности.
Что касается практики, то в любом случае - работаете ли вы в паре с «усерд­
ным джуниором» ИИ, который расписывает за вас функции, или просматриваете diff, состоящий сплошь из сгенерированного ИИ-кода - важно не забы­
вать пользоваться своим уникальным человеческим взглядом. Задавайте себе
вопросы: «Решает ли этот код именно эту задачу? Смогут ли другие специалисты понять этот код и смогут ли они поддерживать его? Каковы возможные ри­
ски и граничные случаи?» Ответственность за эти вопросы лежит на вас. Буду­
щее программирования - это и в самом деле меньше рутинной работы и больше
контроля и управления процессом в целом, но тем более востребованными бу­
дут разработчики, готовые встать за штурвал и повести судно в нужном направ­
лении.
По большому счёту, «высокое» программирование всегда было искусством
решения задач, а не искусством «написания кода». ИИ в этом смысле ничего
не поменял - он лишь побуждает нас перейти на следующий уровень решения
задач. Примите с честью его вызов - и вы с уверенностью вступите в новую гла­
ву нашей индустрии.

ГЛАВА 5

Анализ сгенерированного кода:
код-ревью,доработка,ответственность
Итак, вы научились формулировать запросы для генерации кода с помощью ИИ
и, вероятно, к этому моменту уже получили какой-то результат. Перейдём теперь
к решающему этапу, на котором мы должны убедиться, что полученный код кор­
ректен, безопасен и пригоден для сопровождения.
Нельзя просто так скопировать фрагмент сгенерированного ИИ-кода и сра­
зу же отправить его в продакшен. Разработчик, как специалист, несущий ответ­
ственность за код в рамках всего проекта, должен сначала его просмотреть, про­
тестировать, при необходимости улучшить и интегрировать в кодовую базу. Эта
глава посвящена как раз итеративному процессу правки и отладки кода.
В главе рассматриваются следующие темы:
- анализ сгенерированного ИИ-кода с точки зрения исходного замысла;
- феномен «решения большинства» и почему сгенерированный код часто
выглядит как очень шаблонный;
- методы проверки кода на читаемость и наличие потенциальных проблем;
- отладка написанного ИИ-кода, если он работает не так, как ожидается;
- рефакторинг кода с точки зрения стиля или эффективности;
- создание тестов для проверки поведения кода.
После того как вы освоите эти навыки, можно будет уверенно пользоваться
ИИ и интегрировать создаваемый с его помощью код в свой проект.

От замысла к реализации: как понять написанный
ИИ-код
Получив код от ИИ, первым делом стоит соотнести его с вашим замыслом и со
сформулированным вами запросом. Соответствует ли код поставленным требо­
ваниям? Бывае: так, что ИИ не совсем верно интерпретирует запросы или вы­
полняет их лишь частично.
Глава 5. Анализ сгенерированного кода: код-ревью, доработка, ответственность

/

135

Внимательно прочитайте код. Прокрутите ход его работы в голове или раз­
берите на бумаге.
- Подумайте, как он будет обрабатывать стандартные входные данные.
- Если запрос состоял из нескольких частей ( «сделай Х и У»), проверьте, что
реализованы все эти части.
- Убедитесь в том, что ИИ не добавил функционал, о котором вы не про­
сили, - иногда он добавляет «полезные», по его мнению, элементы вроде
журналирования (логирования) или дополнительных параметров; иногда
они бывают уместными, а иногда нет.
Как и при код-ревью, коллеги, если вам что-то непонятно - отметьте этот
пункт. Попробуйте найти ему разумное объяснение. Если объяснения нет, сто­
ит задать вопрос или задуматься об удалении этого фрагмента.
Например, если вы попросили написать проверку чисел на простоту, а код до­
полнительно выводит сообщения вроде: «Проверка числа 7 ...», то это либо след­
ствие формулировки запроса, либо отголосок шаблона для обучающих данных
(в обучающем коде часто встречается вывод на печать промежуточных резуль­
татов или хода выполнения программы). Если вам это не нужно, удалите соот­
ветствующие фрагменты или попросите ИИ их удалить.
Также убедитесь, что граничные случаи обрабатываются как ожидается. Если
вы предполагали поддержку пустого ввода, поддерживается ли она? Учёл ли ИИ
случай, когда на вход подаются отрицательные числа или None?
Если запрос был неоднозначным и ИИ пришлось выбирать один из возмож­
ных вариантов трактовки, подумайте, какой вариант он выбрал. Возможно, вы
не указали формат вывода и ИИ вместо возврата значения решил его напеча­
тать. Вам нужно решить, подходит ли вам этот фрагмент кода или его стоит пе­
ределать.
Этот этап анализа кода критически важен, и его нельзя пропускать. Даже если
вы собираетесь тестировать код, вам всё равно нужно его понять, ведь тесты мо­
гут и не охватывать все без исключения случаи (а несложные фрагменты кода
часто бывает быстрее прочитать, чем тестировать).
И наконец, учитывайте допущения, на которых строит свой код ИИ. Он часто
выбирает самое типичное решение, или «решение большинства», то есть наибо­
лее распространённое, о чём мы поговорим в следующем разделе.

136

Часть 11. Практика работы с ИИ

«Решение большинства»: «самое распространённое»
не значит «самое подходящее»
Обуч енные на больших объёмах кода ИИ-модели с большей вероятностью вы­
дают самый типичный ответ, который чаще встречается в обучающих данных
(или самый простой из соответствующих запросу). Я называю это «решением
большинства», или «типичным решением»; обычно в нём нет ничего плохого,
просто оно не всегда лучше всего подходит для какой-то конкретной ситуации.
Например, если попросить ИИ выдать алгоритм поиска без дополнительного
контекста, то он, скорее всего, предложит вариант линейного поиска - самый
простой и часто встречающийся. Но предположим, что вам был нужен алгоритм
бинарной сортировки; вы не уточнили свои требования, и ИИ, конечно же, их
не учёл. Линейный поиск вполне подходит для многих случаев, но, если крити­
чески важна производительность, применяются другие алгоритмы.
Точно так же ИИ может использовать во всём проекте глобальные перемен­
ные, потому что именно они встречаются во многих простых примерах, но для
вашего проекта они не подходят.
Не забывайте, что вьщаваемые искусственным интеллектом варианты чаще
всего соответствуют самым общим сценариям. Если ИИ не сообщить подроб­
ностей, он покажет самое типичное решение, тогда как люди чаще ориентиру­
ются на известный им контекст.
Как же избежать ловушки «решения большинства»? Вот вам советы.
- Подумайте, какие важные для ситуации детали вы щ>rли упустить. Если
вам нужно отсортировать список, то по какому именно критерию? Ва­
лидны ли входные данные? Если нет, то стоит добавить проверку данных.
- Рассматривайте альтернативы. Если вам известны другие способы реше­
ния задачи, подумайте, почему ИИ выбрал именно этот способ. Подхо­
дит ли он для вашего случая? Если нет, переформулируйте запрос или пе­
ределайте решение вручную.
Если сгенерированный код ИИ работает для «типичных» случаев, но не пред­
усматривает важные для вас граничные условия, нужно их учесть. Например,
для некоторых вычислений не предусмотрен случай переполнения целого числа.
Во многих обучающих примерах проверки на переполнение нет, но для вас это
может иметь критическое значение.
Помня о склонности ИИ выдавать «типичное решение», вы будете вниматель­
нее анализиро�ать его код и соотносить его со своими требованиями. Ничего
сложного в этом нет - достаточно проявлять разумную предусмотрительность.
Глава 5. Анализ сгенерированного кода: код-ревью, доработка, ответственность 1

137

Читаемость кода и его структура: шаблоны
и потенциальные проблемы
В сгенерированном ИИ-коде часто заметны некоторые характерные черты. Та­
кой код может:
- сопровождаться слишком обширными, слишком размытыми или необыч­
но сформулированными комментариями (так как ИИ обучался на примерах, которые обычно сопровождаются подробными комментариями);
- содержать стандартные для определённых случаев имена переменных (на­
пример, i, j, k для циклов);
- отличаться некоторой избыточностью (чтобы охватывать общие случаи).
Обращайте внимание на эти особенности. Если они не соответствуют требо­
ваниям вашего проекта, избавляйтесь от них и вносите свои правки. Сгенериро­
ванный код может быть функционально корректным, но плохо читаемым или
отличающимся по стилю от других фрагментов. В любом случае стоит:
- переименовывать переменные, чтобы они лучше описывали ситуацию
или соответствовали принятым для вашего проекта правилам;
- удалять лишние комментарии или уточнять их. Если ИИ добавил над оче­
видным циклом if комментарий вроде «Проверка, является ли число про­
стым», этот комментарий можно убрать. А вот комментарий с объяснени­
ем сложной логики лучше оставить или улучшить;
- для приведения кода к единому стилю (одинаковые отступы, фигурные
скобки в одних и тех же местах) пропустить его через линтер или средст­
во форматирования - например, Black для Python или gofmt для Go.
Обращайте также внимание на необычную структуру кода. Может, ИИ
определил несколько классов или функций там, где вы ожидали увидеть один
класс или одну функцию? Иногда он разбивает одну задачу на несколько функ­
ций и подзадач, потому что так было показано в обучающих примерах. Избы­
точные классы и функции можно объединить (и наоборот, в других случаях
их можно разбивать на несколько классов или функций). Не кажется ли вам
код слишком примитивным или, наоборот, слишком сложным? В одних слу­
чаях ИИ может выдать совершенно шаблонный кусок, в других - запутанный
однострочник. Соответствует ли структура сгенерированного кода структуре,
принятой в вашем коллективе? Если нет, код нужно адаптировать под установ­
ленные правила.
Среди распространённых «подводных камней» стоит назвать следующие.
138

1

Часть 11. Практика работы с ИИ

Ошибка на единицу
Да, ИИ тоже допускает такую ошибку- например, неправильно определя­
ет границы циклов. Если у вас есть время, мысленно прокрутите в уме про­
стой тестовый случай.
Необработанные исключения
ИИ может выдать код, в котором не предусмотрены ошибки или ввод данных
в некорректном формате. При необходимости добавьте обработку исключе­
ний.
Неэффективное решение
ИИ может предлагать неэффективное с точки зрения производительности
решение- например, проверять принадлежность элементов к большому на­
бору данных с помощью вложенного цикла, тогда как эффективнее было бы
воспользоваться множеством (set).
Использование неподходящих библиотек
Если в коде использована какая-то библиотека, убедитесь, что она действи­
тельно подходит для вашей ситуации. Иногда бывает так, что ИИ, например,
подключает nuмpy ради простого вычисления суммы, потому что такой при­
мер был в обучающих данных. В таком случае лучше воспользоваться сред­
ствами «чистого» Python или более подходящей библиотекой.
Несогласованность
Иногда в коде встречаются мелкие несостыковки- например, в строке до­
кументации функции говорится одно, а сама функция делает другое; или из­
менилась логика, а комментарий остался прежним. Такие несостыковки нуж­
но исправлять.
Незначительные синтаксические ошибки
Для хорошо обученных моделей это редкость, но для некоторых языков по­
добное всё же возможно.
Устаревшие АР!
ИИ может, например, воспользоваться старой версией какой-нибудь биб­
лиотечной функции. Заметив вызов незнакомой вам функции, постарай­
тесь свериться с документацией и убедиться, что используется корректная
версия.

Глава 5. Анализ сгенерированного кода: код-ревью, доработка, ответственность

139

Заглушки
Если вместо каких-то осмысленных команд в сгенерированном фрагменте
написано что-то вроде «Здесь должен быть ваш код» (You code here) - та­
кое редко, но случается для шаблонного кода, - заполните эти «заглушки».
В целом относитесь к сгенерированному ИИ-коду как к коду, который напи­
сал стажёр, которому хотелось как можно быстрее разобраться с делами и по­
ехать домой. Этот код обязательно нужно проверять на качество и правильно
интегрировать со всем проектом.

Стратегии отладки: поиск и исправление ошибок
Представим, что вы решили запустить сгенерированный код (или пишете для
него тесты, о чём мы поговорим чуть ниже) и что-то не работает или работает
не так, как надо. Отладка сгенерированного ИИ-кода ничем не отличается от от­
ладки кода, который написали вы сами или кто-то другой - разве что он мо­
жет показаться вам менее знакомым и понятным, потому что писали его не вы.
Но к этому моменту вы, скорее всего, уже тщательно просмотрели его, так что
отладка не составит особого труда (см. иллюстрацию 5.1).
Происходит ошибка
Код ИИ выполняется

о

ИИ предлагает
исправление

�
Сообщение и код'
направляется ИИ

Исправление

'P'J;�i�

Повторение (если ошибка сохраняется)

Иллюстрация 5.1. Цикл отладки кода ИИ: запустить сге­
нерированный ИИ код, выявить ошибку, предоставить кон­
текст ошибки ИИ для анализа, применить предложенное исправ­
ление, повторить до тех пор, пока ошибка не исчезнет
140

1

Часть 11. Практика работы с ИИ

Вот шесть шагов отладки.
1. Воспроизвести проблему
Запустите функцию или фрагмент кода с некорректным поведением. По­
смотрите, что будет на выходе или какая ошибка произойдёт.
2. Определить источник проблемы
Выполните стандартные действия при отладке: выведите на экран резуль­
таты вычислений или запустите пошаговый отладчик. Если ошибка ло­
гическая (неверный результат), проследите логику мысленно или с по­
мощью вывода.
3. Проверить, насколько код соответствует исходному запросу
Иногда проблемы с кодом возникают, потому что он не полностью соот­
ветствует требованиям. Например, вы попросили отсортировать данные,
но сортировка работает не так, как вы предполагали. Тут либо виновата
ошибка в коде, либо ИИ не учёл какой-нибудь граничный случай (напри­
мер, пустой список).
4. Воспользоваться ИИ для отладки
Проблемный код можно передать ИИ и попросить его найти ошибку. Как
правило, ИИ хорошо анализирует код и находит источник проблемы. На­
пример, он может заметить, что в цикле должны перебираться элементы
до lеn(агг), а не до len(arr) - 1- такие ошибки он обычно выявляет
быстрее человека. Но в любом случае не следует слепо доверять выводам
ИИ - относитесь к его сообщениям как к совету коллеги.
5. Исправить код
Далее вы можете либо исправить код вручную, либо попросить сделать
это ИИ. Если решение очевидно, быстрее бывает исправить код вруч­
ную. В противном случае можно сформулировать примерно следующий
запрос: «Эта функция выполняется некорректно. С аргументом Х резуль­
тат получается У, хотя ожидался Z». ИИ откорректирует код.
6. Протестировать код ещё раз
Убедитесь в том, что код теперь выполняется без ошибок и при этом
не появилось новых проблем.

Я советую заниматься так называемой отладкой через тестирование (test­
driven debugging). Для важных функций постарайтесь написать несколько тестов
(подробнее об этом будет сказано в разделе про тестирование далее в этой главе).
Неверные результаты этих тестов помогут вам определить источник проблемы.
Если дело не касается самых простых функций, то этот метод почти всегда бы­
стрее простой ручной отладки.
Глава 5. Анализ сгенерированного кода: код-ревью, доработка, ответственность

141

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

Рефакторинг как способ поддержки кода:
превращаем код ИИ в свой
Допустим, вы убедились, что исправленный код с функциональной точки зрения ра­
ботает корректно. Теперь стоит заняться рефакторинrом, чтобы привести его в со­
ответствие стандартам проекта и чтобы с ним было легче работать в дальнейшем.
Вот ещё шесть шагов, на этот раз рефакторинrа.
1. Привести код в соответствие с правилами стиля
Пропустите код через форматтер или линтер. Обращайте внимание
на технические указания вроде «имя переменной должно быть в нижнем
регистре» или «слишком длинная строка» и исправляйте код соответст­
вующим образом. Так код визуально и стилистически будет восприни­
маться как часть вашей кодовой базы. Да, многие ИИ неплохо справля­
ются со стилем, но почти всегда бывает нужно вносить мелкие правки.
2. Исправить имена и структуру
Если, например, ИИ назвал методы класса _helper1 и _helper2, а вы
предпочитаете более осмысленные имена, переименуйте их. Если он вы­
делил несколько небольших отдельных функций, каждая из которых вы­
зывается только один раз, то, возможно, стоит перенести их логику непо­
средственно в код (упростить вложенность).
3. Удалить всё лишнее
Иногда ИИ включает в свой фрагмент кода блок l'lai.n или другие допол­
нительные фрагменты - то, о чём вы не просили. В этом случае нужно
удалить всё лишнее. И наоборот, если он расписал всё в одной функции,
а вы хотите разбить её на более мелкие части для ясности, то разбейте.
4. Добавить документацию
Если код предназначается для библиотеки или модуля, которым будут
пользоваться другие специалисты, добавьте строки документации или
142

1

Часть 11. Практика работы с ИИ

комментарии (там, где это уместно). Если в проекте принят определён­
ный формат строк документации с описанием параметров и возвращае­
мых значений, приведите код к этому формату.
5. Выполнить оптимизацию при необходимости
Допустим, код работает так, как задумано, но достаточно ли он эффек­
тивен? Если в нём выполняется цикл с большим объёмом данных, оце­
ните его алгоритмическую сложность. Не забывайте, что ИИ чаще всего
предлагает «типичное решение» (или «решение большинства»), а не са­
мый оптимизированный вариант. Если производительность важна, пере­
работайте код, выбрав алгоритм получше. Опять же, за помощью в этом
можно обратиться к ИИ:
Оптимизируй этот код, чтобы он выполнялся быстрее; для поиска вос­
пользуйся множеством (set), а не списком.
Впрочем, вы, как разработчик, наверняка уже и сами понимаете, какой
паттерн вам нужен, так что вам остаётся только изменить код соответст­
вующим образом.
6. Упростить код там, где нужно
Иногда ИИ генерирует немного избыточный код - например, использу­
ет условную конструкцию i. f -е lse с несколькими возвращаемыми значе­
ниями return, хотя было бы достаточно одного return. Подробно распи­
санный код - это не всегда плохо, но иногда бывает полезно его сократить
на несколько строк и тем самым улучшить читаемос!ь без ущерба ясности.
Цель рефакторинга - добиться того, что другой разработчик, взглянув
на этот код, не сразу бы понял, что его написал ИИ. Он должен просто выгля­
деть как обычный хороший код. Часто для этого бывает достаточно добавить не­
большие человеческие штрихи, делающие код более прозрачным и ясным.
После рефакторинга нужно убедиться, что код по-прежнему работает так,
как было задумано. Поэтому далее логично будет перейти к тестированию.

Важный этап тестирования: модульные,
интеграционные и сквозные тесты
Тесты важны всегда, но особенно они важны для сгенерированного ИИ-кода
по двум причинам. Во-первых, так как вы не писали код с нуля самостоятельно,
Глава 5. Анализ сгенерированного кода: код-ревью, доработка, ответственность 1

143

вам нужно убедиться, что он работает корректно во всех случаях. Во-вторых,
если позже нужно будет изменить код или интегрировать его с помощью того же
ИИ, тесты помогут убедиться, что изменения не испортили функциональность
кода. Рассмотрим вкратце разные виды тестов.
Модулы-tые тесты
Составляйте тесты для каждой функции или каждого модуля из тех, что сге­
нерированы ИИ, не забывая учитывать граничные случаи. Так, для кода на­
хождения простых чисел можно протестировать его для простого числа,
составного числа, единицы (граничный случай), нуля или отрицательного чи­
сла (определив заранее возможное поведение), для большого простого числа
и т. д. Если все тесты проходят удачно, то код, скорее всего, корректен. Мож­
но даже попросить ИИ сгенерировать эти тесты:
Напиши на PyTest модульные тесты для указанной выше функции с покры­
тием граничных случаев.
Обычно искусственный интеллект справляется с этой задачей неплохо, но всё
равно нужно будет убедиться в корректности тестов и в том, что они охватывают все возможные случаи.
Интеграционные тесты
Если предполагается, что сгенерированный ИИ-код будет взаимодействовать
с другими фрагментами из кодовой базы, например с какой-нибудь функци­
ей из этой базы, напишите тест, вызывающий этот код в соответствующем
контексте. Сохраняются ли данные в базе так, как должны сохранятьсяr Если
код передаёт результат другой функции, проверьте их вместе в одном тесте.
Сквозные тесты
Если сгенерированный ИИ-код- это часть более крупного рабочего процес­
са, выполните сценарий от начала до конца. Например, если это часть веб­
маршрута, выполните тестовый запрос к этому маршруту в тестовой среде
и проверьте корректность формата, обработки ошибок и других аспектов.

Уровень тестирования зависит от того, насколько важен и сложен код, но в лю­
бом случае даже ручной проход или простые утверждения assert в скрипте
лучше, чем ничего. Помните, что тестирование - это не только поиск ошибок,
это ещё и средство фиксации поведения программы. Если впоследствии что-то
144

Часть 11. Практика работы с ИИ

изменится (или ИИ что-то изменит), тесты помогут проследить за тем, чтобы
функциональность кода сохранилась.
Стоит также упомянуть, что тесты помогают сделать код «своим». Проте­
стировав код и исправив все найденные проблемы, вы можете с уверенностью
утверждать, что он «ваш», как и любой другой код в вашей кодовой базе. Вы по­
нимаете, как он работает, вы доверяете ему, и у вас есть тесты для его провер­
ки и поддержки.
Пара слов об ИИ и тестировании
В последнее время в некоторые ИИ-инструменты по напи­
санию кода начинают включать подсказки по тестирова­
нию. CodeWhisperer, например, после некоторых фрагментов
кода предлагает добавить assert. Конечно, такие подсказки
не охватывают все достойные тестирования случаи, так что
стоит их воспринимать как своего рода призыв к размышле­
нию. Для того чтобы придумать нетривиальные граничные
случаи, до сих пор нужна человеческая интуиция.

Итоги и дальнейшие шаги
Итак, мы прошли весь цикл от генерации кода и его анализа до отладки и рефак­
торинга. Цикл этот может как занимать считаные минуты (для небольшой функ­
ции), так и растягиваться на часы и даже дни (для разра�отки сложного модуля
с регулярным привлечением ИИ).
Очень важно уяснить раз и навсегда, что ответственность за итоговый код
лежит на вас, как на разработчике. Искусственный интеллект - это инструмент
ускорения разработки, но он не будет нести ответственность, если что-то пой­
дёт не так. Также существует риск, связанный с лицензированием и авторским
правом; некоторые компании, предоставляющие ИИ, утверждают, что ответы
сверх какой-то определённой длины статистически с большей вероятностью мо­
гут содержать заимствованный материал (https://oreil.ly!kYyO). Да, такое встреча­
ется редко, и разработчики ИИ утверждают, что в последнее время риск сущест­
венно снизился, но всё равно стоит проверять сгенерированный код на предмет
авторства или лицензирования - как это делают в отношении кода из ответов
на Stack Overflow, особенно если код слишком большой или выглядит слишком
«идеально». Например, если в ответ на запрос «реализуй быструю сортировку»
ИИ выдаст 20 строк аккуратного кода, то это, как правило, нормально, потому
что в таком коде нет ничего оригинального и он относится к общеизвестным
Глава 5. Анализ сгенерированного кода: код-ревью, доработка, ответавенность 1

145

знаниям. Но если ИИ выдаёт большой фрагмент кода на узкоспециализированный запрос, то имеет смысл поискать в интернете соответствия его строкам
и проверить, не воспроизведён ли он дословно из какого-то источника. В по­
следнее время эта проблема стала более заметной; задокументированы случаи,
когда ИИ-системы воспроизводили текст из научных журналов и других источ­
ников, защищённых авторским правом (https://oreil.lylh_BzA). Согласно принци­
пам ответственного владения кодом, разработчики должны проверять происхо­
ждение любого ИИ-контента, который выходит за рамки общих шаблонов или
выглядит слишком похоже на фрагменты из очень специфических источников.
Наконец, уделяйте внимание интеграции кода в свой проект, добавляйте его
в систему контроля версии и постарайтесь упоминать в коммитах, что для его
создания привлекалась помощь ИИ. Это не обязательное требование, но в неко­
торых коллективах принято отслеживать такие вещи.
Возможно, в дальнейшем, по мере уточнения или изменения требований
проекта, вам придётся изменить сгенерированный ИИ-код. Относитесь к нему
как к любому другому коду, не считайте, что раз он был написан с помощью ИИ,
то и изменять его также нужно с помощью ИИ. Поступайте так, как сочтёте наиболее подходящим для конкретного случая.
После тщательной проверки и тестирования сгенерированный искусствен­
ным интеллектом код становится просто ещё одним фрагментом кода в вашем
проекте. На этом этапе уже неважно, написал ли какую-то строку ИИ, или соста­
вили вы её сами - важно лишь, чтобы код соответствовал требованиям и стандартам проекта.
Следуя этим советам, вы воспользуетесь скоростью ИИ, не жертвуя каче­
ством кода. Не доверяйте слепо ответам ИИ, встраивайте написанный им код
в весь процесс профессиональной разработки программного обеспечения.
Далее в главе 6 мы поговорим о том, как ИИ-инструменты радикально меняют
этап прототипирования ПО. Я опишу некоторые практические приёмы использо­
вания ИИ-ассистентов, помогающих ускорить путь от исходной идеи до рабоче­
го прототипа, благодаря чему время разработки часто сокращается от нескольких
дней до нескольких часов. Будут рассмотрены конкретные ИИ-инструменты про­
тотипирования (включая Vercel vO) и утилиты преобразования скриншотов в код,
а также стратегии итеративного улучшения под руководством ИИ.
Я затрону и крайне важный процесс перехода от сгенерированных ИИ про­
тотипов к коду, готовому к продакшену, описав как положительные стороны, так
и потенциальные сложности этого процесса, когда его центральной частью стано­
вится ИИ. Я покажу на реальных примерах, как разработчики удачно используют
ИИ для быстрого тестирования идей с сохранением качества кода и при этом из­
бегают типичных ловушек быстрого перехода от концепции к реализации.

ГЛАВА 6

Прототипирование с использованием ИИ:
инструменты и техники
В этой главе говорится о том, как вайб-кодинг с использованием ИИ ускоря­
ет этап прототипирования в процессе разработки программного обеспечения.
Прототипирование - это быстрый переход от идеи к рабочей модели, и с по­
мощью ИИ-ассистентов и метода последовательных итераций разработчики
за несколько часов выполняют то, что обычно заняло бы дни. Здесь также опи­
сываются техники перехода от концепции к прототипу, сравниваются популяр­
ные инструменты ИИ-прототипирования (включая Vercel vO и утилиты форма­
та «от скриншота к коду»), рассматривается итеративная доработка прототипов
под руководством ИИ. Отдельное внимание уделяется такому ключевому этапу,
как переход от сгенерированного ИИ грубого прототипа к коду производственного качества (продакшена). На протяжении всей главы анализируются приме­
ры удачного прототипирования с помощью ИИ с упоминанием как положитель­
ных его сторон, так и возможных «подводных камней».

Быстрое прототипирование с ИИ-ассистентами
ИИ-инструменты позволяют в значительной степени повысить скорость ге­
нерации кода при создании прототипов. Цель прототипирования - получить
не готовый к употреблению программный продукт, а код, доказывающий воз­
можность реализации концепции, то есть такой код, который можно оценить
и впоследствии доработать. В этом ИИ-ассистенты программирования особен но эффективны, так как они на основе минимального описания быстро выдают
работающий код. Например, вместо того чтобы делать макет пользовательского
интерфейса вручную, разработчики описывают его на естественном языке, а ИИ
генерирует его компоненты HTML/CSS или React. Так можно очень быстро пе­
рейти от задумки к реализации.
Один UХ-инженер (https:!!oreil.ly!dPSUЗ) утверждает, что помощь гене­
ративного ИИ полностью изменила его рабочий процесс: «Я начал создавать
Глава 6. Прототипирование с использованием ИИ: инструменты и техники

1

147

функциональные прототипы с поистине потрясающей скоростью. То, на что
раньше уходили дни, теперь выполняется за несколько часов». ИИ автоматиче­
ски берёт на себя рутинный код, освобождая для разработчика время для дизай­
на и задач более высокого уровня. За один и тот же период удаётся испробовать
больше идей. Дополнительное преимущество в том, что ИИ почти мгновенно со­
здаёт шаблонные компоненты прототипа (базовые элементы интерфейса, обра­
ботка форм, примеры данных), благодаря чему разработчик сосредотачивается
на самой концепции и проверяет жизнеспособность уникального функционала.
Вместе с тем не стоит забывать, что сгенерированный ИИ-код прототипа
вряд ли войдёт в окончательный продукт. Да, искусственный интеллект создаёт
этот код очень быстро, но код этот обычно плохо структурирован и плохо под­
даётся масштабированию. Для прототипов это приемлемо, потому что скорость
и возможность поэкспериментировать для них важнее эффективности, особенно
если вы и так собираетесь переписывать критически важные части кода перед эта­
пом продакшена (об этом я расскажу позже в этой главе). Как говорилось в главах
3 и 4, ИИ успешно справляется примерно с 70% кода для прототипов, если разра­
ботчики следят за его архитектурой и исправляют основные недостатки.
Важную роль в этом играет описанное в главе 1 «программирование с наме­
рением». Разработчик формулирует своё намерение (то, что должен делать или
как должен выглядеть прототип) в запросах, а ИИ его реализует. Для иллюстра­
ции рассмотрим очень простой пример прототипирования с помощью ИИ-асси­
стента. Предположим, у нас возникла идея создать страницу авторизации на но­
вом сервисе. Бы хотите быстро получить прототип фронтенда, поэтому задаёте
такой запрос:
Создай простую НТМL-страницу авторизации (Sign Up) с полями для имени
(name), электронного адреса (email) и пароля (password), а также с кнопкой
«Отправить» (Submit). Оформи её согласно базовым требованиям к стилю.
Современный ассистент для программирования, например Cline, выдаст го­
товый пример HTML/CSS:
<! DOCTYPE ht�l>
<ht�l lang="en">
<head>
<�eta charset="UTF-8" />
<�eta na�e="v'i.ewport" content="w'i.dth=dev'i.ce-w'i.dth, 'i.n'i.t'i.al-scale=l.0" />
<t'i.tle>S'i.gn Up</t'i.tle>
<style>

148

1

Часть 11. Практика работы с ИИ

body {font-faмily: Arial, sans-serif; мax-width: 400рх; мargin: 2ем -auto;}
fогм {display: flex; flex-direction: coluмn;}
label {мargin-top: 1ем;}
input, button {padding: 0.Sем; font-size: 1ем;}
button {мargin-top: 1ем; background: #4CAF50; color: #fff; Ьогdег: none;}
</style>
</head>
<body>
<h2>Sign Up</h2>
<fОГМ>
<label>Naмe: <input type="text" nаме="nаме" required></label>
<label>EмaH: <input tуре="емаН" nаме="емаН" required></label>
<label>Password: <input type="password" naмe="passwoгd" required></label>
<button type="subмit">Create Account</button>
</fогм>
</body>
</htмl>

И этот сгенерированный ИИ-код вполне неплохая отправная точка для со­
здания прототипа формы регистрации. В нём предусмотрена базовая размет­
ка и простой набор стилей CSS. Разработчику не пришлось расписывать HTML
и CSS вручную - достаточно было описать желаемый результат, и ИИ быстро
его создал. Это наглядный пример «программирования с намерением»: основ­
ное внимание уделяется поведению и оформлению инте_рфейса, а ИИ сам «при­
думывает», как воплотить намерение в коде.
Разумеется, выше показан очень тривиальный пример. В реальности прототипы
бывают сложнее; обычно они состоят из множества файлов и подразумевают работу
с фреймворками и данными. Но принцип остаётся тем же: с помощью ИИ быстро
создаётся черновой вариант. Далее прототип открывают в браузере, оценивают его
внешний вид и поведение, после чего дорабатывают. Так мы подходим к следую­
щей теме - использованию специализированных ИИ-инструментов для созда­
ния более сложных прототипов, выходящих за рамки простых текстовых запросов.

ИИ-инструменты прототипирования
Несмотря на то что генерировать код прототипа по текстовым запросам уме­
ют такие универсальные ассистенты, как Gemini, ChatGPT и Claude, сфера
специализированных ИИ-инструментов для прототипирования продолжает
Глава 6. Прототипирование с использованием ИИ: инарументы и техники 1 149

стремительно развиваться. На момент написания книги доступные инструмен ты предлагают разные подходы с разным балансом точности и контроля.
Экосистема заметно повзрослела и теперь удовлетворяет разные потребно­
сти в прототипировании. Некоторые инструменты прекрасно справляются с за­
дачей превращения визуального дизайна в код: дизайнер загружает скриншоты
или наброски прототипа и уже через несколько секунд получает работающие
компоненты HTML, CSS или React. Такой механизм «от скриншота к коду» ра­
дикально ускоряет процесс перехода от дизайна к работающему коду, и особен но он пригождается, когда нужно реализовать нарисованные вручную наброски
или макеты Figma. К таким инструментам принадлежит Vercel vO, обеспечиваю­
щий высокую точность соответствия исходному дизайну ценой частичной по­
тери контроля над структурой кода.
Другие платформы специализируются на генерации полноценных приложе­
ний с помощью диалогового интерфейса. Функционал в них описывается на ес­
тественном языке, а на выходе получается полноценная стековая реализация.
Дизайнер, которому нужно быстро собрать приложение без написания кода,
пользуется инструментами вроде LovaЫe или Bolt.new, которые с помощью вы­
сокоуровневого интерфейса запросов генерируют каркасы целых приложений.
По отзывам некоторых дизайнеров, рабочие прототипы, на которые раньше ухо­
дило несколько дней, создаются за несколько часов, и ИИ автоматически берёт
на себя все утомительные компоненты и типовые шаблоны.
ИИ-инструменты третьей категории встраиваются непосредственно в среду раз­
работки и на этапе прототипирования выполняют роль высокоинтеллектуального
напарника. IDE вроде Cursor, Windsurf и Cline позволяют разработчику сохранять
контроль над генерацией кода и одновременно ускоряют процесс разработки. Раз­
личия между ними часто сводятся к философии рабочего процесса: одни автомати­
чески применяют изменения для быстрых экспериментов, другие требуют явного
подтверждения правок и ориентированы на более тщательный анализ кода.
Общая черта всех этих подходов - сокращение пути от продумывания кон цепции до создания рабочего прототипа. Но они значительно различаются
по двум ключевым аспектам, от которых зависит их польза для разных пользо­
вателей и сценариев.
Точность воспроизведения - это соответствие сгенерированного результа­
та исходному описанию или замыслу. Инструменты формата «от скриншота
к коду» обычно поддерживают высокую точность соответствия визуальному
дизайну, но при этом нередко генерируют код, не совпадающий с архитектур­
ными предпочтениями разработчика. Диалоговые же инструменты, в свою оче­
редь, трактуют требования более свободно, выдавая рабочие, но обобщённые
реализации, которые потом приходится дорабатывать.
150

Часть 11. Практика работы с ИИ

Контроль - это возможность управлять процессом генерации и вносить из­
менения в создаваемые прототипы. Одни инструменты работают по принципу
«чёрного ящика», сразу выдавая готовый результат, другие позволяют итеративно
уточнять реализацию с помощью диалога или непосредственного редактирования
кода. Особенно контроль важен для поддержания архитектурных паттернов, оп­
тимизации производительности или интеграции с существующей кодовой базой.
Инструменты прототипирования выбираются исходя из этих двух важней­
ших аспектов и из характера задачи. Дизайнер, проверяющий новый сценарий
взаимодействия, отдаст приоритет скорее точности и скорости за счёт некото­
рого отказа от контроля. Разработчик, проверяющий техническую осуществи­
мость идеи, напротив, будет ценить контроль и прозрачность процесса, даже
если придётся чаще направлять процесс генерации вручную.
Но ни один из этих инструментов не выдаёт код производственного качества
без участия человека. Обычно они выдают то, что я называю «восьмидесятипро­
центным прототипом» - достаточно формальным для проверки идеи и демон­
страции результата заинтересованным лицам, но требующим дополнительной
работы перед производственной стадией. Оставшиеся 20% - это, как правило,
обеспечение безопасности, оптимизация производительности, обработка оши­
бок и архитектурная доработка.
Даже для быстрого прототипирования обязателен код-ревью. Пусть прото­
тип и не доводится до идеала, но поверхностная проверка на очевидные пробле­
мы (вроде открытых АРI-ключей или небезопасной обработки данных) не даст
возможным ошибкам проникнуть на более поздние этапы разработки. Боль­
шинство современных инструментов поддерживают прозрачность сгенериро­
ванного кода, то есть позволяют просматривать и анализировать его.
По мере дальнейшего развития экосистемы ИИ-прототипирования конкрет­
ные инструменты неизбежно будут меняться, но базовые концепции - баланс
между точностью и контролем, а также необходимость человеческого надзора останутся неизменными. Главное здесь чётко понимать цель прототипирования
и выбирать подход под конкретную задачу, будь то быстрая визуальная реализа­
ция, демонстрация функционала или техническое исследование.

От концепции к прототипу: итеративная доработка
Одна из сильных сторон ИИ-прототипирования - это итеративный цикл,
то есть процесс доработки начальной версии с помощью ИИ. Вместо того что­
бы редактировать код вручную, разработчик просто описывает нужные измене­
ния (см. иллюстрацию 6.1). Лично я сторонник более ответственного подхода,
Глава 6. Прототипирование с использованием ИИ: инструменты и техники

1

151

а не «вайб-кодинга наугад», но при работе с прототипами вполне можно вос­
пользоваться и быстрыми циклами обратной связи.

t'I

Начальный запрос
п
п
о №
и_и _ _ро_, ._тм_ _ _1
_
_
ИИ пр тотип 2
- о
№
-

о

ИИ-прототип № З

l

Изменить

- __
х__

(1 l

.,.а
___

доба ить

:

Применить
и nроrестировать

Иллюстрация 6.1. Итерати вный процесс доработки: по начальному
запросу генерируется прототип, который в дальнейшем последовательно
улучшается. При помощи ИИ создаются всё более удачные решения
Большинство ИИ-инструментов прототипирования сохраняют историю или
контекст запросов, что крайне полезно. ИИ запоминает назначение приложения
и предыдущие инструкции, так что ему не нужно объяснять всё заново при каж­
дом новом шаге. Сохранение контекста - отличительная черта среды вайб-ко­
динга, когда диалог ИИ становится своего рода журналом разработки.
Типичный процесс итеративной доработки выглядит следующим образом.
Шаг 1. Начальная генерация
Вы вводите запрос или начальные данные для создания прототипа:
Создай базовое приложение для учёта расходов с формой для добавления
расходов и таблицей для их отображения.
Шаг 2. Проверка и запуск кода
Получив сгенерированный код, вы запускаете его. Допустим, код работает,
но вы обращаете внимание на некоторые детали, которые можно улучшить.
Например, интерфейс функционален, но слишком прост, или таблица не сор­
тирует расходы.
152

1

Часть 11. Практика работы с ИИ

Шаг 3. Доработка (уточнение) запросов
Вы даёте ИИ дополнительные инструкции, например:
Сделай список расходов сортируемым по сумме или дате.
ИИ соответствующим образом изменяет код, добавляя логику сортировки
или используя библиотеку для сортировки таблиц.
Добавь цветовую стилизацию, возможно с применением современного СSS­
фреймворка.
ИИ интегрирует СSS-библиотеку (например, Tailwind или Bootstrap) или же
просто добавляет свой стиль для улучшения внешнего вида.
Добавь валидацию формы, чтобы нельзя было добавлять расход без назва­
ния и суммы.
ИИ добавляет простую фронтенд-валидацию.
Каждый такой запрос модифицирует прототип. Благодаря пониманию кон­
текста (инструменты вроде Cursor или современных чатов сохраняют состо­
яние кода), ИИ обычно добавляет изменения там, где они нужны - напри­
мер, вставляет код проверки прямо в форму или добавляет к коду таблиц
сортируемые колонки.
Шаг 4. Проверка и повторение
После каждой доработки результат проверяется. Если в коде ИИ обнаружи­
вается какая-нибудь новая ошибка или если он ведёт себя не так, как вы хо­
тели, запрос уточняется:
- сортировка идёт в обратном порядке - сделай по умолчанию сортиров­
ку по возрастанию;
- новая цветовая схема неплоха, но сделай заголовок не чёрным, а тёмно­
синим.
Каждый цикл проходит очень быстро, порой за несколько секунд, так что
за час можно выполнить десятки итераций. По сравнению с написанием кода
вручную и проверкой всех изменений разработка прототипа с помощью ИИ ока­
зывается значительно быстрее. Особенно это заметно при глобальных измене­
ниях, например при смене стиля или добавлении новой функции.
Глава 6. Прототипирование с использованием ИИ: инструменты и техники

153

Важно заметить, что работа с ИИ требует чёткой коммуникации, то есть фор­
мулировки запросов, и здесь вступают в силу навыки промпт-инжиниринга.
Чем более конкретно и ясно сформулирован запрос на изменение, тем с боль­
шей вероятностью ИИ выполнит его корректно. Например, фраза «Сделай кра­
сивее» очень расплывчата, и лучше задать ИИ-ассистенту более конкретное на­
правление:
Примени светлую тему с синим заголовком и для удобства чтения увеличь
размер шрифтов.
Если вы пользуетесь инструментами вроде Vercel vO или LovaЫe, то бывает
достаточно даже показать на часть интерфейса и написать: «Замени это на Х».
Рассмотрим небольшой пример диалоговой итерации между разработчиком
и ИИ-ассистентом:
Создай Rеасt-компонент для списка задач. Он должен отображать список
задач и текстовое поле для добавления новой задачи.
ИИ создаёт Rеасt-компонент с состоянием для задач и рендерит список, поле
ввода и кнопку для добавления задач.
Отлично. Теперь сделай каждую задачу редактируемой и добавь чек-боксы
для отметки выполненных задач.
ИИ обновляет код, отображает каждую задачу с чек-боксом и функцией ре­
дактирования. Разработчик запускает приложение и замечает, что редактирова­
ние работает, но кнопки удаления нет:
Добавь кнопку удаления для каждой задачи.
ИИ добавляет в код функционал удаления.
Макет немного тесный. Добавь базовые СSS-стили, чтобы элементы списка
расширились, и увеличь шрифт.
ИИ добавляет СSS-стили, либо как элемент <style>, либо в виде отдельного
СSS-сниппета.
Так-то лучше!
154

Часть 11. Практика работы с ИИ

Обмен командами продолжается до тех пор, пока прототип не будет соответ­
ствовать задуманной концепции. В итоге разработчик получает рабочий прото­
тип приложения для списка задач с возможностями создания, редактирования,
выполнения и удаления; всё это получилось реализовать с помощью запросов
на естественном языке и быстрых ответов ИИ.
На протяжении всего процесса разработчик остаётся «режиссёром» происхо­
дящего. ИИ предлагает способы реализации той или иной функции, но только
вам решать, отвечают ли они вашим требованиям. Иногда реализация ИИ кор­
ректна, но не соответствует ожиданиям (например, использован другой стиль
интерфейса). Вы либо соглашаетесь с ней (если это не нарушает цели прототи­
па), либо приказываете ИИ внести изменения.

Эволюция прототипа на пути к производству
Прототип - это способ проверки жизнеспособности концепции и инструмент
изучения рабочих вариантов. После того как роль его выполнена - например,
вы проверили дизайн с пользователями или получили подтверждение, что ка­
кую-то функцию действительно можно реализовать, - нужно переходить к сле­
дующему шагу, то есть к превращению прототипа в рабочее приложение. И пе­
реход этот очень важен. ИИ может помогать и на этом этапе, но превращают
прототип в реальное приложение именно люди. В этом разделе мы рассмотрим
ключевые моменты перехода от прототипа к продакшену.
Первым делом нужно внимательно проанализироватh архитектуру и струк­
туру кода. «Под капотом» прототипы часто бывают неряшливыми и запутан­
ными. Иногда весь код бывает представлен в виде одного-единственного файла,
или ради скорости приносятся в жертву читаемость и упорядоченность. Сейчас
самое время исправить структуру. Скрипт на одну страницу имеет смысл разде­
лить на несколько модулей; для веб-интерфейса - предусмотреть корректную
структуру компонентов; для бэкенда - настроить формальный архитектурный
паттерн «модель - представление - контроллер» (MVC, Model-View-Controller).
Даже если большую часть прототипа создал ИИ, именно вы, как разработчик,
лучше всего понимаете цель архитектуры. Иногда имеет смысл воспользоваться
прототипом только как ориентиром или каркасом и начать новый проект; мож­
но воспользоваться частями кода прототипа, но в целом рассматривать его как
временное решение или «одноразовый код». В других случаях разработчики по­
степенно переделывают кодовую базу прототипа (занимаются рефакторингом)
и приводят её в порядок с помощью ИИ, который предлагает решения и генерирует тесты для поддержания кода в рабочем состоянии.
Глава 6. Прототипирование с использованием ИИ: инструменты и техники

155

Далее добавьте обработку ошибок и граничные случаи. Код прототипа часто
рассчитан на «идеальный сценарий», но что, если вызов API завершится неуда­
чей? Или что произойдёт в случае пустого ввода? Систематически пройдитесь
по каждой функции и подумайте, что может пойти не так.
ИИ может помочь учесть граничные случаи, если дать ему такой запрос:
Какие для этой функции могут быть ошибки и как их обработать?
Ассистент, скорее всего, предложит некоторые сценарии (сбой сети, некор­
ректный ввод данных, проблемы параллельного выполнения), для которых мож­
но реализовать обработку или попросить помочь с реализацией искусственный
интеллект. Готовый к продакшену код - это в первую очередь устойчивый код.
Код прототипа с большой вероятностью не будет оптимизирован, поэтому
нужно проверить его на эффективность или на потенциальные уязвимости. На­
пример, ИИ может воспользоваться простым алгоритмом, неплохо работающим
для небольшого объёма тестовых данных, но слишком медленным для реальных
данных. Найдите такие участки кода и оптимизируйте их. (Распространённые
недостатки сгенерированного ИИ-кода я рассматриваю в главе 8.)
Одна из стратегий состоит в том, чтобы запускать тесты производитель­
ности или использовать профайлеры для рискованных частей прототипа,
а затем попросить ИИ оптимизировать соответствующую функцию. Обяза­
тельно проверяйте на безопасность такой функционал, как аутентификация
пользователя и обработка данных; часто ИИ предлагает решения SQL-запро­
сов без корректной параметризации (что грозит так называемой SQL-инъек­
цией) или с передачей конфиденциальной информации (https://oreil.ly!gzUjn).
Эти недочёты обязательно нужно исправлять. Согласно одному исследованию
2021 года (https:!!oreil.ly!a72lb), потенциальные уязвимости обнаруживаются
примерно в 40% сгенерированного ИИ кода, поэтому важное качество при под­
готовке прототипа к продакшену - это внимательность. Выполняйте статиче­
ский анализ и тесты безопасности вручную или дайте ИИ команду: «Проверь
этот код на уязвимости».
Прототипам часто не хватает документации, которую нужно добавлять при
формализации кода. Чёткое и проверенное человеком описание каждого моду­
ля поможет последующим разработчикам, а также вам самим при повторном
обращении к коду несколько месяцев спустя. После приведения кода в поря­
док можно приказать ИИ создать документацию API в формате Markdown или
в виде файла README, в котором будет описана работа системы. В главе 1 я пи­
сал о том, как ИИ может объяснять код, и сейчас отличный момент, чтобы вос­
пользоваться такой возможностью.
156

1

Часть 11. Практика работы с ИИ

В главе 5 говорилось о том, насколько важно тщательно тестировать прото­
тип. Можно написать модульные тесты для ключевой логики, интеграционные
тесты для основных пользовательских сценариев и так далее. Процесс можно
ускорить, попросив ИИ сгенерировать тесты:
Напиши тесты на Jest для компонента списка задач, покрывающие добавле­
ние, редактирование, выполнение и удаление задач.
Затем эти тесты выполняют и при необходимости корректируют. Хороший
набор тестов позволяет с уверенностью выполнять рефакторинг прототипа.
Иногда приходится полностью заменять отдельные части кода - например,
если в прототипе использовалась временная библиотека или некий «хаю>, непри­
годный в долгой перспективе. ИИ ускоряет и такие задачи. Допустим, в прото­
типе данные хранятся в локальных массивах, но их нужно полноценно интегри­
ровать с базой данных. Тогда можно сформулировать примерно такой запрос:
Не храни задачи в памяти. Для хранения задач подключи базу данных SQLite.
ИИ предложит решение, которое далее можно будет довести до ума.
При подобных правках полезно переключать своё мышление с режима «бы­
строго прототипирования» в режим «дисциплинированного инженера». ИИ те­
перь становится вашим помощником по обеспечению качества кода, а не про­
сто инструментом быстрой генерации. Динамика взаимодействия меняется,
и каждое предложение ИИ оценивается более критично! потому что на первый
план выходят стабильность и надёжность. Как уже отмечалось в главе 4, макси­
мальную выгоду из ИИ извлекают именно опытные разработчики, потому что
они понимают, какие предложения можно принимать, а какие нужно исправ­
лять. На этом этапе должно включаться мышление «старшего разработчика»:
чёткое представление об итоговой системе и формулировка конкретных запро­
сов по улучшению или реализации отдельных частей ПО.
Для закрепления материала рассмотрим небольшой пример. Предположим,
что разработчик-одиночка Джейн хочет создать небольшое веб-приложение для
преобразования данных из СSV-файлов в диаграммы. С помощью ИИ-ассистен­
та она за один уик-энд делает быстрый прототип - простой скрипт на Node.js
с API и несложным фронтендом для загрузки СSV-файлов и отображения диа­
грамм с помощью библиотеки визуализации JavaScript.
Она показывает этот прототип нескольким потенциальным пользователям,
и те высказываются положительно, после чего она решает превратить его в пол­
ноцен.ный продукт, веб-сервис. Далее следует этап перехода.
Глава 6. Прототипирование с использованием ИИ: инструменты и техники

157

Усиление бэкенда
В прототипе API на Node.js не было аутентификации (данные мог загру­
жать любой пользователь). Для продакшена требуется система учётных
записей и авторизации. Для интеграции системы авторизации (например,
на основе JWT) Джейн решила воспользоваться помощью ИИ. Искусст­
венный интеллект предлагает каркас решения, но Джейн не спешит ко­
пировать его, а внимательно проверяет; она убеждается, что пароли кор­
ректно хешируются, а токены обрабатываются безопасно. Также она
добавляет в конечную точку загрузки валидацию входных данных (чего
ИИ изначально не сделал), совмещая предложенный ИИ-код с собствен­
ными правками.
Рефакторинг фронтенда
Начальный фронтенд представлял собой один НТМL-файл с подключаемы­
ми через CDN скриптами. В целях поддержки кода Джейн решает перера­
ботать его в структурированное приложение React. Сначала она просит ИИ
привести проект к более ориентированному на продакшен виду с использо­
ванием системы сборки и менеджера пакетов npm вместо прямого подклю­
чения скриптов. Затем она просит ИИ помочь интегрировать функционал
в виде компонентов React. Например, код отрисовки диаграмм из прото­
типа превращается в компонент <Chart>. ИИ ускоряет процесс написания
этих компонентов, но Джейн следит за тем, чтобы код соответствовал об­
щепринятым стандартам качества, чему в прототипе уделялось мало внимания.
Тестирование и проверка производительности
Для критически важных функций (парсинг CSV, преобразование данных)
Джейн пишет модульные тесты. В случае сомнения по поводу крайних слу­
чаев, она обращается к ИИ с запросом:
Какие крайние случаи при разборе CSV стоит протестировать?
ИИ предлагает сценарии вроде пустых полей и нерегулярных столбцов,
которые она включает в тесты. Джейн также замечает, что прототип за­
гружал СSV-файлы в память целиком, что для больших файлов может
привести к сбоям. Она перерабатывает код с учётом потоковой обработ­
ки и привлекает ИИ для дополнительной проверки логики работы с по­
токами. В результате приложение надёжно обрабатывает файлы большо­
го размера.
158 1 Часть 11. Практика работы с ИИ

Финальная доработка интерфейса
Интерфейс прототипа был чисто утилитарным, и в продукте Джейн решила
уделить больше внимания пользовательскому опыту. Она просит ИИ предло­
жить вариант с адаптивной вёрсткой и, возможно, интеграцией фреймворка
CSS. ИИ добавляет фреймворк Bootstrap, с помощью которого Джейн улуч­
шает внешний вид - формы, кнопки и общую композицию. После этого
Джейн вручную настраивает отдельные СSS-стили. На этом этапе работа под­
разумевает меньше собственно программирования и больше дизайнерских
решений, но ИИ помогает тем, что предлагает код для типовых шаблонов ин­
терфейса (например, для навигационной панели или индикатора загрузки).
В итоге грубый прототип превращается в более чистое, безопасное и масшта­
бируемое приложение, готовое к работе с реальными пользователями. Джейн
уверена в его работоспособности, потому что внимательно проверила сгенери­
рованный ИИ код и пропустила его через тесты. Весь процесс превращения про­
тотипа в рабочую программу занял пару недель, тогда как разработка продукта
с нуля потребовала бы значительно больше времени. ИИ ускорил создание на­
чального прототипа и помогал на этапе перехода, но решающую роль сыграли
контроль со стороны человека и структурная переработка, обеспечившие каче­
ство финального продукта.

Проблемы, характерные для прототипирования
С ПОМОЩЬЮ ИИ
ИИ - это очень мощный инструмент прототипирования, но работа с ним со­
пряжена со своими сложностями и потенциальными проблемами. Разработчик
должен не только знать об этих «подводных камнях», но и уметь минимизиро­
вать их влияние. Две самые главные проблемы - это разрастание функционала
и сложность интеграции.
Так как добавлять новый функционал при помощи ИИ очень легко, возни­
кает соблазн добавить в прототип «ещё одну мелочь» - такое явление называ­
ется разрастанием функционала (scope creep). По мере превращения в финаль­
ный продукт прототип обрастает различными дополнительными функциями
вплоть до того, что его работоспособность оказывается под угрозой. Не забы­
вайте, главная цель прототипа - это проверка какого-то ключевого вопроса
или демонстрация основных аспектов пользовательского опыта. Всякий раз,
как у вас возникает идея добавить систему авторизации, обработки платежей
и прочие функции продакшена, задайте себе вопрос, насколько они необходимы
Глава б. Прототипирование с использованием ИИ: инструменты и техники

1

159

на этапе прототипа. Часто бывает лучше ограничиться«заглушками» (ИИ может
сгенерировать фиктивный процесс авторизации, лишь имитирующий реаль­
ный). Прототип, сосредоточенный на одной цели, экономит время, и на после­
дующем этапе от него будет легче избавиться или его будет легче переработать
в нечто более функциональное.

Не сбивайтесь с пути
Зафиксируйте цель прототипа в письменном виде (например:
«Проверить жизнеспособность идеи загрузки CSV и создания
диаграмм») - это будет ваша«путеводная звезда». ИИ помо­
жет вам как можно быстрее достичь этой цели; сопротивляйтесь искушению«отполировать до блеска» прототип и добав­
лять в него лишние детали.
Второй важный момент - интеграция с реальными системами. В прототипах
часто используют тестовые данные или упрощённые подсистемы. Если ИИ-про­
тотип работает с фиктивными данными или локальными файлами, то на этапе
продакшена его интеграция с реальными базами данных или внешними сервисами может оказаться весьма нетривиальной задачей. Важно всегда помнить, что
при создании прототипа были допущены определённые упрощения. Например,
прототип мог не отправлять электронные письма по указанным адресам, а лишь
выводить их текст в консоль. В рабочей же версии нужно будет реализовать пол­
ноценный почтовый сервис. Да, ИИ позже поможет и с интеграцией, но полезно
заранее составить список того, что«нужно будет доделать, если проект двинется
дальше». Так вы не забудете, какие решения были временными. Все эти момен­
ты стоит четко проговаривать при командной работе. Например, можно остав­
лять в коде комментарии вида«// TODO: подключить в этом месте реальный
почтовый сервис». Многие ИИ-инструменты при генерации упрощённого ре­
шения сами добавляют такие ТОDО-комментарии, что бывает очень полезно.
Зная о подобных ловушках и подводных камнях, вы будете успешно поль­
зоваться ИИ для создания прототипов. Вдумчивый подход поможет в рекорд­
ные сроки создать надёжный прототип, который впоследствии либо превра­
тится в полноценный продукт, либо будет отложен, когда из него извлекут все
нужные уроки и сделают соответствующие выводы.

160

Часть 11. Практика работы с ИИ

Итоги и дальнейшие шаги
В этой главе мы затронули тему радикального ускорения создания прототипов
с помощью вайб-кодинга. Перекладывая всю рутину по созданию кода на ИИ,
разработчики переходят от идеи к рабочей модели с беспрецедентной скоро­
стью. Были упомянуты такие инструменты, как Vercel vO для генерации пользо­
вательского интерфейса, LovaЬle для создания полноценных прототипов, а также
IDE с поддержкой ИИ, Cursor и Windsurf, каждая из которых охватывает свою
часть задач по быстрому созданию прототипов. Также был подчёркнут итера­
тивный характер работы с ИИ: генерация, тестирование и доработка в корот­
ких циклах, в которых запросы на внесение изменений задаются на естествен­
ном языке.
Отдельно обсуждался такой важный аспект, как переход к разработке про­
мышленного варианта приложения (продакшен). Несмотря на то что с помо­
щью ИИ рабочую демонстрацию приложения можно получить за считаные
часы, прототип ни в коем случае нельзя воспринимать как финальный продукт.
Это лишь его первый черновик. Разработчикам в любом случае придётся пе­
ределывать архитектуру и «укреплять» код. ИИ помогает и на этом этапе тем,
что предлагает варианты улучшений, генерирует тесты и т. д. Как специалисты­
одиночки, так и коллективы сообщают о реальном росте продуктивности, ко­
гда прототипы создаются за несколько дней, а не за несколько недель, благодаря
чему получае_тся быстрее получать обратную связь от пользователей и прини­
мать бизнес-решения.
К этому моменту вы, наверное, уже поняли, что вайб-кодинг делает про­
цесс прототипирования похожим скорее на мозговой штурм с ассистентом, чем
на рутинное создание шаблонного кода. Это принципиально иной подход: более
интерактивный, более высокоуровневый и значительно более быстрый. Но даже
при быстром прототипировании важно уделять внимание качеству кода и тем
более не следует забывать о качестве во время превращения кода в полноцен­
ный продукт.
В главе 7 я перейду от темы быстрого прототипирования к теме комплексной
разработки веб-приложений с поддержкой ИИ. Если прототипирование - это
проверка возможных решений, то масштабная работа подразумевает системный
подход к архитектуре, реализации и развёртыванию.

ГЛАВА 7

Создание веб-приложений
с помощью ии
В этой главе мы переходим от запросов для быстрого создания прототипов к раз­
работке полноценных веб-приложений с помощью ИИ. Под веб-приложением
обычно подразумевают фронтенд ( часто на фреймворках вроде React, Angular
или Vue), бэкенд (API, базы данных, серверы) и связующий слой, объединяю­
щий всё в единую систему. Вайб-кодинг позволяет ускорить работу на каждом
из этих уровней.
Я опишу сквозной рабочий процесс создания веб-приложения с ИИ в роли
парного программиста, в том числе следующие этапы:
- настройка проекта и его базовой структуры;
- разработка пользовательского интерфейса;
- реализация серверной логики;
- интеграция с базой данных;
- тестирование и проверка всего стека целиком.
По ходу изложения будут выделены типовые паттерны разработки с ИИ для
фронтенда (например, такой, как генерация компонентов React или Vue по тек­
стовому описанию) и для бэкенда (создание маршрутов, бизнес-логики и запро­
сов к базе данных на естественном языке). Также будет рассмотрена оптимиза­
ция взаимодействия между человеком и ИИ в полноформатном проекте, когда
каждая сторона вносит в проект свой наибольший вклад. К концу главы у вас
сформируется чёткое представление о том, как использовать ИИ не только для
отдельных задач программирования, но и для эффективного управления всем
процессом веб-разработки в целом.

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

1

Часть 11. Практика работы с ИИ

файлов, зависимостей и прочего. ИИ позволяет автоматизировать большую
часть этого шаблонного этапа. В современных веб-фреймворках часто имеются
утилиты с интерфейсом командной строки (CLI, Command Line Interface), с по­
мощью которых можно создать базовый проект, но потом всё равно приходит­
ся дополнительно его настраивать или подключать к нему нужные библиотеки.
ИИ-ассистент может либо подсказывать по работе с этими инструментами на
каждом шаге, либо сразу по запросу формировать структуру будущего проекта.
Допустим, мы приступаем к работе над новым проектом, в котором для фрон­
тенда (клиентской части) будет использоваться React, а для бэкенда (серверной
части) - Express. Раньше процесс выглядел бы следующим образом:
1. Запускаем CLI-инструмент или Vite для настройки React.
2. Инициализируем приложение на Express (например, с помощью np111 i.ni.t
и установки Express).
3. Настраиваем прокси для режима разработки или включаем CORS (сов­
местное использование ресурсов между источниками, Cross-Origin
Resource Sharing) (https:!!oreil.ly!bgwlV), чтобы клиентская часть на React
взаимодействовала с сервером на Express.
4. При необходимости подключаем базу данных, например MongoDB, или
настраиваем файл SQLite для простого варианта использования.
Теперь же вместо всех этих шагов можно прямо в среде разработки (IDE)
с поддержкой ИИ (такой как Cursor или Cline) описать нужную конфиrурацию
будущего приложения в одном запросе, например:
Создай новый проект с фронтендом на React (с использованием Vite)
и бэкендом на Express. Бэкенд должен предоставлять REST API для
списка задач и на начальном этапе использовать массив в памяти.
Настрой фронтенд так, чтобы в режиме разработки запросы к API прокси­
ровались на бэкенд.
IDE с интегрированным ИИ по этой инструкции выполняет следующие шаги:
- создаёт два каталога (frontend и backend);
- запускает npl'l create vi.te@latest (если у IDE есть доступ к оболочке)
либо генерирует шаблон базового приложения React;
- инициализирует базовый файл сервера Express в каталоге backend с конеч­
ной точкой типа /api/todos, возвращающей тестовые данные;
- добавляет package.json в каждый каталог с нужными скриптами (напри­
мер, для запуска фронтенда и бэкенда);
Глава 7. Создание веб-приложений с помощью ИИ 1 163

- настраивает взаимодействие между фронтендом и бэкендом либо через
прокси в сервере разработки React, либо через добавление заголовков CORS.
Так за пару минут мы получаем каркас полнофункционального веб-прило­
жения «фронтенд + бэкенд». Даже если ИИ и не выполняет все шаги полностью
автоматически, он, как правило, выдаёт код и чёткие инструкции для заверше­
ния настройки (например: «Добавь эту настройку прокси в файл package.json
в React»). В результате экономится огромное количество времени на шаблонную
конфигурацию, и вместо утомительной и скучной настройки разработчики мо­
гут сразу сосредоточиться на реализации функционала.
Но даже если вы не пользуетесь IDE с интеграцией ИИ, то примерно то же са­
мое можно делать пошагово в ChatGPT или с помощью другого ИИ-ассистента.
Взаимодействие с ним выглядит примерно так:
Я хочу создать новое приложение на React. Какие команды нужно для это­
го выполнить?
ИИ перечислит нужные шаги или предложит воспользоваться более совре­
менными инструментами создания приложений, такими как Vite или Next.js.
Теперь настрой сервер на Express с маршрутом /api/to-dos.
ИИ сгенерирует код сервера Express, который затем можно будет скопиро­
вать в файл.
Как подключить приложение React к этому API в режиме разработки�
В ответ ИИ либо предложит настройку прокси, либо объяснит, как вызывать
API напрямую (включая полный адрес, если не используется прокси).
Так даже базовая настройка проекта вместо утомительного поиска нужной
информации в куче справочных документов превращается в диалог. Как уже
говорилось в предыдущих главах, суть «программирования с намерением>> за­
ключается в том, что разработчик формулирует желаемый результат, а ИИ сам
подбирает нужные шаги. Настройка проекта - идеальный сценарий такого
взаимодействия.
На этом этапе важно настоять на своём архитектурном решении и просле­
дить за тем, чтобы ИИ следовал намеченному вами курсу. Архитектура и ре­
шения верхнего уровня - это сфера ответственности человека, поэтому весь
стек и основные паттерны (типовые приёмы разработки) разработчик должен
164

1

Часть 11. Практика работы с ИИ

определять самостоятельно. Будет ли в проекте монорепозиторий или отдель­
ные репозитории для фронтенда и бэкенда? Использовать REST или GraphQL?
Какую базу данных выбрать?
Определившись с выбором, разработчик даёт ИИ конкретные указания, на­
пример:
Настрой также базовую схему Prisma для базы данных SQLite.
Или:
Вместо REST используй сервер GraphQL.
ИИ не всегда идеально справляется со сложной конфигурацией, но основную
часть работы он выполнит, а детали можно будет доработать вручную.
Многие опытные разработчики автоматизируют эти шаги с помощью про­
ектных шаблонов или генераторов заготовок, но ИИ предлагает более гибкий
подход, когда конфигурацию можно настраивать на ходу на основе запросов
на естественном языке. Такой подход особенно полезен в случае нетипичного
проекта (например, вместо привычных двух уровней вам нужно три уровня сер­
виса или вы хотите заранее настроить конкретную библиотеку вроде Tailwind
CSS) - для этого достаточно просто попросить ИИ добавить нужные компо­
ненты.

Паттерны (типовые приёмы) разработки фронтеttда с ИИ
После того как каркас проекта готов, самой трудоёмкой частью становится раз­
работка фронтенда (клиентской части) веб-приложения. В этом разделе мы по­
говорим о том, как пользоваться ИИ в роли напарника-программиста при на­
писании кода фронтенда.

Реализация компонентов по описанию
Можно просто попросить ИИ создать компоненты по их описанию, например:
Создай Rеасt-компонент TodoList, который принимает список задач и ото­
бражает их. Для каждой задачи нужно показывать название и флажок для
отметки выполненной задачи.
ИИ должен сгенерировать код функционального компонента с нужными
свойствами (props) и состоянием.
Глава 7. Создание веб-приложений с помощью ИИ

1 165

Создай компонент Vue для формы входа с полями для ввода имени пользова­
теля и пароля, при отправке которых генерируется событие с данными формы.
ИИ, скорее всего, покажет код для компонентов <te111plate>, <scri.pt>
и <style>. Вам, как разработчику, не придётся корпеть над шаблонным кодом,
и вы сразу получите готовую структуру, которую потом можно будет легко до­
работать. ИИ также часто добавляет базовую валидацию или управление состо­
янием, если в запросе подразумевается их наличие.
Главное на этом этапе - следить за согласованностью всех компонентов, иначе
потом нужно будет ещё приводить их в соответствие между собой. Например, если
список задач TodoLi.st ожидает элементы в определённом формате (входные данные
props), убедитесь, что любой компонент, использующий Todol i.st, передаёт данные
именно в таком виде. Для этого либо описывайте все связанные между собой ком­
поненты в одном запросе (чтобы ИИ представлял общую картину), либо свяжите
компоненты самостоятельно и попросите ИИ исправить несоответствия.

Стилизация и вёрстка
Оформление приложения с помощью CSS и прочих средств бывает утомитель­
ным. Но и здесь вам на помощь придёт ИИ. Достаточно только будет описать
нужный вам внешний вид, а всеми деталями займётся искусственный интеллект.
- Создай стиль для компонента списка задач (to-do list): для отображения
списка используй flех-контейнер, добавь отступы и измени цвет текста
выполненных задач на серый с перечёркиванием.
- Компонент авторизации расположи по центру страницы и сделай поля
ввода больше с округлыми границами.
В зависимости от контекста ассистент выдаёт код CSS-in-JS, обычного фай­
ла CSS или встроенных стилей. При использовании фреймворка вроде Tailwind
CSS можно попросить ИИ сгенерировать соответствующие классы (но учтите,
что полностью синтаксис Tailwind знают не все модели).
Смысл в том, чтобы итеративно дорабатывать дизайн, не занимаясь ручной
настройкой всех свойств CSS. Так вы сосредоточитесь на решениях более высо­
кого уровня, то есть на общем оформлении, а не на расписывании каждого от­
ступа 111argi.n или цвета соlог.

Интеграция с API и управление состоянием
Фронтенду веб-приложений часто нужно получать данные с бэкенда и управлять
состоянием с помощью Redux, контекста или простого состояния компонентов.
166

Часть 11. Практика работы с ИИ

Написать блоки кода интеграции вам поможет ИИ с помощью примерно таких
запросов:
- добавь код для получения списка задач с /api.fto-dos при подключении
компонента Todol i.st и сохрани его в состоянии;
- реализуй функцию в Тodol i.st, которая при переключении флажка от­
правляет РОSТ-запрос на /api/to-dos/{id}!complete и соответствующим
образом обновляет состояние.
ИИ может сгенерировать хук useEffect в React для выполнения запроса или
хук мounted() в Vue. Также он может создавать заглушки для НТ ТР-вызовов
(с помощью fetch, Axi�s и т. д.). Вам нужно будет только убедиться, что конеч­
ные точки API и формат данных совпадают с ожиданиями бэкенда (если он уже
реализован или у вас есть его спецификация).
Если бэкенд ещё не готов, можно одновременно создавать его с помощью
ИИ, о чём мы поговорим ниже. ИИ позволяет разрабатывать фронтенд и бэк­
енд параллельно, так как каждый можно описывать и генерировать относи­
тельно независимо, если не забывать отслеживать интерфейс взаимодействия
между ними.
Работа со сложной логикой под руководством ИИ
Если фронтенд содержит сложную логику, например динамические правила ва­
лидации форм, условный рендеринг или запутанные пользовательские взаимо­
действия, то их можно реализовывать пошагово с помощью ИИ. Здесь хорошо
себя показывает метод разбиения сложной задачи на час�и:
Добавить функционал: когда пользователь отмечает задачу как «выполнен­
ную», элемент списка постепенно исчезает (СSS-переход) и через 1 секун­
ду удаляется из списка.
ИИ сгенерирует код, который добавляет СSS-класс для отмеченного элемен­
та, удаление элемента по времени и плавное исчезновение средствами CSS.
Форма имеет необязательное поле «Заметки». Показывай текстовое поле,
только если включён флажок «Добавить заметки».
ИИ умеет менять состояние компонента и код JSX для условного рендерин­
га заметок.
Каждое из таких изменений можно оформлять отдельным итеративным за­
просом. По сути, разработчик описывает поведение интерфейса, а ИИ пишет
Глава 7. Создание веб-приложений с помощью ИИ

167

соответствующий этому поведению код. После каждого изменения не забывай­
те протестировать результат и убедиться, что всё работает как ожидалось.
Советы по конкретным фреймворкам
Для разных фреймворков характерны свои особенности.
- React: ИИ может использовать хуки (такие как useState, useEffect). Сле­
дите за тем, чтобы они соответствовали общепринятым правилам (напри­
мер, проверяйте, правильно ли указан массив зависимостей в useEffect).
- Vue: ИИ умеет генерировать код в стиле Options API или Composition API,
в зависимости от примеров, на которых проходило его обучение. Если вы
предпочитаете конкретный стиль, уточните его в запросе (например: «Ис­
пользуй Vue 3 Composition API» ).
- Angular : ИИ умеет генерировать компоненты, но у Angular более кру­
той порог входа. По запросу ИИ может прописать шаблоны, классы
на TypeScript и базовую инъекцию сервисов, но структуру, скорее всего,
придётся создавать вручную или пользоваться интерфейсом командной
строки Angular, после чего просить ИИ заполнять конкретные части (на­
пример, логику валидации формы).

Паттерны (типовые приёмы) разработки бэкенда и API
спомощьюИИ
Перейдём теперь к бэкенду. Работа с ИИ здесь строится по тому же принципу, что и при создании фронтенда. Вы в запросе описываете, какие вам нуж­
ны конечные точки, модели данных и логика, а ИИ генерирует код. К типичным
компонентам бэкенда относятся обработчики маршрутов, бизнес-логика, взаи­
модействие с базой данных и валидация. ИИ помогает с каждой из этих задач,
ускоряя процесс разработки и сокращая объём рутины.
Реализация конечных точек API
Предположим, вы создаёте RESTful API для приложения списка задач (to-do list),
и конечные точки у вас такие: GET /to-dos, P0ST /to-dos, PUT /to-dos/:i.d,
DELETE /to-dos/:i.d.
В таком случае можно прорабатывать каждую конечную точку по отдельности.
В приложении Express добавь маршрут GET /api./to-dos, возвращающий
список задач (пока просто массив в памяти).
Добавь маршрут P0ST /api.fto-dos, который принимает JSON-тeлo и добав­
ляет новую задачу в список. Возвращай созданную задачу (new to-do) с 1D.
168

1

Часть 11. Практика работы с ИИ

ИИ создаст соответствующие обработчики маршрутов Express, например
app.get('/api/to-dos', ...). Если в запросе указано, что вы используете Express
с JSON, ИИ может добавить промежуточный обработчик (middleware), если он
ещё не подключён:
app.use(express.json())

По мере увеличения объёма бэкенда можно попросить ИИ провести его ре­
факторинr:
Вынеси маршруты Express в отдельный модуль маршрутизации.
ИИ разобьёт маршруты на отдельные файлы, как это рекомендуется для под­
держки кода.

Интеграция с базами данных
При работе с прототипом можно хранить данные и в памяти, но для полно­
ценного приложения нужна база данных. Предположим, вы выбираете между
MongoDB и PostgreSQL. Можно дать ИИ такой запрос:
Интегрируй MongoDB в Ехрrеss-приложение с помощью Mongoose. Создай мо­
дель задач с полями: title (строка), completed (логическое значение). Измени мар­
шруты GET/POST так, чтобы вместо массива в памяти использовать базу данных.
ИИ сгенерирует определение модели Mongoose и изменит обработчики мар­
шрутов так, чтобы они работали с базой данных (например, Todo. fi.nd() для GET
и Todo. create() для POST). Для SQL можно попросить настроить ОRМ, напри­
мер с помощью инструментов Pris m a или Sequelize. Учтите, что при этом нужно
будет указать конфигурацию (например, строку подключения к базе).ИИ напи­
шет общий код, хотя вряд ли будет знать URI вашей базы данных, и его, скорее
всего, придётся вставлять вручную.

Бизнес-логика и валидация
Если для сервера предусмотрены какие-то специфические правила (например,
нельзя удалять задачу, помеченную как важная, или заголовки списков должны
быть уникальными), их можно также реализовать с помощью ИИ:
Добавь проверку на маршруте POST /api/to-dos: отклонять запрос, если за­
головок пустой или длиннее 100 символов, и возвращать статус 400.
Глава 7. Создание веб-приложений с помощью ИИ

169

ИИ вставит соответствующие проверки и отправит соответствующие ответы.
Добавь логику: когда весь список помечен как выполненный (например, че­
рез PUT /api/to-dos/: id), и если выполнены все задачи, вывести сообщение
«Все сделано!».
ИИ добавит соответствующую логику в обработчик PUT.
Итак, вы описываете правила и требования на естественном языке, а ИИ вно­
сит в код соответствующие поправки. В любом случае нужно обязательно про­
верить код и убедиться, что он работает, как было задумано.

Использование фреймворков и шаблонов
Многие серверные веб-приложения поверх чистого Express используют фрейм­
ворки (например, NestJS для Node или Django для Python). ИИ умеет работать
и с ними, хотя более сложные задачи иногда приходится разбивать на части.
- Для Django (Python) можно дать следующую команду:
Создай модель Django для списка задач (to-do) с полями Х и соответст­
вующие представления для списка и создания.
- При условии знакомства с контекстом ИИ может сгенерировать код моде­
ли и общий обработчик или DRF (Django REST Framework).
- Если вы работаете с Ruby on Rails, ИИ поможет вам в создании моделей
и контроллеров. Можно пользоваться встроенным генератором Rails,
а ИИ будет добавлять валидацию или настраивать маршруты.
Эффективность ИИ-моделей бывает разной, в зависимости от языка про­
граммирования и технологического стека; способности ИИ во многом зависят
от набора его обучающих данных. Модели способны работать с любым языком,
с которым они сталкивались во время обучения, но не все владеют тем или иным
языком в равной степени. Обычно лучше поддерживаются языки с большим ко­
личеством открытого кода, документации и образовательных материалов в от­
крытых источниках, такие как JavaScript, Python и Java.
Определить, в какой степени ИИ владеет выбранной технологией, можно
с помощью практических тестов. Начните с простых задач на целевом языке
и постепенно усложняйте их, чтобы получить представление о возможностях
модели. Обращайте внимание t!З то, соответствует ли сгенерированный ИИ-код
принятым в языке соглашениям, узнаёт ли ИИ популярные фреймворки и биб­
лиотеки без подробных объяснений и предлагает ли он подходящие паттерны
проектирования для конкретной экосистемы. О хорошем знакомстве с той или
170

Часть 11. Практика работы с ИИ

иной технологией свидетельствуют удачные и соответствующие текущей зада­
че предложения, тогда как о плохом знакомстве говорит слишком общий или
устаревший код.
Многие разработчики ИИ публикуют документацию с описанием возмож­
ностей своих моделей, но в ней редко перечисляются подробные показатели для
конкретных языков. Самый надёжный способ убедиться, что ИИ имеет пред­
ставление о технологии, - это эксперименты. Например, при работе с Ruby
on Rails проверьте, понимает ли модель соглашения Rails, такие как паттерны
ActiveRecord, и умеет ли она генерировать корректные тесты RSpec. Для новых
или не слишком популярных фреймворков результаты бывают более непредска­
зуемыми, поэтому лучше предоставлять в запросах дополнительный контекст
и тем самым компенсировать возможные пробелы в обучении модели.
Оркестровка многоэтапных операций
Некоторые конечные точки могут включать несколько шагов - например, со­
здание записи в одной таблице, затем создание записи в другой таблице или вы­
зов внешнего API. Для таких операций нужно перечислить последовательность
действий, на основе чего ИИ подготовит черновой вариант:
При регистрации нового пользователя (POST /api/users) нужно создать
запись пользователя и одновременно отправить приветственное сообще­
ние через API SendGrid.
ИИ сгенерирует код для сохранения пользователя (например, с использова­
нием объектно-реляционного отображения, ОRМ), а затем пропишет НТТР-за­
прос к API SendGrid с соответствующим набором данных. Вам останется толь­
ко подставить реальные ключи API или отредактировать текст сообщения,
но основная рутинная часть будет уже готова.
Пропиши транзакцию: при переводе денег (POST /api/transfer) нужно спи­
сать средства с аккаунта А и зачислить на аккаунт В; сделай операцию ато­
марной («всё или ничего»).
Если вы используете ОRМ или базу данных с поддержкой транзакций, ИИ
может использовать эти функции (например, блок транзакций SQL или метод
транзакций ОRМ). Код такого рода обязательно нужно внимательно проверять
на корректность, особенно логику транзакций, которая бывает довольно слож­
ной. Впрочем, с помощью того же ИИ можно предусмотреть типовые ошибки
и добавить проверки.
Глава 7. Создание веб-приложений с помощью ИИ

171

Например, по запросу на создание конечной точки перевода денег ИИ сгене­
рировал код следующей структуры:

async function transferMoney(froмAccountld, toAccountld, aмount) {
const session = await db.startSession();
tгу {
await session.staгtTransactton();
// Списание со счёта источника
const sourceAccount = await Account.findByldAndUpdate(
froмAccountld,
{$tnc: {balance: -aмount}},
{session, new: true}
);

if (sourceAccount.balance < 0) {
throw new Еггог('Недостаточно средств');
}

// Зачисление на счёт получателя
await Account.findByldAndUpdate(
toAccountld,
{$inc: {balance: aмount}},
{session}
);

await session.coммitTransaction();
retuгn {success: true};
} catch (еггог) {
await session.abortTransactton();
throw еггог;
} fina11y {
session.endSession();
}

172

Часть 11. Практика работы с ИИ

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

Составление документации и тестирование API
При разработке API можно поручить ИИ сгенерировать соответствующую доку­
ментацию. Например, по запросу «Составь краткую документацию для конеч­
нь1х точек !api!to-dos» он может выдать что-то вроде следующего:

GЕТ /api./to-dos- возвращает список задач.
POST /api./to-dos- создаёт новую задачу. Ожидается JSON: {ti.tle:
stri.ng}. Возвращает созданную задачу.
Такая документация очень удобна для быстрого ознакомления с особенно­
стями проекта и для передачи информации разработчикам фронтенда в команде.
Кроме того, ИИ можно использовать для генерации тестов API с помощью таких
фреймворков, как Jest или Mocha для Node.js или PyTest для Python. Например,
по запросу «Создай тесты для API списка задач to-dos (один для получения спи­
ска, один для создания, один для проверки ошибок валидации)» ИИ выдаст код
тестов, который можно выполнить и проверить работу API.

Проектирование и интеграция баз данных
Чтобы создать проект базы данных, нужны специальные знания, и здесь осо­
бую роль играет подготовка специалиста, но ИИ помогает написать код проек­
та (например, в виде скриптов миграции или моделей ОRМ). Кроме того, если
вы не уверены в эффективности своей схемы, ИИ поможет вам провести моз­
говой штурм.
Допустим, ваше приложение переросло из простого списка задач в полно­
ценный проект управления проектами и теперь вам нужно спроектировать не­
сколько таблиц: «Проекты» (Projects), «Задачи» (Tasks), «Пользователи» (Users)
и т. д. Для этого можно спросить ИИ: «Какие модели данных нужны для просто­
го приложения управления проектами с пользователями, проектами и задачами?
Укажи связи между ними».
ИИ может предложить, например, такой вариант:
Глава 7. Создание веб-приложений с помощью ИИ

173

- User (id, name, email и т. д.)
- Project (id, name, owner_id - ссылка на User)
- Task (id, descr iption, project_id, assigned_to - User, status и т. д.)
Может, такая организация и не совсем подойдёт для окончательного вариан­
та, но послужит хорошей отправной точкой для последующей разработки. Далее
структура уточняется и дорабатывается, после чего реализуется в коде.

Использование ORM
При работе с ОRМ, такими как Prisma, Entity Framework или SQLAlchemy, ИИ
можно использовать для генерации классов моделей или описаний схемы.
Например, можно задать следующий запрос:
С помощью Sequelize (для Node.js) определи модели пользователя, проекта
и задач (User, Project и Task) с такими связями: для одного пользователя User
может быть много задач Projects, каждая задача Project принадлежит опре­
делённому пользователю User ; для каждого проекта Project может быть не­
сколько задач Tasks, и каждая задача Task принадлежит какому-то опреде­
лённому проекту Project; каждая Task может быть назначена пользователю
(схема many-to-one).
ИИ должен выдать код на JS/TS определения этих моделей Sequelize и связей
между ними, и разработчик интегрирует его в кодовую базу. Заодно ИИ может
предложить внешние ключи или правила каскадного удаления, если ему знако­
мы эти механизмы.
Если же вы не пользуетесь ОRМ и пишете миграции на чистом SQL, можно
поручить ИИ подготовить сами миграции:
Напиши SQL-скрипт для создания таблиц пользователей, проектов и задач
(users, projects, tasks) с соответствующими внешними ключами.
ИИ вернёт DDL-скрипт SQL, который перед выполнением нужно будет про­
верить.

Запросы к базе данных
При интеграции базы данных часто бывает нужно прописывать запросы слож­
нее базовых СRUD-операций. Допустим, вы хотите получить все проекты вместе
174

1

Часть 11. Практика работы с ИИ

с их задачами и пользователями для каждой задачи, а это объединение данных
из таблиц Project, Task и User. Запрос можно сформулировать следующим обра­
зом:
Напиши SQL-зaпpoc, возвращающий проекты с задачами и именем пользо­
вателя для каждой задачи.
В ответ ИИ попытается сгенерировать соответствующий SQL-зaпpoc с объ­
единением таблиц.
Или, если используется ОRМ, запрос может быть таким:
Получи все проекты с соответствующими задачами и именами пользовате­
лей для каждой задачи с использованием Sequelize.
В этом случае выданный ИИ код должен содержать механизм загрузки свя­
занных данных вроде такого:
tnclude: [Task, {�odel: User, as: 'asstgnedUser'}]

Проверка сгенерированного ИИ кода запросов
Сгенерированный ИИ код операций с базами данных нужно тщательно прове­
рять на соответствие реальной схеме работы с учётом сохранения целостности
данных. Если не предоставить ИИ информацию в явном виде в запросе, он мо­
жет и не знать точные имена таблиц, полей или связей, и даже при наличии у мо­
дели контекстной памяти нужно включать подробности схемы в каждый слож­
ный запрос, связанный с базой данных. Так вы избежите типичной проблемы,
когда ИИ ссылается на обобщённые имена полей вроде user_i.d, тогда как в ре­
альной схеме используется, например, имя user!d или custol'ler_ref.
Проверять код нужно и для обеспечения производительности. Да, ИИ имеет
какое-то понятие о базовых концепциях баз данных, таких как первичные клю­
чи (primary keys) и соединения (joins), но он не всегда предлагает оптимизиро­
ванные решения - например, не всегда добавляет индексы для часто использу­
емых полей или учитывает план выполнения запросов. Сгенерированный код
запросов нужно обязательно проверять на эффективность, особенно если пред­
полагается, что он будет выполняться часто или обрабатывать большие объё­
мы данных.
Ещё одна критически важная сфера, в которой нужно явно задавать требо­
вания - это правила согласованности данных. Для операций удаления нужно
Глава 7. Создание веб-приложений с помощью ИИ

175

задать ожидаемое каскадное поведение. Например,если предполагается удалять
запись проекта (Projects),то нужно реШJ:fТЬ,должна ли база автоматически ка­
скадно удалять связанные с ним задачи (Tasks) или же их будет удалять логика
приложения. В запросах сообщайте ИИ эти правила,например,так:
Для удаления проекта настрой каскадное удаление всех связанных задач.
Или так:
При удалении проекта сначала нужно проверить наличие задач и запретить
удаление,если они есть.
Если дать ИИ чёткие указания, он может корректно реализовать любой
из указанных вариантов. Для каскадного удаления это может быть ограниче­
ние внешних ключей с помощью опции ON DELETE CASCADE. Для обработки
на уровне приложения ИИ выдаст код,проверяющий перед удалением наличие
связанных записей. Главное здесь - явно указывать требования к целостности
данных,а не надеяться,что ИИ сам предусмотрит корректное поведение в кон­
кретной предметной области.

Полностековая интеграция: объединение фронтенда
и бэкенда
После того как с помощью ИИ будут созданы фронтенд и бэкенд,следующей
задачей станет их интеграция в полноценное веб-приложение. Конечные точки
API должны при этом корректно вызываться из фронтенда,данные должны кор­
ректно передаваться,и вся система должна работать согласованно.

Контрактное взаимодействие
фронтенда и бэкенда
------------

Фронтенд (клиент) ожидает данные в определённом формате,и отправляемые
бэкендом (сервером) данные должны этому формату соответствовать. Такое со­
гласование играет важнейшую роль,и при несогласованных данных приложение
корректно работать не будет. Если позволить ИИ работать над каждой частью
отдельно,то могут возникнуть небольшие несоответствия {например,бэкенд
возвращает данные в виде {success: true, data: [ ... ]},тогда как фрон­
тенд ожидает получить массив напрямую). Для согласованности можно явно

176

1

Часть 11. Практика работы с ИИ

указывать формат ответа в запросе при разработке обеих частей. Другой вари­
ант - после завершения работы над обеими частями выполнить сквозной тест:
например, открыть веб-приложение и проверить, загружается ли список. Если
он не загружается, нужно проверить сообщения в консоли браузера с логами
сервера.
Для корректировки соответствия я часто пользуюсь помощью ИИ.
- Если бэкенд возвращает данные в формате JSON с именами ключей, кото­
рые отличаются от ожидаемых фронтендом, то можно попросить ИИ ис­
править имена в одной из частей. Например, так:
Измени код так, чтобы в JSON задачи назывались tasks (во множествен­
ном числе) вместо taskList (в единственном).
- Если фронтенд отправляет данные формы в виде form-encoded, а сервер
ожидает их в формате JSON, можно попросить ИИ преобразовать их, на­
пример, с помощью JS0N. stri.ngi.fy на фронтенде или с помощью body­
parser на сервере.

Взаимодействие с ИИ в реальном времени
На этапе интеграции особенно полезными будут IDE с ИИ-ассистентами, храня­
щие контекст всего проекта, такие как Cline или Cursor. В них можно рядом от­
крыть файлы фронтенда и бэкенда и написать примерно такой запрос:
Убедись, что fetch к /api/to-dos во фронтенде соответствует ожидаемому
формату запроса/ответа на сервере. Исправь любые несоответствия.
ИИ подкорректирует код (например, добавит команду awai.t response.
json() на фронтенде, если её не было, или подправит структуру JSON).

Управление состоянием и синхронизация
Для полноценного веб-приложения стоит продумать индикацию состояния за­
грузки и обработки ошибок при неудачных АРI-запросах - так приложение бу­
дет выглядеть более профессионально. Запросы могут быть примерно такими:
Добавь индикаторы загрузки: когда компонент React получает задачи, пока­
зывать текст «Загрузка ... >> до окончания загрузки.

Глава 7. Создание веб-приложений с помощью ИИ

177

Или такими:
Добавь обработку ошибок: если АРI-запрос проходит неудачно (код ответа
не 200), отображать сообщение об ошибке в интерфейсе.
ИИ добавит состояние i.sloadi.ng и условный рендеринг или обернёт fetch
в конструкцию try /catch для перехвата ошибок. Так приложение станет более
надёжным.

Веб-сокеты и расширенная интеграция
Если приложение нужно обновлять в реальном времени (например, с использо­
ванием WebSockets или SSE), можно дать следующую команду:
Настрой WebSocket с помощью Socket.io. Когда на сервере создаётся новая
задача, транслируй её всем подключённым клиентам. Измени фронтенд так,
чтобы он прослушивал новые задачи и добавлял их в список в реальном
времени.
Это сложная задача, но ИИ может сгенерировать серверную часть для Socket.
io (например, i.o.on ( 'connecti.on' , ... ) и отправку события при создании но­
вой задачи), а также клиентский код для подключения и обработки события. Ко­
нечно, при интеграции разработчик должен проявлять повышенное внимание,
но всё равно впечатляет сама такая возможность - получить рабочий код для
работы в реальном времени на основе описания. Если решение не сработает иде­
ально с первого раза, нужного результата можно добиться с помощью итератив­
ных корректировок запросов и тестов.

Пример полностековой реализации с помощью ИИ
Рассмотрим для примера процесс работы над простым веб-приложением для
управления контактами.
- Сначала, как описывалось в первой части главы, создаётся каркас фрон­
тенда на React и бэкенда на Node/Express.
- Для фронтенда вы просите ИИ создать компоненты ContactList
и ContactForm. Затем добавл�те АРI-вызовы:
В ContactList нужно получать (fetch) список контактов с /api/contacts.
В ContactForm при отправке формы нужно отправлять POST на /api/contacts
с данными формы и обновлять список контактов при успешном ответе.
178

1

Часть 11. Практика работы с ИИ

- Для бэкенда можно сначала использовать массив в памяти или сразу под­
ключить базу данных. Затем добавляются маршруты Express: GET /api/
contacts для возврата списка и POST /api/contacts для добавления контак­
та в базу или в массив.
- Попробуйте добавить контакт через пользовательский интерфейс. Если
он не появился в списке, выполните отладку; может оказаться так, что
маршрут POST возвращает новый контакт некорректно или фронтенд
не обновляет список. Исправьте ошибку с помощью ИИ:
После добавления контакта бэкенд должен вернуть объект новоrо кон­
такта, а фронтенд добавить его в список без полной перезагрузки.
ИИ постарается подправить логику ответа бэкенда и обновления состоя­
ния фронтенда (например, через обновления состояния React).
- Аналогичным образом реализуются функции редактирования и удале­
ния: ИИ занимается рутинной работой, а вы сосредотачиваетесь на по­
ведении функции.
Если бы младший разработчик занимался всем этим вручную, то он бы по­
тратил на создание такого приложения неделю или две, но с помощью ИИ, зани­
мающегося шаблонным кодом и связями, с подобной задачей можно справить­
ся за день-другой.
Оптимизация взаимодействия человека и ИИ при полностековой разработке
При работе со всем стеком полезно выработать продуктивный ритм работы
с ИИ-ассистентом. Вот несколько стратегий такого взаимодействия.
Использовать ИИ для рутинного кода, уникальную логику писать самостоятельно
Подумайте, какие части кода будут рутинными и шаблонными, а в каких бу­
дет содержаться ключевая логика. ИИ может генерировать CRUD-API или
стандартные компоненты, но сложную логику - например, проприетарные
алгоритмы или специфическое бизнес-правило - пишите вручную, после
чего просите ИИ проверить или протестировать её. Воспринимайте такую
работу как делегирование повторяющихся задач ИИ, тогда как всю ответст­
венность за новые и уникальные решения несёте вы сами.
Использовать ИИ для последовательной проработки списка задач
В ходе разработки ведите список задач (новые функции, исправление ошибок
и т. д.). Каждую задачу по отдельности описывайте ИИ, чтобы он предлагал
Глава 7. Создание веб-приложений с помощью ИИ

179

варианты её решения. Например, для задачи «Реализовать хеширование па­
ролей при регистрации пользователя» можно сформулировать следующий
запрос:
Добавь хеширование пароля с использованием bcrypt в маршрут POST /api/
register перед сохранением пользователя.
Такой целенаправленный и системный подход поможет не упустить ничего
важного.
С помощью ИИ улучшать качество кода по мере работы
После реализации какого-либо функционала можно попросить ИИ проде­
лать рефакторинr или оптимизирощ1ть функцию. У ИИ часто получается сде­
лать код аккуратнее или более эффективным с точки зрения производитель­
ности. В этом сценарии он исполняет роль помощника, просматривающего
готовый код, но всё равно после его исправлений нужно ещё раз пройтись
по коду свежим взглядом.
Использовать ИИ для проверки решений
Если вы сомневаетесь в архитектурном выборе, задайте вопрос ИИ:
Достаточно ли хранить контакты в массиве в памяти или стоит использо­
вать базу данных? Каковы плюсы и минусы этих решений?
Даже если в целом ответ очевиден (использовать для постоянного хранения
базу данных), такой диалог с ИИ похож на обсуждение вопросов с коллегой.
Иногда ИИ отмечает какие-нибудь детали, которые вы могли упустить или
о которых могли не задуматься, например:
При наличии нескольких экземпляров сервера хранилище в памяти не бу­
дет синхронизироваться между ними.
Использовать ИИ для координации работы в команде
Бывает так, что не все специалисты, работающие над одним проектом, поль­
зуются ИИ напрямую. В этом случае можно попросить ИИ задокументи­
ровать проделанную работу. Важно также объяснять коллегам, почему вы
воспользовались помощью ИИ и в чём она заключалась: «Я воспользовал­
ся ИИ, чтобы быстро сгенерировать код для этих контроллеров. Я проверил
его, но стоит проверить его на возможные нетипичные решения». Если вы
180

1

Часть 11. Практика работы с ИИ

регулярно проводите код-ревью, то к сгенерированному ИИ коду нужно от­
носиться так же внимательно, как и к коду, написанному человеком.
Многие коллективы, внедряющие ИИ в свои рабочие процессы (например,
в компании Snyk (https://oreil.ly/8Dmn7)), отмечают рост производительности,
но подчёркивают при этом важность человеческого фактора и необходимость
проверки полученных результатов. Согласно одному опросу, проведённо­
му на GitHub в 2024 году, о том, что для создания кода в той или иной форме
они пользуются на работе инструментами ИИ, сообщили 97% разработчиков
(https:lloreil.ly/oivAx).

Тестирование и валидация веб-приложений,
созданных с помощью ИИ
По окончании работы над созданным с помощью ИИ веб-приложением его нуж­
но тщательно протестировать и убедиться, что всё работает как задумано, или
выявить возможные допущенные вами или ИИ ошибки. Если исходить из прин­
ципов разработки с помощью ИИ, то здесь возможны следующие варианты.
Модульные тесты
Что касается серверной логики (бэкенда), то стоит писать модульные тесты,
проверяющие критически важные функции (например, функции вычисле­
ний или валидации входных данных). Особенно модульные тесты полезны,
если функцию написал ИИ, потому что они помогают выявлять скрытые
ошибки. Но не нужно забывать об осторожности: созданные при участии
ИИ тесты иногда оказываются слишком банальными или опираются на кон­
кретную реализацию, поэтому часто бывает нужно явно указывать гранич­
ные случаи. Например:
Напиши тесты для функции проверки надёжности пароля, включая гранич­
ные случаи, такие как пустой пароль, очень длинный пароль, пароль со спе­
циальными символами и друтие.
Интеграционные тесты
Тестируйте конечные точки API с помощью инструментов вроде Supertest
(для Node.js) или посредством прямых НТТР-запросов. Убедитесь, что каж­
дая конечная точка возвращает ожидаемый результат. ИИ может помочь с ос­
новой таких тестов:
Глава 7. Создание веб-приложений с помощью ИИ

1

181

Напиши интеграционные тесты для конечных точек /api/to-dos с использо­
ванием Jest и Supertest.
По этому запросу ИИ попытается сгенерировать тесты, которые будут запу­
скать приложение, обращаться к конечным точкам и проверять ответы.
Фронтенд-тесты
Проверять пользовательский интерфейс можно с помощью инструментов
вроде Jest (для логики компонентов) и Cypress или Playwright для сквозного
тестирования интерфейса. Можно напрямую попросить ИИ сгенерировать
сценарий для Cypress, например:
Напиши тест Cypress, который загружает приложение, добавляет через
форму новую задачу и проверяет, появилась ли она в списке.
ИИ выдаст тестовый скрипт, который можно сразу запустить. И это весь­
ма эффективный метод - описывая действия пользователя на естественном
языке, вы быстро покроете тестами весь процесс.
Ручное тестирование
Сколько бы автоматических тестов вы ни запускали, ручное тестирование
всё равно играет важную роль. Разработчик обязательно должен сам «про­
кликать» веб-приложение (или поручить это тестировщику, если работа идёт
в команде). У ИИ не всегда получается предсказать реальные сценарии ис­
пользования: например, бывает так, что кнопка «Назад» в браузере нарушает
состояние приложения или определённая последовательность действий при­
водит к сбою. Обнаруженные ошибки можно исправлять самостоятельно или
устранять их с помощью ИИ. Ручное тестирование также помогает оценить
удобство интерфейса - насколько комфортно пользоваться приложением
и нет ли каких-то неочевидных или неудобных переходов. ИИ не способен
оценить такие субъективные аспекты интерфейса, поэтому решающую роль
здесь играет человеческое восприятие.
Код-ревью
Если работа ведётся в команде, обязательно передавайте сгенерированный
ИИ-код на проверку другим разработчикам. Свежий взгляд помогает заме­
тить то, что легко упустить самому: потенциальные уязвимости, логические
ошибки или просто возможность сделать код более идиоматичным и читае­
мым. В коллективах, пользующихся помощью ИИ, как правило, сохраняется
182

Часть 11. Практика работы с ИИ

обычный процесс код-ревью, но больше внимания уделяется скрытым ошиб­
кам и вопросам безопасности, потому что ИИ вероятнее всего может подве­
сти именно в этих сферах (https://oreil.ly!OSDbj).
Аудит безопасности
Более подробно вопросы безопасности рассматриваются в главе 8, но про­
верять код на типичные уязвимости полезно уже на этапе разработки. Для
этого можно либо пользоваться автоматическими инструментами - линте­
рами и средствами статического анализа безопасности приложений (SAST)
(https:/!oreil.ly/TSЗlz), - либо напрямую задавать ИИ запросы вроде следу­
ющего:
Проанализируй код приложения на Express и перечисли возможные уязви­
мости и случаи несоответствия кода общепринятым правилам и рекомен­
дованным способам разработки.
ИИ может указать на неочевидные проблемы, например: «Здесь не выполняется санитизация пользовательского ввода)) или «нужно корректно настроить
CORS (междоменный доступ))) . Все подобные замечания удобно использовать
как элементы контрольного списка для последующего усиления защиты при ложения.
Один из любопытных эффектов использования ИИ заключается в том, что
тесты пишутся чаще, потому что их становится проще создавать, и в результате
повышается надёжность кода. Если выработать привычку генерировать тесты
сразу же после реализации функционала ( согласно принципам так называемой
тест-ориентированной разработки с помощью ИИ, или же просто с помощью
ретроспективных тестов), то можно сохранить высокое качество даже при боль­
шой скорости разработки. Логика здесь проста: сэкономленное с помощью ИИ
время на написание кода стоит потратить на написание и запуск тестов.
Без должного контроля ИИ может предлагать небезопасный код. Так, неко­
торые ранние версии ИИ-моделей при отсутствии явных указаний генерирова­
ли уязвимые для инъекций SQL-запросы. Эти недочёты и проблемы позволяют
выявить проверки и код-ревью. Согласно одному из исследований (https://oreil.
lу!ИЗЬВН), пользующиеся помощью ИИ разработчики склонны переоценивать
степень безопасности сгенерированного кода, даже если она ниже степени без­
опасности кода, написанного вручную.
Никогда не пропускайте этап валидации только на том основании, что код
написал ИИ. Исходите из предположения о том, что в нём могут быть ошибки как и в коде, написанном человеком.
Глава 7. Создание веб-приложений с помощью ИИ

183

Удачные примеры создания веб-проектов
С ПОМОЩЬЮ ИИ
Рассмотрим несколько примеров (обобщённых, на основе различных отчётов)
веб-приложений, созданных при значительной помощи со стороны ИИ.

Интернет-магазин, разработанный одиночкой
Один разработчик решил создать небольшой веб-магазин для продажи ка­
стомных футболок, но время у него было ограничено. Для реализации всей
системы целиком он воспользовался GPT в расширении IDE. С помощью за­
просов к ИИ были сгенерированы интерфейс на React со списками товаров,
корзиной и страницами оформления заказа, а также серверная часть на Node.
js с обработкой товаров и заказов. Для приёма платежей использовался сер­
вис Stripe, подключённый с помощью ИИ через API Stripe. Работая по вече­
рам на протяжении двух недель, разработчик получил полноценный функ­
ционирующий сайт.
По его оценкам, ИИ выполнил около 70% всей работы по написанию кода
(в первую очередь рутинных элементов интерфейса и обработки форм), а сам
разработчик сосредоточился на корректной настройке Stripe и доводке ин­
терфейса под фирменный стиль. В результате пользователи могли просма­
тривать товары, добавлять их в корзину и совершать покупки, и всё это в си­
стеме, в значительной степени созданной с помощью вайб-кодинга. Также
этот пример показывает, что при поддержке ИИ вполне можно интегриро­
вать внешние сервисы (такие как Stripe), при условии что у модели есть до­
ступ к их документации или если её предоставлять специально.
Внутренний корпоративный дашборд
Продакт-менеджер с базовыми навыками программирования воспользо­
валась ИИ-ассистентом для разработки внутренней аналитической панели
для своей команды. В обычной ситуации ей пришлось бы обратиться к про­
граммным инженерам, но с помощью таких инструментов, как Ghostwriter
от Replit или Copilot от GitHub, ей удалось самостоятельно создать базовое
веб-приложение.
ИИ помог настроить простой бэкенд на Flask для выполнения запросов
к базе данных (с безопасными правами только на чтение) и фронтенд на Vue.
js для отображения диаграмм (с использованием библиотеки визуализации).
Она описывала, что должна показывать каждая диаграмма («общее число
пользователей по времени», «активные пользователи по регионам»), а ИИ
генерировал SQL-зanpocы и код для построения диаграмм.
184 1 Часть 11. Практика работы с ИИ

Весь процесс с экспериментами и тестами занял пару недель, но в итоге
она получила рабочий дашборд. Качество кода не соответствовало корпора­
тивным стандартам, но для внутреннего инструмента этого было приемлемо.
Важнее то, что вся команда получила полезный инструмент за небольшое
время. Этот пример говорит о том, что ИИ-инструменты позволяют неспе­
циалистам создавать рабочие веб-приложения, не дожидаясь специалистов,
которые поставили бы эту задачу себе в список дел и ещё неизвестно, ко­
гда бы выполнили её. Это пример пресловутого «размывания границ специ­
ализации», о котором я рассуждаю в главе 10, когда речь заходит о том, что
отдельным людям теперь гораздо легче создавать персональное или специ­
фическое корпоративное ПО.
MVP стартапа
Небольшому стартапу (в нём было два сооснователя: один отвечал за биз­
нес, другой - за техническую часть) для демонстрации инвесторам понадо­
билось веб-приложение уровня MVP (минимально жизнеспособного про­
дукта). Технический сооснователь с помощью активного вайб-кодинга создал
MVP в рекордные сроки. С помощью ИИ-ассистента он развернул совре­
менное веб-приложение: фронтенд на React с серверным рендерингом через
Next.js и простой API на Node.js.
ИИ использовался для реализации таких возможностей, как вход через
социальные сети (ИИ сгенерировал ОАuth-процессы), загрузка изображе­
ний (интеграция с API облачного хранилища), а также ИИ-функциональ­
ность внутри самого продукта. Более того, ИИ помог подключить модель
обработки естественного языка через внешний API. За несколько месяцев
один разработчик сделал то, на что обычно у небольшой команды уходит
четыре - шесть месяцев. В итоге получился «сыроватый», но рабочий про­
дукт, который можно было показать в демо и даже подключить первых бе­
та-пользователей.
Позже, когда сооснователи наняли дополнительных разработчиков для
доводки продукта, выяснилось, что код, сгенерированный ИИ, в целом по­
нятен, хотя значительные части пришлось переработать с учётом масштаби­
руемости. Этот пример говорит о том, что ИИ позволяет очень быстро дойти
до первой стадии, но на следующих этапах неизбежно приходится инвести­
ровать время и усилия в качество.

Эти истории, хоть и единичные, хорошо соотносятся с формирующимися
тенденциями в сфере разработки веб-приложений, где в одном продукте часто
приходится совмещать между собой множество компонентов и потому прирост
Глава 7. Создание веб-приложений с помощью ИИ

185

производительности особенно заметен. Microsoft (https://oreil.ly!QLunu) и другие
компании (https:/!oreil.ly!BNVrB) в своих исследованиях отмечают, что разработ­
чики, пользующиеся помощью ИИ, выполняют задачи заметно быстрее тех, кто
работает без него.
С другой стороны, есть и предостерегающие примеры. Разработчики вполне
могут развернуть сгенерированное ИИ неб-приложение с уязвимостями в пла­
не безопасности, особенно если они не до конца понимают сгенерированный
код. Такой риск лишний раз подчёркивает, какую важную роль играют тесты
и код-ревью.
В заключение нужно сказать, что разработка неб-приложений с привлечением
ИИ становится массовой практикой, но не устраняет, а, наоборот, усиливает по­
требность в квалифицированных разработчиках. Такими сферами, как архитек­
тура, проверка корректности и сложная новая логика по-прежнему занимаются
люди, тогда как ИИ берёт на себя рутинный шаблонный код, объединяющий части
системы. Рассмотренный нами общий процесс создания приложения от каркаса
до фронтенда, бэкенда и тестирования говорит о том, что с помощью ИИ можно
ускорить практически каждый этап неб-разработки, но только при условии по­
стоянного контроля со стороны человека, обладающего критическим мышлением.

Итоги и дальнейшие шаги
В этой главе говорилось о том, как приёмы вайб-кодинга масштабируются
до разработки полноценных (полностековых) неб-приложений. ИИ в роли по­
стоянно доступного напарника позволяет параллельно работать над клиент­
ской и серверной частями (фронтендом и бэкендом), генерировать компоненты
и API на основе описаний на естественном языке и итеративно улучшать прото­
тип до готового к развёртыванию качества. Ключевые факторы успеха - чёткая
формулировка замысла (то есть «намерения», благодаря чему ИИ понимает, что
от него нужно на каждом шаге), внимательная проверка результата (чтобы вы­
явить ошибки в сгенерированном ИИ-коде) и привлечение ИИ не только для на­
писания кода, но и для задач вроде проектирования схем и с�тавления тестов.
Также было показано, как один разработчик фактически может выполнять
роль полностекового программного инженера, когда ИИ закрывает пробелы
в знаниях и предлагает свои варианты кода для тех областей, с которыми разра­
ботчик не слишком знаком. Такой способ работы значительно сокращает вре­
мя разработки приложений и в некоторой степени демократизирует разработку
тем, что позволяет создавать специализированные веб-приложения без больших
команд (к этой теме мы вернёмся в главе 10).
186

1

Часть 11. Практика работы с ИИ

ИИ не думает за вас и не обеспечивает качество автоматически, он лишь уско­
ряет работу.
Теперь, когда веб-приложение готово к работе, следующим шагом нужно убе­
диться в его безопасности, надёжности и сопровождаемости. В главе 8 рассма­
триваются вопросы безопасности и надёжности сгенерированных ИИ кодовых
баз и описываются типичные уязвимости сгенерированного кода; в ней также
рассматриваются практические приёмы (вроде тех, которыми мы уже начали
пользоваться в тестах и обзорах), благодаря которым скорость разработки с по­
мощью ИИ не снижает качество и не ломает систему. По сути, мы переходим
от создания приложения к его доработке, то есть подготавливаем его к реаль­
ным угрозам и испытаниям.

ЧАСТЬ 111

Доверие и автономия

ГЛАВА 8

Безопасность, поддерживаемость
••
и надежность
Эта глава посвящена одному из ключевых аспектов вайб-кодинга и разработки
с помощью ИИ, а именно вопросам безопасности, надёжности и поддерживае­
мости сгенерированного искусственным интеллектом кода. Если программное
обеспечение страдает от уязвимостей и сбоев, то уже неважно, насколько быст­
ро оно было сделано и сколько ресурсов удалось сэкономить в процессе его раз­
работки.
Сначала мы рассмотрим проблемы безопасности, типичные для сгенериро­
ванного ИИ-кода. Мы познакомимся с приёмами аудита и код-ревью, когда раз­
работчик выступает в роли своеобразного «предохранителя» для своего ИИ-на­
парника.
Далее мы обсудим эффективные системы тестирования и контроля качества
сгенерированного ИИ-кода, помогающие выявлять ошибки и проблемы надёж­
ности на ранних стадиях. Также мы затронем вопросы производительности. ИИ
умеет генерировать корректный код, но этот код не всегда отличается эффектив­
ностью, поэтому я покажу, как находить и оптимизировать узкие места. Кро­
ме того, мы рассмотрим стратегии сопровождаемости (дальнейшей поддержки
кода), такие как соблюдение единого стиля или рефакторинг сгенерированно­
го ИИ-кода, так как ИИ порой предлагает непоследовательные или избыточ­
ные варианты.
Я покажу, как делать код-ревью в процессе работы с помощью ИИ, и объяс­
ню, на что следует обращать внимание человеку, анализирующему код, частич­
но или полностью сгенерированный машиной. Под конец я приведу примеры
успешного вывода проектов в эксплуатацию, от конвейеров непрерывной инте­
грации до мониторинга в рабочей среде. Прочитав эту главу до конца, вы позна­
комитесь с приёмами, обеспечивающими надёжность и безопасность ПО, раз­
работанного с помощью ИИ.

Глава 8. Безопасность, поддерживаемость и надёжность

1

191

Распространённые проблемы безопасности
в сгенерированном ИИ коде
Несмотря на всю свою мощь, ИИ-ассистенты без предварительного предупре­
ждения иногда допускают ошибки, приводящие к проблемам с безопасностью.
Они обучаются на открытом коде, находящемся во всеобщем доступе, а в этом
корпусе бывают как удачные, так и неудачные примеры. Чтобы вовремя заме­
тить и исправить недостатки, нужно иметь представление о типичных «подвод­
ных камнях» и уметь пользоваться как ручными, так и автоматизированными
средствами обнаружения потенциальных проблем безопасности (см. иллюстра­
цию 8.1).

ИИ генерирует код

Сканер безопасности

ПробJJемабезоnасносnt
�

Иллюстрация 8.1. ИИ выдаёт код с уязвимостями в области
безопасности. Этот код нужно внимательно проверить
на наличие таких проблем, после чего устранить их
Среди типичных проблем безопасности в сгенерированном ИИ коде можно
упомянуть следующие.
Жёстко закодированные секреты или учётные данные
Иногда ИИ генерирует код с явно заданными АРI-ключами, паролями или то­
кенами, особенно если в его обучающих данных было много подобных при­
меров. Например, при интеграции сервиса AWS он может вставить фиктив­
ный секретный ключ в код напрямую, что опасно, ведь другие пользователи
могут легко узнать этот ключ, просто просмотрев код. Поэтому для конфи­
денциальных данных всегда нужно пользоваться переменными окружениями
или конфигурационными файлами. Увидев в сгенерированном ИИ коде не­
что вроде api._key = "ABC123SECRET", воспринимайте это как призыв к дей­
ствию - удалить реальные ключи из исходного кода.
192

1

Часть 111. Доверие и автономия

Уязвимость для SQL-инъекций
Предлагая ИИ сгенерировать SQL-запросы (или воспользоваться ОRМ), про­
следите за тем, чтобы запросы не объединялись непосредственно с вводимыми пользователем данными. Вот пример небезопасного кода, уязвимого
к инъекциям:
sql

=

"SELECT * FROM users WHERE nаме

= '"

+ usernaмe + "'";

И такой код ИИ может выдать с довольно высокой вероятностью, если явно
не попросить его воспользоваться параметризированными запросами. Все­
гда используйте подготовленные выражения или связывание параметров.
Многие ИИ-ассистенты делают это автоматически, если они обучены на хо­
роших примерах (например, с использованиемзаглушек для пользователь­
ских данных в SQL), но надеяться на это не стоит. Нужно обязательно прове­
рять выдаваемый ИИ код и при необходимости просить его исправить:
Измени этот запрос так, чтобы использовать параметры для предотвраще­
ния SQL-инъекций.
Межсайтовый скриптинг (XSS) в веб-приложениях
ИИ не всегда автоматически экранирует пользовательский ввод в генериру­
емом им коде. Например, ИИ может сгенерировать шаблон, в котором текст
комментариев { {cof'lf'lent. text}} вставляется в НТМL-документ без экра­
нирования, в результате чего злоумышленники могут разместить в ком­
ментариях вредоносный скрипт. Во фреймворках код часто экранируется
по умолчанию, но, если ИИ создаёт НТМL-документ с нуля, будьте особенно
осторожны. Предусмотрите функции кодирования или санитизации вывода.
Для этого можно дать ИИ такую инструкцию:
Добавь санитизацию пользовательского ввода для предотвращения XSS.
Проследите за тем, чтобы ИИ пользовался встроенными во многие совре­
менные фреймворки механизмами - например, i.nnerText вместо i.nnerHTML
при работе с DOM (https://oreil.ly/5o_2x).
Неправильная аутентификация и авторизация
ИИ умеет создавать код для потоков аутентификации, но в такой код могут
закрасться незаметные с первого взгляда ошибки: например, генерация JSON

Глава 8. Безопасность, поддерживаемость и надёжность

193

Web Token (JWT) (https:/!oreil.lylrPJL) без достаточно криптостойкого секрет­
ного ключа или некорректная проверка хеша пароля.
То же касается авторизации: ИИ может упустить из виду, что какое-то
действие, например удаление ресурса, разрешено только владельцу ресурса.
Такие логические ошибки трудно выявлять автоматически и потому нужно
специально продумывать модель безопасности и явно указывать эти усло­
вия в запросе:
Удалять ресурс может только его владелец. Добавь проверку ID пользова­
теля.
Полученный код нужно протестировать на соответствие этим условиям. ИИ
может забыть о проверке, потому что он «не понимает» контекст без явно­
го его указания.
Небезопасные настройки или конфигурации по умолчанию
Без специального указания ИИ может предпочитать удобство безопасности.
Здесь можно привести следующие примеры:

- Использование НТТР вместо HTTPS для АРI-вызовов (если TLS не ука­
зан явно).
- Отсутствие проверки SSL-сертификатов (в интернете встречаются при­
меры, в которых прописано veri.fy=false, и ИИ может скопировать та­
кой код).
- Разрешение CORS для всех источников и методов без ограничений (что
потенциально открывает приложение для любых междоменных запро­
сов).
- Выбор устаревшей системы криптографии (например, MDS или SНAl для
хеширования вместо SНA-256/Bcrypt/Argon2 для паролей).
Такие потенциальные проблемы часто ускользают от внимания при по­
верхностном анализе, поэтому важно особенно тщательно проверять кон­
фигурационные файлы и код инициализации. Любые настройки вроде арр.
UseCors(allowAll) или указания устаревшего алгоритма шифрования нужно
замечать и соответствующим образом исправлять.
Обработка ошибок с раскрытием конфиденциальной информации
ИИ может сгенерировать код обработки ошибок, выводящий или возвраща­
ющий трассировку стека. Например, API Node.js может перехватить ошибку
194

1

Часть 111. Доверие и автономия

и выполнить res.send(eгr.toStri.ng()), раскрыв тем самым внутренние
детали. Проследите за тем, чтобы сообщения об ошибках для пользовате­
лей были обезличены, а логи обрабатывались корректно. При необходимости
внесите исправления, которые не дадут злоумышленникам подсказки вроде
полного текста ошибки или путей к файлам.
Управление зависимостями и их обновления
Если ИИ добавляет в проект какие-то зависимости (например, библиотеки),
проследите за тем, чтобы они были актуальными и полученными из надёж­
ных источников. Среди обучающих данных могли содержаться ссылки
на библиотеки, популярные на момент обучения ИИ, но больше не поддер­
живаемые или содержащие известные уязвимости. Если ИИ, например, пред­
ложит воспользоваться старой версией пакета, обновите её до последней ста­
бильной. После генерации полезно запустить np111 audi.t или аналогичный
инструмент, а также спросить у ИИ:
Эта библиотека поддерживается до сих пор� Насколько она безопасна�
ИИ не всегда знает ответы на такие вопросы, но сообщит то, что ему из­
вестно.
В 2023 году был проведён широкомасштабный анализ использования GitHub
Copilot в реальных проектах, который показал, что от 25 до 33% сгенериро­
ванного кода (в зависимости от языка) содержат потенциальные уязвимости,
включая те, что входят в список CWE, вроде инъекции команд, инъекции кода
и межсайтового скриптинга (https://arxiv.org!abs/2310.02059). Эти данные гово­
рят о том, что Copilot не намеренно создаёт уязвимый код, а воспроизводит
небезопасные шаблоны из обучающих данных. Рекомендация остаётся преж­
ней: разработчики должны проявлять осмотрительность и вручную проверять
сгенерированный ИИ код, пользуясь инструментами проверки безопасности
и поддерживая строгую гигиену кода. Особенно это верно для вайб-кодинга,
когда за небольшое время ИИ может выдавать огромный объём кода. Сокра­
щение времени на разработку часто сопровождается одновременным увеличе­
нием времени на аудит.

Неправильная аутентификация и авторизация
Предположим, вы попросили ИИ создать маршрут входа в приложении Express
и он сгенерировал нечто вроде этого:
Глава 8. Безопасность, поддерживаемость и надёжность

195

// Небезопасный пример
app.post('/logi.n', async (геq, геs) => {
const {usernaмe, passwoгd} = req.body;
const user = awai.t Useгs.fi.ndOne({usernaмe: usernaмe});
i.f (!user) return res.status(401).send("No such user");
i.f (user.password === password) {// сравнение пароля в открытом виде
res.send("Logi.n successful!");
} else {
res.status(401).send("Incorrect password");
}
)
;
}
Что же здесь не так?
- Здесь пароли сравниваются напрямую, а это значит, что они хранятся
в базе в открытом виде, что категорически недопустимо.
- Отправляемые сообщения слишком стандартные, что с точки зрения без­
опасности приемлемо, но через них может случайно раскрыться чувстви­
тельная информация.
Особое внимание стоит уделить сообщениям об ошибках аутентификации.
В безопасной системе при неудачном входе должно возвращаться сообщение об­
щего характера вроде «Неверные учётные данные» (Invalid credentials) - неза­
висимо от того, ввёл пользователь неверное имя или неверный пароль. Но ИИ
может сгенерировать код, выдающий более конкретные сообщения вроде «Поль­
зователь не найден» ( Username not found) или «Неверный пароль для этого поль. зователя» (Incorrect password for this user).
Они указывают потенциальным злоумышленникам, на что стоит обратить
внимание. Если злоумышленник увидит сообщение «Неверный пароль», то он
поймёт, что такое имя пользователя в системе существует. При повторных по­
пытках он сосредоточит усилия на известных именах и постарается подобрать
пароли для них. Такая техника, называемая перебором пользователей (user
enumeration), упрощает взлом и превращает догадки в целенаправленную атаку.
Склонность ИИ выдавать подробные сообщения, «помогающие» пользователю,
может непреднамеренно помочь и злоумышленникам, поэтому нужно специаль­
но указать в запросе, чтобы он выдавал максимально обобщённые ответы для
чувствительных к безопасности операций.
Также в коде не предусмотрено ограничений по числу попыток и отсутству­
ют другие защитные меры (хотя явно это не показано).
196

Часть 111. Доверие и автономия

Безопасная реализация должна включать несколько ключевых мер защиты.
- Первое и главное: пароли никогда не должны храниться в открытом виде.
Система должна сохранять криптографические хеши паролей и использо­
вать безопасную функцию сравнения при проверке попыток входа.
- Для процесса сравнения нужно использовать алгоритмы с постоян­
ным временем выполнения, чтобы предотвратить атаки по времени, ко­
гда злоумышленники по времени задержки ответа пытаются определить
корректность пароля. Многие библиотеки, ориентированные на без­
опасность, предоставляют специальные функции сравнения именно для
устранения такой уязвимости.
- Кроме того, система аутентификации должна ограничивать частоту за­
просов или использовать механизмы замедления (throttling) для предот­
вращения атак методом перебора. Для мониторинга безопасности неу­
дачные попытки входа должны заноситься в журнал (лог), с помощью
которого администраторы смогут обнаруживать подозрительные дейст­
вия и реагировать на них. Вместе все эти меры создают многоуровневую
защиту, поддерживающую безопасность учётных данных даже в случае
компрометации одного из уровней.
В связи с этими соображениями можно попросить ИИ исправить показан­
ный выше код:
Улучши маршрут входа login, используй Ьсгурt для хеширования и срав­
нения паролей и проследи, чтобы пароль в базе данных хранился в хеши­
рованном виде.
ИИ может ответить так:
const Ьсгурt

requtre('bcrypt');

app.post('/logtn', async (геq, геs) => {
const {usernaмe, password} = req.body;
const user = awatt Users.ftndOne({usernaмe});
Н (!user) {
return res.status(401).send("Invaltd credenttals");
}
const мatch = awatt bcrypt.coмpare(password, user.passwordHash);
Н (!мatch) {
Глава 8. Безопасность, поддерживаемость и надёжность

197

return res.status(401).send("Invaltd credenttals");

}
res.send("Logtn successful!");
});

И этот код уже лучше: здесь используется Ьсгурt. col'lpare() для сравнения
введённого пароля с хранящимся в базе хешем (переменная user. passwordHash).
При создании пользователей для генерации хеша нужно будет воспользовать­
ся Ьсгурt. hash().
При небольшой корректировке со стороны человека ИИ способен выдать
правильное решение, но первоначальный его вариант может оказаться небез­
опасным, что, опять же, подводит нас к главному правилу работы с ИИ: прове­
ряй и дорабатывай.

Проблемы с пакетами
Ещё одна распространённая категория уязвимостей связана с пакетами. ИИ иног­
да выдумывает библиотеку или неправильно вспоминает её название (так назы­
ваемые галлюцинации). Пакета может вовсе не существовать, но теоретически па­
кеты с такими выдуманными названиями могут опубликовать злоумышленники.
Если не убедиться, что такие пакеты настоящие, то их установка грозит серьёз­
ным риском. В случае сомнений по поводу конкретного пакета стоит выполнить
быстрый поиск в интернете или проверить его напрямую в npm/PyPI.
Помимо этого, ИИ может непреднамеренно сгенерировать код, идентичный
какому-нибудь лицензированному фрагменту кода из обучающих данных. Это
скорее проблема из области интеллектуальной собственности, нежели безопас­
ности, но она также требует внимания. У ассистента Copilot от GitHub, напри мер, есть функция обнаружения дубликатов, помечающая код, очень похожий
на код из публичных репозиториев, что помогает разработчикам избегать по­
тенциальных лицензионных конфликтов. Появляются и другие инструменты,
решающие проблемы с происхождением сгенерированного ИИ-кода. Вопросы
лицензирования и интеллектуальной собственности рассматриваются подроб­
нее в главе 9, где я даю рекомендации по работе с этими сложными аспектами.
Итак, основной посыл остаётся прежним (и да, я понимаю, что настолько
часто подчёркивал эту мысль на протяжении всей книги, что вы наверняка уже
заучили её наизусть): сгенерированный ИИ-код нужно так же тщательно про­
сматривать, как и код какого-нибудь младшего разработчика. Но я ещё раз по­
вторю эту мысль, потому что принцип этот лежит в основе почти всех вопро­
сов безопасности и эффективности разработки ПО с помощью ИИ. Создаёте ли
198 1

Часть 111. Доверие и автономия

вы прототипы, разрабатываете бэкенд или реализуете механизмы безопасно­
сти, именно тщательная проверка делает из ИИ полезного напарника, которо­
му можно доверять. Да, он может очень быстро выдавать огромный объём кода,
но этот код обязательно нужно проверять на безопасность и направлять ИИ так,
чтобы он придерживался принятых в этой сфере правил. Как однажды писатель
Фрэнк Герберт выразился в своём романе «Бог-император Дюны» (Putnam, 1981)
(https://oreil.ly/yr2B): «И что же делают эти машины? Они увеличивают количе­
ство того, что делаем мы не задумываясь. И именно в том, что мы делаем не за­
думываясь, и кроется настоящая опасность».
Привычка полагаться на помощь ИИ усыпляет бдительность, и человек всё
меньше задумывается о рутинном коде, поэтому так важно сознательно пере­
ключаться в «режим осознанности». Без этого легко упустить из виду то, «что
мы делаем не задумываясь».

Аудит безопасности
Так как же всё-таки стоит проверять сгенерированный ИИ-код с учётом всего
того, что говорилось об уязвимости и о проблемах безопасности? В этом разде­
ле мы рассмотрим несколько приёмов и инструментов.

Автоматизированные сканеры безопасности
Автоматически сканировать код на наличие известных проблем уязвимости по­
могают инструменты статического анализа (SASТ, Security Static Analysis Security
Tools). Среди таких инструментов можно назвать следующие:
- ESLint с плагинами безопасности (https://oreil.ly/55ppН) выявляет небез­
опасные функции или несанитизированный ввод в коде на JavaScript
иNode.
- Bandit для Python (https:!/bandit.readthedocs.io) помечает assert в продак­
шене, примеры слабой криптографии, жёстко заданные секреты и про­
чие проблемы.
- CodeQL от GitHubH (https:llgithub.com!githuЬ!codeql) по запросу проверя­
ет всю кодовую базу на предмет возможных SQL-инъекций, XSS и других
распространённых уязвимостей.
- Semgrep (https://semgrep.dev) содержит правила для многих языков, вклю­
чая поддерживаемые сообществом JavaScript, Python, Java, Go и другие,
и по умолчанию выявляет самые распространённые проблемы.
Глава 8. Безопасность, поддерживаемость и надёжность

199

Эти инструменты можно интегрировать в рабочие пайплайны или процесс не­
прерывной разработки (CI/CD), но с их помощью можно обрабатывать и сгенери­
рованный ИИ-код. Утверждать, что они обнаружат все без исключения проблемы,
нельзя, но очевидные ошибки они выявят (например, проверку паролей в откры­
том виде, несанитизированный SQL, небезопасную криптографию). Восприни­
майте их как надёжное средство поддержки, своего рода подушку безопасности.

Отдельный ИИ как рецензент
Пользоваться ИИ для аудита безопасности сгенерированного кода можно дву­
мя способами, и каждый обладает своими преимуществами. Первый заключа­
ется в том, чтобы задействовать для аудита ту же модель ИИ, что создавала код;
при этом нужно попросить её сменить роль или точку зрения и проверить свой
результат. После генерации кода модели можно дать примерно такой запрос:
Проверь этот код на уязвимости в области безопасности и объясни суть
найденных проблем.
Этот метод часто даёт на удивление хорошие результаты, так как любая бо­
лее или менее достойная модель ИИ способна выявлять такие типичные пробле­
мы безопасности, как хранение паролей в открытом виде, отсутствие валидации
ввода, возможные SQL-инъекции и другие.
Второй способ заключается в том, чтобы в качестве независимого рецензента воспользоваться другой моделью ИИ. Например, если код был сгенерирован
ChatGPT, проанализировать его с точки зрения безопасности можно попросить
Claude или Gemini. Такой кросс-модельный аудит полезен тем, что другая мо­
дель может выявить ошибки, пропущенные исходной моделью. Это всё равно
что привлекать для анализа кода разных экспертов по безопасности, каждый
из которых обладает своей точкой зрения и делает акцент на разных вещах. Раз­
ные модели могли обучаться на различных данных и с разным фокусом, то есть
ориентироваться на разные категории уязвимостей.
Оба способа представляют собой дополнительное полезное средство аудита
безопасности, но ни в коем случ ае не заменяют полноценное тестирование и че­
ловеческую экспертизу. ИИ часто упускают из виду не столь явно выраженные
проблемы или, наоборот, сообщают о несуществующих угрозах, хотя в целом
они отлично справляются с выявлением типичных проблем. Рассматривайте их
как напарника, занимающегося исключительно вопросами безопасности. Глав­
ное - воспринимать отчёты ИИ как ещё один источник данных для общей оцен­
ки безопасности, а не как окончательное решение и одобрение кода.
200

Часть 111. Доверие и автономия

Ручной код-ревью с акцентом на безопасность
При работе в команде стоит воспользоваться списком основных вопросов для
проверки кода с точки зрения безопасности. ИИ часто генерирует код, который
работает «в общем случае», но не защищён от попыток злоумышленников взло­
мать его. Поэтому при проверке кода стоит задавать следующие вопросы:
О Насколько надёжны потоки аутентификации?
О Проверяются (валидируются) ли все точки ввода данных в систему?
О Санитизируются ли данные во всех точках вывода из системы? Защища­
ется ли конфиденциальная информация?
О Обрабатываются ли сбои внешних API? Не раскрываются ли ключи?
О Как осуществляется доступ к базе данных? Безопасно ли используются
ОRМ? Применяются ли параметризованные запросы?
О Как низкоуровневый код управляет памятью? Если ИИ пишет на С/С++
или Rust, могут ли возникнуть проблемы переполнения или неправиль­
ного использования памяти?

Пентестинг и фаззинг
Помощь ИИ оказывается весьма полезной и при динамических методах тестиро­
вания. Метод фаззинга (juzzing) заключается в том, что на вход, в функции или
в конечные точки, подаются случайные или специальным образом сформиро­
ванные данные - так разработчики проверяют, при каких условиях програм­
му можно взломать или при каких условиях она будет работать некорректно.
С помощью ИИ можно генерировать данные для фаззинга либо использо­
вать готовые инструменты (https:!!oreil.ly!OoFzТ), такие как OSS-Fuzz от Google
(https://oreil.ly!FvKSU).
Метод пентеста заключается в имитации поиска уязвимостей со стороны зло­
умышленника, и в этом помогают такие инструменты, как ZAP проекта OWASP,
автоматизирующие поиск уязвимостей вроде XSS и SQL-инъекций. Например,
ZAP может попытаться внедрить некий скрипт, проанализировать полученный
от него ответ и сигнализировать о том, что какие-то данные не проходят сани­
тизацию.
Если вы разрабатываете API, то инструменты вроде Postman или ваших соб­
ственных скриптов позволят вам отправлять некорректно сформированные
данные и наблюдать за поведением системы: выдаёт ли она ошибку 500 или об­
рабатывает ошибки корректно?
Глава 8. Безопасность, поддерживаемость и надёжность 1 201

Модульные тесты безопасности
Для критически важных участков кода стоит прописать отдельные тесты на без­
опасность. Например, можно проверить, срабатывает ли ограничитель попыток
ввода после Х неудачных попыток и возвращаются ли определённые входные
данные (например, <scri.pt>alert(l)</scri.pt>) в экранированном виде. Что­
бы убедиться, что неавторизованные пользователи не получат доступ к защищённому ресурсу, моделируйте авторизованные и неавторизованные запросы
и наблюдайте за корректностью поведения приложения.
Можно попросить ИИ помочь с генерацией таких тестов, например:
Напиши тесты, проверяющие, что при обращении к конечной точке
/deleteUser неавторизованный пользователь получит ошибку 403.

После этого достаточно просто запустить эти тесты.

Обновление информации для моделей
Один из фундаментальных недостатков моделей ИИ, непосредственно относя­
щийся к сфере безопасности, заключается в том, что все доступные им сведения
ограничиваются каким-то определённым временем. Все их знания фиксируют­
ся на момент обуч ения, и после обучения модель уже ничего не узнаёт о новых
уязвимостях, выпущенных патчах или новых методах обеспечения безопасно­
сти. Такая отсечка знаний (knowledge cutojf) порой играет весьма критическую
роль в вопросах безопасности.
Представим, что мы в 2025 году поручаем генерировать код модели, обучен­
ной в 2023 году. За прошедшие пару лет было обнаружено, зафиксировано и ис­
правлено множество уязвимостей. Появились новые векторы атак, фреймворки
добавили функции безопасности, изменились методы решения подобных про­
блем. Если в запросах не предоставить ИИ обновлённую информацию, он ниче­
го не будет знать об этом.
Особенно острым такое ограничение становится в контексте быстро раз­
вивающихся стандартов безопасности и баз данных уязвимостей. Так, напри­
мер, регулярно обновляется список OWASP Тор 10 (https:!!oreil.ly!US-uh), отра­
жающий новые угрозы. Если попросить ИИ «написать безопасную функцию
загрузки файлов», он может предусмотреть разумные меры защиты на осно­
ве имеющихся данных - например, реализовать в коде проверку типа фай­
лов, предусмотреть ограничения по размеру и хранение файлов не в корневом

202

1

Часть 111. Доверие и автономия

каталоге сервера - но без учёта недавно обнаруженных векторов атак или но­
вых рекомендованных методов защиты.
Решение - активное дополнение знаний ИИ с помощью актуальной инфор­
мации по безопасности. Включайте в свои запросы ссылки на текущие луч шие
методы обеспечения безопасности. Например, вместо того чтобы просто попро­
сить ИИ «написать безопасный код», дайте ему такое поручение:
Напиши функцию загрузки файлов с учётом требований безопасности
из OWASP Тор 10 2025 года, с особым вниманием к инъекциям и подделкам
межсайтовых запросов (Server-Side Request Forgery).
Так вы настроите ИИ на актуальные стандарты безопасности, а не на потенциально устаревшие обучающие данные.
Точно так же уже после обучения ИИ во фреймворки могут внедрить ка­
кие-то специальные функции обеспечения безопасности. Так, например, для
приложений на Express.js появилось промежуточное ПО (middleware) Helmet,
(https:!!oreil.ly!WSPar) устанавливающее заголовки безопасности. ИИ, обучен­
ный до того, как Helmet стал частью стандартного процесса, может сгенери­
ровать приложения без этого важного слоя защиты. Итак, явно указывая в за­
просах современные инструменты и практики безопасности, вы помогаете ИИ
создавать код, соответствующий современным стандартам.

Оптимизация журналирования
Уделяйте повышенное внимание журналированию (логированию) критических
участков кода (как сгенерированного ИИ, так и написанного людьми) или потен­
циальных точек отказа. Так вы упростите себе отладку ПО в рабочей среде. Если ИИ
сгенерировал фрагмент кода с минимальным логированием, стоит добавить допол­
нительные записи. Например, если в сгенерированном коде блок catch просто «про­
глатывает» ошибку, то для большей прозрачности измените его так, чтобы ошибка
логировалась (возможно, с добавлением контекста). При этом не забывайте очищать
(санитизировать) логи, чтобы в них не оставалась конфиденциальная информация.

Использование актуальных моделей и инструментов с акцентом
на безопасность
Некоторые ИИ-инструменты для написания кода совмещают функции ге­
нерации кода со встроенным сканированием кода на безопасность. Яркий

Глава 8. Безопасность, поддерживаемость и надёжность 1 203

пример - Snyk с гибридным подходом (https://oreil.ly/OZGFv); он одновремен­
но генерирует код по принципам LLM и проводит анализ помеченных данных
(taint analysis). По утверждениям разработчиков Snyk, при запросе кода (даже
из LLМ-библиотек вроде OpenAI, Anthropic или Hugging Face) Snyk Code от­
слеживает потенциально небезопасные потоки данных и помечает ненадёж­
ные входы до того, как они достигнут чувствительных участков. На практике
это значит, что, увидев запрос к базе данных, Snyk проверяет его параметри­
зацию и предотвращает SQL-инъекции, даже если пользователь забыл указать
это в явном виде. Подобные инструменты особенно полезны тем, что помога­
ют избегать инъекций небезопасного кода через приложения, сгенерированные с ПОМОЩЬЮ ии.

Предупреждения в контексте
Во время работы в IDE часто можно увидеть различные предупреждения или
подчёркнутые фрагменты кода. Современные IDE с функцией IntelliSense, на­
пример, могут отмечать подозрительную конкатенацию строк в SQL-зaпpocax.
Не игнорируйте такие предупреждения только потому, что код сгенерирован
ИИ; постарайтесь выяснить, почему возникло такое предупреждение, и ис­
правьте возможные проблемы. ИИ генерировал код без таких предупреждений
и потому мог допустить ошибки.

Вдумчивый подход
После быстрой генерации большого объёма кода с помощью ИИ стоит немно­
го замедлиться на этапе аудита и перейти в более спокойный режим. При бы­
строй разработке легко увлечься следующей задачей, но важно выделять вре­
мя на проверку текущей. Воспринимайте это так: «ИИ ускорил разработку,
а теперь я, как человек, займусь вопросами безопасности)). Разработчики Snyk
(https://oreil.ly/uUExW) советуют анализировать сгенерированный ИИ-код пря­
мо в IDE и предупреждают об опасности бездумного следования за ИИ. Иными
словами, проверка кода на безопасность должна стать одной из главных задач
в цикле разработки ПО и все возможные уязвимости должны выявляться сра­
зу после написания кода.
Для аудита сгенерированного ИИ-кода используются те же инструменты, что
и при традиционной разработке - статический анализ, динамическое тестиро­
вание, код-ревью, но применять их стоит чаще, потому что сам код создаётся быстрее. Воспринимайте каждый результат работы ИИ как фрагмент, который
нужно проверять обязательно.
204

1

Часть 111. Доверие и автономия

Создание эффективных тестовых фреймворков
для сгенерированных ИИ систем
Безопасность - это один из столпов надёжности, но в более широком смысле поня­
тие надёжности подразумевает и стабильность ПО на фундаментальном уровне. Во­
просы надёжности затрагивают и архитектуру, и вероятность сбоев, и возможные
последствия этих сбоев. Насколько устойчивой к отказам должна быть система? На­
сколько от её работы зависят жизни или безопасность людей? Повлечёт ли её выход
из строя серьёзные последствия для организации и каковы будут её финансовые по­
тери? Эти и подобные вопросы определяют степень строгости, которую нужно бу­
дет соблюдать при разработке и тестировании соответствующего ПО.
При разработке с помощью ИИ требования к надёжности остаются неизмен­
ными. Банковское приложение, сгенерированное с помощью ИИ, должно обес­
печивать ту же точность транзакций и целостность данных, что и приложение,
полностью написанное людьми. Медицинская система обязана соответствовать
одинаковым стандартам безопасности пациентов, независимо от того, как был
написан её код. Участие ИИ в генерации кода не снижает фундаментальных тре­
бований к надёжности.
По мере перехода к разработке с помощью ИИ роль всестороннего тестирова­
ния только усиливается. Надёжный тестовый фреймворк гарантирует коррект­
ное поведение ПО и помогает сохранять его по мере развития проекта. Вместе
с тем, хотя при тестировании сгенерированного ИИ кода следует руководство­
ваться теми же принципами, что и при тестировании кода, написанного чело­
веком, особого внимания требуют некоторые нюансы и детали самого процесса
разработки с помощью ИИ.
В последующих разделах мы рассмотрим, как можно использовать ИИ
не только для генерации кода, но и для создания надёжных тестов, проверяю­
щих стабильность системы, гарантирующих корректную работу ПО и обеспечи­
вающих его надёжность в критических ситуациях.
Для начала стоит посоветовать внедрять регулярное автоматизированное те­
стирование на более ранних этапах. Понятно, что при медленной разработке хо­
чется как можно быстрее добавить новый функционал, а о тестах вспоминают
в последнюю очередь, но, как ни странно, соблазн пропустить тесты возникает
и при быстрой разработке, когда новые функции добавляются почти непрерывно.
Но именно при быстрой генерации кода особенно нужны тесты, выявляющие рег­
рессию (нарушение ранее работавшего функционала) и проблемы с интеграци­
ей. Вырабатывайте в себе привычку после реализации функции с помощью ИИ
сразу же писать для неё тесты (или пользоваться ИИ для написания тестов). Так
вы проверите надёжность функции и защитите её при последующих изменениях.
Глава 8. Безопасность, поддерживаемость и надёжность

1 205

Согласно проведённому в 2022 году исследованию (https://oreil.ly!Vc8Gd),
разработчики с ИИ-ассистентом воспринимали сгенерированный код как бо­
лее безопасный, даже если объективно он был менее безопасным по сравнению
с кодом, написанным без участия ИИ. Такую излишнюю уверенность неплохо
было бы подкрепить реальными тестами.
Как говорилось в главе 4, ИИ можно использовать не только для генерации
кода, но и для создания набора тестов. Помимо прочего, ИИ помогает прове­
рять сгенерированный им же код - так он занимается не только реализацией,
но и первичной валидацией. Например, после генерации нового модуля можно
задать следующий запрос:
Напиши модульные тесты для этого модуля, покрывающие граничные случаи.
Если тесты выполняются корректно, отлично. В противном случае либо
в коде скрыт какой-то баг, либо тесты ожидали какого-то другого результата.
Постарайтесь разобраться в ситуации и исправьте либо код, либо тесты.
Но будьте внимательны: ИИ может неправильно истолковать как некоторые
результаты, так и поведение кода, поэтому и его код, и его тесты следует вос­
принимать только как рекомендации, а не как истину в последней инстанции.
Скорее всего, вам придётся немного подправить ожидаемые результаты теста
в соответствии с ожидаемым поведением программы, но даже в таком случае
вы почерпнёте немало пользы и научитесь чётко формулировать свои запросы.
Интегрируйте набор тестов в СI-пайплайн, который запускается при каж­
дом коммите. Проследите за тем, чтобы при каждом добавлении или изменении
сгенерированного ИИ кода все тесты выполнялись автоматически. Так любые
ошибки или «поломки» можно будет обнаружить на ранней стадии. Иногда ИИ
вносит изменения, которые каким-то не очень явным образом нарушают рабо­
ту ПО (например, меняют сигнатуру функции или формат вывода), но набор
надёжных тестов позволяет выявить такие недостатки. Также включайте в про­
цесс CI проверки безопасности (nрм audi.t, статический анализ и другие) для
своевременного выявления любых потенциально опасных уязвимостей. Что ка­
сается конкретных типов тестов, то здесь можно отметить следующие.
Тестирование свойств и фаззинг
Очень полезны тесты свойств (с помощью таких инструментов, как Hypothesis
для Python (https:!/oreil.ly/JcYBfJ или fast-check для JavaScript (https:!!fast­
check.dev)). Вместо того чтобы прописывать отдельные тесты с конкретны­
ми входными данными и ожидаемыми результатами, можно задать высоко­
уровневые свойства, которым код должен соответствовать всегда. На основе

206

Часть 111. Доверие и автономия

определения этих свойств фреймворк генерирует широкий диапазон вход­
ных данных для проверки, соблюдаются ли эти свойства.
Возьмём в качестве примера задачу по сортировке. Вместо явной провер­
ки вида so г t ( [ 3, 1, 2] ) === [ 1, 2, 3] можно задать такие свойства:
- результат должен быть отсортированным;
- он должен содержать те же элементы, что и входные данные.
Далее инструмент генерирует десятки или сотни входных массивов для
проверки этих условий и находит граничные случаи, которые при ручном те­
стировании легко было бы упустить из виду.
Особенно такая проверка с условиями полезна для сгенерированного ИИ­
кода. Если ИИ написал функцию нормализации адресов электронной почты
(которая, например, переводит символы в имени домена в нижний регистр),
тест на свойства может проверить идемпотентность результата - то есть
проверить, выдаёт ли повторный запуск функции тот же результат, что и пер­
вый запуск. Если какой-то граничный случай нарушает это условие, фрейм­
ворк тестирования сгенерирует контрпример, который поможет диагностировать ошибку.
Нагрузочное тестирование и тестирование производительности
ИИ порой генерирует далеко не оптимальный код, поэтому имеет смысл
проверять систему под нагрузкой. Эффективность работы под нагрузкой ещё один аспект надёжности ПО. Для этого используют инструменты вро­
де JMeter, Locust или kб, моделирующие большое количество запросов или
большие объёмы входных данных и проверяющие, выдерживает ли система
такую нагрузку. При неудачных результатах тестов выявляют слабые места.
Так, например, ИИ может прописать в коде какой-нибудь наивный алго­
ритм со сложностью O(n2), который нормально обрабатывает 100 элементов,
но начинает «тормозить» уже на 10 000. Без тестов на производительность
такую просадку можно заметить только уже на стадии продакшена, поэто­
му по возможности нужно включать тесты на производительность на ста­
дии разработки: измеряйте время выполнения критических операций при
росте объёма входных данных или пользуйтесь профилировщиками, кото­
рые помогают понять, на что тратится процессорное время или память при
тяжёлых нагрузках.
Обработка ошибок
Намеренно вызывайте ошибки, чтобы проверить, насколько корректно их
обрабатывает система, например:
Глава 8. Безопасность, поддерживаемопь и надёжность

207

- для API: отключите базу данных и посмотрите, возвращает ли API понят­
ное сообщение об ошибке. При некорректном поведении добавьте код об­
работки ошибок подключения к базе данных (или попросите ИИ доба­
вить его);
- для фронтенд: смоделируйте ситуацию, когда бэкенд возвращает ошиб­
ки 500, и проверьте, действительно ли выводится сообщение об ошибке,
а не пустая страница или бесконечный индикатор загрузки.
При генерации кода ИИ не всегда учитывает такие сценарии, поэтому их
нужно специально тестировать и затем дорабатывать обработку ошибок. Та­
кая проверка повышает надёжность системы, потому что заставляет разра­
ботчиков добавлять правильную логику отката, механизмы повторных по­
пыток или понятную обратную связь для пользователя.
Мониторинг и логирование
Интегрируйте в рабочий процесс журналирование и используйте записи ло­
гов в тестах для верификации. Например, если какое-то действие должно со­
здавать запись в аудит-журнале, нужно проверить, действительно ли создаёт­
ся такая запись. ИИ умеет генерировать строки логов, но нужно проследить
за тем, чтобы они выводились в корректном формате.
Также стоит подумать и о настройке мониторинга (для тестов можно
симулировать мониторинг сервиса в памяти). Например, проверьте, за­
носятся ли в журнал сообщения о необработанных исключениях во вре­
мя тестовых прогонов. Если да, то считайте это неудачным результатом,
потому что он говорит о том, что какой-то сценарий обрабатывается не­
корректно.
Поддерживаемость
Не менее важно тестировать код и на поддерживаемость - например, про­
верять его на соответствие стилям и стандартам. Для единообразия поль­
зуйтесь линтерами и форматтерами, потому что стили разных фрагмен­
тов сгенерированного ИИ-кода могут немного отличаться в зависимости
от запросов. Унифицировать стиль помогут такие инструменты формати рования, как Prettier (https:!lprettier.io) или Black для Python (https:l/pypi.org!
project!Ыack). Для большей логической согласованности и выявления из­
лишне сложного кода, который может потребовать рефакторинга, добавьте
правила линтинга - например, ограничивающие сложность функций. Под­
робнее об этом говорится в разделе «Поддерживаемость кодовых баз, со­
ставляемых с помощью ИИ».
208

1

Часть 111. Доверие и автономия

При наличии готовых тестов заниматься рефакторингом сгенерированно­
го ИИ-кода становится гораздо легче, как и легче следить за его безопасностью.
Любое рабочее, но в каком-то смысле «громоздкое» решение можно всегда улуч­
шить с опорой на тесты, которые не дадут ему «сломаться». Можно даже попро­
сить ИИ сделать рефакторинг написанного им же кода:
Сделай рефакторинг этой функции для повышения читаемости, но так, что­
бы она соответствовала имеющимся тестам.
Если тесты качественные, они подтвердят, что рефакторинг ничего не нару­
шил.
ИИ-системам присуща некоторая доля недетерминизма, поэтому полезно
различать два принципиально разных сценария. Когда ИИ подключается к системе во время работы приложения - например, в виде отвечающего на вопро­
сы пользователей чат-бота или в виде рекомендательной системы - выходные
данные могут различаться между собой даже при одинаковых входных данных.
Вариативность ответов зависит от таких параметров, как температура модели,
случайный «сид» или изменение внутреннего состояния. Такие системы тестиру­
ют с помощью особых методов с учётом допустимого диапазона вариантов и без
ожидания точного совпадения результатов.
Но генерация кода с помощью ИИ - это совершенно другая схема работы.
После того как ИИ сгенерировал код и код отправлен в репозиторий, этот фраг­
мент становится таким же детерминированным, как и фрагмент кода, напи­
санного человеком. Функция расчёта налоговых ставок будет каждый раз воз­
вращать один и тот же результат независимо от того, написал её человек или
ИИ. Такая детерминированность крайне важна для надёжности системы, и по­
тому сгенерированный ИИ-код тестируют с помощью хорошо известных тра­
диционных методов.
Более деликатная проблема возникает при интеграции нескольких сгене­
рированных ИИ компонентов, особенно если каждый создавался независи­
мо от другого и с разными неявными допущениями. Рассмотрим эту ситуацию
на примере системы электронной коммерции. Допустим, ИИ попросили сгене­
рировать модуль обработки заказов с требованием поддерживать международ­
ные заказы. Отдельно ИИ попросили создать сервис расчёта доставки для той же
системы. В итоге получилось так, что модуль обработки заказов форматирует
даты по американскому стандарту - например, как «12/25/2024» для 25 дека­
бря. Сервис же доставки ожидает даты в европейском формате, то есть в виде
«25/12/2024». Оба компонента по отдельности работают корректно и успешно
проходят свои модульные тесты.
Глава 8. Безопасность, поддерживаемость и надёжность

209

Несоответствие проявляется только на этапе интеграционного тестирования,
когда модуль обработки заказов передаёт дату сервису расчёта доставки. Сервис
интерпретирует запись «12/01/2024» как 12 января, а не 1 декабря и в результа­
те неверно рассчитывает сроки доставки. Такие расхождения в допущениях до­
вольно характерны для сгенерированных ИИ компонентов, потому что при не­
зависимой генерации каждого компонента модель может опираться на разные
примеры или региональные стандарты. Поэтому такую важную роль играет ком­
плексное интеграционное тестирование, проверяющее реальный поток данных
между компонентами, и чем раньше выявятся несоответствия между компонен тами, тем быстрее можно довести ПО до готового к продакшену.
Что касается обеспечения качества (QA) в проектах с использованием ИИ,
то эта задача часто требует большей изобретательности по сравнению с тра­
диционными проектами, потому что ИИ чаще создаёт нетипичные граничные
случаи. Например, модель может реализовать функционал, о котором её явно
не просили, и в таком случ ае тесты должны охватывать и этот функционал. При
обнаружении непредусмотренного поведения его нужно либо удалить, либо за­
фиксировать и протестировать.
Под конец стоит сказать, что тестировать приложение лучше всего в окру­
жении, максимально приближенном к продакшену и с реалистичной нагрузкой
данных. Некоторые проблемы с производительностью проявляются только при
больших объёмах данных или при большом количестве одновременных запро­
сов. Результаты таких тестов помогают выявить проблемные места и неэффек­
тивные участки системы.

Оптимизация производительности
ИИ далеко не всегда генерирует оптимальный, хотя и корректный код. Сами по себе
большие языковые модели (LLM) не занимаются анализом производительности;
они, как правило, воспроизводят то, что встречалось в обучающих данных. Поэто­
му следует особое внимание уделять потенциальным проблемам производительно­
сти, особенно для критически важных участков кода или при его масштабировании.
Впрочем, с ИИ можно обсудить идеи по оптимизации производительности.
- Какова сложность этого кода? Можно ли её улучшить?
- Эта функция работает медленно, какими способами её можно ускорить?
ИИ не всегда даёт корректные или практичные решения, но иногда даёт по­
лезные советы или хотя бы подтверждает ваши идеи.
210

Часть 111. Доверие и автономия

При этом слишком увлекаться оптимизацией не стоит. Иногда предложенное
ИИ решение само по себе работает неплохо, особенно если объём данных неве­
лик или операции выполняются редко. Данные профилирования помогут вам
сосредоточиться на самых проблемных местах и оптимизировать то, что дейст­
вительно требует оптимизации. Преимущество вайб-кодинга как раз заключа­
ется в том, что не нужно тратить время на создание кода с нуля, поэтому некото­
рые не слишком важные фрагменты можно оставить достаточно простыми, без
максимальной оптимизации, если, конечно, это не влияет на пользовательский
опыт или затраты. О том же говорит и правило эджайла: сначала сделать нечто
работающее и только потом ускорять (если нужно).
Перечислим области (направления оптимизации), на которые нужно в первую
очередь обратить внимание при оптимизации проекта, созданного с помощью ИИ.
Анализ сложности
Если ИИ генерирует реализацию какого-то алгоритма, стоит оценить слож­
ность этого алгоритма. Иногда модель ИИ выбирает наивное решение, несмо­
тря на наличие более эффективного. Например, она может сортировать список
дважды, потому что не вспомнила одношаговый метод - так сложность реше­
ния становится O(n log n х 2), когда хватило бы и O(n log n) (здесь О обозначает
сложность относительно памяти и ресурсов). Или она использует вложенные
циклы, повышающие сложность до O(n2 ), хотя известен способ со сложностью
O(n). В этом случае имеет смысл попросить ИИ улучшить решение:

Можно ли оптимизировать этот фрагмент так, чтобы в нём не было вложен­
ных циклов? Например, использовать для поиска множество (set).
Часто ИИ по такому запросу выдаёт решение получше, но иногда прихо­
дится оптимизировать его вручную.
Выявить медленные функции можно с помощью профайлера или посред­
ством измерения времени выполнения ключевых участков кода с репрезен­
тативными данными или с данными для худшего сценария. Если какой-то
фрагмент выполняется слишком медленно, можно попробовать оптимизировать его вручную или с помощью ИИ:
Оптимизируй эту функцию (узкий участок на данный момент); попробуй
уменьшить её сложность.
ИИ постарается переделать код так, чтобы повысилась производительность.
Чтобы убедиться в корректности выполнения кода, прогоните его через тесты.
Глава 8. Безоласность, поддерживаемость и надёжность

211

Для критически важных алгоритмов стоит написать небольшой бенчмарк­
харнесс (тестовую среду для измерения производительности). Если ИИ генери­
рует код для вычислений, протестируйте его вместе с альтернативой или хотя бы
измерьте, как масштабируется выполнение при увеличении объёма данных. При
необходимости перепишите код так, чтобы повысить его эффективность.
Использование памяти, утечки и удержание
Сгенерированный ИИ-код может задействовать слишком много памяти например, вместо потоковой обработки загружать в память целые файлы
и одновременно удерживать в ней большие структуры данных. При работе
с большими объёмами данных проверяйте, как система использует память,
и при необходимости оптимизируйте код с учётом потоковой обработки или
разбиения данных на части.
Например, если нужно обработать миллионы записей, лучше будет перепи­
сать сгенерированную ИИ функцию загрузки всех записей loadAl lRecords ()
так, чтобы она обрабатывала данные порциями или потоком из базы данных.
Также проверьте, освобождает ли сгенерированный ИИ-код ресурсы.
В языках вроде Java или С# можно открыть подключение к базе данных и не
закрыть его. В одностраничном фронтенд-приложении обработчики собы­
тий могут не закрываться, что приводит к утечкам памяти. Здесь помогают
инструменты наподобие Memory Inspector в Chrome DevTools для фронтен­
да или Valgrind для поиска утечек в С++, но часто бывает достаточно просто
внимательно проверить код. Постарайтесь найти и исправить подобные про­
блемы. Заметив, например, что открытый файловый дескриптор так и про­
должает оставаться открытым, закройте его в блоке fi.na lly.
Конкурентность и параллелизм
Если вы пользуетесь языками с поддержкой нескольких потоков или асинхронности, постарайтесь найти в сгенерированном ИИ-коде места, где под­
держивается только один поток, хотя можно было бы запустить параллель­
но несколько. ИИ не всегда автоматически применяет асинхронные функции
async/ awai. t там, где это уместно, и может «забыть», что задачу, потребляю­
щую значительное количество ресурсов центрального процессора, стоит вы­
нести в рабочий поток.
Например, для ограниченных выводом задач в Node.js или Python лучше
предусмотреть асинхронное выполнение, чтобы система не блокировалась.
Для «тяжёлых» с точки зрения процессорных ресурсов задач ИИ, возмож­
но, предложит далеко не лучший вариант, но его решение можно переписать
на более производительном языке или вынести в фоновое задание.
212

Часть 111. Доверие и автономия

Кешuрованuе
К задачам, которые ИИ оптимизирует далеко не всегда, можно добавить и ке­
ширование результатов ресурсоёмких операций. Внимательно просмотри­
те полученный код - не пересчитывается ли в нём что-то повторно? Если
да, то стоит добавить кеширование (либо в памяти, либо с помощью внеш­
него кеша вроде Redis). ИИ можно дать следующий запрос:
Добавь в эту функцию кеширование, чтобы не производить повторные вы­
числения.
ИИ постарается реализовать простую мемоизацию или предложит вос­
пользоваться специализированной библиотекой для кеширования.
Оптимизация запросов к базе данных
Если приложение использует базу данных, внимательно изучите сгенериро­
ванные ИИ-запросы. Насколько корректны в них индексы? Не написал ли
ИИ SELECT * там, где достаточно будет лишь нескольких столбцов? Не извле­
кает ли он большой объём данных, которые далее фильтруются в коде, из-за
чего возникают узкие места производительности, такие как проблема N + 1
запросов. Все такие неэффективные решения требуют оптимизации, в основ­
ном за счёт переноса большей части обработки на сторону базы данных или
благодаря корректным индексам.
Например, если в сгенерированном ИИ-коде вызывается метод fi.ndOne
внутри цикла, заставляющий много раз обращаться к базе, то можно вместо
него прописать один пакетный запрос с использованием WHERE i.d IN ( ••. ).
И аналогично, если ИИ в миграции не создал индексы для часто используе­
мых полей, для приемлемого уровня производительности нужно будет доба­
вить такие индексы. ИИ часто генерирует функционально корректные, но не­
оптимальные взаимодействия с базой данных; выявить и устранить такие
проблемы помогает человеческая экспертиза.
Рассмотрим пример. Допустим, ИИ написал функцию, объединяющую два
отсортированных массива с помощью простой конкатенации и последующей
сортировки результата (сложность O(n log n)), хотя мог бы воспользоваться
известным линейным алгоритмом слияния двух отсортированных списков
(например, шаг rчегgе в сортировке слиянием, сложность O(n)). Во время код­
ревью выясняется, что этот алгоритм для больших массивов станет узким ме­
стом по производительности, так что вы просите ИИ реализовать линейное
слияние:
Глава 8. Безопасность, поддерживаемость и надёжность

213

Оптимизируй функцию mergeSortedArrays так, чтобы она выполняла слия­
ние за линейное время без использования встроенной сортировки.
ИИ «вспомнит» классический алгоритм слияния и постарается реализовать
его. Финальный результат хорошо проходит через тесты на производительность.
Так удалось повысить производительность, не пожертвовав корректностью.
Разработка с использованием ИИ - это не повод забыть об оптимизации
производительности, ИИ лишь смещает момент, когда этой оптимизацией нуж­
но заниматься. Чаще всего сначала генерируется корректное решение (что уже
ценно само по себе), и только потом разработчики переходят к измерениям и то­
чечной оптимизации, в которой вам поможет тот же ИИ при условии чёткой
формулировки требований.

Поддерживаемость кодовых баз, составляемых
С ПОМОЩЬЮ ИИ
Под поддерживаемостью кодовой базы понимают удобство её обслуживания,
обновления, развития и чтения по мере роста проекта. Многие разработчики
опасаются, что сгенерированный ИИ-код получится слишком неаккуратным
или несогласованным с другими фрагментами кода, особенно если при гене­
рации пользоваться разными запросами с разными стилями или шаблонами.
В этом разделе мы рассмотрим способы преодоления этой проблемы, которые
помогут сохранять прозрачность и читаемость кода в проекте с использованием вайб-кодинга.

На этапе формулировки запросов
При формулировке запросов стоит учитывать несколько моментов.
Единь1е стандарты кода
Для сохранения единого стиля разных фрагментов кода пользуйтесь линте­
рами и форматтерами. Как уже говорилось, ИИ при ответах на разные запро­
сы часто ориентируется на разные соглашения об именовании или форматировании. Пропустив весь сгенерированный код через форматтер (например,
Prettier для JavaScript, Black для Python, gofmt для Go и т. д.), вы значительно
повысите единообразие всего кода, что упростит его чтение (за счёт сниже­
ния когнитивной нагрузки при переключении между стилями). Кроме того,
стоит заранее определиться с правилами именования в проекте и строго
214

1

Часть 111. Доверие и автономия

придерживаться их. Если в одном фрагменте ИИ называет функцию get_
user_data, а в другом - fetchUserData, нужно остановиться на одном сти­
ле (snake_case, camelCase и т. д.) и привести все имена к нему.
Архитектурные паттерны для обеспечения модульности и предотвращения
разрастания кода
Просите ИИ писать модульный код, предлагая разбивать логику на отдель­
ные фрагменты. Например, вместо того чтобы попросить ИИ написать еди ный файл для всего сразу, разбейте задачу на части:
- создай класс UserService для пользовательской логики;
- создай отдельный модуль для отправки электронных писем.

В результате формируется кодовая база с чётким логическим разделением.
Когда у каждого модуля есть ясная зона ответственности, сопровождать та­
кой код значительно проще. Архитектурные решения можно указывать в за­
просе напрямую, например:
Вынеси код доступа к базе данных в отдельный файл или класс, отделив его
от кода маршрутизации API.
Так как при работе с ИИ добавлять новые функции очень легко, особенно
важно следить за тем, чтобы функционал не разрастался сверх меры и что­
бы база данных не «расползалась». Без дисциплины и чёткого представления
об архитектуре кодовая база рискует превратиться в то, что разработчики
называют «большой кучей грязи» (Ьig ball of mud, антипаттерн, при котором
в коде отсутствуют чёткая структура и границы). ИИ только усиливает этот
риск, и деградация архитектуры может ускориться, так как на добавление
функционала уходит меньше времени и сил.
Чтобы не допустить такого расползания кодовой базы, опирайтесь в раз­
работке с помощью ИИ на проверенные архитектурные паттерны и прин­
ципы. При формулировке запроса явно ссылайтесь на уже используемые
в проекте образцы:
- добавь новую функцию, следуя принятому в проекте паттерну repository/
service;
- реализуй это с помощью установленной в нашем доменном слове гекса­
гональной архитектуры.
Такая конкретика помогает сохранять архитектурную целостность даже
при быстром разрастании функционала.
Глава 8. Безопасность, поддерживаемость и надёжность

215

Разработчикам, желающим получить более основательные знания по архи­
тектуре, можно посоветовать ряд фундаментальных работ, предоставляющих
необходимую базу.
- Design Patterns: Elements of ReusaЫe Object-Oriented Software (Addison­
Wesley, 1994) - Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон Влис­
сидес ( Gang ofFour). До сих пор остаётся эталонным собранием часто ис­
пользуемых проектных решений.
- Fundamentals of Software Architecture: Ап Engineering Approach - Марк Ри чардс и Нил Форд. Книга предлагает всесторонний обзор архитектурных
паттернов и принципов в разных технологических стеках.
- Domain-Driven Design: Tackling Complexity in the Heart of Software - Эрик
Эванс (Addison-Wesley, 2003). В книге описаны ключевые приёмы согла­
сования архитектуры ПО с бизнес-доменом, что особенно полезно, когда
сложную бизнес-логику генерирует ИИ.
Эти книги дают представление об основных архитектурных принципах, ко­
торые помогут осознанно пользоваться ИИ-инструментами без накопления тех­
нического долга. Не забывайте, что ИИ отлично реализует паттерны, но не умеет
определять, какие из них уместны в том или ином контексте. Общими архитек­
турными решениями до сих пор должен заниматься человек.

Работа с результатами генерации кода
После того как ИИ выдал сгенерированный код, нужно позаботиться о его со­
провождаемости, а для этого применяются следующие приёмы.
Рефакторинг по мере необходимости
Не стесняйтесь переделывать сгенерированный ИИ-код, если вам кажется, что
такая переделка оправданна. Часто бывает так, что первый вариант работает кор­
ректно, но не слишком удачен с точки зрения структуры - например, функция
слишком длинная или одна и та же логика дублируется в разных местах. ИИ
иногда «не понимает», что две функции делают одно и то же, и прописывает обе.
Заметив подобные дубликаты, постарайтесь объединить их. Выявлять их помо­
гают такие инструменты, как линтеры, подсвечивающие похожие участки кода.
Для рефакторинга можно использовать запросы вроде следующего:

Сделай рефакторинг этого кода (переработай этот код), убери дубликаты
и улучши читаемость.
216

Часть 111. Доверие и автономия

ИИ постарается вынести общую логику во вспомогательные функции или
упростить отдельные участки. После каждого рефакторинга обязательно за­
пускайте тесты.
Тестирование
В этой главе уже рассматривалось тестирование, поэтому здесь стоит лишь
напомнить, что хорошая тестовая база в значительной степени упрощает со­
провождение кода. Когда вам или другим разработчикам в будущем нужно
будет изменить код (возможно, также с помощью ИИ), тесты помогут вы­
явить проблемные участки. Так вы будете спокойно заниматься рефакторин­
гом или менять реализацию. Тесты позволяют отделить структуру кода («как
он это делает») от его функционала («что именно он делает») и тем самым сво­
боднее менять структуру без риска затронуть функционал.
Отказ от излишней сложности или специфических для ИИ конструкций
Иногда ИИ использует какой-нибудь замысловатый трюк или незнакомую
для разработчика редкую функцию. Само по себе это не плохо, но не забы­
вайте о сопровождении кода. Если код кажется слишком непонятным для
среднестатистического разработчика, постарайтесь его упростить. Напри­
мер, если ИИ воспользовался «магией» регулярных выражений или слишком
мудрёным генератором списков, перепишите код с использованием циклов
(или, по крайней мере, оставьте комментарии).
Иногда ИИ чрезмерно усложняет решение, добавляя лишние уровни аб­
стракции, или вводит дополнительный слой, не приносящий никакой реаль­
ной пользы. Такие элементы стоит удалять, чтобы код оставался простым
и понятным. Простой код обычно легче сопровождать.
Паттерны устойчивости и механизмы отката
На случай сбоев продумайте стратегии и механизмы отката. Например, как
будет вести себя программа, если сгенерированный ИИ компонент обраща­
ется к внешнему API, а тот недоступен или возвращает неожиданные дан­
ные? В этом случае можно воспользоваться кешированными данными или
ответом по умолчанию. Такие «паттерны устойчивости» (автоматические вы­
ключатели, повторные попытки с увеличивающейся задержкой и т. д.) повы­
шают надёжность системы, но без явного указания в запросе ИИ их обыч­
но не применяет. Проследите за тем, чтобы система корректно реагировала
на частичные сбои. Отказ одного микросервиса не должен выводить из строя
всё приложение. Для предсказуемой и аккуратной обработки сбоев пользуй­
тесь таймаутами и логикой отката.
Глава 8. Безопасность, поддерживаемость и надёжность

217

Завершающий этап
После того как код будет приведён в надлежащий вид, его сопровождаемость по­
могут поддерживать ещё несколько приёмов и методов.

Документация и комментарии
Не забывайте о документации к коду. Обычно, если ИИ не попросить об этом,
он оставляет минимальное количество комментариев, поэтому будут полез­
ны такие запросы:
- добавь комментарии, объясняющие назначение каждого раздела кода;
- напиши для этой функции строку документации.
Так вы сэкономите время тем, кто будет читать код после вас. ИИ обычно
неплохо объясняет код, но иногда неправильно толкует некоторые моменты,
и поэтому его комментарии обязательно нужно проверять.
Также имеет смысл поддерживать документацию более высокого уровня
(в виде, например, файлов README или «дизайнерского документа»), в кото­
рой описывается архитектура проекта, перечисляются основные компоненты
и тому подобное. Конечно, в основном такие тексты можно писать самосто­
ятещ,но, но помощь ИИ может оказаться полезной - например, если нужно
вкратце описать структуру кодовой базы.
Заметив в коде какие-то повторяющиеся особенности, стоит отме­
тить их в специальных заметках для разработчиков, например: «ИИ все­
гда странно называет этот параметр». Такие заметки должны стать частью
новой среды совместной разработки. Если со сгенерированным ИИ кодом
работаете только вы, к отдельным странностям можно привыкнуть, но ко­
гда к проекту подключаются другие специалисты, у них неизбежно возник­
нут вопросы к коду. В таких случаях лучше сразу договориться о стандар­
тах именования.
Ещё один полезный совет для повышения сопровождаемости - отмечать,
какие фрагменты кода были сгенерированы ИИ, а какие написаны челове­
ком. Формально это не обязательно, но в некоторых командах принято остав­
лять комментарии наподобие: «Сгенерировано с помощью GPT-4, 2025-05-01».
В идеале всё, в отношении чего могут возникнуть сомнения, стоит явно по­
мечать в описании пул-реквеста: «Эта функция написана с использованием
ChatGPT; на первый взгляд всё работает, но стоит внимательно проверить
логику обработки ошибок».
Пока что это не общепринятая практика. Она полезна на этапе ревью,
но обычно не нужна, если код уже просмотрен человеком и воспринимается
218

Часть 111. Доверие и автономия

как обычная часть кодовой базы. Если вы всё же сохраняете запросы или
записи диалогов с ИИ, то в комментариях можно помечать сложные участ­
ки: «Алгоритм получен с помощью GPT-4 на основе запроса Х; разбор запро­
са смотри в документации». Ревьюеру не нужно как-то особенно относиться
к такому коду, так как любой код нужно проверять одинаково вниматель­
но, но описание контекста помогает лучше оценить ситуацию. Если, напри­
мер, стиль какого-то фрагмента отличается от остальных участков или в нём
встречается какая-то нетипичная идиома, комментарий о том, что этот код
сгенерирован ИИ, подскажет, что это не осознанный выбор разработчика,
а артефакт генерации.

Код-ревью и командные соглашения
Если вы работаете в команде, код должны просматривать все, даже если его
и написал только один разработчик с помощью ИИ. Коллеги помогут выявить неудачные решения или отклонение от принятых в коллективе правил.
Со временем вы научитесь лучше составлять запросы так, чтобы ответы ИИ
соответствовали принятому в команде стилю (например, описывая требо­
вания в системных запросах или в начальных инструкциях). Если ИИ поль­
зуются несколько разработчиков, то они должны все придерживаться одних
правил, одного стиля и одних и тех же соглашений об архитектуре, отмечая
их в запросах (например: «Пиши в функциональном стиле» или «Используй
async/await, а не функции обратного вызова»). Дополнительные рекоменда­
ции по ревью, написанному с привлечением ИИ, рассматриваются в следу­
ющем разделе.
Отслеживание технического долга
Если в процессе разработки вы сознательно решаете воспользоваться оче­
видно неидеальным ответом ИИ, зафиксируйте его как «технический долг»
в комментариях или в списке задач проекта (TODO), например: «TODO: ра­
бочее решение со сложностью O(n2 ); при увеличении объёма данных нужно
оптимизировать» или «TODO: для простоты используется глобальная пере­
менная; позже нужно исправить». Можно попросить ИИ явно добавлять та­
кие пометки.
Если какие-то участки в дальнейшем нужно будет доработать, помечай их
какТОDО.
Главное - не забывать потом возвращаться к этим заметкам и вносить со­
ответствующие исправления.
Глава 8. Безопасность, поддерживаемость и надёжность

219

Обучение на примерах ИИ
Если ИИ воспользовался какими-то неизвестными вам паттернами или биб­
лиотеками, лучше не игнорировать их, а изучить подробнее. Знакомство
с определённым приёмом кеширования или с конкретной библиотекой помо­
жет вам в дальнейшем поддерживать код и при необходимости перерабатывать его. Если решение выглядит слишком экзотичным, его можно заменить
на более привычное. Но иногда ИИ приятно удивляет: предлагает полезный
и при этом широко известный паттерн или инструмент, о котором вы просто
не знали. Если это распространённое решение, команда может освоить его
и принять на вооружение, что даже улучшит поддерживаемость.
В целом поддерживаемость подразумевает хорошо известные базовые
принципы поддержки ПО, только в отношении кода, написанного частично
с привлечением ИИ. Отличие лишь в том, что поскольку ИИ снижает объём
рутинной работы, у разработчиков появляется больше времени на рефакто­
ринг и составление документации, а это напрямую улучшает поддерживае­
мость кода.
Некоторые компании сообщают, что после первоначальной генерации
кода с помощью ИИ они выделяют время для так называемых закрепляю­
щих спринтов, посвящённых рефакторингу, стабилизации и документации
всего сгенерированного кода (https://oreil.ly/2lrTW). Также в качестве потен­
циальной стратегии можно рассматривать чередование спринтов с активной
генерацией кода и спринтов, ориентированных на доработку кода.

Стратегии код-ревью
Как обсуждалось в главе 4, код-ревью - это ключевой процесс в традиционной
разработке ПО, и он сохраняет свою важную роль в разработке с помощью ИИ.
В этом разделе рассматриваются некоторые особенности, которые стоит учиты­
вать, если часть кода для ревью была предложена машиной. Так как ИИ способен
очень быстро генерировать большой объём кода, то могут возникнуть опасения,
что ревью станут «узким местом», замедляющим общий процесс разработки,
но эти опасения не должны мешать собственно ревью. Проверка кода - это
очень важный этап. Не пытайтесь сэкономить время исходя из предположения
«Если код был быстро написан, то и проверять его нужно быстро». Лучше чаще
коммитить небольшие изменения, чтобы ревью проходили чаще (и вообще, это
хорошая практика). Частые и небольшие пул-реквесты (PR) проверять проще,
чем один объёмный. При правильном планировании процесса разбивать зада­
чи на части можно также с помощью ИИ.
220

Часть 111. Доверие и автономия

Не считайте код «правильным» только потому, что «его написал ИИ и он про­
ходит тесты». Проявляйте критическое мышление и анализируйте его логику.
По возможности протестируйте её мысленно или добавьте в тесты дополнитель­
ные проверки, потому что базовые тесты могут охватывать не все случаи. Можно также запустить код на выполнение и даже поэкспериментировать с входны­
ми данными, чтобы проверить его поведение.
Код-ревью можно также рассматривать как инструмент обучения. Если
ИИ предлагает по-настоящему эффективное решение, неизвестное рецензен­
ту, рецензент может обучиться чему-то новому и полезному. А если автор кода
по совету ИИ написал неоптимальное решение, то рецензент может подсказать
автору решение получ ше. Такая обратная связь со временем повышает эффективность использования ИИ; команда учится лучше составлять запросы и лучше
понимает, что следует ожидать от искусственного интеллекта. В каком-то смыс­
ле код-ревью - это завершение цикла обучения человека, ведь автор кода дол­
жен понять и усвоить всё, что предложил ИИ.
Во время ревью в первую очередь нужно убедиться, что код соответствует
требованиям и предполагаемому дизайну. Делает ли код или исправление то, что
было задумано? Охватывает ли он все указанные в спецификациях граничные
случ аи? При неточном запросе ИИ может решить немного иную задачу, преду­
смотреть неожиданный случай или пропустить нужный. Это вполне нормаль­
ная ситуация, но разработчик должен проследить за тем, чтобы не был одобрен
код, решающий задачу лишь частично. Например, ИИ может сгенерировать код
для форматирования даты не в том часовом поясе, в каком нужно.
Если для рецензента в коде не всё очевидно, он должен попросить автора
объяснить, как этот код работает и почему он именно такой. Если автор за­
трудняется с объяснениями или говорит: «Так предложил ИИ, и я подумал,
что это правильно», то это тревожный сигнал. Все специалисты в команде
должны понимать все фрагменты кода во всей кодовой базе. При любом сом­
нении авторы должны тщательно проверять сгенерированный ИИ-код или
документацию, чтобы объяснить все сомнительные места, по возможности
в комментариях.
Также обращайте внимание на уязвимости в отношении безопасности и про­
изводительности, о которых шла речь ранее в этой главе. Не забывайте отме­
чать случаи нарушения каких-то общепринятых правил - например, когда вы­
вод не экранируется (в веб-разработке) или в коде в явном виде указываются
учётные данные.
Если код работает, но его можно упростить или переделать так, чтобы он луч­
ше соответствовал принятому в команде стилю, можно попросить автора вне­
сти соответствующие исправления:
Глава 8. Безопасность, поддерживаемость и надёжность

221

ИИ создал для разных ролей пользователя три отдельные функции, которые
почти полностью дублируют друг друга. Можно ли объединить их в одну
функцию с параметром для роли?
Автор постарается выполнить вашу просьбу (возможно, с помощью ИИ).
Также особо отмечайте случаи несоответствия предложенного ИИ решения
принятому командой стилю или случаи использования несогласованных биб­
лиотек:
Для НТ ТР-запросов мы обычно пользуемся библиотекой requests, но в этом
коде указан модуль http.client. Давайте для согласованности придерживать­
ся requests.
Автор кода в ответ может попросить ИИ переписать код с использованием
соответствующей библиотеки.
Если ИИ написал что-то действительно сложное, например реализовал ка­
кой-то хитрый алгоритм, постарайтесь дополнительно обсудить его с другими
рецензентами или посовещаться со всеми членами команды.
Для ревью можно попробовать воспользоваться новыми инструментами
с поддержкой ИИ - например, Copilot от GitHub Copilot для Pull Request, кото­
рый умеет генерировать краткие описания и выделять потенциальные ошибки
и другие проблемы. Такие инструменты могут выдавать подсказки вроде следу­
ющей: «Этот фрагмент кода похож на фрагмент в модуле Х с небольшими отли­
чиями» (предположение о возможном дублировании). Такие подсказки служат
отличным дополнением к ревью со стороны человека, но не заменяют его.
Наконец, во время ревью сохраняйте уважительный и конструктивный на­
строй. Даже обнаружив допущенные ИИ ошибки, не обвиняйте разработчика
во всех грехах; да, ответственность всегда остаётся за человеком, но учитывайте
контекст. ИИ - это инструмент, с которым работают и автор, и рецензент. Цель
ревью - улучшить код и поделиться знаниями, а не поиск виноватых. Старай­
тесь выражаться примерно так: «В этом месте, похоже, проблема с безопасно­
стью; наверное, ИИ предложил не совсем корректный вариант, давайте испра­
вим этот фрагмент».
В конечном счёте ревью при вайб-кодинге - это возможность продемон­
стрировать преимущества человеческого интеллекта в паре «человек - ИИ».
Именно ревью позволяют выявить потенциальные ошибки и недочёты и повы­
сить качество кода. Они также способствуют обмену знаниями внутри команды,
в результате чего разработчики начинают лучше разбираться как в предметной
области, так и в сфере разработки с помощью ИИ.
222

Часть 111. Доверие и автономия

Код-ревью также можно рассматривать как воплощение концепции «разра­
ботчики как редакторы», предложенной Грантом Гроссом на сайте электронно­
го журнала CIO (https://oreil.ly/INPFV): рецензент выступает в роли редактора
и следит за тем, чтобы код был «отшлифован» и готов к продакшену. Такая роль
полностью соответствует и концепции вайб-кодинга, при котором код генери­
рует ИИ, но последнее слово остаётся за человеком.

Лучшие практические рекомендации по надёжному
развёртыванию
После того как разработчики убедятся в безопасности кода, протестируют его
и обеспечат поддерживаемость, его нужно будет развернуть и обеспечить ста­
бильную работу на этапе эксплуатации (в продакшене).
Разработка с помощью ИИ не меняет базовые принципы развёртывания ПО,
но добавляет нюансы, связанные с высокой скоростью разработки и с опера­
ционной сложностью развёртывания. Если вы хотите получить более полное
представление об основах развёртывания кода, то в этом вам поможет книга Тhе
DevOps Handbook (IТ Revolution Press, 2016) Джина Кима, ДжезаХамбла, Патрика
Дебуа, Джона Уиллиса и Николь Форсгрен (Gene Кim, Jez HumЫe, Patrick Debois,
John Willis, and Nicole Forsgren). В этом авторитетном руководстве разбираются
все связанные с развёртыванием основные темы, от непрерывной интеграции
и конвейеров (пайплайнов) развёртывания до мониторинга, вопросов безопас­
ности и организационных трансформаций. Базовые знания в этой сфере ста­
новятся ещё важнее, когда речь идёт об ускоренной разработке с помощью ИИ,
потому что ускорение разработки убыстряет и все эти процессы эти процессы,
требующие такого же быстрого масштабирования.

Подготовка и собственно развёртывание
При подготовке к развёртыванию стоит ориентироваться на следующие дока­
завшие свою эффективность методы и приёмы.
Автоматизация пайплайна CI/CD
При высокой скорости разработки с помощью ИИ особую роль начинает иг­
рать надёжный пайплайн непрерывной интеграции и непрерывного развёр­
тывания (CI/CD, Continuous integration / Continuous Deploy). Каждый коммит
(со сгенерированным ИИ-кодом или без него) должен собираться, тестиро­
ваться и при необходимости развёртываться через автоматический пайплайн,
Глава 8. Безопасность, поддерживаемость и надёжность

1

223

что снижает риск человеческой ошибки и гарантирует последовательное вы­
полнение всех шагов (тесты, линтер, сканы безопасности). Любой сбой или
неудовлетворительный результат тестов будет сразу же зафиксирован, а ав­
томатизация CI/CD при исправлении допущенных ИИ ошибок позволит бы­
стро вносить изменения в код и развёртывать патчи.
Инфраструктура как код
При проектировании среды развёртывания ориентируйтесь на концеп­
цию «инфраструктура как код» (с использованием таких инструментов, как
Terraform, CloudFormation и другие). Напрямую этот метод не связан с напи­
санием кода с помощью ИИ, но его можно назвать частью надёжного развёр­
тывания. Составлять скрипты для Terraform можно также с помощью ИИ,
но тестировать их нужно так же тщательно, как и любой сгенерированный
ИИ-код; по возможности перед продакшеном стоит протестировать их в пе­
сочнице. Хорошим руководством для этого послужит книга Terraform: Ир &
Running (O'Reilly, 2022) («Terraform: инфраструктура на уровне кода») Евге­
ния Брикмана, в которой подробно описаны как сама концепция «инфра­
структура как код», так и практические приёмы работы с Terraform.
Пошаговое развёртыван.ие с план.ом отката
Разворачивайте приложение поэтапно и предусмотрите план отката. Для на­
чала стоит проверить работу приложения в тестовой среде, затем в виде «ка­
нареечного» релиза, и только потом выпускать его в полноценном рабочем ре­
жиме в продакшен. Так можно будет выявить пропущенные ошибки до того,
как они затронут всех пользователей. Например, новую сгенерированную
ИИ-функцию можно развернуть сначала только для 5% пользователей и от­
слеживать её выполнение (через метрики и логики), проверяя на наличие
ошибок или проблем с производительностью. И только когда вы убедитесь,
что с ней всё в порядке, можно будет развернуть её для всех пользователей.
Всегда имейте план отката, потомучто, несмотря на всетесты и ревью, какие-то
ошибки и недочёты всегда просачиваются в рабочий код. Если с новым релизом
возникли проблемы, будьте готовы вернуть прежнюю стабильную версию. Если
вы пользуетесь средством контейнеризации (например, Kubernetes), для быстро­
го отката сохраняйте предыдущие выпуски. Для бессерверных функций сохра­
няйте активными предыдущие версии, пока не убедитесь в корректности новой.
Настройка н.аблюдаемости
Настройте комплексный мониторинг продакшен-среды с отслеживанием си­
стемных метрик и логов приложений.
224

Часть 111. Доверие и автономия

- Пользуйтесь инструментами для отслеживания ошибок и перехвата
исключений (вроде Sentry). Если сгенерированный ИИ-код вызовет не­
ожиданный сбой в рабочем режиме (например, не был учтён какой-то гра­
ничный случай), вы получите уведомление и сможете всё исправить.
- Пользуйтесь инструментами мониторинга производительности (АРМ,
Application Performance Monitoring) для отслеживания времени отклика,
пропускной способности и использования памяти. Они помогут вам опре­
делить случаи, когда новый код замедляет выполнение или вызывает утеч­
ку памяти.
- Следите за доступностью: например, опрашивайте конечные точки сервиса, чтобы убедиться в их рабочем состоянии. При сбое (возможно, из-за
какого-то непроверенного сценария) должно сработать оповещение, ко­
торое поможет вам оперативно отреагировать.
Сохраняйте бдительность в вопросах безопасности
Проследите за тем, чтобы при развёртывании корректно обрабатывались
секреты вроде АРI-ключей. Например, если ИИ сгенерировал код, кото­
рый ожидает секрет в переменной окружения, настройте этот секрет в CI/CD
или в конфигурации облака, чтобы он случайно не попал в логи или не был
раскрыт. Пользуйтесь инструментами управления секретами, такими как
HashiCorp Vault (HashiCorp Vault предлагает управление секретами, ключами
и другие возможности со множеством интеграций) или AWS Secrets Manager
(https://oreil.ly!LlYX-) (AWS Secrets Manager позволяет безопасно хранить
и обновлять секреты вроде учётных данных базы данных, API-ключей и то­
кенов, а также интегрируется с СI/СD-инструментами вроде GitHub). При ис­
пользовании контейнерных образов сканируйте их на уязвимости.
Стратегии «сине-зелёного развёртывания» и «теневого тестирования»
Для крупных изменений стоит придерживаться так называемой стратегии сине-зелёного развёртывания, которая заключается в настройке двух идентич­
ных рабочих сред: «синей» (для текущей активной версии) и «зелёной» (для
новой версии). Первоначально трафик направляется в синюю среду, а после
настройки и тестирования «зелёной» среды он перенаправляется в неё. При
возникновении проблем с «зелёной» средой трафик можно будет быстро вер­
нуть в «синюю» с минимальными простоями и рисками. Этот метод позволя­
ет протестировать новую версию в полноценной рабочей среде до того, как
она станет единственной активной средой.
В качестве альтернативы, если какое-то конкретное изменение реали­
зованного с помощью ИИ алгоритма считается рискованным или если вы
Глава 8. Безопасность, поддерживаемость и надёжность

225

хотите проверить его работу на реальных данных, но не затрагивая пользова­
телей, можно воспользоваться методом «теневого тестирования». Этот метод
заключается в том, чтобы развернуть новую версию параллельно с текущей
рабочей, чтобы реальные данные подавались на обе версии одновременно,
но для пользователей будут отображаться только результаты текущей вер­
сии. Результаты новой («теневой») версии собираются и сравниваются с ре­
зультатами текущей для оценки её производительности, точности и стабиль­
ности. При удовлетворительных результатах и хорошей производительности
«теневая» версия становится новой активной версией.

Методы дальнейшей поддержки ПО
После развёртывания (деплоя) поддерживать стабильность и надёжность систе­
мы помогут следующие методы.
Создание руководства по эксплуатации («ранбука»)
Подготовьте для команды руководство по эксплуатации ПО («ранбук»,
runbook), в котором будут описаны особенности работы участков кода, на­
писанных ИИ, например: «Этот сервис пользуется сгенерированной ИИ­
моделью; если вывод модели кажется некорректным, попробуйте переза­
пустить сервис или проверить версию модели». Пример другого совета
в руководстве: «Для повышения производительности функция У активно
использует кеширование; при проблемах с производительностью проверь­
те коэффициент попаданий в кеш». Иными словами, документируйте все
неочевидные операционные нюансы. Если ИИ добавил какую-то зависи­
мость (например, от временных файлов), укажите в руководстве эту осо­
бенность, чтобы рабочая команда знала, что стоит мониторить дисковое
пространство и т. д.
Тесты во время эксплуатации
Помимо тестирования на этапе разработки и в процессе развёртывания не­
которые компании проводят тесты во время эксплуатации (такая практика
иногда называется TiP, то есть Testing in Production - «тестирование в про­
дакшене»). Для безопасности тесты ограничиваются небольшими экспери ментами. Так, например, можно воспользоваться флагами для включения
сгенерированного ИИ-функционала только для небольшой группы пользова­
телей, чтобы отслеживать возможные ошибки. Такая практика похожа на ме­
тод «канареечного» релиза, но позволяет более точечно тестировать отдель­
ные функции.
226

Часть 111. Доверие и автономия

Регулярный аудит
Регулярно проводите аудит безопасности и производительности кодовой
базы, особенно по мере увеличения объёма кода, сгенерированного с по­
мощью ИИ. Это похоже на управление техническим долгом; такие провер­
ки помогают выявить решения, которые поначалу считались приемлемыми,
но со временем могут стать проблемными из-за роста масштаба или измене­
ния контекста. Следите также за «дрейфом», то есть отклонением реального
состояния от объявленного; если сгенерированный ИИ-код создаёт SQL-за­
просы, проследите за тем, чтобы после миграции они оставались корректны­
ми, причём удостоверьтесь в этом ещё до того, как новая версия начнёт при­
нимать пользовательский трафик.
Контроль со стороны человека
Здесь мы вновь возвращаемся к одной из главных тем книги: автоматизация
должна находиться под контролем человека. ИИ может помогать писать код,
но он не устранит проблему в рабочей среде в два часа ночи. Делать это дол­
жен специалист, понимающий, как работает вся система. Со временем мож­
но привлекать ИИ для вспомогательных задач, таких как анализ логов (такой
функционал уже появляется в некоторых инструментах), но окончательное
решение о внесении исправлений должен принимать человек.
Обучение на ошибках
Ничто не бывает безупречным. Если через все защитные механизмы в окон­
чательный код всё же проникла какая-то ошибка, проведите разбор инци­
дента (postmortem). Выясните, связана ли ошибка с тем, что в написании кода
использовался ИИ (например: «В этом фрагменте мы доверились сгенери­
рованному ИИ-коду, и он не справился со сценарием Х»), после чего обно­
вите все соответствующие процессы и тесты, чтобы предотвратить подоб­
ные проблемы в будущем. Регулярный анализ кода напрямую повышает его
надёжность.
Разумеется, понятие надёжности не ограничивается стабильностью кода
и подразумевает также надёжность инфраструктуры и операционных процес­
сов, связанных с этим кодом. ИИ в основном помогает на уровне кода, но общую
надёжность системы обеспечивают методы её эксплуатации (которые частично
тоже можно внедрять и поддерживать с помощью ИИ).
В целом к продукту, созданному и развёрнутому с активным участием
ИИ, следует относиться так же, как к любому другому высококачественному
ПО: тщательно проверяйте его при помощи тестов, развёртывайте поэтапно,
Глава 8. Безопасность, поддерживаемость и надёжность

227

осуществляйте мониторинг и предусматривайте возможность быстрого отка­
та изменений. Так как ИИ позволяет менять код быстрее, то и развёртывать
его можно чаще, что допустимо при наличии хорошо настроенного конвейера
CI/CD). На практике небольшие развёртывания (https://oreil.ly!AТjYo) снижают
риски (https:!loreil.ly!YSuDn) по сравнению с редкими крупными релизами. Если
каждое отдельное изменение по объёму невелико, то возникающие при обнов­
лении проблемы выявить и исправить проще. В случае же сбоя откат небольшо­
го изменения также выполняется быстрее и с меньшими последствиями. Такой
метод противоположен методу крупных и редких релизов, когда множество из­
менений объединяются в одном выпуске, что затрудняет поиск причин проблем
и увеличивает потенциальный ущерб от неудачного развёртывания.
Следуя этим рекомендациям, вы можете быть уверены, что даже если суще­
ственная часть кода сгенерирована машиной, то в целом система для пользова­
телей будет надёжной. Автоматизированное тестирование, аккуратное развёр­
тывание и мониторинг выявляют все проблемы и уязвимости, которые могли
остаться от предыдущих этапов. Так удаётся воспользоваться всеми предостав­
ляемыми ИИ преимуществами в скорости и продуктивности без ущерба дове­
рию к ПО во время эксплуатации (в продакшене).

Итоги и дальнейшие шаги
Подводя итоги, можно сказать, что вайб-кодинг не отменяет требований к инже­
нерной дисциплине и увеличивает продуктивность программистов-инженеров,
придерживающихся строгих принципов. В связи с этим как нельзя уместнее зву­
чит русская пословица: «Доверяй, но проверяй». ИИ можно доверить рутинную
работу, но всё без исключения им созданное нужно проверять с помощью ин­
струментов и человеческой экспертизы.
Безопасность и надёжность - лишь одно измерение ответственной разра­
ботки; другое измерение - этика. Разработка с использованием ИИ поднима­
ет важные вопросы, связанные с интеллектуальной собственностью, предвзятостью, влиянием на рынок труда разработчиков и многие другие. Эти и более
широкие этические аспекты рассматриваются в главе 9. Что значит «ответствен­
ное» и «справедливое» использование ИИ-инструментов? Как быть с лицензи­
рованием сгенерированного ИИ-кода и как «этично» пользоваться в своей ра­
боте моделями и запросами?

ГЛАВА 9

Этические вопросы вайб-кодинга
Разработка с помощью ИИ постепенно становится всё более привычной, но вме­
сте с тем всё большее внимание уделяется связанным с ним этическим вопросам.
В этой главе мы ненадолго отойдём от технических деталей и рассмотрим вайб­
кодинг через призму этики. Да, все эти новые методы повышают эффективность
работы, но их нужно внедрять ответственно - так, чтобы они приносили поль­
зу как отдельным людям, так и обществу в целом.
Для начала я рассмотрю вопросы интеллектуальной собственности. Кому
именно принадлежит сгенерированный ИИ-код и допустимо ли пользовать­
ся результатами работы ИИ, созданными на основе открытого кода, без указа­
ния авторства? Далее я порассуждаю о том, что такое предвзятость и справед­
ливость. Особое внимание уделяется прозрачности. Должны ли разработчики
указывать на то, какие фрагменты кодовой базы были сгенерированы ИИ и ка­
кую ответственность должны нести команды за качество кода и ошибки в нём?
Затем излагаются принципы ответственной разработки при использовании
ИИ, от соблюдения принципов прозрачности и ответственности до недопустимости использования чувствительных данных в запросах; здесь же затрагивает­
ся тема доступности и инклюзивности. В конце главы перечисляются практиче­
ские рекомендации по ответственному использованию ИИ-инструментов.

&:

1

Юридическое замечание
В следующем разделе затрагиваются сложные юридические
темы, в первую очередь касающиеся законодательства об ав­
торском праве и интеллектуальной собственности, преимуще­
ственно с точки зрения США. Законы в разных странах мира
отличаются, как и отличаются их толкования, и особенно это
заметно в связи с такой бурно развивающейся областью, как
нейросети и искусственный интеллект. Вся приведённая да­
лее информация предназначена только для образователь­
ных целей и не должна рассматриваться как юридическая
консультация. Если у вас возникли какие-то опасения по по­
воду авторства или лицензирования созданного вами или
Глава 9. Этические вопросы вайб-кодинга

229

сгенерированного ИИ-кода, то перед тем, как принять реше­
ние, вам следует проконсультироваться с квалифицирован­
ным юристом, специализирующимся на интеллектуальной
собственности.

Размышления по поводу интеллектуальной
собственности
Кому принадлежит сгенерированный ИИ-код? И можно ли им пользоваться, со­
блюдая лицензии и авторские права материала, на котором обучалась модель
ИИ? Такие модели, как ChatGPT, обучались на огромных массивах кода из Ин­
тернета, в том числе на репозиториях с открытым исходным кодом, распро­
страняемым по разным лицензиям (МIТ, GPL, Apache и т. д.). Если ИИ сгене­
рирует фрагмент кода, очень похожий (https://oreil.ly!IЗHxТ) на фрагмент кода
из проекта с лицензией GPL (или даже идентичный ему), то использование та­
кого фрагмента в проприетарной базе по неосторожности может привести к на­
рушению условий лицензии GPL, которая обычно требует, чтобы такой код на­
ходился в открытом доступе (https:!/oreil.ly!Binfc).
Согласно нормам программного обеспечения с открытым исходным кодом
(ореп source) и согласно общим принципам авторского права, небольшие фраг­
менты из нескольких строк не попадают под защиту авторского права, если им
недостаёт оригинальности для признания самостоятельным творческим про­
изведением или же если их использование сочтено слишком незначительным
для правовой защиты (так называемое правило de minimis). Но любой объём­
ный фрагмент кода, отражающий уникальное авторское решение, скорее все­
го, будет защищён авторским правом. Важно понимать, что понятие «свобод­
ное» и «с открытым исходным кодом» (ореп source) не означает «находящееся
в общественном достоянии». Авторское право на любой продукт творческого
труда, включая программный код, исходно принадлежит его создателю, просто
лицензии на «опенсорсное» ПО явно предоставляют разрешение на свободное
использование продукта, которое в противном случае было бы ограничено нор­
мами авторского права.
Если вы хотите больше узнать о нормах и практике «опенсорсного» ПО,
то в этом вам помогут следующие ресурсы.
«Инициатива открытого исходного кода», Ореп Source Initiative (OSI)
Организация OSI (https://oreil.ly!hmJVN) формулирует определения, от­
носящиеся к ПО с открытым исходным кодом, и распространяет такое
230 1

Часть 111. Доверие и автономия

программное обеспечение по лицензиям, соответствующим заявленным ор­
ганизацией критериям.
«Фонд свободного ПО», Free Software Foundation (FSF)
Фонд свободного ПО, или FSF (https:l!fsforg), пропагандирует концепцию
«свободного программного обеспечения» (которая во многом пересекает­
ся с принципами ореп source) и курирует такие лицензии, как GNU General
PuЬlic License (GPL).
Документация конкретных проектов
Отдельные проекты ПО с открытым исходным кодом обычно включают
в свои пакеты файлы LICENSE, README и руководства CONТRIBUТING,
в которых подробно описываются условия использования конкретного про­
екта и внесения в него изменений.
Ресурсы сообществ и юридические ресурсы
Такие сайты, как GitHub, предлагают обширную документацию и обсужде­
ния по вопросам практики открытого исходного кода. Помимо этого, цен­
ные материалы по вопросам соблюдения лицензий на «открытый исходный
код» и связанным с ними правовым аспектом предлагают такие организации,
как Linux Foundation, а также специализированные юридические и справоч­
ные сайты.

Вопрос о том, подпадает ли использование небольших фрагментов кода под
концепцию «добросовестного использования» (https://oreil.ly!dOZKB) (в США
это называется fair use, а во многих других юрисдикциях - fair dealing), до­
вольно сложен и в очень большой степени зависит от конкретных обстоя­
тельств. Понятие «добросовестного использования» (fair use) (https://oreil.lyl
EwrJ2) допускает ограниченное использование защищённых авторским пра­
вом материалов без разрешения правообладателя - например, для критики,
в комментариях, в новостях, для обучения, в научной или исследовательской
деятельности.
При определении «добросовестного использования» суды США, как прави­
ло, учитывают четыре следующих фактора:
- Цель (https://oreil.ly/lTESB) и способ использования (коммерческое или
некоммерческое; переделка или копия).
- Характер произведения, защищённого авторским правом (высокая сте­
пень творческой оригинальности или просто констатация факта).
Глава 9. Этические вопросы вайб-кодинга

1 231

- Объём и значимость использованной части по отношению к произведе­
нию в целом.
- Влияние использования на потенциальный рынок или ценность произ­
ведения.
В целом копирование очень небольших функциональных фрагментов кода например, для обеспечения совместимости или доступа к неохраняемым автор­
ским правом идеям - считается добросовестным использованием, особенно
если код переделывается, но такая практика до конца не урегулирована и её нель­
зя назвать устоявшейся. Не существует универсально признанного количества
строк, чтобы использование кода однозначно считалось «добросовестным» или
«незначительным» (de minimis). Безопаснее всего обычно либо получить разре­
шение, либо переработать код с переосмыслением лежащих в его основе идей.
Верховный суд США, рассматривая дело Google LLC v. Oracle America, !пс., в кон­
тексте использования программных API, признал повторную реализацию кода
Java API компанией Google добросовестным использованием, но это было кон­
кретное решение относительно сложного и узкоспециализированного случая,
относящегося именно к API, а не к программному коду как таковому. Соглас­
но общепринятому толкованию, авторское право защищает конкретную фор­
му выражения идеи, но не саму идею, процедуру или метод функционирования.
Разработчик, использующий ИИ, как правило, считается «автором» в том
смысле, что ИИ выступает инструментом, аналогичным компилятору или тек­
стовому редактору. Соответственно, если код создаётся в рабочем контексте,
владельцем кода, созданного разработчиком с использованием такого инстру­
мента, вероятнее всего, будет считаться компания разработчика, с учётом усло­
вий обслуживания (Terms ofService, ToS) ИИ-инструмента и принципов защиты
интеллектуальной собственности. Но условия обслуживания (ToS) инстру­
ментов при этом имеют принципиальное значение. В большинстве ToS права
на сгенерированный результат предоставляются пользователю. Так, в услови­
ях OpenAI прямо указано: «Вы владеете результатами, которые создаёте с помо­
щью GPT-4, включая код».
Тем не менее само понятие «владение)) или «авторство)) в отношении кода
предусматривает ряд толкований. Обычно это означает, что провайдер ИИ
не претендует на право собственности в отношении того, что пользователи со­
здают с помощью инструментов провайдера. Но при этом предполагается, что
у пользователя есть права на предоставляемые им входные данные, а права на ре­
зультат работы ИИ не предоставляются автоматически, и этот результат не осво­
бождается автоматически от претензий со стороны третьих сторон в сфере интеллектуальной собственности. Иными словами, если вы предоставляете свой
232

Часть 111. Доверие и автономия

собственный оригинальный код для модификации или расширения, то резуль­
тат, скорее всего, принадлежит вам (или вашему работодателю) - опять же, в за­
висимости от того, как ИИ его обрабатывает и какие элементы он заимствует
из обучающих данных. Но если вы для исправления или переделки вводите чу­
жой код, защищённый авторским правом, то результат может рассматриваться
как производное произведение на основе кода, принадлежащего третьей сторо­
не (https://oreil.ly!mBPyq).
В США и многих других странах юридический статус результатов работы ИИ
остаётся не до конца ясным, и продолжаются споры о том, считать ли «производ­
ным произведением» код, который существенно похож на обучающие данные
или создан на основе чужого, защищённого авторским правом материала. По­
этому ни в коем случае не передавайте ИИ крупные фрагменты чужого кода, если
у вас нет на него прав или надлежащей лицензии. Сгенерированный на их осно­
ве результат могут признать производным произведением, и тогда этот резуль­
тат унаследует лицензионные ограничения исходного кода (https:/!oreil.ly/O4ktq).
Из-за такой неопределённости безопаснее всего относиться к сгенерирован­
ному ИИ-коду как к произведению с неуказанным лицензионным статусом.
Используйте его, только если полностью уверены, что он не нарушает чужие
авторские права и если вы готовы выполнить все требования лицензии «открытого исходного кода». Что касается статуса кода, созданного собственно ИИ,
то, согласно заявлению Бюро по авторским правам США (https://oreil.ly!Y0PYG),
произведения, созданные исключительно ИИ без значительного участия чело­
века, не подлежат защите авторским правом. Защите авторского права подле­
жат только существенно или творчески переработанные материалы (https:!!oreil.
ly!NVЗGl), но собственно сгенерированные ИИ-элементы авторским правом
не охраняются. Поэтому разумнее всего исходить из того, что либо код, полно­
стью созданный ИИ, не охраняется вовсе, либо охраняется только та его часть,
что подверглась творческой переработке со стороны человека.
И это вовсе не надуманная гипотетическая проблема. По этому поводу уже
ведутся юридические споры. Наглядный пример - коллективный иск Doe v.
GitHub, Inc. (https:llgithubcopilotlitigation.com), поданный против GitHub, Microsoft
и OpenAI, в котором утверждалось, что GitHub Copilot генерирует код, слиш­
ком близкий к лицензированному открытому исходному коду, без надлежаще­
го указания авторства и без соблюдения условий лицензий. Несмотря на то что
часть требований по этому делу была отклонена или находится на стадии обжа­
лования (по состоянию на середину 2025 года разбирательство продолжается,
включая апелляцию в Девятый окружной суд США по требованиям, связанным
с DMCA, а также оставшихся исков о нарушении договора), сам процесс под­
чёркивает реальную опасность: ИИ действительно иногда воспроизводит или
Глава 9: Этические вопросы вайб-кодинга

233

в очень большой степени повторяет защищённый авторским правом код из сво­
их обучающих данных 6•
В проведённом самим GitHub ещё до этого разбирательства исследовании
(но по-прежнему актуальном и впоследствии подтверждённом) (https:!!oreil.ly!
fFUUd) отмечалось, что Copilot иногда предлагал варианты кода, совпадающие
с обучающими данными, а в редких случаях выдавал и копии более длинных
фрагментов. Конечно, большинство ИИ-инструментов проектируются так, что­
бы не допускать прямого и масштабного копирования узнаваемого кода, если
только это не указывать специально в запросах или речь не идёт об общеиз­
вестных стандартных алгоритмах, но риск такого копирования всё же остаётся.
Кроме того, проблема не ограничивается открытым исходным кодом. Писате­
ли, художники и медиакомпании подали множество исков о том, что их полно­
стью защищённая авторским правом и находящаяся в частной собственности
интеллектуальная собственность использовалась для обучения больших язы­
ковых моделей и других генеративных ИИ-систем без разрешения или без ка­
кой-либо компенсации. Проблема с проприетарным кодом заключается в том,
что, в отличие от открытого, он часто недоступен публично и конечному поль­
зователю сложнее проверить, не является ли результат работы ИИ случайно по­
хожим на такой закрытый код.
В любом случае с этической и практической точек зрения разумнее всего дей­
ствовать так, как будто вы полностью несёте ответственность за использова­
ние любого сгенерированного ИИ-кода. Перед тем как включать такой код в свой
проект, тщательно протестируйте и проанализируйте его, а также убедитесь, что
его использование соответствует всем применимым лицензиям и законам об ав­
торском праве.

Что делать при получении сомнительного результата
Если результат работы ИИ выглядит как дословная или почти дословная копия
известного кода (особенно если в нём присутствуют характерные комментарии
или имена авторов), проявляйте крайнюю осторожность. Попытайтесь прове­
рить его на сходство с помощью инструментов для выявления плагиата или вы­
полнить поиск в Интернете по уникальным строкам.
Руководствуйтесь принципом «Сомневаешься - не используй». Либо отка­
житесь от использования такого кода, либо убедитесь, что он распространяется
6

234

Информацию по таким судебным делам часто можно найти в судебных реестрах (court
dockets) (https://oreil.ly!BdDiV), например в реестре Окружного суда США по Северно­
му округу Калифорнии или Девятого окружного апелляционного суда, а также в юриди­
ческих новостных изданиях и с помощью специализированных трекеров судебных дел
(https://oreil. ly!AZrc-).
Часть 111. Доверие и автономия

по совместимой лицензии, и при необходимости указывайте его источник. На­
пример, если Copilot выдал знакомую вам по Stack Overflow или какому-либо
открытому проекту реализацию известного алгоритма, укажите её источник
или перепишите код самостоятельно, пользуясь решением ИИ как ориентиром,
но не цитируя его дословно.
Если вы подозреваете, что результат совпадает с кодом из какой-либо суще­
ствующей библиотеки, попробуйте подключить эту библиотеку (с соблюдением
лицензии). Можно также дать ИИ прямую инструкцию:
Перепиши этот код в оригинальной реализации, а не копируй его из биб­
лиотеки.
ИИ постарается сгенерировать более уникальное решение. (Конечно, ника­
ких гарантий, что он не будет отталкиваться от существующего кода, нет, но он
хотя бы постарается не копировать напрямую.)
С этической точки зрения также недопустимо пользоваться ИИ для предна­
меренного удаления информации об авторстве. Например, будет неэтично с по­
мощью ИИ скопировать код из Stack Overflow без указания источника, чтобы
обойти правило об обязательном указании авторства. Такая практика подрыва­
ет доверие к экосистеме открытых знаний. Лучше всегда по возможности ука­
зывать авторство материала. В зависимости от ситуации варианты бывают сле­
дующими:
- Если ИИ написал комментарий к коду с указанием автора (например, ско­
пировал фрагмент с комментарием «John Doe 2018» ), этот комментарий
нужно сохранить или переместить в отдельный раздел с полной ссылкой.
Так вы проявите уважение к труду автора этого фрагмента.
- Если ИИ предложил решение, которое, по вашему мнению, точно соот­
ветствует известному алгоритму или известному фрагменту кода, укажите авторство - как вы сделали бы, если бы нашли такой фрагмент само­
стоятельно.
- Если ИИ создал нечто похожее на «творческое» решение (например, ре­
ализовал уникальный подход или написал уникальный текст для доку­
ментации), отметьте его вклад. Пусть у ИИ и нет прав, но так вы посту­
пите в согласии с принципами прозрачности (и заодно признаете ценный
вклад технологий).
Некоторые лицензии с открытым исходным кодом (например, МIТ) доста­
точно либеральны и требуют лишь указания авторства скопированного кода.
Глава 9. Этические вопросы вайб-кодинга

235

Другие же лицензии, такие как GPL или AGPL, требуют, чтобы весь ваш код
с включением скопированного фрагмента распространялся открыто, что неже­
лательно для частных и закрытых проектов.
Короче говоря, если есть подозрение, что ИИ выдал код, проблемный с точки
зрения интеллектуальной собственности, то либо откажитесь от его использо­
вания, либо переработайте его так, чтобы гарантировать соблюдение всех воз­
можных лицензионных требований.

Серые зоны
Даже сейчас, пока я пишу эти строки, ИИ-инструменты продолжают порождать
новые вопросы об интеллектуальной собственности, авторском праве и этике.
Например:
- Если в процессе вайб-кодинга использовать ИИ не только для генерации
кода, но и для генерации текста документации, конфигурационных фай­
лов, изображений и других материалов, то схожие вопросы об интеллек­
туальной собственности возникают и в их отношении. Например, кому
принадлежат права на значок (иконку), сгенерированный с помощью ИИ,
обученного на защищённых авторским правом изображениях?
- Если значительная часть кода продукта сгенерирована ИИ, то должны ли
получать признание авторы кода, на котором обучался ИИ?
- Вправе ли какой-то автор утверждать, что сгенерированный ИИ с вашим
участием код нарушает его авторские права, потому что походит на код,
написанный этим автором? Если код достаточно длинный и многие его
фрагменты совпадают с авторским кодом, то возможно, нужно будет про­
верить его на сходство.
В последнее время распространяется мнение, что разработчикам ИИ, воз­
можно, придётся внедрять фильтры с учётом лицензий или предоставлять от­
дельным компаниям право вето на использование кода этих компаний для
обучения ИИ. Пока правовая база не устоялась, разработчикам ПО лучше пере­
страховываться и стараться не нарушать права третьих лиц.
На решение всех юридических вопросов потребуется время, а до тех пор,
пока все они не решены, мы должны руководствоваться принципами честно­
сти и уважения к интеллектуальной собственности. Если ИИ воспользовался
известным алгоритмом из опубликованной статьи, указывайте в комментариях
ссылку на эту статью. Если ИИ прописал вспомогательную функцию, известную
вам из источников с открытым исходным кодом, укажите исходный проект. Если
236

Часть 111. Доверие и автономия

вы точно знаете, где уже использовался такой код, то лучше перестраховаться
и указать его источник. Это хороший практический совет, способствующий по­
вышению прозрачности.
Не забывайте, что все свои знания ИИ получил благодаря тысячам разработ­
чиков, публично поделившихся своим кодом. С этической точки зрения инду­
стрия разработки ПО обязана проявить уважение всему сообществу програм­
мистов, ко всем лицензиям и ко всем нормам, касающимся распространения
открытого исходного кода. Признавайте труд других и не злоупотребляйте воз­
можностью пользоваться результатами чуждого труда без такого признания
только потому, что «этот код написал не я, а ИИ».

Прозрачность и признание авторства
Под прозрачностью понимается открытое указание на то, что в процессе разра­
ботки и в оформлении результатов работы принимал участие ИИ, а под призна­
нием авторства (атрибуцией) подразумевается корректное указание источни­
ков кода, на основе которых ИИ сгенерировал свой код.
Прозрачность важна с точки зрения ответственности за код. Если сгенери­
рованный ИИ код приводит к ошибкам или уязвимостям в сфере безопасно­
сти, то примечание «этот код был предложен ИИ» поможет при анализе причин
таких ошибок и уязвимостей; разработчикам, возможно, придётся переформу­
лировать неоднозначный запрос, чтобы улучшить результат. В комментариях
к коду, в файле README или в проектной документации иногда достаточно про­
сто пометок вроде: «Этот проект создавался с использованием ИИ-инструмен­
тов, таких как ChatGPT ». Иногда стоит уточнять, например: «Добавлена функ­
ция для разбора CSV (сгенерирована с помощью ChatGPT, затем доработана)».
Такие комментарии похожи на упоминания использованных фреймворков или
библиотек.
Прозрачность также важна и с точки зрения доверия. Заинтересованные сто­
роны (ваша команда, клиенты, конечные пользователи или отраслевые регулято­
ры), возможно, захотят узнать, каким именно образом разрабатывалось и про­
верялось ваше программное обеспечение. Мнения в этой сфере бывают разные;
кто-то переоценивает надёжность сгенерированного ИИ-кода, кто-то, напротив,
недооценивает его. Прозрачность позволяет вести осмысленный разговор о ка­
честве и надёжности: «Да, мы использовали ИИ, но тщательно протестировали
весь окончательный код» или «Эта часть проекта была очень сложной, и с на­
чальной реализацией нам помог ИИ, но потом мы проверили и верифицирова­
ли код вручную».
Глава 9. Этические вопросы вайб-кодинга 1 237

Во многих академических контекстах также ожидается или даже требуется
указание на авторство (атрибуция). Некоторые проекты с открытым исходным
кодом ограничивают или даже вовсе запрещают вклад ИИ из-за рисков, свя­
занных с правами на интеллектуальную собственность, поэтому перед тем, как
пользоваться помощью ИИ, стоит проверить правила для таких проектов. Часто
в таких проектах нужно указывать, что тот или иной фрагмент кода был создан
при участии ИИ - так, например, ответственные за патч лица будут вниматель­
нее относиться к вопросам лицензирования, связанным с этим кодом.
Более того, в некоторых строго регулируемых отраслях от поставщиков ПО
в целях аудита требуют явно указывать все случаи использования ИИ. Закон ЕС
об искусственном интеллекте (ЕИ AI Act) предписывает соблюдать нормы про­
зрачности в случаях автоматизированного принятия решений, затрагивающих
людей (например, для алгоритмов оценки кредитоспособности). Если с помо­
щью вайб-кодинга создаются подобные системы, то информирование пользова­
телей о том, что «рекомендации формируются автоматически и могут отражать
закономерности в данных», становится правовой и этической необходимостью.
Точно так же, если продукт передаёт пользовательские или проприетарные
данные (например, предоставленные пользователями примеры кода) в ИИ-мо­
дель для её дообучения и улучшения анализа, то в политике конфиденциально­
сти, скорее всего, нужно будет указать, что полученные с разрешения пользова­
тельские данные могут использоваться для улучшения ИИ-моделей (как всегда,
по всем юридическим вопросам стоит консультироваться с юристом). Здесь про­
зрачность напрямую пересекается с вопросами конфиденциальности.
В целом, с этической точки зрения следует явно указывать все использованные для создания ПО инструменты и источники. Если 30% кода было написано
с помощью Copilot, разумно будет упомянуть это в документации или во вну­
тренней переписке - не для того чтобы принизить свою роль, а для того чтобы
честно описать весь процесс.
Некоторые разработчики опасаются, что если они признают вклад ИИ, то их
обвинят в читерстве. По мере распространения вайб-кодинга и становления
его привычной практикой такие опасения должны снижаться; возможно, скоро
будет необычной ситуация, когда какой-то разработчик вообще не пользуется
доступной ему версией ИИ. Нужно рассматривать ИИ-инструменты как вспо­
могательные для работы средства, такие же как сайт Stack Overflow или интег­
рированная среда разработки (IDE), использование которых сейчас никто не на­
зывает читерством.
С другой стороны, избыточное упоминание ИИ может породить ненуж­
ные опасения. Если сказать клиенту, что для создания продукта разработчи­
ки воспользовались помощью ИИ, то у клиента могут возникнуть сомнения
238

Часть 111. Доверие и автономия

в безопасности продукта (пусть даже основанные на заблуждениях). Важна
именно формулировка, и в данном случае было бы уместно сказать: «Мы созда­
ли этот продукт с помощью современных инструментов для ускорения рабо­
ты, но весь сгенерированный ИИ-код был тщательно проверен и протестирован
в соответствии с нашими стандартами качества».
В итоге прозрачность и признание роли ИИ способствуют установлению
доверия между клиентами и разработчиками, благодаря чему поддерживают­
ся ценности всего сообщества. Нужно просто признавать вклад людей и чест­
но говорить, что какая-то часть кода создавалась при содействии ИИ. Взять для
примера картину - её ценность не уменьшится от того, что художник перечис­
лит использованные инструменты и источники вдохновения - их упоминание
лишь расширит контекст. Если вы, как и я, хотите, чтобы вайб-кодинг получил
широкое признание, важно открыто говорить об использовании ИИ и о том, как
минимизируются связанные с ним риски.

Предвзятость (дискриминация) и справедливость
К этому моменту вы уже наверняка понимаете, что ИИ-модели выдают ответы
на основании данных, на которых они обучались. Если в этих данных содержа­
лись какие-то «перекосы» («смещения», Ьiases) или же если они отражали ка­
кое-то предвзятое мнение, модели могут выдавать предвзятые ответы.
Вы можете спросить: «Как вообще код может отражать какую-то предвзя­
тость или дискриминацию? Это же не LLM, принимающая решения о найме ра­
ботника на основании его возраста, расы или пола». Однако предвзятое мнение
может проникать в код разными неявными способами.
- Код часто отражает неявные предубеждения его создателей. В текстах, ге­
нерируемых ИИ для пользовательского интерфейса или для «контента»,
могут содержаться присутствующие в обучающих данных культурные
предрассудки или неуместная лексика. Так, например, созданный компа­
нией Microsoft ещё в 2016 году чат-бот Тау (https://oreil.ly!d8wx0) всего че­
рез несколько часов после запуска на основании публикаций пользовате­
лей соцсетей начал воспроизводить расистские и женоненавистнические
высказывания.
- ИИ может ориентироваться на какие-то конкретные культурные нор­
мы, например на стиль жизни представителей среднего класса Север­
ной Америки (подразумевая обязательное наличие автомобиля или до­
ступ к определённым технологиям). Показательным примером в этом
Глава 9. Этические вопросы вайб-кодинга

239

отношении можно назвать первоначальный релиз приложения Apple
Health в 2014 году (https://oreil.ly/67sZG), в котором отсутствовал трекер
менструального цикла. Это серьёзное упущение, вероятно, было связано
с недостатком женщин и людей с разными точками зрения в команде раз­
работки. Также ИИ-модель в примерах кода, в комментариях или в синте­
тических данных может постоянно использовать местоимения мужского
рода, тем самым отражая гендерную предвзятость.
- Хорошо известно, что репозитории кода и вся экосистема разработки
программного обеспечения в целом отражают западный взгляд на жизнь
и ориентированы преимущественно на англоязычную аудиторию. Об­
ученный на таких репозиториях ИИ может упускать из виду важные ас­
пекты локализации и не обеспечивать корректную поддержку Unicode
и символов (для языков вроде китайского, японского, корейского, араб­
ского, хинди и многих других, использующих свои алфавиты или систе­
мы письменности). Кроме того, ИИ может подбирать только английские
слова для имён переменных и типов. Следить за соответствием кода мест­
ным практикам должны разработчики.
- При написании кода следует с особым вниманием относиться к перемен­
ным, связанным с расой, полом, возрастом и прочими личными аспек­
тами. У ИИ нет врождённого понимания морального или правового кон­
текста, так что, если он генерирует какие-то данные, разработчикам нужно
следить за тем, чтобы в этих данных были в равной степени отражены все
категории возможных пользователей.
Помимо собственно кода, модели могут воспроизводить смещение данных
в конкретной предметной области. Представим для примера, что ИИ поручи­
ли написать алгоритм для расчёта кредитного рейтинга при выдаче займов. Из­
вестно, что многие исторические документы в США из этой сферы отражают
расовые предрассудки и различные распространённые ранее практики дискриминации, которые привели к долгосрочным последствиям и повлияли на жизни
огромного количества людей, особенно афроамериканцев и других маргинали зированных групп. Подробно вопрос влияния государства на сегрегацию в Аме­
рике освещает Ричард Ротстейн в своей книге «Цвет закона>> (Richard Rothstein,
Тhе Color ofLaw, Economic Policy Institute, 2017).
Если обучающие данные отражают такие исторические предубеждения,
то ИИ может включить в свой код дискриминационные переменные, такие
как, например, почтовые индексы районов, в которые заставляли переселять­
ся чернокожих американцев или из которых их принуждали выселяться. Бы­
вают и другие нейтральные на первый взгляд данные, соотносимые с весьма
240

Часть 111. Доверие и автономия

чувствительными темами. Если не проследить за этим вопросом, ИИ может
сгенерировать код, из-за которого банки будут принимать несправедливые ре­
шения о кредите, воспроизводя историческое неравенство и напрямую влияя
на жизнь реальных людей. Аналогичные проблемы возникают и в других обла­
стях, например в прогностических алгоритмах для полиции, когда исторические
данные об арестах (сами по себе потенциально предвзятые) приводят к тому,
что ИИ-системы в качестве подозреваемых непропорционально часто выделяют представителей определённых сообществ (https://oreil.ly!H4rmr).
Точно так же нужно следить за тем, чтобы какие-то предвзятые ( «смещён­
ные») данные не отражались в работе специализированных моделей (напри­
мер, ИИ-ассистента для разработки медицинского программного обеспечения).
Так, некоторые медицинские рекомендации в прошлом основывались на иссле­
дованиях, в которых преобладали испытуемые мужского пола, что приводило
к ошибочным диагнозам или к менее эффективному лечению для женщин. Ко­
гда ИИ предлагает какой-то фрагмент кода или решение для медицинской ди агностики, разработчик должен отдельно проверить их на такую возможную
предвзятость.
В последнее время появляются инструменты для обнаружения такого сме­
щения в ответах ИИ, хотя их чаще используют для GРТ-моделей, генерирующих
текстовый контент. Сами провайдеры ИИ также пытаются фильтровать откро­
венные предвзятые или «токсичные» высказывания. ИИ-ассистенты по напи­
санию кода редко отражают какую-то предвзятость, но всё равно хорошо, что
и для них существуют свои фильтры. Во многие ИИ-инструменты встраивает­
ся механизм этических ограничений, и при попытке заставить модель сгенерировать вредоносное ПО или алгоритмы с отражением дискриминации она от­
кажется это делать. Не стоит пытаться обходить такие фильтры ради получения
неэтичных результатов.
Существуют и другие способы распознавания «смещения данных» и сниже­
ния их влияния на разных этапах процесса разработки. К ним, в частности, от­
носятся следующие методы.
Тестирование на разных примерах
Если ИИ генерирует пользовательские интерфейсы или логику работы с дан­
ными, касающимися людей, стоит проверять их на разных входных данных.
Например, если сгенерированная ИИ форма авторизации содержит поля
«Имя» и «Фамилия», проверьте, допускает ли она наличие одного лишь име­
ни, как это принято в некоторых культурах. Если ИИ генерирует примеры
имён пользователей и все они выглядят как «Джон Смит», постарайтесь до­
бавить в примеры больше разнообразия.
Глава 9. Этические вопросы вайб-кодинга

241

Формулирование запросов с учётом инклюзивности
Можно явно указать ИИ соблюдать нейтральность или предусматривать ин­
клюзивность, например: «Сгенерируй примеры с именами из разных куль­
тур». Если модель постоянно обращается к пользователю в мужском роде,
можно задать примерно такой запрос:
В комментариях к коду избегай гендерно ориентированного языка; исполь­
зуй нейтральные формулировки или местоимение «они» вместо «он» или
«она».
Также следует с осторожностью относиться к генерируемым шуткам или
примерам, которые могут оказаться культурно неприемлемыми - в таких
случаях полезно попросить придерживаться профессионального тона. ИИ,
как правило, выполняет такие указания. У него нет собственной «повест­
ки» - он лишь воспроизводит то, что считает нормой, если не задать ему дру­
гие стандарты. Задавать ему представление о «нормальном» должны имен­
но мы.
Разнообразие в коллективе
Многие этические проблемы легче выявлять в командах с большим культур­
ным и прочим разнообразием. Например, кто-нибудь из разработчиков мо­
жет заметить: «ИИ постоянно выбирает имена переменных вродеfoo!bar, что
допустимо, но в документации все персонажи мужчины». Разнообразие по­
зволяет исправлять проблемы систематически. Если все разработчики про­
исходят из одной и той же среды, им труднее уловить «смещение данных»,
поэтому для разработки и пересмотра правил использования ИИ стоит привлекать представителей недостаточно отражённых групп или хотя бы учитывать их взгляды на жизнь.
В целом, вопросы предвзятости и смещения нужно учитывать, чтобы с по­
мощью инструментов вайб-кодинга создавать код, который корректен и спра­
ведлив по отношению к пользователям любого происхождения и который
не отражал бы (и тем более не усиливал бы) историческую дискриминацию.
Внутри коллектива разработчиков этими инструментами также следует пользо­
ваться справедливо по отношению к коллегами с разным уровнем опыта и раз­
ным жизненным опытом. Этические аспекты влияния ИИ-инструментов на ра­
бочую среду, особенно в отношении младших разработчиков, обсуждаются
в главе 4.

242

Часть 111. Доверие и автономия

Золотые правила ответственного использования ИИ
Объединим многое из того, о чём говорилось выше, и сформулируем общий на­
бор принципов ответственного вайб-кодинга.
1. Всегда оставляйте последнее слово за человеком
Иначе говоря, ИИ никогда не должен работать без надзора. Ответствен­
ный разработчик должен проверять каждую сгенерированную строку
кода и принимать решение о том, оставлять её или нет. Нельзя использо­
вать сгенерированный ИИ-код без одобрения человека.
2. Несите ответственность за свой код
Если что-то пошло не так, то это не вина ИИ, это вина разработчиков.
Не нужно снимать с себя ответственность и перекладывать её на машину.
Будьте готовы объяснить поведение любого кода, как написанного чело­
веком, так и сгенерированного ИИ. Если вас спрашивают: «Почему код
работает именно так?», нельзя отвечать: «Не знаю, его написал Copilot».
Именно поэтому одно из золотых правил главы 3 гласит: «Не выполняй­
те слияние кода, который не понимаете». Это и есть ответственная инже­
нерная практика.
3. Защищайте конфиденциальность пользователей и запрашивайте их со­
гласие на использование личных данных
С этической точки зрения вы обязаны защищать конфиденциальные данные пользователей и компании. При использовании ИИ-инструментов,
особенно облачных, важно не раскрывать в запросах или в диалогах чув­
ствительные личные данные. Например, при отладке проблемы с поль­
зовательской базой данных не нужно передавать в ChatGPT реальные
записи пользователей - вместо этого воспользуйтесь обезличенными
или синтетическими данными.
Многие современные инструменты позволяют пользователям (или,
по крайней мере, корпоративным клиентам) запрещать использовать
их личные данные для обучения моделей. Если вы работаете в корпо­
ративной среде, то всегда включайте такие настройки или применяй­
те для работы с конфиденциальной информацией локальные решения.
Если какие-то пользовательские данные всё-таки передаются модели
или ИИ взаимодействует с пользователями напрямую (например, че­
рез чат-бот в приложении на базе LLM), обязательно получайте согласие

Глава 9. Этические вопросы вайб-кодинга

243

пользователей и предусмотрите возможность отказа передавать личные
данные. Предупреждение ф ормата «Эта функция задействует ИИ-сервис;
введённые данные будут переданы для обработки» позволяет пользова­
телям принять осознанное решение.
4. Соблюдайте законы и нормативные требования
Следите за правовыми нормативами и юридическими требованиями,
связанными с ИИ. Эта сфера постоянно развивается, и выходят но­
вые законы, такие как Общий регламент ЕС по защите данных (GDPR,
General Data Protection Regulation) и Закон ЕС об искусственном интел­
лекте. Согласно им, сгенерированный ИИ-контент, в котором содержат­
ся сведения о конкретных лицах, рассматривается как персональные
данные. Для обучения моделей на пользовательских данных может пона­
добиться их согласие. Некоторые регулирующие органы приравнивают
генерацию кода к «использованию ИИ общего назначения» и заставля­
ют придерживаться требований по прозрачности или управлению рисками. Чтобы не нарушить законы, нужно оставаться в курсе изменений
и тесно взаимодействовать с юридическими консультантами и специа­
листами по комплаенсу.
Пусть этот совет и покажется банальным, но не пользуйтесь ИИ для
создания вредоносного ПО и эксплойтов без этического обоснования или
для автоматизации неэтичных и незаконных действий 7• Пусть ИИ, скорее
всего, способен написать весьма эффективное фишинговое письмо или
реализовать атаку с внедрением кода, такое его использование нарушает
этические нормы, законы большинства стран и обычно условия исполь­
зования самих ИИ-инструментов. Сосредоточьтесь на создании чего-то
полезного, а не на разрушительной деятельности.
5. Поддерживайте культуру ответственного использования ИИ в органи­
зации
Если в вашей команде допускается вайб-кодинг, то нужно договориться
о принципах его использования с учётом этических соображений. Имеет
смысл предложить разработчикам и рецензентам воспользоваться крат­
ким контрольным списком вроде приведённого на иллюстрации 9.1.

7

244

Бывают и этически обоснованные исключения. Специалисты по безопасности могут
пользоваться ИИ для тестирования кода и поиска уязвимостей, при условии что эти
специалисты действуют в рамках процедур и со всей ответственностью подходят к во­
просам раскрытия информации.
Часть 111. Доверие и автономия

ии

Список ответственного
разработчика
� Интеллектуальная
lY..I собственность

0 Предвзятость
0 Аудит безопасности
Перед добавлением в продукт сгенерированного ИИ кода
Иллюстрация 9.1. Контрольный список ответственной разработки

с помощью ИИ: ключевые этапы валидации, включая проверку вопросов
интеллектуальной собственности, оценку предвзятости и аудит
безопасности перед интеграцией сгенерированного ИИ-кода
Каждый участник процесса должен понимать, что он несёт ответственность
за этичное использование ИИ; это коллективная задача, а не бремя какого-то от­
дельного разработчика, назначенного ответственным за эти вопросы или рабо­
тающего с ИИ-инструментом в данный момент. Особое внимание следует уде­
лять следующему:
- мониторинг современных тенденций в области этического использования
ИИ и нормативной базы;
- совещания на тему этических аспектов конкретных проектов;
- соблюдение этических принципов на всех этапах жизненного цикла разработки;
- помощь в подборе и распространении соответствующих ресурсов и учеб­
ных материалов;
- выбор контактного лица по вопросам этики.
Так как область эта развивается очень быстро, все члены команды должны
иметь представление о новых версиях ИИ-инструментов, об их возможностях,
ограничениях и о том, как пользоваться ими ответственно. Одна из ключевых
концепций, которые стоит внедрять в рабочие процессы, - это карты моделей.
Так называются стандартные документы, в которых перечислены основные ха­
рактеристики модели ИИ и сведения о том, как ею пользоваться. Эти документы
можно сравнить с описанием ингредиентов и ценности какого-нибудь продукта
питания. Обычно в них содержится следующая информация:
- название модели, её версия и дата разработки;
- конкретные сценарии применения, для которых модель была разработана
и на которых она была протестирована;

Глава 9. Этические вопросы вайб-кодинга

245

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

Согласно принципам ответственности системы с ИИ должны иметь за­
щитные механизмы. Например, если код содержит ошибку выхода ин­
декса за пределы массива, то лучше, чтобы система прекратила работу
с явным сообщением о сбое, чем со скрытой ошибкой из-за попытки ИИ
замаскировать проблему. Если система рекомендаций на базе ИИ может
ошибаться, то пользователям нужно предоставить право подкорректиро­
вать результат или отменить рекомендации. Старайтесь проектировать
такие системы, функционал которых частично отключается, если их ИИ­
компоненты ведут себя неправильно.
7. Фиксируйте решения по использованию ИИ в команде

Ведите внутренний журнал с указанием причин, по которым вы восполь­
зовались рекомендациями ИИ или отказались от их использования. На­
пример: «Для модуля Х мы пробовали использовать ИИ, но генерирова­
лось слишком много дублирующего кода, поэтому мы написали эту часть
вручную». Документация помогает развивать рабочие процессы, предо­
ставляет контекст новым участникам команды и укрепляет коллектив­
ную память команды. Также документация бывает полезной при аудите.
8. Активно работайте над устранением предвзятости, дискриминации
и несправедливости

Обращайте внимание на возможные признаки предвзятости или дискриминации со стороны ИИ и предотвращайте такие ситуации заранее. Если
246

Часть 111. Доверие и автономия

ваше приложение планируется использовать в разных странах, подумай­
те, не отдаёт ли оно предпочтение англоязычным пользователям? Пред­
усмотрена ли в нём поддержка нескольких языков? Имеют ли все разра­
ботчики равный доступ к инструментам ИИ и обучению?

Чек-лист ответственного использования ИИ

1. Формулировка запросов и генерация кода (разработчики)
О Убедитесь, что ваши запросы не содержат конфиденциальных данных, личных данных клиентов или секретов.
О Проверьте, не содержится ли в сгенерированном ответе фрагмен­
тов проприетарного кода или кода, распространяемого по лицензии
GPL, если пользоваться им не разрешено. Для анализа применяйте
инструменты вроде FOSSA.
О Тестируйте ответы ИИ на предвзятость, чтобы в коде и в коммента­
риях не отражались стереотипы или дискриминация.
О По умолчанию задавайте безопасные параметры. Проследите за тем,
чтобы в коде не было небезопасных конструкций (eval, несанитизи рованного ввода).
О Уточняйте запросы с указанием стиля, фреймворков, требований
к производительности и совместимости.
2. Проверка кода (разработчики и рецензенты)
О Проследите за тем, чтобы код не содержал защищённого авторским
правом материала, если у вас нет лицензии на его использование.
О Проверьте, корректно ли указано авторство и происхождение кода.
О Проверьте логику, язык и имена (особенно в пользовательском ин­
терфейсе) на предмет предвзятости и справедливости.
О Проверьте, не способен ли код причинить какой-либо вред, не спо­
собствует ли он злоупотреблениям, манипуляциям или дискриминации.
О Проверьте санитизацию входных данных, обработку данных и жур­
налирование, исключите утечки секретов.
О Подтвердите корректность и работоспособность кода с помощью
модульных тестов и тестов граничных случаев; проверьте, как выполняется обработка ошибок и насколько тесты охватывают все воз­
можные сценарии.
О Проверьте, нет ли в коде неэффективных или энергоёмких кон­
струкций.
Глава 9. Этические вопросы вайб-кодинга

247

О Проверьте зависимости, убедитесь, что в коде не используются не­
проверенные библиотеки и что он не чреват лицензионными рисками.
□ Проверьте код на читаемость: убедитесь, что он соответствует руко­
водствам по стилю и понятным соглашениям об именовании.
О Проследите за тем, чтобы был удалён весь неиспользуемый код.
О Убедитесь, что комментарии к коду объясняют его назначение, осо­
бенно для сгенерированной ИИ-логики.
О Убедитесь, что ваша рецензия на код корректна и содержит замеча­
ния по существу.
3. Управление и процессы (организация)
О Убедитесь, что для используемых инструментов имеются средства
контроля лицензий, аудита изменений и отслеживания источников
кода.
О Предусмотрите обуч ающие занятия по этике и использованию ИИ
в разработке.
О Ведите список проверенных ИИ-инструментов; запретите использо­
вание непроверенных или рискованных инструментов.
О Предусмотрите процедуру обработки инцидентов с каналами эска­
лации и механизмами защиты осведомителей (тех, кто сообщает
о случаях неэтичного использования кода).
□ Отслеживайте метрики ответственного использования ИИ с учётом
предвзятости, уязвимости безопасности и нарушения лицензий. Со­
ставьте чек-лист этих метрик и периодически обновляйте его.
О Предусмотрите средства обратной связи. У читывайте различные
точки зрения, устраивайте ретроспективные совещания или орга­
низуйте внешний аудит.

Как пользоваться этим чек-листом

- Настройте список под конкретные требования вашей организации
и сферы деятельности с учётом технологий, уровня риска и ценностей
команды.
- Начните с ключевых вопросов о конфиденциальных данных и лицен­
зиях.
- Включите проверки и чек-листы в рабочий процесс с помощью ша­
блонов запросов на слияние (PR), конвейров непрерывной интеграции
(CI/CD) и инструментов код-ревью.

248

Часть 111. Доверие и автономия

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

По мере дальнейшего развития и расширения экосистем ИИ в индустрии ПО,
скорее всего, появятся новые, связанные с ИИ стандарты и программы сертификации. Мы пока находимся на раннем этапе, но уже сегодня компании могут
участвовать в разработке рекомендаций и подключаться к инициативам по стан дартизации, таким как рабочие группы IEEE или ISO по программной инже­
нерии с использованием ИИ. С этической точки зрения разработчикам лучше
самим принимать участие в определении правил, а не оставлять этот процесс
на усмотрение исключительно регуляторов или судебных органов.

Итоги и дальнейшие шаги
Ответственный вайб-кодинг подразумевает интеграцию ИИ в жизненный цикл
разработки программного обеспечения с учётом интересов всех сторон: авторов
материалов (посредством соблюдения прав на их интеллектуальную собствен­
ность), коллег (благодаря принципам прозрачности и справедливости), пользо­
вателей (посредством защиты конфиденциальных данных, соблюдения правил
безопасности и принципов справедливости) и общества в целом (благодаря за­
щите от злоупотреблений). При этом нужно пользоваться сильными сторонами
ИИ, одновременно контролируя его недостатки.
Как я уже неоднократно говорил, вайб-кодинг - это не оправдание низко­
го качества работы. И это не оправдание нарушений в этической сфере. Мы, как
люди, должны нести ответственность за создаваемый код и следить за тем, что­
бы скорость работы не шла в ущерб общественным ценностям.
В следующей главе речь пойдёт о новой технологии, меняющей способы ра­
боты с ИИ-моделями, а именно об автономных агентах по созданию кода.

ГЛАВА 10

Автономные агенты фонового
программирования
В последнее время быстро набирают популярность автономные агенты фоново­
го программирования, которые можно рассматривать как следующий этап эволю­
ции ИИ-инструментов. В отличие от привычных ассистентов (формата Copilot)
такие агенты, скорее, выполняют роль младшего разработчика, которому пору­
чают целые задачи без постоянного надзора. Код генерируется в специально со­
здаваемой для агента изолированной среде, в которой также можно запускать
и тесты. Результат чаще всего имеет вид полностью оформленного и готового
к ревью пул-реквеста.
В этом разделе я расскажу, что представляют собой фоновые агенты, как они
работают и какие инструменты доступны сегодня (OpenAI Codex, Google Jules,
Cursor, Devin и прочие). Далее я разберу их отличия от традиционных, встро­
енных в IDE ассистентов, а также упомяну их преимущества, ограничения и их
возможное влияние на практику разработки ПО в будущем.

От напарников к автономным агентам:
что такое агенты фонового программирования
Традиционные ИИ-ассистенты для написания кода (такие как Cursor, Copilot
от GitHub или расширения для VS Code вроде Cline) - это управляемые аген­
ты для написания кода, то есть интерактивные помощники, которые реагиру­
ют на запросы разработчика или на контекст прямо в среде написания кода.
По сути, это «прокачанное автодополнение», оно генерирует подсказки в чате
или в процессе набора кода, но весь процесс по-прежнему контролирует человек­
разработчик, следящий за каждым их шагом.
В отличие от них автономные фоновые агенты для написания кода гораз­
до более самостоятельные. Разработчики задают им высокоуровневую задачу
или ставят общую цель, после чего какое-то время не вмешиваются в их работу.
Эти агенты читают кодовую базу и вносят в неё изменения, составляют план
250 1

Часть 111. Доверие и автономия

действий, выполняют код (в том числе тесты) и выдают результат - часто в виде
готового коммита или пул-реквеста - и всё это асинхронно, то есть без посто­
янного надзора человека.
Если традиционные агенты вроде Copilot можно сравнить со вторым пилотом
или помощником пилота, то автономные агенты - это автопилот: второй пилот
всегда находится рядом в кабине с основным и ждёт его указаний; автопилот же
(фоновый агент) может какое-то время управлять самолётом самостоятельно.
Автономные фоновые агенты берут на себя многосоставные задачи по разра­
ботке и выполняют их, пока вы заняты чем-то другим. Асинхронные агенты
вроде Codex и Jules в каком-то смысле расширяют когнитивную пропускную
способность разработчика: конкретную задачу можно целиком поручить ИИ
и забыть о ней до тех пор, пока она не будет сделана. На смену однопоточному
диалогу с ИИ приходит многопоточный рабочий процесс; агент работает парал­
лельно с вами подобно младшему разработчику, занимающемуся своими делами.
Здесь принципиально важно отметить, что фоновые агенты работают не на­
прямую в редакторе кода, а в изолированной среде разработки (часто это облачные виртуальные машины или контейнеры). Обычно эти агенты создают клон
репозитория в «песочнице», устанавливают библиотеки с зависимостями и поль­
зуются различными инструментами, необходимыми для сборки и тестирования
проекта. В целях безопасности такие «песочницы» настраиваются с ограничени­
ями (например, без выхода в интернет) и используются временно. В них агент
может запускать компиляторы, тесты, линтеры и другие инструменты без ка­
кого-либо риска для локальной машины. После завершения задачи агент пред­
лагает изменения в коде (диффы) и генерирует краткое описание выполненных
действий. Конечный результат, как правило, оформляется в виде пул-реквеста
с указанием изменений, сообщением для коммита и иногда с поясняющим текс­
том - всё это можно просмотреть в ходе ревью и слить с основной веткой проекта.
Итак, фоновый агент для написания кода - это автономный ИИ-инструмент
разработки, который понимает намерение, выполняет задачу целиком в изоли­
рованной среде, читая, изменяя и тестируя код, а затем передаёт результат на ре­
вью. Он не просто предлагает одну-две строки, а способен брать на себя задачи
более крупного масштаба, такие как:
- реализация нового функционала по всей кодовой базе;
- рефакторинг модуля для повышения эффективности;
- обновление зависимостей проекта.
Автономные фоновые агенты существенно меняют весь процесс разработки
с помощью ИИ, потому что вместо генерации отдельных подсказок они могут
выполнять целые задачи по реализации.
Глава 10. Автономные агенты фонового программирования

251

Как работают автономные агенты
На уровне внутренней логики большинство фоновых агентов работают по примерно одинаковой схеме: планирование, выполнение, проверка и отчёт. Рассмо­
трим эти этапы и связанные с ними возможности.

Планирование

Когда агенту поручают задачу (как правило, в виде запроса с описанием ожи­
даемого результата), он сначала анализирует запрос и составляет план дей­
ствий. Некоторые агенты перед началом работы явно показывают этот план.
Например, агент Jules компании Google выдаёт план, который можно просмо­
треть и скорректировать до начала собственно работы над кодом, что, по сло­
вам его разработчиков, «снимает тревогу от неопределённости и помогает
убедиться, что агент понял запрос правильно». Хороший агент разбивает за­
дачу на этапы:
Шаг 1: найти в кодовой базе релевантные участки. Шаг 2: внести изменения
в файлы А, В и С. Шаг 3: запустить тесты. Шаг 4: коммит изменений.
Планирование - чрезвычайно важный этап автономной работы, потому что
на этой стадии ИИ заранее продумывает стратегию достижения поставленной
цели и только потом переходит к её выполнению.
Далее агент запускает среду разработки, выделенную под конкретную за­
дачу. Jules, например, как пишут разработчики, «клонирует вашу кодовую базу
в защищённую виртуальную машину Google Cloud» и работает там асинхронно (то есть независимо от разработчика-человека). Схожим образом поступает
и Codex от OpenAI - он выполняет каждую задачу в отдельной облачной «песоч­
нице» с заранее загруженным репозиторием. Инструменты вроде фоновых аген­
тов Cursor используют удалённую машину на базе Ubuntu с выходом в интер­
нет для установки пакетов, которую можно настраивать с помощью Docker или
снапшотов. Подготовка среды со всеми необходимыми зависимостями (вклю­
чая соответствующие рантаймы и инструменты сборки) - задача одновремен­
но важная и сложная. Как я заметил в одном из своих предыдущих обзоров,
«очень важно продумать удобный механизм для развёртывания именно такой
среды, какая нужна агенту... а процесс настройки, с точки зрения пользователя,
бывает не менее сложным, чем в случае с СI-конвейером, а то и сложнее». Тем
не менее агенты решают эту проблему с помощью файлов конфигурации. Цель
настроек - создать в облаке среду разработки, максимально соответствующую
252

1

Часть 111. Доверие и автономия

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

Выполнение
Далее начинается основная часть работы: агент начинает создавать и модифицировать код в соответствии с планом. Пользуясь языковой моделью (или несколь­
кими моделями), дообученной под задачи программирования, он читает фай­
лы, генерирует новый код и при необходимости создаёт новые файлы. По сути,
агент ведёт себя как разработчик, то есть находит нужные места в кодовой базе,
редактирует код и добавляет новую логику.
На основании ранних экспериментов было сделано любопытное наблюде­
ние: для нахождения релевантных фрагментов кода агенты часто пользуются
довольно грубым, но надёжным приёмом, а именно обычным текстовым поис­
ком (в духе Uniх-команды gгер). Так они, например, ищут имя функции или не­
кое ключевое слово, чтобы определить нужный фрагмент в репозитории для
изменения. Такой способ кажется довольно примитивным - вроде было бы ло­
гичнее воспользоваться семантическим поиском или анализом на уровне аб­
страктного синтаксического дерева (AST), но на практике грубый способ рабо­
тает стабильно и предсказуемо. Как отмечает Биргитта Бёкелер (https:l/oreil.lyl
wDSkr), многие кодовые агенты, несмотря на существование более продвинутых
техник, по умолчанию полагаются именно на полнотекстовый поиск как на уни­
версальный метод.
По мере редактирования кода некоторые системы ведут журнал записей
или выдают сообщения в режиме реального времени, чтобы пользователь мог
при желании следить за процессом. Так, например, Codex от OpenAI выводит
журнал «мыслей» и команд агента (в кратком виде). Cursor позволяет «просма­
тривать статус и заходить на машину с работающим агентом», так что человек­
разработчик может вмешиваться в процесс по ходу выполнения задачи. Впро­
чем, основная идея фоновых агентов заключается как раз в том, что за ними
не нужно постоянно присматривать, потому что они работают по образцу «ав­
топилота».
Глава 10. Автономные агенты фонового программирования

253

Проверка(верификация)

Главная особенность автономных фоновых агентов заключается в том, что они
не ограничиваются только написанием кода, а часто компилируют его и запуска­
ют тесты для проверки внесённых изменений. Так, например, Codex от OpenAI
спроектирован так, чтобы итеративно, то есть раз за разом, запускать тесты
до получения успешного результата. Агент, способный запускать весь набор те­
стов (или хотя бы их существенную часть), обнаруживает ошибки и автомати­
чески исправляет их в каждой итерации. Важно здесь то, что ИИ перестаёт про­
сто генерировать код, а начинает также самостоятельно заниматься отладкой
и проверкой своего кода.
Теоретически агент с полноценной системой тестирования может автоматически, без участия человека, предлагать исправления, фиксировать результаты
тестов, корректировать код и повторять цикл отладки до успешного прохожде­
ния всех тестов. На практике же иногда этому мешают ограничения и недостатки
среды. В одном из проанализированных мною случаев Codex не смог запустить
полный набор тестов из-за того, что в среде недоставало некоторых инструмен­
тов, так что в итоговом пул-реквесте содержался код, не проходящий два теста.
Если бы среда была настроена как следует, агент исправил бы все мелкие ошиб­
ки заранее, до составления пул-реквеста.
Отсюда следует, что среда и её настройка для работы автономных агентов иг­
рают очень важную роль; если агенты смогут запускать все инструменты, которы­
ми пользуется разработчик-человек (линтеры, тесты, сборщики), многие ошибки
они будут исправлять автоматически. Работа агентов наподобие Devin представ­
ляет собой следующий цикл: Devin «пишет код, находит баги, исправляет их и за­
пускает собственные сквозные тесты для проверки работоспособности». Поми­
мо этого, Devin может запускать в реальном режиме предварительную версию
фронтенд-приложения, чтобы пользователь вручную проверял её функциональ­
ность в браузере, а это очень полезная возможность для данного этапа.

Отчёт
Получив рабочее решение (код проходит все тесты или агент считает его гото­
вым), агент выдаёт результат. В зависимости от платформы это может быть пул­
реквест для GitHub, дифф в чате или готовые файлы для слияния.
На этом этапе вмешивается человек, который выполняет ревью кода. Здесь
снова работает принцип «Доверяй, но проверяй»: вы доверяете агенту задачу
по созданию кода, но должны проверить его работу, проанализировав полученный код и пропустив его через дополнительные тесты. Многие системы агентов
254

Часть 111. Доверие и автономия

напрямую интегрированы с процессом отправки пул-реквестов (PR), так как для
разработчиков это привычный процесс. Например, Jules подключается к указан­
ному репозиторию GitHub и открывает ветку с PR. Codex от OpenAI показывает
дифф в диалоге с ChatGPT, чтобы разработчик мог одобрить изменения или за­
дать уточняющие вопросы. Если разработчик обнаружит проблемы или захочет
внести правки, то можно попросить агента пройти через очередную итерацию.
Некоторые агенты работают по указаниям в чате (Devin может получать
обратную связь из связанной ветки Slack: если указать на проблемный уча­
сток или попросить изменить какой-то фрагмент, он «начнёт работать над от­
ветом»). Для других агентов нужно будет сформулировать новый запрос или
воспользоваться интерфейсом комментариев к ревью. Devin, что весьма впе­
чатляет, даже отреагировал на оставленный в ветке GitHub PR комментарий
с вопросом о том, почему были внесены определённые изменения: сначала он
поставил эмодзи «удивлённые глаза», показывая тем самым, что заметил ком­
ментарий, а потом опубликовал подробное объяснение своих рассуждений.
(Конкретно в этом случае объяснение оказалось не совсем точным, но сам факт
возможности обсуждать PR с агентом говорит о высокой интерактивности та­
ких агентов.)
Если результат кажется человеку-разработчику удовлетворительным, он до­
бавляет изменения пул-реквеста агента в основную ветку или интегрирует из­
менения; если нет - результат отклоняется и разработчик повторяет задание.
На практике часто возникает ситуация, когда результат работы агента кажется
«почти» готовым, но не удовлетворяет полностью всем требованиям. Стоит ли
тратить время на исправление последних 10-20% созданного ИИ-патча, даже
если это была второстепенная задача, которую вы делегировали агенту? В этом
случае возникает типичная «дилемма затрат» - вы уже потратили время и уси­
лия на решение какого-то вопроса и не готовы просто так отказаться от резуль­
тата. Как пишет Биргитта Бёкелер (https://oreil.ly!IdJ9d), если пул-реквест агента
удачен лишь частично, разработчику придётся самостоятельно решать, «в каких
случаях отклонять пул-реквест, а в каких тратить дополнительное время на вы­
полнение последних 20% задачи», изначально не требовавшей много ресурсов.
Универсального ответа не существует; всё зависит от контекста и ценности из­
менения, но таков новый тип компромиссов, с которыми начинают сталкивать­
ся разработчики с появлением автономных агентов.
Итак, фоновые агенты для написания кода работают по следующему циклу:
понять ➔ спланировать ➔ написать код ➔ протестировать ➔ предоставить ре­
зультат. По сути, это имитация работы внимательного и методичного разра­
ботчика, которому поручили выполнить отдельную задачу, но со всеми подра­
зумеваемыми ограничениями ИИ (см. иллюстрацию 10.1).
Глава 1 О. Автономные агенты фонового программирования

255

------------Планирование

[�Агент]

Выполнение кода [�Агент]
в песочнице

Проверка
(тестирование)

Применить и протестировать

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

Сравнение фоновых агентов и ИИ-ассистентов в IDE
Стоит чётко различать ИИ-инструменты для написания кода, которые суще­
ствуют уже несколько лет (Copilot от GitHub, режим создания кода в ChatGPT
и др.), и автономные агенты нового поколения. Оба типа инструментов полез­
ны, но они выполняют разные роли и обладают разными преимуществами и не­
достатками.
Самое очевидное различие - уровень автономии. Ассистенты внутри
IDE, такие как Copilot или ИИ-расширения для VSCode, работают синхронно
с человеком-разработчиком: они предлагают подсказки или отвечают на вопро­
сы, и их область действия обычно ограничена текущим контекстом (например,
редактируемым файлом, функцией или конкретным запросом). Человек сам ре­
шает, соглашаться ли с подсказками, попросить дополнительную помощь или
внести предложенные изменения.
Фоновые же агенты сразу после запуска автономно выполняют сотни дей­
ствий (редактируют файлы, запускают код, ищут данные) без дополнительно­
го подтверждения со стороны человека. Они работают асинхронно. Такой ре­
жим предполагает более высокий уровень доверия (человек позволяет агенту
256

1

Часть 111. Доверие и автономия

вносить изменения самостоятельно) и освобождает разработчика от постоян­
ного контроля. Я часто описываю разницу между этими инструментами как
разницу между программистом-напарником и разработчиком-помощником.
Программист-напарник (Copilot) работает вместе с вами над каждым шагом,
а помощник (Codex, Jules и другие) работает параллельно над другой задачей.
Инструменты типа Copilot хорошо справляются с микрозадачами: написать
функцию, закончить строку, сгенерировать небольшой фрагмент кода, ответить
на вопросы про API. Они плохо воспринимают большие проекты в целом или
общую логику, выходящую за пределы открытых в редакторе файлов или огра­
ниченного окна контекста.
Автономные агенты работают на уровне всего проекта. Они загружают весь
репозиторий (или хотя бы индексируют его), вносят согласованные изменения
в несколько модулей одновременно и выполняют задачу в несколько этапов по за­
ранее составленному плану. Например, Copilot от GitHub может по запросу раз­
работчика помочь написать модульные тесты, а фоновый агент уже действует са­
мостоятельно: по своему решению меняет код в одних файлах, тестирует другие,
меняет конфигурацию в третьих, и всё это в рамках одной задачи. Эти агенты го­
раздо лучше подходят для задач вроде рефакторинга всего проекта (с журналиро­
ванием и обработкой ошибок), обновления зависимостей (часто затрагивающего
множество файлов) или реализации функций, относящихся как к фронтенду, так
и к бэкенду. ИИ-ассистенты в IDE справляются с этими задачами с трудом, пото­
му что им недостаёт памяти и восприятия контекста всей кодовой базы.
Ассистенты типа Copilot реактивны в том смысле, что реагируют на имею­
щийся код или на запросы, - они отвечают на ваш код или запросы и не дейст­
вуют самостоятельно. Фоновые же агенты, напротив, проактивны - после ак­
тивации они сами предпринимают какие-то шаги для достижения цели. Агент
типа Jules или Devin может создать новый файл или запустить тесты без всяких
запросов. Они же могут проактивно уведомлять пользователя о важных собы­
тиях, например:
Я нашёл ещё одно место, где можно воспользоваться этим решением; сде­
лаю это позже.
Поведение таких агентов больше похоже на поведение сотрудника, который
говорит: «Работая с кодом, я заметил ещё одну проблему и исправил её тоже».
Вместе с тем понятие автономности предполагает, что агент может сделать не­
что неожиданное или поступить вразрез с ожиданиями разработчика. Работа­
ющий под постоянным контролем Copilot делает только то, что просите вы или
на что соглашаетесь вы (за исключением самых мелких и незаметных правок).
Глава 1 О. Автономные агенты фонового программирования

257

С увеличением же активности агента повышаются и требования к разработчику,
который должен более внимательно проверять результаты работы этого агента.
Ещё одно важное отличие заключается в том, что агенты могут исполнять
код и команды, тогда как традиционные IDЕ-ассистенты этого обычно не дела­
ют (за исключением режима «интерпретатор кода» в ChatGPT, который больше
предназначен для анализа данных и не обновляет проект в процессе сборки).
Агенты могут запускать составленные вами тесты, запускать локальный сер­
вер разработки, компилировать приложение и даже разворачивать его. Они ра­
ботают в песочнице, но, по сути, работать с агентом - это всё равно что рабо­
тать с автоматизированным разработчиком, пользующимся терминалом. Они
принципиально меняют правила игры и включают в процесс автоматизирован­
ной разработки циклы проверки и исправлений. IDЕ-агенты способны генери­
ровать код, который будет выглядеть правдоподобно, но понять, насколько он
надёжен и работоспособен, можно будет только после тестов и проверок.
Независимые фоновые агенты повышают шансы получить по-настояще­
му рабочий результат. Они в какой-то степени снимают с разработчиков часть
бремени по отладке: если что-то ломается, агент может попытаться исправить
проблему сразу же. С другой стороны, для такой возможности, как говорилось
выше, ему требуется корректно настроенная среда, и такое поведение чревато
потенциальными побочными эффектами. Представьте, что может произойти,
если агенту поручат провести миграцию базы данных или модифицировать дан ные; конечно, они обычно работают в режиме «песочницы», без влияния на про­
дакшен, но всё равно нужно соблюдать осторожность.
Copilot от GitHub и похожие инструменты интегрированы в редактор, что от­
лично подходит для кодинга «в потоке». Фоновые же агенты часто также инте­
грируются с инструментами управления проектами и с инструментами DevOps
(тестирования, развёртывания и поддержки приложений). Например, можно со­
здать задачу в системе отслеживания GitHub и поручить агенту приступить к её вы­
полнению с последующей подготовкой запроса на слияние, либо запустить аген­
та в рамках конвейера непрерывной интеграции (CI) для отдельных задач, таких
как автоматическое исправление ошибок в пул-реквесте. В рекламе CodeGen пря­
мо говорится, что их агенты умеют подключаться к трекерам задач и начинать ра­
боту, когда задача переходит в статус «в работе» (In Progress). Такой уровень инте­
грации выходит далеко за рамки возможностей IDЕ-ассистентов и указывает на то,
что со временем ИИ-агенты могут стать частью цикла непрерывной интеграции
и установки (СI/СD-цикла) - например, автоматически устранять сбои сборки
или формулировать дополнительные запросы на слияние для незначительных про­
блем. Это уже другой формат взаимодействия: не просто помощь разработчику
при написании кода, а роль бота-участника в инструментальной цепочке команды.
258

Часть 111. Доверие и автономия

Работа с ассистентами типа Copilot, по ощущениям, всё ещё воспринимается
как программирование, просто более быстрое: человек набирает код, ассистен­
ты дают подсказки, человек принимает их и тестирует. Работа с фоновым аген­
том больше похожа на делегирование обязанностей с последующей проверкой.
Роль человека смещается от написания кода к формулировке задач и к анализу
полученного результата. Я называю такую схему «асимметрией генератор - ре­
цензент»: сгенерировать рабочее решение с нуля сложно, но проверить и дора­
ботать предложенный ИИ вариант заметно проще. Асинхронные агенты хоро­
шо вписываются в эту схему: они берут на себя основную генерацию, оставляя
людям задачи по правке и проверке (какие обычно выполнять бывает быстрее).
Такой образ взаимодействия человека и машины серьёзно повышает продук­
тивность, но одновременно требует от инженера более развитых навыков ана­
лиза и валидации кода.
Код-ревью всегда играл важную роль, но теперь через него проходит не толь­
ко код, написанный коллегами-людьми, но и код, сгенерированный ИИ, в ко­
тором бывают свои характерные ошибки. Я советую придерживаться простого
правила: относитесь к сгенерированному агентом коду так, как будто его напи­
сал довольно усердный, но ещё недостаточно опытный младший разработчик.
Несмотря на то что он действует из благих намерений и обладает базовыми по­
знаниями, его код всё равно нужно проверять, просить исправить или откло­
нять, если этот код недотягивает до предъявляемых требований.
На практике я часто пользуюсь инструментами типа Copilot вместе с фо­
новыми агентами. Так, например, Copilot или подсказки Cursor удобны, когда
я сам пишу сложную логику и хочу контролировать весь процесс. Одновремен­
но с этим можно параллельно поручить фоновому агенту второстепенную, но за­
тратную по времени задачу (вроде обновления всех клиентских библиотек API
под новые конечные точки). Это разные ниши, и один тип инструментов не за­
меняет другой. Более того, я ожидаю, что со временем IDE расширят функции
своих помощников от «дополни эту строку» и «сгенерируй функцию» до «ИИ,
реализуй эту задачу целиком». Конкретный инструмент будет выбираться в за­
висимости от масштаба задачи.

Объединение нескольких ИИ-моделей
для максимального эффекта
До сих пор я часто говорил об ИИ так, как будто это какая -то одна и та же мо­
дель. В реальности же всё иначе: существует множество моделей ИИ, каждая
со своими преимуществами. Одни хорошо понимают естественный язык, другие
Глава 1 О. Автономные агенты фонового программирования

1

259

отлично генерируют код, третьи специализируются на отдельных областях (на­
пример, решают математические задачи или генерируют пользовательский ин­
терфейс). Опытные адепты вайб-кодинга задействуют сразу несколько моделей,
каждую в той сфере, где она даёт наилучшие результаты. Такое сочетание моде­
лей называется «оркестрацией», и его можно сравнить не с индивидуальной ра­
ботой одного универсального специалиста, а со слаженным взаимодействием
группы специалистов.
Представьте, что в недалёком будущем в вашем распоряжении окажутся сле­
дующие специалисты:
- ИИ-разработчик кода, хорошо обученный программированию, способ­
ный выдавать и исправлять работающий код;
- ИИ-тестировщик, обученный составлять тесты и находить граничные
случаи;
- ИИ-документатор, пишущий понятные документы и комментарии;
- ИИ-дизайнер, создающий макеты пользовательского интерфейса и графики;
- ИИ-оптимизатор, сосредоточенный на оптимизации производительности
и, возможно, вникающий в низкоуровневые детали.
Всю задачу можно будет прогонять через цепочку таких ИИ. Например, вы
поручаете ИИ-программисту реализовать задуманную вами функцию; резуль­
тат его работы передаёте ИИ-тестировщику для генерации тестов или критики
кода. Далее код и тесты подаются на вход ИИ-документатору, который подго­
тавливает документацию или пишет гайды по использованию. Если задача связана с пользовательским интерфейсом, то на раннем этапе можно подключить
ИИ-дизайнера, который предложит структуру макета для реализации её сила­
ми ИИ-разработчика. В таких цепочках каждая модель и каждый агент будут
выполнять свою экспертную задачу, и по сути такая схема похожа на программный пайплайн или на конвейерную сборку, только вместо разных специалистов­
людей здесь работают разные ИИ с разными ролями.
Надёжность результата повышает даже совместная работа схожих моделей.
Допустим, у вас имеются два разных ИИ-программиста от разных провайдеров
или разной архитектуры; можно поручить одну и ту же задачу обоим, а затем
сравнить или протестировать полученные результаты и выбрать работающий
вариант, проходящий все тесты. Если все тесты проходят оба варианта, то можно
выбрать более чётко оформленный и легко читаемый. Если одна из моделей вы­
дала неудачный результат, ей можно показать результат другой модели как обра­
зец для дальнейшей генерации. Такой перекрёстный диалог между ИИ снижает
260

Часть 111. Доверие и автономия

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

Разграничение моделей по типу задач
Подбирайте инструмент под конкретную задачу. Большие языковые модели
(LLM) - это неплохой универсальный помощник, но в некоторых случаях более
эффективно с задачами справляются небольшие специализированные модели.
Например, для арифметических вычислений или для некоторых алгоритмиче­
ских задач лучше подходят детерминированные средства (или ИИ-модели с бо­
лее жёсткими ограничениями). В некоторых продвинутых средах разработки для
отдельных подзадач применяются символьные решатели или классические ИИ­
системы, ориентированные на правила, тогда как для других этапов используют­
ся LLM. Освоив основы вайб-кодинга, разработчик может создать собственный
набор инструментов: когда нужны регулярные выражения, вызывать генератор,
специально предназначенный для регулярных выражений; когда нужно сообще­
ние для коммита, возможно использовать модель, точно настроенную для сум маризации. Преимущество такого подхода заключается в том, что все эти компо­
ненты легко интегрируются с помощью простых скриптов или обёрток запросов.
Например, можно запустить локальный скрипт ai._regex_generator, обращаю­
щийся к ИИ, но с предварительной обработкой запросов и дополнительной об­
работкой выводов для корректного составления регулярных выражений, а также
с автоматической проверкой на заданных примерах при необходимости.

Системы оркестрации
Если вам часто приходится комбинировать разные модели, стоит задуматься над
созданием системы оркестрации - нового класса фреймворков, часто называ­
емых ИИ-оркестрацией или агентами. Такие системы позволяют задавать по­
следовательность действий, например:
Шаг 1. Модель А интерпретирует пользовательский запрос.
Шаг 2. Если запрос связан с анализом данных, модель В генерирует SQL;
если с текстом, модель С генерирует...
Шаг 3. Результат передаётся модели D для объяснения.
Глава 10. Автономные агенты фонового программирования

261

Особенно актуальны такие модели для многоэтапных процессов созда­
ния приложений или сервисов с использованием ИИ. Но автоматизировать
многошаговые процессы можно и для личной разработки. Есть пример одно­
го кастомного инструмента с интерфейсом командной строки ai._dev_assi.st,
который классифицирует запрос по таким категориям, как «код», «дизайн»,
«тестирование», «оптимизация». В зависимости от категории запрос перена­
правляется в соответствующую специализированную модель ИИ. Полученный
результат при желании можно отправить в другую модель для проверки или
улучшения.
Такой «мета-ИИ», координирующий работу других ИИ, на первый взгляд ка­
жется довольно сложным инструментом, но современные технологии позволяют опытным пользователям относительно легко настраивать его. По всей види­
мости, с появлением встроенной поддержки оркестрации в IDE или в облачных
платформах процесс станет ещё проще.

Гибридные команды «человек- ИИ»
Раз уж речь зашла о «множественном интеллекте», не стоит забывать и о людях­
сотрудниках. Опытный вайб-кодер должен понимать, когда можно и нужно об­
ращаться за помощью к коллегам-ра�работчикам. Например, с помощью ИИ
можно сгенерировать два-три варианта прототипа дизайна функции, а затем по­
казать их для оценки UХ-дизайнеру команды, который выскажет своё мнение
о том, какой вариант соответствует бренду или какой кажется более интуитив­
ным. Если ИИ написал сложный фрагмент кода, стоит провести с коллегой сес­
сию ревью кода, потому что, как сказано в одном обзоре, «так как создавать код
помогал ИИ, то для его анализа нужен взгляд со стороны ещё одного человека».
В каком-то смысле «мультимодальная» схема может включать и людей как вы­
сокоразвитых «моделей», и каждый участник в ней (человек или ИИ) обладает
своими уникальными преимуществами. В будущем получит распространение
разработка парами «человек + ИИ» или командное взаимодействие, в котором
отдельными представителями команды будут ИИ.
Предположим, что вам нужно с помощью вайб-кодинга создать небольшое
веб-приложение. Весь рабочий процесс может выглядеть так:
1. Один ИИ генерирует макет интерфейса и по описанию создаёт HTML/
СSS-страницы (специализация - фронтенд).
2. Другой ИИ генерирует текстовый контент или изображения (например,
маркетинговую статью с иллюстрациями - в таком случае ИИ специа­
лизируется на копирайтинге).
262

Часть 111. Доверие и автономия

3. Далее основной ИИ генерирует код: создаёт интерактивный функционал
на JavaScript и встраивает его в HTML для подключения к разным эле­
ментам по их ID.
4. ИИ-тестировщик генерирует тесты Selenium или Playwright для провер­
ки взаимодействия с интерфейсом.
5. Под конец ещё один ИИ сканирует код на безопасность и выявляет по­
тенциальные уязвимости. Это может быть отдельная модель или просто
статический анализатор, дополненный ИИ.
Эта мультимодальная схема объединяет фронтенд, бэкенд (если он есть), кон­
тент, тестирование и безопасность в одном интегрированном процессе. Каждый
ИИ выполняет свою роль, а разработчик, как дирижёр, следит за согласованно­
стью их работы.
В настоящее время, возможно, результаты работы одного инструмента при­
дётся вручную переносить в друrой инструмент или пользоваться для этого вспо­
могательными скриптами, но в будущем можно будет настраивать IDE так, чтобы
все задачи выглядели как единый процесс, или конвейер (пайплайн). Главная идея
здесь такова: не нужно ограничиваться одной моделью ИИ, если у вас есть доступ
к нескольким моделям. Пользуйтесь для каждой задачи той, которая подходит для
неё лучше всего, и заставляйте их работать вместе. Так вы повысите качество ре­
зультатов и снизите риск сбоев в конкретных местах, потому что если одна модель
с чем-то не справится, то её недостаток компенсирует другая модель.
Сочетание ИИ-моделей - логичное продолжение принципа специализа­
ции, хорошо известного в разработке ПО (вспомните о микросервисах, каждый
из которых качественно выполняет одну задачу). Здесь же каждое дело выпол­
няет та ИИ-модель, у которой оно получается лучше всего. Роль вайб-кодера
расширяется от простого инициатора команд до дирижёра ИИ. Такая работа
требует чуть большей подготовки и продумывания, но в результате получается
слаженная симфония ИИ-сотрудников, каждый из которых вносит свой вклад
в качественный конечный продукт.
Теперь, после того как вы получили представление о совместной работе ИИ­
моделей, ознакомимся с ведущими их образцами и оценим их возможности.

Основные автономные агенты для написания кода
Сейчас, по состоянию на 2025 год, когда я пишу эти строки, автономные агенты для написания кода проделали значительный путь - за прошедший год они
быстро эволюционировали и были представлены на различных платформах.
Глава 10. Автономные агенты фонового программирования

263

Из инструментов автоматического завершения кода они превратились в актив­
ных партнёров, самостоятельно выполняющих сложные задачи.
Облачные агенты с командной строкой: Codex от OpenAI
Codex от OpenAI (https://oreil.ly!Ml-NU) представляет собой пример облач­
ного агента, работающего через интерфейс ChatGPT или интерфейс команд­
ной строки с открытым исходным кодом. Он создаёт изолированные «песоч­
ницы» для параллельного выполнения разных задач, от обновлений React
до создания модульных тестов. Отличительная особенность Codex - об­
учение с подкреплением на реальных задачах; он следует лучшим практиче­
ским приёмам - например, итеративно запускает тесты, пока они не пройдут
успешно. От запуска к запуску результаты могут различаться, но для хоро­
шо сформулированных задач Codex обычно находит рабочие решения. Его
главное преимущество - реальное выполнение кода в средах, аналогичных
системам непрерывной интеграции (CI), что делает его представителем пер­
вой волны агентов, по-настоящему «встроенных» в конвейеры разработки.
Агентьt, интегрированные в рабочие процессы: Jules от Google
Jules от Google (https:/ljules.google) использует иной подход посредством тесной
интеграции с рабочими процессами GitHub. Работая на виртуальных машинах Google Cloud с полными клонами репозиториев, Jules делает упор на на­
глядное, структурированное планирование: он выдаёт ход своих рассуждений
и позволяет вносить изменения в план до начала его выполнения. Такая фи­
лософия - «сначала план, затем выполнение» - в сочетании с обратной свя­
зью в реальном времени позволяет позиционировать Jules как «ассистента, ра­
ботающего под надзором», а не как автоматизированный «чёрный ящик». Его
дизайн ориентирован на GitHub, то есть на среду, в которой непосредственно
работают команды, создающие ветки и пул-реквесты, так что им не приходит­
ся переключать контекст. Агент даже экспериментирует с новыми функция­
ми, такими как аудиожурналы изменений, облегчающими процесс ревью кода.
Агенты, интегрированные в IDE: Cursor
Фоновые агенты Cursor (https:/loreil.ly/V-Pci) служат образцами, ориентиро­
ванными на IDE (интегрированную среду разработки): они запускаются на­
прямую из редактора, но выполняются на удалённых машинах. Гибридная
модель позволяет разработчикам оркестрировать набором ИИ-исполнителей
из единого командного центра, сохраняя при этом контроль над локальным
окружением. Cursor разворачивает экземпляры Ubuntu с настраиваемым
окружением (посредством env"ironмent. json или DосkегПle), предоставляя
264

Часть 111. Доверие и автономия

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

Агенты с командной интеграцией: Devin
Созданный компанией Cognition Labs агент Devin (https:!!devin.ai) позицио­
нируется не как просто инструмент, а как ИИ-сотрудник, интегрированный
со Slack, GitHub и трекерами задач вроде Jira. Он использует собственные мо­
дели ИИ с долгосрочным планированием и многозадачным выполнением.
Devin хорошо справляется с параллельным выполнением мелких рутинных
задач, которые остаются в низком приоритете, такими как исправление багов,
добавление тестов, очистка кода линтерами. Сама его архитектура ориенти рована на совместную работу и включает обновления статуса, запросы уточ­
нений и даже автоматические ревью развёртывания. Вместе с тем, несмотря
на то что с простыми задачами он справляется отлично, сложные вопросы
всё ещё требуют значительного участия человека, что подчёркивает текущие
ограничения автономных агентов.

Данная сфера развивается стремительно, и новый класс инструментов напе­
регонки развивают как крупные игроки, так и стартапы. Судя по некоторым на­
мёкам, Microsoft собирается предъявить публике новый инструмент Copilot++,
расширяющий возможности прежнего инструмента от подсказок до полноценной
автономной работы. Стартапы вроде CodeGen обещают показать «разработчиков
ПО, которые никогда не спят» (на основе Claude от Anthropic). Открытые проек­
ты и академические исследования расширяют границы возможного в попытках
повысить надёжность генерации кода и сделать её контекстно ориентированной.
Всё это разнообразие говорит о рождении новой парадигмы разработки, в ко­
торой отдельный разработчик управляет несколькими ИИ-агентами, каждый
из которых специализируется на разных аспектах жизненного цикла ПО. Ос­
новные различия между ними касаются следующего:
- среда выполнения (локальная или облачная);
- степень интеграции (IDE или инструменты рабочего процесса);
- уровень автономности (плотный контроль или независимость);
- целевые сценарии использования (сопровождение кода или разработка
нового функционала).
Глава 10. Автономные агенты фонового программирования

265

Проблемы и ограничения
Помимо проблем, присущих всем сценариям разработки с поддержкой ИИ,
о которых уже говорилось в книге (особенно рассмотренной в главе «пробле­
мы 70%)) ), автономность агентов порождает специфические трудности, требую­
щие отдельного рассмотрения.
Эффект накопления последовательных решений
В отличие от ИИ-инструментов с постоянным контролем со стороны чело­
века, автономные агенты самостоятельно принимают ряд решений, ошиб­
ки в которых могут накапливаться последовательно. Неверно интерпретиро­
вав входные данные, агент может не просто допустить ошибку в какой-либо
функции, а создать целую ошибочную и неправильно работающую архитек­
туру. Каждое последующее решение закрепляет первоначальную ошибку,
в результате которой возникает код, внутренне согласованный, но принци­
пиально не соответствующий реальным требованиям - такую ситуацию
я называю «неправильной согласованностью)).
Особую проблему представляют ошибки в цепочке принятых решений
агентами, которые вносят изменения сразу в несколько разных файлов.
Агент, реализующий новую функцию, может правильно изменить API бэкенда, но неправильно переделать фронтенд, схему базы данных и тесты. К мо­
менту проверки полного пул-реквеста выявлять все взаимосвязанные ошиб­
ки будет гораздо труднее, чем исправлять их поэтапно, как это позволяют
традиционные интерактивные ИИ-инструменты.
Ошибки при масштабировании
В главе 8 упоминались возникающие при настройке среды сложности обще­
го характера, но для автономных агентов есть и отдельная сложность, связан­
ная с настройкой «песочниц)). При каждом запуске агента создаётся изоли­
рованная среда, точно повторяющая среду разработки, но эта задача плохо
масштабируется. При параллельной работе нескольких агентов даже самые
незначительные различия в среде могут привести к заметно отличающимся
результатам.
Рассмотрим сценарий, в котором над разными функциями одновремен­
но работают пять агентов. В контейнере агента А может быть немного уста­
ревшая версия Node, у агента В может отсутствовать конкретная системная
библиотека, а агент С может быть настроен на другой часовой пояс. Эти не­
заметные во время выполнения отличия превращаются в мелкие баги, кото­
рые можно обнаружить только при интеграции. Такой «сдвиг среды)) между
266

Часть 111. Доверие и автономия

«песочницами» агентов представляет собой новый тип проблем интеграции,
не характерный для обычных рабочих процессов с одним разработчиком.
Парадокс асинхронной координации
Автономные агенты по своему заявленному функционалу, казалось бы, дол жны облегчать параллельную разработку, но эта параллельная разработка от­
личается от человеческого взаимодействия в команде и сопряжена со своими
проблемами. У агентов нет неявных каналов коммуникации между собой,
и когда они работают над пересекающимися фрагментами кода, они не могут,
например, переслать друг другу сообщения в Slack: «Это ты изменил модуль
авторизации?» Они не понимают, над чем работают их «коллеги».
В этом и заключается то, что я называю парадоксом асинхронной координа­
ции: чем больше агентов запускается для повышения продуктивности, тем слож­
нее их интегрировать. В отличие от людей, координирующих свои действия с по­
мощью формальных и неформальных средств, агенты действуют изолированно
друг от друга. Один агент вполне может приступить к рефакторингу какой­
нибудь утилитарной функции, тогда как другой агент параллельно в это же вре­
мя добавляет вызовы к старой версии и создаёт конфликты, которых не возник­
ло бы, если бы над этими задачами работали люди, общающиеся между собой.
Усиление проблемы код-ревью
Ревью сгенерированного ИИ-кода - это важный этап в любом случае, но ав­
тономные агенты осложняют его, увеличивая объём работы и время её выполнения. В случае с интерактивными ИИ-инструментами (о которых речь
шла в предыдущих главах), код создаётся постепенно, по мере их работы,
но автономные агенты через какой-то срок выдают или полностью готовые
реализации, или сразу несколько пул-реквестов одновременно.
В результате возникает когнитивная нагрузка, отличающаяся от нагруз­
ки, возникающей при проверке пул-реквестов, созданных человеком. В слу­
чае с человеком рецензент в своих попытках понять ход мыслей разработчика
может ориентироваться на сообщения коммитов и описания пул-реквестов.
В случае с агентом приходится восстанавливать «логическую цепочку» рабо­
ты прямо из кода. Когда утром в понедельник пять агентов присылают пулреквесты (PR) на 500 строк и более, проверка превращается в своего рода ар­
хеологические раскопки.
Проблема доверия
Пожалуй, одна из самых важных проблем касается того, что автономные аген­
ты ставят под вопрос привычные модели доверия инструментам. Поручая
Глава 1 О. Автономные агенты фонового программирования

267

задачу агенту, разработчик, по сути, идёт на определённый риск, тогда как при
работе с управляемым ИИ-ассистентом контроль сохраняется на каждом шаге.
Особое внимание стоит уделить вопросам безопасности. Автономные
агенты с правами записи в репозиторий и возможностью выполнения кода
порождают уникальные уязвимости. Автономный агент, неправильно на­
строенный, не просто предлагает плохой код - он активно его внедряет и по­
тенциально даже развертывает. Как следствие, «песочницы» и механизмы
контроля доступа для таких агентов должны быть значительно более надёж­
ными, чем соответствующие «песочницы» и механизмы для ИИ-инструмен­
тов, просто предлагающих код (см. главу 8).
Организационные сложности
По мере распространения практики работы с автономными агентами возни­
кают и новые организационные вопросы, не характерные для работы с тра­
диционными ИИ-помощниками. Кого нужно будет считать «автором» кода,
если разработчик, который поручил агенту создать этот код, допустим, забо­
леет? Как отслеживать использование агента в коллективе? Что делать, если
месячный план рефакторинга с помощью агента конфликтует со срочными
задачами по разработке функционала?
Это не технические ограничения, а организационные вызовы, уникальные
для автономных систем. Они требуют новых ролей («координаторов аген­
тов»?), новых процессов («оценка вклада агента»?) и новых инструментов
(«управление разными агентами»?), выходящих за рамки индивидуальной
разработки, о которой шла речь в предыдущих главах.
Автономность этих агентов, то есть их самостоятельность, способность при­
нимать последовательные решения и масштабировать процессы, превращает их
из инструментов повышения продуктивности в своего рода «членов команды».
Такой сдвиг в восприятии подразумевает не только иные практические методы
работы с ними, но и совершенно иные подходы к координации, доверию и интеграции, о чём мы лишь начинаем задумываться в последнее время.

Лучшие методы эффективного использования ИИ­
агентов для программирования
Многие общие советы по разработке с помощью ИИ применимы и к автономным агентам, но некоторые аспекты работы с ними требуют отдельного вни­
мания. На основе опыта работы с Codex, Jules, Devin и фоновых агентов Cursor
268

Часть 111. Доверие и автономия

можно составить некоторые рекомендации с учётом уникальных сложностей
и возможностью делегирования целых задач на усмотрение автономных ИИ­
агентов.

Стратегический выбор задач для автономных агентов
Фундаментальное отличие ИИ-ассистентов от автономных агентов заключается
в масштабе и степени независимости. Агенты лучше всего справляются с чётко
определёнными, ограниченными задачами с ясными критериями успеха, особен­
но если эти задачи предполагают параллельное выполнение множества мелких
действий. Идеальные задачи для агентов - составление тестов, покрывающих
весь спектр проверки, системное обновление зависимостей, массовый рефакто­
ринг и реализация стандартных функций в нескольких компонентах.
Попросить ИИ-ассистента написать простой тест - это не то же самое, что
попросить агента написать тесты с 80-процентным покрытием всего модуля.
Агент может методически прорабатывать каждую непротестированную функ­
цию, генерировать соответствующие тестовые случаи, выполнять тесты и повто­
рять процесс до получения удовлетворительного результата. Для автономных
агентов лучше всего подходит как раз такая систематическая работа с измеримыми результатами.
И наоборот, задачи вроде архитектурных решений, интерпретации сложных
требований заказчиков или разработки новых алгоритмов лучше выполнять
с помощью ИИ-ассистентов под руководством человека. Главное - это понять,
какие аспекты крупной задачи можно уверенно делегировать агентам, а какие
требуют оценки со стороны человека и творческого подхода.

Специфичные для агентов возможности планирования и контроля
Современные автономные агенты выделяются благодаря своим продвинутым
функциям планирования и прозрачности исполнения при активном участии че­
ловека. Jules, например, показывает план выполнения до начала работы, а Cursor
отображает логи своих действий в реальном времени - и это как раз ключевые
моменты для контроля, характерные именно для работы с агентами.
Фаза планирования - это основной фильтр качества. Проверяйте предлага­
емый план не только на отсутствие ошибок, но и на эффективность и на соот­
ветствие вашим стандартам. Если, например, Jules собирается обновить прило­
жение на Next.js, но забыл запланировать изменения в конфигурации webpack,
то лучше обнаружить это упущение заранее, чем потом заставлять его пере­
делывать работу. Такая «проактивная» проверка принципиально отличается
Глава 10. Автономные агенты фонового программирования

269

от «реактивного» код-ревью и становится новым навыком в арсенале разра----ботчика.
Ещё один уровень контроля, специфичный для агента, - это мониторинг
во время выполнения. Следить за каждой операцией не обязательно, но перио­
дические проверки помогают выявить неэффективные решения или слишком
масштабные изменения. Cursor, например, может «входить» в среду агента в про­
цессе выполнения и вносить изменения, не прерывая полностью автономный ра­
бочий процесс. Для максимальной эффективности важно научиться понимать,
когда нужно вмешиваться, а когда позволять агенту самому исправлять ошибки.

Управление параллельной работой агентов
В отличие от традиционной разработки, где один разработчик работает над од­
ной задачей за раз, агенты могут действовать параллельно, и такая работа требу­
ет новых стратегий координации. При одновременном запуске нескольких аген­
тов (например, один обновляет зависимости, другой добавляет инфраструктуру
логирования) важно учитывать возможные конфликты и зависимости.
Для минимизации конфликтов при слиянии устанавливайте чёткие границы зон ответственности каждого агента. По возможности назначайте разным
агентам работу над разными модулями или уровнями приложения. Продумайте
порядок интеграции - так, например, один агент добавит новые функции уже
после того, как другой агент переработает инфраструктуру. В этом смысле орга­
низация работы нескольких агентов (оркестрация) ближе к управлению коман­
дой, а не к традиционной одиночной работе.

Развивайте методы работы с агентами для управления командой
Автономные агенты кардинально меняют динамику командной работы и ревью.
Сгенерированные агентом пул-реквесты, в отличие от пул-реквестов коллеги­
человека, могут быть технически корректными, но стилистически несогласован­
ными. Команде понадобится выработать новые правила ревью с учётом стили­
стических вопросов.
Попробуйте составить чек-листы для проверки пул-реквестов агентов, по ко­
торым вы будете оценивать не только корректность кода, но и степень его соот­
ветствия принятым в команде стандартам и архитектурным паттернам. Подме­
чайте типичные особенности работы с агентом: например, какой-то агент может
регулярно использовать антипаттерны или упускать возможность оптимизации.
Выявленные закономерности помогут рецензентам быстро выявлять и устра­
нять повторяющиеся проблемы.
270

1

Часть 111. Доверие и автономия

Обратная связь с автономными системами
Автономные агенты формируют новый тип итеративной разработки, при кото­
рой цикл обратной связи выходит за рамки простого ревью. Если пул-реквест
агента требует доработки, его можно отправить обратно агенту с конкретными
указаниями для следующей итерации. В этом заключается ещё одно отличие ра­
боты с автономными агентами от традиционной разработки, при которой воз­
врат работы коллеге чреват затратами времени и социальными издержками.
Придумывайте шаблоны запросов, хорошо работающих с выбранными аген­
тами. Найдя удачную формулировку, стабильно дающую качественный резуль­
тат, задокументируйте её. Создавайте шаблоны для типовых задач, предусма­
тривающие весь нужный контекст и все ограничения - это уже своего рода
специализированная «промпт-инженерия для агентов», что можно назвать от­
дельным навыком по сравнению с обычным взаимодействием с ИИ.
Главная цель при этом остаётся прежней: эффективная разработка качествен­
ного программного обеспечения. Автономные агенты - это лишь новый инстру­
мент для достижения этой цели, но его нужно внедрять в существующие процес­
сы осознанно, а не только ради формального перехода на новые рабочие схемы.
Поняв, как именно они работают и какие уникальные возможности они предо­
ставляют, команды могут существенно повысить продуктивность при сохране­
нии строгих стандартов качества и не жертвуя архитектурной целостностью кода.

Итоги и дальнейшие шаги
В заключение повторю мысль из главы 4: ИИ не заменит разработчиков, но раз­
работчики, умеющие эффективно пользоваться ИИ, вполне могут заменить тех,
кто не умеет им пользоваться. Появление автономных агентов для написания
кода - очередной шаг именно в этом направлении: тот, кто научится управ­
лять этими «механическими коллегами», сможет делать больший объём работы
за меньшее время. Мы живём в поистине вдохновляющую эпоху для разработ­
чиков, при условии что мы приспособимся к переменам и продолжим соблюдать
высокие стандарты качества в своей работе. Инструменты меняются, но цели
остаются прежними: создание надёжного, эффективного и инновационного ПО.
ИИ-агенты (работающие под нашим контролем или автономно) лишь предла­
гают новые способы достижения этих целей - и, наверное, мы наконец-то как
следуем выспимся ночью, пока над рутинными задачами будут трудиться боты.
В последней главе я рассуждаю о более широкой перспективе и будущем ИИ,
в том числе и ИИ-агентов, в сфере написания кода.

ГЛАВА 11

Не просто генерация кода: что стоит
ожидать от ИИ в будущем
Концепция вайб-кодинга сформировалась, когда искусственный интеллект стал
генерировать код по текстовым запросам, но она выходит далеко за рамки про­
стого написания кода. ИИ-технологии постоянно развиваются и обещают корен­
ным образом изменить все этапы жизненного цикла разработки ПО. В этой главе
рассматриваются гипотетические, но основанные на практическом опыте предпо­
ложения о дальнейшем расширении роли ИИ в области программного обеспече­
ния. Будут затронуты такие аспекты, как тестирование, отладка и сопровождение
на базе ИИ; влияние ИИ на дизайн ПО и персонализацию пользовательского опы­
та; управление проектами с участием ИИ-ассистентов и даже возможное будущее
самих языков программирования. Цель - показать возможное будущее, в кото­
ром ИИ будет играть роль не просто генератора кода, а полноценного участника
процесса разработки. При этом я буду ориентироваться на самые фундаменталь­
ные принципы, чтобы актуальность рассуждений сохранялась независимо от кон­
кретных технологий, на смену одним из которых постоянно приходят другие.

ИИ в тестировании, отладке и сопровождении
Представьте среду разработки будущего, в которой сразу после написания ка­
кой-либо функции (вручную или с помощью вайб-кодинга) ИИ-инструмент
мгновенно генерирует набор модульных тестов, находит потенциальные ошиб­
ки и даже исправляет их, и всё это за считаные секунды. Такой сценарий уже
выглядит вполне реалистичным. Поговорим о том, какой вклад ИИ способен
внести (и уже начинает вносить) в обеспечение качества и сопровождение ПО.

Автоматическая генерация тестов
На составление полноценных тестов требуется время, и часто из-за сжатых сро­
ков этой задачей пренебрегают. Как говорилось в главе 7, частично эту пробле­
му решают современные ИИ-ассистенты, генерирующие тесты автоматически.
272 1

Часть 111. Доверие и автономия

Получив фрагмент кода, ИИ предлагает набор модульных тестов, охватывающих
типовые сценарии, граничные случаи и ошибочные условия.
В перспективе ИИ сможет пойти и дальше: проанализировать всю кодовую
базу, выявить функции или модули с недостаточным покрытием тестами и сге­
нерировать дополнительные проверки. Он также может моделировать входные
данные, о которых человек-тестировщик обычно не догадывается (фазз-тести­
рование), и тем самым выявлять ошибки для редких, граничных сценариев. В ре­
зультате кодовая база становится более устойчивой при минимальных затратах
на ручное написание тестов.
Но здесь следует сделать важную оговорку: качество тестов напрямую зав и сит от того, насколько хорошо ИИ понимает спецификацию, поэтому сгенери­
рованные тесты стоит просматривать вручную и проверять, действительно ли
они соответствуют ожидаемому поведению системы. Например, ИИ может по­
метить результат теста как корректный, если выходное значение формально сов­
падает с логикой кода, но не соответствует требованиям. При наличии человека,
контролирующего вывод тестов, такие случаи даже бывают полезными, потому
что они помогают выявить слабые места либо в коде, либо в тесте.

Интеллектуальная отладка
Отладка часто сводится к утомительному поиску по логам или пошаговому выпол­
нению кода в попытке найти источник ошибки. В главе 5 говорилось о том, как ИИ
может выступать в роли умного напарника по отладке. Некоторые современные
инструменты уже принимают на вход сообщение об ошибке и проблемный код,
а на выходе выдают объяснение причины и предложения по исправлению кода.
Чтобы представить будущие сценарии отладки с помощью ИИ, рассмотрим
систему, которая следит за выполнением программы и при сбое или исключе­
нии анализирует стек вызовов и состояния переменных. Вместо сухого сообще­
ния об ошибке она, например, пишет:
Приложение завершилось с ошибкой, потому что переменная userProfi.les
при вызове getE111ai. l() приняла значение null. Это говорит о том, что при
загрузке профилей пользователей они не проверяются на null.
Далее ИИ предлагает исправление:
Возможное решение - инициализация userProfi. les, если она равна null,
или добавление условия перед вызовом getE111ai.l(). Воспользоваться та­
кой правкой?
Глава 11. Не просто генерация кода: что стоит ожидать от ИИ в будущем

273

ИИ-отладчики в будущем будут напрямую интегрироваться со средой вы­
полнения и перехватывать проблемы в реальном времени. Более того, они даже
научатся предсказывать ошибки ещё до их возникновения, анализируя возмож­
ные варианты выполнения кода:
Эта функция может выдать исключение Di.vi.si.onByZero, если будет вызва­
на с переменной у = 0; стоит добавить обработку этого случая.
Такое предсказание похоже на статистический анализ, но более гибкий и про­
думанный благодаря бесчисленным кодовым базам и шаблонам ошибок, на ко­
тором обучался ИИ.

Предсказательное обслуживание и рефакторинг
Со временем требования к ПО меняются, из-за чего код устаревает или пере­
стаёт быть оптимальным. Сопровождение кода подразумевает такие задачи, как
рефакторинг (улучшение структуры кода без изменения поведения), обновление
зависимостей и оптимизация производительности, и во всём этом может ока­
зать существенную помощь ИИ.
Рефакторинг
ИИ будущего сможет выявлять так называемый код с душком (code smells,
то есть проблемный код) - например, дублирование или чрезмерно длинные функции - и автоматически выполнять рефакторинr. Он будет обнару­
живать повторяющиеся фрагменты в разных местах и предлагать создать от­
дельную функцию вместо таких фрагментов. Либо он сможет переписывать
глубоко вложенные циклы для облегчения их читаемости. Так как ИИ обуча­
ется на большом количестве «хорошего кода», то он может предлагать и сти­
листические правки (https:!!oreil.ly!XWXC), помогающие поддерживать кодо­
вую базу в чистом виде и облегчающие её сопровождение. Не исключено, что
со временем в редакторах появится режим, при котором ИИ занимается не­
прерывным фоновым рефакторингом, а разработчик лишь просматривает
и одобряет изменения.
Обновление зависимостей
ИИ-инструменты будущего будут отслеживать зависимости проекта (библио­
теки и фреймворки), автоматически обновлять их версии и вносить прав­
ки в код с учётом этих новых версий. Например, если в новой версии веб­
фреймворка изменится API, ИИ адаптирует код под обновлённый интерфейс.
274

1

Часть 111. Доверие и автономия

В результате разработчики будут избавлены от рутинной работы и им не нуж­
но будет читать гайды по миграции и устранению проблем, связанных с вер­
сиями.
Оптимизация производительности
Сопровождение часто подразумевает улучшение производительности
по мере роста объёма данных или изменения сценариев использования ПО.
ИИ способен анализировать профили производительности и выявлять узкие
места в этой сфере. Например, он может заметить, что определённый запрос
к базе данных выполняется слишком долго, и предложить добавить индекс
или переписать запрос. Либо он может заметить, что цикл выполняет лиш­
ние вычисления, и порекомендовать кеширование. По сути, он может играть
роль эксперта по производительности, который постоянно следит за работой
приложения и выявляет неэффективные конструкции вроде лишних циклов
и неоптимальных структур данных.
ИИ может работать в тестовой среде, моделировать высокие нагрузки
и выдавать отчёт вида: «При большой нагрузке модуль Х становится про­
блемным местом из-за У. Предлагаю рефакторинг с использованием Z». Так
ИИ будет не только поддерживать код в оптимальном состоянии, но и об­
учать разработчиков лучшим практическим приёмам.

Дизайн и персонализация пользовательского опыта
В будущем ИИ не станет ограничиваться одним лишь написанием кода и проду­
мыванием логики; он будет влиять и на дизайн ПО, и на образ взаимодействия
с ним пользователей. Хорошее программное обеспечение - это не только кор­
ректная работа всех скрытых от глаз элементов программы, но и интуитивный
и доступный пользовательский интерфейс, а также приятные впечатления от его
использования. С помощью ИИ будут разрабатываться новые способы создания
удобных интерфейсов и новые схемы персонализации в соответствии с потреб­
ностями конкретного пользователя.

Инструменты генеративного дизайна
Современные ИИ-инструменты дизайна применяют методы генеративных со­
стязательных сетей или трансформеров для создания макетов интерфейсов
на основе текстового описания. Продакт-менеджер может, например, описать
функционал на естественном языке:
Глава 11. Не просто генерация кода: что стоит ожидать от ИИ в будущем 1 275

Нам нужен экран регистрации на мобильном устройстве с приветственным
сообщением, забавной иллюстрацией и полями для ввода имени, адреса
электронной почты и пароля. В дизайне должны использоваться фирмен­
ные цвета, и он должен выглядеть дружелюбно.
На основе такого описания ИИ- дизайнер за считаные секунды генерирует не­
сколько вариантов пользовательского интерфейса, включая расположение эле­
ментов, заполнители текста и даже компоненты стиля. Далее дизайнер или раз­
работчик выбирает самый подходящий вариант и дорабатывает его.
В будущем такие инструменты смогут интегрироваться прямо в дизайнер­
ские программы или даже в среду разработки, из-за чего будут размываться гра­
ницы между «дизайном» и «написанием кода для UI». ИИ сможет непосредст­
венно выдавать код в виде HTML/CSS или код на Flutter, что позволит сразу же
протестировать этот дизайн. Цикл итераций значительно ускорится. Вместо того
чтобы делать наброски вручную или в дизайнерской программе, люди будут со­
трудничать с ИИ, обученным на огромном массиве данных о том, что пользова­
телям кажется привлекательным и удобным.
И даже в сферах, в которых в первую очередь ценятся творческие способно­
сти, ИИ сможет выступать в роли «музы». В помощь дизайнеру, подбирающему
цветовую палитру или стиль иллюстраций, он будет создавать «доски настрое­
ний» или генерировать уникальные иконки. Например, дизайнер может задать
следующий запрос:
Мне нужен логотип, объединяющий идеи кода и музыки.
В ответ ИИ выдаст несколько вариантов логотипа, в котором объединены
символы из программирования (например, фигурные скобки) и музыкальные
ноты. Конечный вариант всё равно должен будет сделать профессиональный ди­
зайнер, но ИИ с его предложениями будет стимулировать творческий процесс
и ускорять этап исследования. По сути, ИИ превратится в быстро работающе­
го создателя прототипов и партнёра по творчеству, расширяющего возможно­
сти дизайнера.
Благодаря «дизайну с помощью ИИ» границы между дизайном и собственно
разработкой сгладятся; работа над дизайном и над кодом будет осуществлять­
ся одновременно. Разработчики смогут генерировать код интерфейса совмест­
но с ИИ и с дизайнерами. Разработчикам фронтенда не придётся тратить много
времени на подгонку макетов и на то, чтобы добиться корректного сочетания
дизайна с функционалом или с требованиями доступности. Повысятся и воз­
можности персонализации - можно будет писать код для нескольких вариантов
276

Часть 111. Доверие и автономия

дизайна, а далее ИИ на основе пользовательских данных будет выбирать нуж­
ный вариант и следить за тем, чтобы все варианты оставались производитель­
ными и надёжными.
В будущем вайб-кодинr, возможно, даже превратится в вайб-дизайн: доста­
точно будет задать нужную атмосферу (вайб) и описать стиль приложения, а ИИ
поможет воплотить идею в жизнь. Здесь уже речь идёт о целостном процессе
разработки с помощью ИИ, когда искусственный интеллект не только пропи­
сывает бэкенд-лоrику или запросы к базе данных, но и вместе с разработчиком­
человеком формирует весь пользовательский опыт.

ИИ и исследования в области пользовательского опыта
Один из аспектов дизайна заключается в том, чтобы понять поведение пользо­
вателей. ИИ способен анализировать данные о том, как люди пользуются при­
ложением (с учётом конфиденциальности) и выявлять возможные проблемы
и неоднозначные ситуации. Например, ИИ может заметить, что многие поль­
зователи наводят курсор мыши на какой-то определённый значок, думая, что
по нему можно щёлкать, тогда как на самом деле этот значок ничего не делает а это уже сигнал для исправления. Ещё один пример проблемы из области поль­
зовательского опыта (UX) - это когда пользователи из определённой демогра­
фической группы на каком-то шаге выходят из процесса, что говорит о том, что
этот процесс для них непонятен.
В будущем ИИ сможет моделировать взаимодействие пользователей с ПО
(на основе моделей их поведения) и предсказывать проблемы в сфере UX до того,
как с ними столкнутся реальные пользователи. Такая «виртуальная UХ-провер­
ка» поможет выявлять сложности с навигацией или непонятные для пользова­
телей фрагменты интерфейса ещё на этапе разработки, когда исправить их про­
ще всего.

Персонализированный пользовательский опыт
Персонализация уже давно стала модным термином, которым обычно обознача­
ют демонстрацию разного контента разным пользователям на основе их пред­
почтений или истории действий. ИИ может поднять персонализацию на но­
вый уровень и предлагать действительно уникальный контент и уникальный
интерфейс для каждого конкретного пользователя. Так, например, отслежи­
вающий работу приложения ИИ может заметить, что какой-то пользователь
чаще пользуется поиском, а не меню, и соответствующим образом адаптиро­
вать интерфейс - сделать строку поиска более заметной или заранее подгружать
Глава 11. Не просто генерация кода: что стоит ожидать от ИИ в будущем

277

результаты, которые пользователь захочет увидеть вероятнее всего - почти как
помощник, предугадывающий желания начальника.
Другой сценарий связан с доступностью: обнаружив, что пользователь поль­
зуется скринридером (программой чтения текста с экрана вслух), ИИ придёт
к выводу, что пользователь, по всей видимости, имеет проблемы со зрением,
и автоматически переключит приложение в режим с высокой контрастностью
и увеличенным шрифтом, с оптимизированными метками для скринридера а это уже больше того, на что способны статистические средства настроек до­
ступности. Проще говоря, программное обеспечение будет становиться всё бо­
лее адаптивным.
Представьте интернет-магазин, который меняет макет динамически: одни
пользователи видят сетку товаров, а другие - подробный список с описания­
ми, в зависимости от того, какой вариант привлекает их больше. По мере того
как ИИ экспериментирует и анализирует данные, изменения могут применять­
ся плавно и постепенно - нечто вроде тестирования в группах с выбором ва­
риантов, только на уровне каждого конкретного человека и в полностью авто­
матическом режиме.

Эволюция проджект-менеджмента с помощью ИИ
Разработка ПО - это не только код и дизайн, это также планирование, коор­
динация и принятие решений, то есть сфера ответственности менеджеров про­
ектов и лидеров команд. Здесь в игру могут вступить аналитические и прогно­
стические возможности ИИ, которые смогут серьёзно помочь в управлении
проектами, от распределения задач и оценки рисков до поддержки в принятии
ключевых решений. Как же ИИ поможет в этой сфере и как он изменит подход
к планированию и выполнению проектов? Рассмотрим следующие варианты:

Распределение задач
Хороший руководитель должен знать сильные и слабые места каждого разра­
ботчика и степень его занятости. ИИ-помощник смог бы проанализировать
историю коммитов, область экспертизы (например, знание определённых ча­
стей кодовой базы, над которыми часто работал этот сотрудник) и даже лич­
ные схемы продуктивности (кто-то лучше пишет код с утра, а кто-то - глу­
бокой ночью). На основе этих данных ИИ сможет распределять обязанности
и новые задачи.
Например, если при разработке нового функционала нужно поработать
с базой данных, а ИИ знает, что в последнее время именно Элис успешно
278

Часть 111. Доверие и автономия

справлялась с такими обязанностями и сейчас она не перегружена, он пору­
чит эту задачу ей. Более того, ИИ мог бы спрогнозировать сроки выполнения,
сравнив текущую задачу с похожими прошлыми с учётом индивидуальной
скорости разработчика. Такой ИИ поможет менеджерам проектов ставить
более реалистичные дедлайны и не перегружать членов команды. Со време­
нем он может научиться балансировать нагрузку почти как опытный менед­
жер, чтобы никто не простаивал и не выгорал.
Планирование спринтов и составление расписания
ИИ может помочь разбивать глобальные цели на конкретные задачи. Разра­
ботчики описывают ему некий функционал или пользовательскую историю,
а он предлагает список задач для реализации этой идеи. По сути, он может
создать черновик плана или структуру выполнения работ. Во время плани рования спринтов (согласно методике «эджайл») ИИ мог бы проанализиро­
вать бэклог и с учётом предыдущей скорости команды предложить набор
на следующий спринт.
Он мог бы даже показать зависимости между задачами и расположить их
в логическом порядке:

Задачу В нужно выполнять после задачи А, потому что она зависит от функ­
ционала предыдущей задачи.
При построении долгосрочных дорожных карт ИИ мог бы моделировать
различные сценарии:
Если сейчас отдать приоритет функционалу Х, то модель предсказывает
риск задержки реализации функционала У на две недели, потому что для
выполнения этих задач требуются общие ресурсы.
Такие симуляции и анализ на основе данных помогут людям-менеджерам
принимать обоснованные решения и правильно расставлять приоритеты.
Анализ рисков и управление рисками
Управление рисками (риск-менеджмент) - это в первую очередь умение
предвидеть проблемы, технические сложности, трудности интеграции; так­
же это планирование в целях смягчения этих проблем и сложностей. ИИ от­
лично распознаёт шаблоны, так что он мог бы проанализировать данные
прошлых проектов (внутри компании или даже отрасли, если такие данные
доступны) и определить все факторы риска.
Глава 11. Не просто генерация кода: что стоит ожидать от ИИ в будущем

279

Например, ИИ мог бы сообщить о следующих проблемах:
- Согласно историческим данным, в проектах со сменой технологическо­
го стека на 30% чаще срываются сроки.
- В последних трёх проектах мы срывали сроки на этапе интеграцион­
ного тестирования; скорее всего, риск повторится и для этого проекта.
На основе этих предупреждений менеджеры могли бы заранее выделить
дополнительное время и дополнительные ресурсы. Другое направление мониторинг текущего прогресса. ИИ -система может отслеживать скорость
выполнения задач, выявления новых багов и прочие показатели и выдавать
предупреждения вроде следующего:
Команда завершает задачи в два раза медленнее запланированного показа­
теля для этого спринта; возможно наличие проблем, требующих внимания.
В целом ИИ мог бы стать постоянным аудитором проекта, замечающим
проблемы до того, как они перерастут в кризисную ситуацию.

Поддержка принятия решений
В проектном менеджменте постоянно приходится принимать решения, на­
пример: «Урезать ли функционал, чтобы уложиться в сроки, или потратить
время на рефакторинг?» ИИ не может принимать такие решения самостоя тельно, потому что они слишком тесно связаны с бизнес-факторами и чело­
веческими факторами, но он может предоставить данные, которые помогут
обосновать решение.
Например, при обсуждении рефакторинга ИИ мог бы выдать такую оценку:
С учётом показателей сложности и вклада команды рефакторинг модуля
Z сократит время разработки связанных с ним функций примерно на 20%.
На данном этапе задержка составит около двух недель, но она окупится че­
рез полгода.
Такие цифры, конечно, будут приблизительными, но объективная анали тика поможет заинтересованным лицам более обоснованно взвешивать все
варианты и идти на компромиссы.
Другой типичный случай - выбор между сторонней библиотекой и соб­
ственной реализацией. ИИ может быстро изучить документацию, проанализировать активность сообщества, выявить известные проблемы библиотеки,
280

Часть 111. Доверие и автономия

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

Как идёт работа над интеграцией платежей? Есть ли какие-то помехи?
ИИ, проанализировав обновления задач, сообщения коммитов и резуль­
таты тестов, сможет ответить, например, так:
Интеграция платежей выполнена примерно на 70%. Сейчас есть одна за­
держка - падающий тест с конвертацией валют. Если проблему решить
к завтрашнему дню, функционал будет готов к пятнице.
Такой формат понятных статус-отчётов упрощает коммуникацию, осо­
бенно в больших командах или при работе с заказчиками, не разбирающими­
ся в технических деталях. ИИ, по сути, становится проект-ассистентом, зна­
ющим все подробности рабочего процесса и умеющим при необходимости
сжато и понятно их пересказывать.
Эмоциональное состояние и «здоровье» команды
Пусть это предположение и кажется пока немного фантастичным, но ИИ
мог бы на основании рабочих коммуникаций (с соблюдением конфиденциальности и личных границ, конечно же) оценивать психологическое состо­
яние и уровень стресса в команде. Например, ИИ мог бы заметить, что ком­
ментарии в код-ревью стали немного более резкими, а задачи в Jira всё чаще
«открываются заново», что свидетельствует о возможном нарастающем на­
пряжении; в этом случае ИИ мог бы деликатно предупредить руководителя
проекта о том, что стоит обратить внимание на психологическую атмосферу
в коллективе. Особенно полезным такой ИИ оказался бы в командах с уда­
лёнными работниками, где такие сигналы уловить сложнее. Разумеется, по­
добные механизмы требуют предельной аккуратности и прозрачности, чтобы
у работников не возникало ощущения, что за ними постоянно следят.

Во всех этих сценариях ИИ расширяет возможности руководителя проек­
та и действует как его помощник. Он берёт на себя трудоёмкий анализ и ру­
тинные рекомендации, благодаря чему человек-менеджер сосредотачивается
Глава 11. Не просто генерац�я кода: что стоит ожидать от ИИ в будущем

281

именно на том, что лучше всего получается у людей: принимает взвешенные
решения, повышает мотивацию команды и оценивает психологическое состоя­
ние сотрудников. Хорошее управление проектом - это в равной степени наука
и искусство. ИИ занимается «научной» частью, то есть данными, прогнозирова­
нием, аналитикой, чтобы ярче проявлялось «искусство»: лидерство, постанов­
ка общих целей, умение адаптироваться. Разработчикам такие перемены тоже
пойдут на пользу, потому что чёткие цели и хороший план означают меньше не­
приятных сюрпризов. А заодно и меньше времени на совещания по поводу со­
стояния проекта и меньше времени на обновление таблиц. Все технические дета­
ли берёт на себя ИИ, предоставляя людям больше возможностей на собственно
творчество.

Как автономные агенты изменят сферу разработки ПО
Мы находимся ещё в начале пути, но ИИ-технологии развиваются стремительно.
Уже сейчас стоит задуматься об их долгосрочных последствиях и о том, как всё
изменится в ближайшие годы. Далее я на основе текущих тенденций и на обос­
нованных предположениях описываю один из возможных сценариев развития
сферы разработки ПО в эпоху автономных агентов по написанию кода.
ИИ-агенты станут стандартной частью команды разработки
Участие ИИ-агентов в разработке ПО станет нормой, как сейчас нормой ста­
ли системы контроля версий и системы CI/CD. Вполне возможно, что каж­
дый рабочий день будет начинаться с просмотра «панели ИИ-ассистентов»,
то есть списка задач, выполненных за ночь агентами, и загрузки обзоров го­
тового для загрузки кода. Какие-то намёки на это уже есть - агенты, рабо­
тающие, «пока вы спите». В конце рабочего дня инженерные программисты
будут составлять пакеты делегируемых ИИ задач, ожидая получить результа­
ты на следующее утро. Изменится само представление о «труде разработчика
ПО»: меньше шаблонного кода и рутинных правок, больше определения про­
блем, интеграции решений и формулировок задач для ИИ. Если немного по­
фантазировать, можно сказать, что разработчики-люди станут чем-то вроде
продакт-менеджеров для ИИ-разработчиков, то есть они будут ставить зада­
чи и следить за соответствием результата требованиям.
Распространённой практикой станет взаимодействие агентов
Сейчас каждый агент в основном работает над поставленной ему задачей от­
дельно от других агентов. В будущем возможны сценарии, при которых будут
282

Часть 111. Доверие и автономия

совместно работать несколько агентов с разной специализацией. Допустим,
один лучше справляется с фронтендом, а другой - с бэкендом, и им пору­
чают скоординированную задачу (или они даже сами распределяют её ме­
жду собой). Другой вариант - параллельный перебор нескольких решений:
то, что Kojo (блоггер Kojo Osei) называет мультивариантным исследованием.
Можно представить ситуацию, когда ИИ получает сложную задачу, запу­
скает три подзадачи с разными подходами или архитектурами, а затем выби­
рает лучший вариант или предлагает выбрать дальнейшее направление че­
ловеку. Такой метод радикально сократит время на оценку альтернативных
реализаций, то есть на то, на что сегодня уходит несколько дней создания
прототипов силами нескольких программистов. Разумеется, такая оркестра­
ция - задача не из простых, но по мере развития агентных фреймворков она
будет выглядеть всё более достижимой.
Интеллектуальные контрольные точки остановки и обращение за помощью
к человеку
В будущем агенты станут настолько умными, что будут самостоятельно ре­
шать, когда обратиться за помощью человека в принятии важных решений.
Это не просто предположение - уже сейчас активно проводятся исследова­
ния в области оценки неопределённости и способности к рефлексии разных
больших языковых моделей (LLM). Некоторые результаты говорят о том, что
модели можно обучить или с помощью запросов заставить распознавать ситуации, когда они не уверены в ответе, и вместо того, чтобы действовать на­
угад, просить подсказку у человека. Например, в какой-то момент агенту придётся выбирать между двумя библиотеками, и вместо произвольного выбора
он может остановиться и спросить (примерно так же, как это сделал бы млад­
ший разработчик):

Здесь можно воспользоваться библиотекой А или библиотекой В. У вас есть
какие-то предпочтения?
Считается, что такие «интеллектуальные контрольные точки» повыша­
ют надёжность агентов: эти агенты начинают восприниматься не как чёрные
ящики, а как полноценные партнёры, участники команды. Такое поведение
хорошо согласуется с поведением людей в командах - с умением вовремя
спросить, вместо того чтобы делать вид, что что-то понимаешь. Технология
находится ещё на ранней стадии развития, но уже появляются модели с таким
поведением, то есть анализирующие инструменты, планирующие с учётом
порога неопределённости и обращающиеся за советами к пользователям
Глава 11. Не просто генерация кода: что стоит ожидать от ИИ в будущем

283

в процессе работы. Метод «интеллектуальных контрольных точек» требует
от агентов умения осознавать степень своей неуверенности; это сложная за­
дача, но исследователи активно работают в этой сфере, в том числе и над ана­
лизом уверенности и сомнений.
Улучшится взаимодействие человека с агентами (пользовательский опыт)
Чем больше работы будут передавать агенты людям, тем более важную роль
будет играть удобство взаимодействия с ними. Kojo предлагает концепцию
«входящего ящика агентов» (agent inbox), то есть единой формы представ­
ления всех задач для всех агентов, который бы сразу давал представление
о том, над чем агенты работают сейчас, что они уже сделали и где требует­
ся внимание человека. Это может быть дашборд со списком активных задач,
с их прогрессом («выполнено 3 из 5 шагов», «ожидает ревью») и с результа­
тами работы.
Вместо нынешней разрозненной мешанины из логов и пул-реквестов по­
явится понятный интерфейс управления агентами. Например, в IDE может
появиться боковая панель «Агенты» со списком активных задач и лентой об­
новлений. Там же могут отображаться всплывающие уведомления вроде сле­
дующих:
- Агент Х завершил задачу У и открыл PR #123.
- Агент Z ожидает вашего решения, чтобы продолжить.
Подобная инфраструктура крайне важна для масштабирования задач
с использованием агентов и для сохранения контроля над ними. Вряд ли ко­
му-то захочется запускать десяток молчаливых ботов, которые делают непо­
нятно что и которыми невозможно управлять из единого места.
Агенты будут интегрированы с трекерами задач и системами непрерывной ин­
теграции (CI)
Можно представить себе ещё более продуктивную ситуацию, когда зада­
ча в трекере (Jira, GitHub Issues, Linear) обрабатывается агентом полностью.
На такую возможность уже намекает интеграция CodeGen с Linear. Процесс
может выглядеть следующим образом:

284

1.
2.
3.
4.

Продакт-менеджер создаёт «тикет» с техническим заданием.
Разработчик или руководитель команды поручает эту задачу ИИ.
ИИ-агент выполняет её и прикрепляет к тикету пул-реквест.
Человек проверяет и тестирует код, после чего закрывает тикет.

1

Часть 111. Доверие и автономия

Так обеспечивается непрерывность процесса. Аналогичным образом при
неудачных тестах могут автоматически запускать агентов и системы непре­
рывной интеграции (CI). Например, если во время сканирования безопас­
ности будут выявлены какие-либо уязвимости, агент попытается обновить
проблемную библиотеку или переписать рискованный код, а затем создать
пул-реквест с исправлением. Либо же, если покрытие кода тестами после
пул-реквеста опускается ниже определённого порога, агент может сгенери­
ровать дополнительные тесты. По сути, это автоматизированное сопрово­
ждение кода.
Для примера стоит упомянуть, что Dependabot уже сейчас создаёт пулреквесты для обновления зависимостей. ИИ-агент мог бы не только созда­
вать пул-реквесты, но и исправлять весь код, который сломался после обнов­
ления, запускать тесты и убеждаться, что всё работает. Это будет своего рода
«прокачанный» Dependabot.
Улучшенные модели сократят «разрыв в 30%»
Большие ИИ-модели (GPT-4, Gemini, Claude и им подобные) будут всё лучше
понимать код и генерировать его. По мере роста их возможностей может ис­
чезнуть упомянутая ранее «проблема 30%»: агенты почти всегда будут поль­
зоваться подходящими фрагментами кода повторно и не будут упускать гра­
ничных случаев, так как будут обучены на большем количестве сценариев
и будут обладать более продвинутым логическим мышлением.
По мере улучшения моделей агенты будут реже ошибаться, будут требо­
вать меньше контроля и смогут справляться с более сложными задачами. Од­
нако разработка ПО - это по своей природе сложная сфера, и она останется
сложной, так что устранить участие человека, по всей видимости, не полу­
чится никогда - пусть и не для «последних 30% )), а для «последних 5-10%)),
Я также ожидаю роста эффективности моделей, благодаря чему те, кто
беспокоится о конфиденциальности данных или о стоимости процесса, смо­
гут запускать локальных или своих собственных агентов. Модели с открытым
исходным кодом догонят лидеров, и локальные агенты станут такими же по­
лезными для многих задач, как и крупные облачные решения.
Агенты и инструменты станут более специализированными
В будущем могут появиться специализированные агенты для разных обла­
стей или ролей. Например, агент «Фиксатор багов», который будет находить
ошибки по упавшему тесту или логам, агент «Гуру производительностю>, со­
средоточенный на профилировании и оптимизации «узких мест», или агент
для генерации документации и комментариев на основе существующего кода.
Глава 11. Не просто генерация кода: что стоит ожидать от ИИ в будущем

285

Специализация позволяет агентам использовать больше знаний и инстру­
ментов, специфичных для конкретной области. Появятся агенты, интегри­
рованные с игровыми движками для разработки игр, или агенты, хорошо
справляющиеся с пайплайнами обработки данных. Такой «командный» на­
бор узкоспециализированных ИИ будет напоминать распределение людей­
экспертов в команде, когда одни разработчики занимаются фронтендом,
а другие инфраструктурой. Можно даже представить себе целую команду
ИИ-агентов, каждый из которых занимается вопросами документации, те­
стирования, рефакторинга и безопасности. В Cursor, например, уже имеется
агент BugBot для автоматического ревью пул-реквестов, который не пишет
код, а комментирует реквесты и указывает на возможные базы подобно «про­
качанному» статистическому анализатору.
Изменится культура разработки и набор навыков разработчика
Если агенты будут всё больше брать на себя рутинные задачи по созданию
кода, большее значение приобретут навыки дизайна, построения архитек­
туры и контролирования процессов (как об этом говорилось в главе 4). Ещё
важнее станут «мягкие навыки», такие как умение чётко формулировать тре­
бования (как для людей, так и для ИИ). Навыки чтения и ревью кода, пожа­
луй, станут такими же необходимыми для разработчика, как и умение писать
код. Возрастёт значимость тестирования, потому что тесты - это важнейший
инструмент проверки результатов работы ИИ, так что специалисты, умею­
щие составлять хорошие тесты (или руководить ИИ, генерирующим хорошие
тесты), останутся востребованными.
Как говорилось при обсуждении «проблемы последних 30%», на долю че­
ловека остаются задачи, требующие высокоуровневого критического мыш­
ления, и задачи по контролю за ИИ. По всей видимости, изменится и путь
становления начинающих разработчиков. Возможно, для начала им будут
поручать управлять ИИ-агентами для выполнения простых задач, и толь­
ко потом они перейдут к активному написанию кода. С одной стороны,
это плюс (младшие сотрудники смогут быстро приносить пользу), но с дру­
гой - это дополнительные сложности (им придётся осваивать навыки об­
ращения с ИИ и не воспринимать его как универсальное средство решения
всех проблем). Сейчас отличное время для тех, кто готов адаптироваться,
но непростое для тех, кто предпочитает работать по старинке. Как отмеча­
лось в главе 4, в настоящее время лучше подстраховаться и освоить ИИ-ин­
струменты, одновременно делая акцент на своих уникальных и сильных че­
ловеческих качествах.

286

Часть 111. Доверие и автономия

Появятся новые роли и процессы
В командах программистов могут возникнуть новые роли вроде «специалист
по работе с ИИ» или «ведущий специалист по автоматизации», то есть роли
специалистов, умеющих эффективно пользоваться И И-агентами, проекти ровать рабочие процессы с их участием и настраивать их. В чём-то это по­
хоже на то время, когда с усложнением систем сборок появились «инженеры
по сборкам и релизам» или с ростом автоматизации инфраструктуры появи лись «инженеры по DevOps». Также стандартной частью ревью может стать
аудит сгенерированного ИИ кода на паттерны уязвимости.
Больше внимания, по всей видимости, будет уделяться культуре тестиро­
вания. Например, для дополнительной уверенности каждый составленный
ИИ пул-реквест перед слиянием должен будет дополняться тестами (напи­
санными агентами или человеком). Для более надёжной проверки написан­
ного ИИ-кода людям придётся писать больше тестов самостоятельно (воз­
можна и обратная ситуация, когда ИИ будет генерировать свои тесты для
проверки кода, написанного людьми).
В целом, будущее с фоновыми ИИ-агентами может выглядеть примерно так:
разработчики координируют и проверяют работу, а ИИ-агенты выполняют и ре­
ализуют задачи (см. иллюстрацию 11.1). Программная инженерия от выполне­
ния каждого шага вручную может сместиться в сторону управления «флотою>
автоматизированных агентов. Смена парадигмы открывает возможности для по­
вышения продуктивности, снижает объём рутинной работы и позволяет коман­
дам заниматься техническим долгом и поддержкой, на которые раньше не хва­
тало времени. (Представьте себе ситуацию, когда все задачи по исправлению
мелких багов и несоответствий можно просто поручить ИИ!) Также, возмож­
но, снизится порог для создания прототипов идей: ИИ может набросать прото­
тип в виде отдельного приложения, а человеку останется лишь доработать его.
Благодаря быстрой генерации альтернативных реализаций можно будет рассмо­
треть больше вариантов перед принятием окончательно решения.
Вместе с тем все эти изменения нужно внедрять осторожно. Огромную роль
продолжит играть человеческий фактор благодаря таким присущим людям ка­
чествам, как креативность, интуиция и этический взгляд на вещи. Да, ИИ рас­
ширяет наши способности, но без надлежащего контроля он может как увели­
чить количество ошибок, так и сделать их более опасными.
Я смотрю в будущее с оптимизмом: при разумном подходе автономные агенты по написанию кода повысят продуктивность разработчиков и позволят им
сосредоточиться на более сложных и увлекательных вопросах разработки, что

Глава 11. Не просто генерация кода: что стоит ожидать от ИИ в будущем

287

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

1
Будущее

ИИ-дизайнер

ИИ-программист ИИ-специалист ИБ
Применить
и протестировать

Иллюстрация 11.1. Мультиагентная архитектура (сотрудничество
агентов): разработчики руководят оркестрацией специализированных
ИИ-агентов, занимающихся тестированием, дизайном, написанием
кода и проверкой кода на безопасность. Все эти специализированные
агенты сообща создают полноценный программный продукт

Будущее языков программирования и возможность
разработки на основе естественного языка
Один из самых интригующих вопросов о будущем вайб-кодинга - это его воз­
можное влияние на языки программирования. Если можно «просто сказать ИИ,
что нам нужно», то останется ли потребность в традиционных языках програм­
мирования с традиционным синтаксисом? Станет ли новым языком программи­
рования английский (или любой другой естественный язык, на котором говорят
люди)? Поговорим в этом разделе о возможных вариантах развития.
Уже сейчас видно, что естественный язык может выступать в роли своеобраз­
ного кода: достаточно описать задачу простыми словами, а нужный код напишет
ИИ. Если эта тенденция продолжится, суть работы программиста-человека сдви­
нется ближе к формулировке намерений и требований и отдалится от собственно
288

1

Часть 111. Доверие и автономия

реализации. В средах разработки будущего программистам (и не программи­
стам) достаточно будет написать нечто вроде следующего:
Каждый час проверяй базу данных на предмет неактивных пользователей
и с помощью шаблона Х отправляй им напоминание по электронной поч те о том, что они не заходили в систему на протяжении последних 90 дней.
Если придёт ответное письмо с сообщением об ошибке, пометь электрон­
ный адрес в базе данных как недействительный.
ИИ превратит это задание в рабочий код (например, настроит планировщик
задач, напишет SQL-запросы или будет работать с базой данных посредством
ОRМ, вызовет API для отправки писем). Итак, роль программиста всё больше
заключается в том, чтобы описывать правила и поведение системы.
Это не значит, что языки программирования сразу возьмут и исчезнут. Ско­
рее всего, сформируется некая многоуровневая модель: на верхнем уровне будет
естественный язык для описания намерений и общей логики, а «под капотом» привычные языки программирования для точного контроля над реализацией.
Одна из причин, по которой вообще существуют языки программирова­
ния, - это неоднозначность естественного языка. Если полностью отказаться
от формальных языков, человеку будет труднее общаться с машиной. ИИ мо­
жет отчасти компенсировать такое недопонимание, уточняя смысл по контексту
и задавая наводящие вопросы, но всё равно до конца сделать он это не сможет:
сложные алгоритмы или схемы оптимизации часто требуют настолько точных
указаний, что гораздо легче выразить их в коде, чем во фразах на естественном
языке. Отсюда можно предположить, что программисты будущего в некотором
смысле станут «двуязычными»: для общения с ИИ они будут свободно формули­
ровать задачи на естественном языке, но одновременно они будут хорошо разбираться в тех технических концепциях, которые подразумевают эти задачи, что­
бы проверять результат работы ИИ и дорабатывать его.
В будущем также, возможно, появятся предметно-ориентированные есте­
ственные языки - формализованные и ограниченные варианты английско­
го (или других языков), лишённые двусмысленности, дающие ИИ понятные
указания и ориентированные на какие-то конкретные области разработки.
Так, например, некий «язык требований» для описания сценариев использо­
вания ПО, чтобы ИИ автоматически превращал эти текстовые описания в те­
сты или код.
Даже если дело и не дойдёт до полноценного программирования на естест­
венном языке, влияние ИИ почти наверняка подтолкнёт языки программиро­
вания к более высоким уровням абстракции. Исторически мы уже проходили
Глава 11. Не просто генерация кода: что стоит ожидать от ИИ в будущем

289

этот путь: от ассемблера к языкам высокого уровня, от ручного управления па­
мятью к средам с автоматической сборкой мусора, и каждый такой шаг повышал
уровень абстракции. В случае с ИИ можно пойти чуть дальше и позволить ему
определять абстракции по мере обработки запросов. Такой подход в той книге
не раз назывался «программированием с намерением»: разработчик формули­
рует цель, а ИИ сам подбирает способ её реализации, при необходимости гене­
рируя код на языке более низкого уровня.
Возможен и другой сценарий, а именно появление гибридных языков, сочета­
ющих в себе естественный язык и код. Например, в будущем код вполне может
выглядеть примерно следующим образом:
// Создай список им@н клиентов из заказов, убери дубликаты,
// отсортируй по алфавиту и выведи результат.
ltst<Custoмer> custoмers = orders -> мар(огdег -> order.custoмerNaмe)
-> untque()
-> sort()
-> prtnt();

В этом примере на псевдокоде для ИИ будет достаточно одного комментария.
В реальной среде, возможно, синтаксис с лямбда-выражениями вообще не по­
надобится и ИИ сможет вывести нужную логику напрямую из комментария.
Либо же язык будет включать конструкции, внешне похожие на обычный текст,
но при этом достаточно формальные, чтобы ИИ мог их интерпретировать од­
нозначно. По сути, это будет эволюция комментариев и псевдокода в полноцен­
ный исполняемый код, интерпретируемый с помощью ИИ.
Программирование уже сейчас становится более диалоговым. Вместо того
чтобы сразу писать законченный код, разработчик вступает в диалог с ИИ.
Запрос: «Нужна функция для расчёта бонусных баллов лояльности на осно­

ве истории покупок клиента».
ИИ: «Хорошо. Все товары учитываются одинаково или для некоторых ка­
тегорий нужно назначать больше? И как учитывать фактор времени? Что
важнее - недавние покупки или старые?»
Запрос: «Электроника даёт вдвое больше баллов, чем другие категории. По­
купки за последний месяц получают бонус + 10%».
ИИ: «Понял. Вот функция, которая это реализует... [ИИ показывает код].
Сгенерировать тесты для разных сценариев?»
Запрос: «Да, и учти случай, когда истории покупок нет вовсе - тогда дол­
жно возвращаться О баллов».
290

Часть 111. Доверие и автономия

В этом сценарии программирование превращается в диалог на естественном
языке, в ходе которого ИИ пишет код и задаёт уточняющие вопросы. Он по­
хож на сценарий парного программирования, только в роли напарника высту­
пает ИИ. Первые версии такого сценария уже предлагают ChatGPT с плагина­
ми, Copilot Chat и другие похожие инструменты. В перспективе он может стать
основным способом создания программ: вместо того чтобы писать вручную код
с нуля, разработчик вступает в диалог с ИИ, в ходе которого программа посте­
пенно уточняется и дорабатывается. Это гораздо более гибкий и живой способ
по сравнению с традиционным жёстким процессом.
Но несмотря на то, что разработка в очень большой степени будет опирать­
ся на естественный язык, вряд ли разработчикам вообще не нужно будет по­
нимать, как работают компьютеры и как работает код. Эти знания остаflутся
очень важным фактором. Калькуляторы и электронные таблицы не заставили
математиков и бухгалтеров забыть арифметику - люди по-прежнему должны
иметь представление об арифметических операциях и о том, как производятся
расчёты. Точно так же нужно распознавать моменты, когда ИИ выдаёт неверный
результат. Если ИИ неправильно поймёт формулировку на английском, опыт­
ный разработчик может показать пример на псевдокоде или на конкретном языке программирования и явно задать логику. Да, помнить все подробности син­
таксиса, возможно, уже и не будет нужно (не обязательно запоминать точный
порядок параметров API, если их подставляет ИИ), но среди необходимых для
программиста навыков останутся алгоритмическое мышление и навык отладки.
Языки меняются, но логика и умение решать задачи - нет.
При этом порог для входа в программирование уже снижается. Неспециа­
листы и эксперты в своих областях уже могут сами создавать простые прило­
жения, общаясь с ИИ в режиме вайб-кодинга. Такая демократизация выгля­
дит многообещающей, ведь она помогает многим людям создавать нужные им
программные приложения без глубоких знаний программирования. Профес­
сиональные же разработчики сосредоточатся на более важных задачах, будут
дорабатывать такие «непрофессиональные скрипты» с учётом требований без­
опасности или создавать платформы для такого взаимодействия машин и поль­
зователей.
Чем больше ИИ-модели будут помогать нам писать код, общаясь с нами на ес­
тественном языке, тем вероятнее они сами сформируют какие-то свои новые
«языки», находящиеся где-то посередине между естественными языками и язы­
ками программирования. Возможно, появятся новые парадигмы программи­
рования, изначально ориентированные на ИИ, предоставляющие ИИ некото­
рую свободу действий и возможность автоматического завершения - например,
допускающие некие «заглушки» в тексте, которые будет заполнять ИИ (здесь
Глава 11. Не просто генерация кода: что стоит ожидать от ИИ в будущем

291

нужна оптимизация по скорости), или с расплывчатыми определениями, кото­
рые ИИ будет доводить до строгой, детерминированной логики.
В итоге английский и другие естественные языки вряд ли полностью вытес­
нят языки программирования. Скорее, произойдёт их слияние: у разработчиков
появится больше выразительных средств, а общение с компьютером станет бо­
лее интуитивным. Как метко отметил Андрей Карпатый, «смысл программиро­
вания будущего - это, пожалуй, уже не создание идеального кода. Это идеаль­
ное объяснение того, что тебе нужно». Суть программирования -умение ясно
сформулировать задачу и найти её рабочее решение - сохранится. Форма же его
станет более естественной; ИИ будет выступать в роли переводчика, передающе­
го наши «высокоуровневые намерения» в виде низкоуровневого кода.
Будущее открывает перед нами грандиозные возможности. Это и гораздо более
быстрая разработка, и доступность программирования, и создание более сложных
систем, соответствующих нашим намерениям, без необходимости уделять внима­
ние каждому символу кода. Как это бывало и раньше, очередной шаг в сторону аб­
стракции порождал целый взрыв креативности (высокоуровневые языки позво­
лили разрабатывать масштабные приложения, создавать которые на ассемблере
было бы невозможно). Разработка на основе естественного языка запустит целую
волну инноваций, и в авангарде её будут вайб-кодеры, буквально порождающие
целые миры на основе описаний и нового программного обеспечения.

Как вайб-кодинг меняет индустрию
На протяжении всей книги был сформулирован ряд ключевых принципов
и идей.
Намерение важнее реализации
Вайб-кодинг сдвигает фокус с поэтапного написания кода к выражению наме­
рения или описанию нужного результата, детали реализации которого переда­
ются на усмотрение ИИ. Эта концепция меняет весь подход к решению задач:
теперь мы больше задумываемся о том, что хотим получить, и меньше о том,
как именно это сделать. Это более высокоуровневый подход к разработке ПО.
ИИ - это партнёр и коллега
ИИ в вайб-кодинге начинает восприниматься не как отдельный инструмент,
а как программист-напарник, коллега или помощник. С ним работают инте­
рактивно. Мы видели, как важно правильно организовать весь процесс. Люди
руководят ИИ с помощью запросов (так называемого промпт-инжиниринга)
292

Часть 111. Доверие и автономия

и проверяют результаты его работы. Так мы объединяем наши сильные сто-.
роны с сильными сторонами ИИ. Будущее - это не замена программистов
искусственным интеллектом, а повышающая продуктивность совместная ра­
бота программистов и ИИ (https:!!oreil.ly!OuP00).
Важность этики и ответственности
Как было сказано, большие возможности ИИ подразумевают и большую от­
ветственность. Устранение дискриминации и несправедливости, повыше­
ние прозрачности, гарантия безопасности - всё это очень важно. Индустрия
признаёт, что ИИ без ограничений может порождать проблемы, поэтому ча­
стью стандартных процедур становится проверка результатов ИИ, упомина­
ние об использовании ИИ в документации и решение юридических вопросов
(например, проблемы авторства сгенерированного ИИ-кода).
ИИ - это не только генерация кода
Роль ИИ охватывает такие сферы, как тестирование, отладка, дизайн, проект­
менеджмент и многие другие. Комплексная интеграция ИИ во все процессы
ускоряет разработку и улучшает весь жизненный цикл ПО. ИИ-инструмен­
ты всё чаще внедряются на разных этапах разработки - например, некото­
рые уже генерируют тесты в IDE, а другие помогают составлять план проекта.
Навыки меняются, фундамент остаётся
Пользующиеся ИИ программисты увидят, как развиваются и меняются их
навыки; к традиционным навыкам писать код на языке программирова­
ния и умению пользоваться алгоритмами добавляются навыки промпт­
инжиниринга, умение контролировать работу ИИ и анализировать данные,
навыки высокоуровневого дизайна. Определяющим фактором остаётся кри­
тическое мышление для решения задач, но повседневные задачи программи­
ста меняются.
Вместе с тем базовые требования сохраняются: они должны разбирать­
ся в своей предметной области, уметь составлять спецификации (запросы это тоже, по сути, спецификации), уметь тестировать ПО и ориентировать­
ся на потребности пользователей. ИИ не отменяет все эти фундаментальные
требования; он, скорее, даже повышает их значение, потому что из-за чрез­
вычайной скорости работы ИИ любая неоднозначность может обернуться
критической ошибкой.
Вайб-кодинг, как новый принцип работы, меняет индустрию на практическом
уровне. Коллективы разработчиков, в которых внедряются ИИ-инструменты,
Глава 11. Не просто генерация кода: что стоит ожидать от ИИ в будущем

293

отмечают значительный рост продуктивности; при тех же ресурсах, что и рань­
ше, они успевают быстрее реализовывать функционал или завершать более
сложные проекты. Вайб-кодинг снижает входные барьеры: менее опытные раз­
работчики с помощью ИИ достигают большего и часто быстрее повышают свою
квалификацию. Опытных разработчиков ИИ стимулирует развиваться дальше,
расширять горизонты и не довольствоваться привычными схемами работы.
Компании начинают нанимать сотрудников, оценивая не только их знания,
но и их «ИИ-грамотность», то есть умение эффективно пользоваться ИИ-ин­
струментами. В ближайшем будущем в описаниях вакансий и в откликах на них
будет упоминаться знакомство с ИИ-ассистентами по написанию кода - точно
так же, как сейчас упоминается знание систем контроля версий или знакомст­
во с облачными платформами. Первопроходцы вайб-кодинга получают карьер­
ное преимущество.
Важно и то, что вайб-кодинг в какой-то степени превращает программиро­
вание в более демократичное занятие. Сейчас создавать свои приложения начинают даже те, кто раньше об этом не задумывался и кто раньше не занимался
программированием на профессиональном уровне - для этого достаточно все­
го лишь описать желаемый результат. Такой подход открывает экспертам в своих
областях огромные возможности для создания нишевого и высокоспециализи­
рованного ПО. Профессиональные разработчики при этом будут дорабатывать
базовые компоненты, чтобы получившимся надёжным приложением можно
было безопасно пользоваться.
Мы живём в поистине захватывающую эпоху и стоим на пороге впечатляю­
щих перемен, характер которых во многом предстоит определять именно нам,
разработчикам. Вспомните ранние этапы развития вычислительной техники,
вспомните, как персональные компьютеры произвели настоящую революцию
и как те, кто их освоил, создали мир, окружающий нас сегодня. В наши дни та­
кая же точка перелома - это появление и развитие ИИ. Приняв его и освоив
способы работы с ним, мы сформируем мир разработки ПО на несколько деся­
тилетий вперёд.

Итоги и дальнейшие шаги
Будущее программирования - это не просто то, с чем нам придётся жить или
придётся смириться; это то, что создаём мы сами. Каждый из нас, разработчи ков, определяет будущее вайб-кодинга, будущее ИИ-инструментов, их регулиро­
вание и их развитие. Вот мой призыв к действию, обращённый к вам, как к чи­
тателям и как специалистам.
294

Часть 111. Доверие и автономия

Экспериментируйте
Не ждите готовых ответов. Пробуйте заниматься вайб-кодингом в разных
ситуациях и в разных контекстах. Пользуйтесь ИИ для создания чего-то но­
вого и необычного. Расширяйте возможности ИИ-инструментов. Возможно,
именно вы обнаружите какой-нибудь новый, ещё не задокументированный
способ их использования. Любой, даже неудачный эксперимент приносит
пользу всему сообществу.
Делитесь результатами
Пишите о своём опыте или хотя бы обсуждайте его с коллегами. Найдя эффек­
тивную технику, опубликуйте её описание. Столкнувшись с какими-то подвод­
ными камнями, предупредите о них других. Обмен знаниями и опытом в усло­
виях такой быстрой эволюции помогает всем разработчикам идти нога в ногу
и держать руку на пульсе перемен. Так вы сэкономите кому-то дни на отладку
или вдохновите кого-нибудь на создание оригинального проекта с помощью ИИ.
Вносите свой вклад в развитие инструментов
При желании вносите свой вклад в развитие самих ИИ-инструментов - на­
пример, пишите код для каких-нибудь открытых ИИ-фреймворков или про­
сто отправляйте свои отзывы разработчикам инструментов (многие из них
очень даже заинтересованы в предложениях по улучшению со стороны поль­
зователей). Помогая развивать инструменты, вы напрямую влияете на своё
будущее и будущее всей индустрии. Многие современные ИИ-ассистенты
по написанию кода достигли высокого уровня именно благодаря тестиров­
щикам бета-версий и отзывам других разработчиков, таких же, как и вы.
Станьте проповедником перемен
Станьте активными проповедниками идей использования ИИ в своих организа­
циях и коллективах, обучайте коллег и сотрудников правильной работе с ними
в целях повышения продуктивности. Советуйте менеджерам выделять время
на изучение ИИ-инструментов и обновлять правила, которые из-за непонима­
ния этих инструментов ограничивают или запрещают их использование. Пока­
зывайте на своём примере, как можно ими пользоваться эффективно и безопасно.
Чем больше успешных примеров, чем больше достижений, сделанных с помощью
ИИ-инструментов, тем активнее они будут внедрятся по всей индустрии.
Не переставайте учиться
Настройтесь на то, что в эту новую эпоху мы все ученики. Будьте готовы вос­
принимать любые новые знания, не довольствуйтесь уже достигнутым вами
Глава 11. Не просто генерация кода: что стоит ожидать от ИИ в будущем

295

уровнем. В недалёком будущем младшие разработчики уже с самого нача­
ла будут обладать большими знаниями в этой сфере (подобно тому, как ны­
нешние выпускники учебных заведений с самого детства были погружены
в культуру написания кода, и у них больше практического опыта, чем было
у некоторых программистов прошлого). Будьте готовы учиться у любого, не­
зависимо от его опыта, ведь эта сфера новая для всех нас. Сохраняя мента­
литет ученика, вы будете постоянно развиваться и идти в ногу со временем.
При всём энтузиазме сохраняйте бдительность
При всём положительном настрое и энтузиазме, вдохновляющем других,
не забывайте о предусмотрительности. Не позволяйте успехам вскружить
вам голову, не увлекайтесь, не подумав как следует, слишком фантастической
и яркой целью. Разрабатывая приложения с помощью ИИ, не забывайте о мо­
дульных тестах и о ревью сгенерированного ИИ-кода. Ваша предусмотри­
тельность покажет другим, что вайб-кодинг имеет право на существование
и что ему стоит доверять.
Станьте наставником следующего поколения
Освоив новые инструменты, помогайте новичкам. Вайб-кодинг снижает по­
рог входа, и всё больше людей начинают заниматься программированием.
Им нужно будет освоить базовые принципы, то есть то, что раньше делалось
вручную, а теперь на себя автоматически берёт ИИ. С вашей помощью следу­
ющее поколение разработчиков может стать более самостоятельным, не за­
висящим во всём от подсказок ИИ. Заодно вы покажете им различные прак­
тические приёмы, польза от которых только усилится при содействии ИИ.

Редко в какие времена наблюдается настолько экспоненциальное развитие
какой-либо технологии, и нам нужно воспользоваться всеми предоставляемы­
ми ею возможностями. Вспомните предыдущие технологические скачки, от про­
мышленной революции до интернет-бума: активно участвовавшие в них люди
заложили основы целых индустрий. Сейчас мы наблюдаем подобный перелом­
ный момент в сфере разработки ПО с помощью ИИ. Речь идёт не только о том,
чтобы сохранить работу или облегчить её, речь о том, чтобы принять участие
в процессе развития технологий и определить их влияние на общество.
Прочитав эту книгу, вы доказали, что умеете мыслить с заделом на будущее.
Теперь я призываю вас перейти к активным действиям. Каждая строка· кода, на­
писанная с помощью ИИ, каждый сформулированный вами запрос, каждый об­
ученный вами коллега, каждое правило, в создании которого вы участвовали всё это определяет будущее вайб-кодинга.
296

Часть 111. Доверие и автономия

Вот вам в заключение ещё один совет: помните, что программирование в сво­
ей основе всегда было творческим занятием, посвящённым решению задач.
Вайб-кодинг при участии ИИ - невероятно мощный инструмент, но это всего
лишь средство достижения творческой цели. Относитесь к нему с энтузиазмом
и любопытством. Пользуйтесь им для создания чего-то действительно значимого. Не забывайте о человеческих качествах, ценностях, вдохновении.
Будущее программирования рождается здесь и сейчас - не только благода­
ря генерируемому ИИ-коду, но и благодаря нашему выбору, нашему общению
с искусственным интеллектом как с коллегой и партнёром. Это путь к чему-то
захватывающему и неизвестному, и каждый из нас может стать первопроходцем.
Смело шагайте вперёд, экспериментируйте, ведите за собой, руководствуясь сво­
ими лучшими человеческими качествами, разумом и духом. Так вы не просто
приспосабливаетесь к будущему - вы активно формируете его.
Удачного вам вайб-кодинга, и увидимся в будущем, которое вы поможете со­
здать!

Об авторе
Эдди Османи - старший инженер в Google, ответственный за такие сферы, как
опыт разработчика, производительность труда и инструменты разработки про­
граммного обеспечения с помощью ИИ. Это специалист с двадцатипятилетним
стажем в индустрии веб-технологий и автор нескольких книг, посвящённых ме­
тодам разработки программного обеспечения.
Эдди Османи активно занимается ИИ-инструментами для разработчиков,
тестируя и оценивая новые платформы, такие как Cursor, Cline, Copilot, Bolt, vO,
LovaЫe и Claude Code. Его статьи о разработке ПО с помощью ИИ повлияли
на тысячи разработчиков; как один из руководителей проекта Google Chrome,
он помог улучшить скорость и эффективность веб-браузера, а также помог вне­
дрить в процессы ИИ-инструменты, упрощающие работу разработчиков и по­
вышающие их продуктивность.
В этой книге он делится своим большим опытом в программировании и рабо­
те с ИИ-ассистентами по написанию кода, показывая разработчикам, как поль­
зоваться ИИ в повседневной работе и успешно приспосабливаться к быстро ме­
няющемуся миру разработки ПО.

Оформление книги
На обложке книги изображены краснокрылые стенолазы (Тichodroma muraria) вид птиц, обитающих на утёсах и горных вершинах в Европе, на Ближнем Во­
стоке и в Азии. В полёте их сравнивают с большими бабочками, но на фоне скал
они с трудом различимы. Крылья у них насыщенного красного цвета с чёрными
и белыми пятнами на кончиках, а туловище в основном голубовато-серое. Отли­
чительный признак взрослых самцов - чёрное оперение на шее.
Взрослые птицы достигают примерно 15 см в длину и весят около 17 г. Они
выводят одно потомство в год, откладывая по три - пять яиц в чашеобразные
гнёзда из мха и травы в расщелинах скал. Питаются насекомыми.
В Красной книге МСОП вид краснокрылых стенолазов упомянут как «вы­
зывающий наименьшие опасения» (Least Concern). Многие животные, изобра­
жённые на обложках книг O'Reilly, находятся под угрозой исчезновения; все они
важны для нашего мира.
Иллюстрацию на обложке создал Хосе Марсан-младший по мотивам старин­
ной гравюры из книги Royal Natural History Ричарда Лидеккера. Дизайн серии
разработали Эди Фридман, Элли Фолькхаузен и Карен Монтгомери. На облож­
ке использованы шрифты Gilroy Semibold и Guardian Sans. Основной текст на­
бран шрифтом Adobe Minion Pro, заголовки набраны шрифтом Adobe Myriad
Condensed, а код - шрифтом Dalton Maag's Ubuntu Mono.

Алфавитный указатель
3D-физика,система. См. также
физика; см. также физика
Angular, 162
советы по фреймворку, 168
Anthropic,разработчик языковой
модели Claude, 19
API
для бэкенда в веб-приложениях, 162
интеграция с API во фронтенд веб­
приложениях, 166
обработка ошибок
в сгенерированных ИИ
системах, 208
обработка ошибок при неудачных
АРI-запросах, 177
паттерны разработки бэкенда и API
с помощью ии
документация и тестирование, 173
оркестровка многоэтапных
операций, 171
реализация конечных точек, 168
пентестинг и фаззинг, 201
проверка кода на устаревшие
API, 139
реализация по установленным
образцам (младшие
разработчики), 126
Artifact (функция Claude), 49
async/awayn,функции, 212
анализ рисков и управление рисками
при использовании ИИ, 279
Bandit (сканер безопасности), 199
bcrypt для хеширования и сравнения
паролей в сгенерированном ИИ
коде, 197
300 1 Алфавитный указатель

Bolt.new, 150
chain-of-thought (СОТ), 81
ChatGPT, 19
и Cursor, 41
разносторонность и широта
знаний, 50
условия обслуживания, 232
Claud
виртуозные рассуждения, 49
Claude, 19,41,46
выбор между моделями Google
Gemini,Claude от Antrhropic
и OpenAI, 51
поддержка нескольких моделей, 47
Cline, 49, 148, 150,250
превращение VSCode в мощную
среду разработки с поддержкой
ии, 40
Code Assist, 49
CodeQL от GitHub, 199
Codex, 19,250,251,252,253,255,264
Copilot, 256
иск против Copilot, 233
реактивные ассистенты, 257
Copilot от GitHub, 250
интеграция с редактором, 258
судебное разбирательство, 233
Copilot для Pull Request, 222
СRUD-операции (create,read,update,
delete), 53

css

генерация с помощью ИИ, 147
добавление стилей с помощью ИИ, 154
интеграция библиотеки с помощью
ии, 153

оформление веб-приложения
С ПОМОЩЬЮ ИИ, 166
пример генерации полной страницы
HTML/CSS, 148
СSV-файлы
конвертация в диаграммы,пример
прототипирования с помощью
ии, 157
Cursor IDE, 41,150,250,253
генерация кода, 41
интеграция с Gemini, 49
использование в профессиональном
рабочем процессе, 43
редактирование существующего
кода, 42
фоновые агенты, 252,264
DeepSeek, модель, 47
de minimis,юридическое правило, 230
Devin, 254,257
DevOps
интеграция вайб-кодинга, 105
интеграция фоновых агентов
с инструментами, 258
советы для разработчиков среднего
уровня, 120
diffs, 254
Django, 170
Doe v. GitHub,Inc.,коллективный
иск, 233
Edit (меню). См. меню Edit
ESLint с плагинами безопасности, 199
Express,добавление маршрутов, 168
freelook. См. свободный взгляд
GameObject (меню). См. меню
GameObject
Gemini, 37
выбор между моделями Google
Gemini, Claude от Anthropic
и OpenAI, 51
мультимодальный тяжеловес, 48
поддержка нескольких моделей, 47
Google Gemini, 41

Google Jules, 264
Google LLC v. Oracle America,Inc.
(судебное разбирательство), 232
GPT-4,условия обслуживания (ToS)
OpenAI в отношении кода, 232
HDR. См. цвета с высоким
динамическим диапазоном (HDR)
Helmet,промежуточное ПО
(middleware), 203
HTML/CSS
генерация макета страницы
с помощью ИИ, 262
генерация с помощью ИИ, 147
генерация с помощью ИИ­
инструментов генеративного
дизайна, 276
пример генерации полной
страницы, 148
НТМL/СSS-страница
генерация с помощью ИИ­
ассистента, 148
IDE (интегрированная среда
разработки
сравнение с автономными
агентами), 256
IDE с поддержкой ИИ, 20
автономные фоновые агенты,
интегрированные в IDE, 264
ИИ-инструменты,встроенные
в среду разработки, 150
с ИИ-ассистентами,хранящими
контекст всего проекта, 177
современные IDE с функцией
IntelliSense, 204
функции IDE,встраивающиеся
в традиционный процесс
разработки, 29
Jules, 251,257,264
LDR. См. рендеринг с низким
динамическим диапазоном (LDR)
LLM, 17
LovaЬle, 298
Алфавитный указатель

1

301

MongoDB, 163,169
MVP (минимально жизнеспособный
продукт), 25
быстрая разработка с помощью ИИ­
партнёра), 53
веб-приложение, 185
OpenAI
мультимодальная поддержка, 47
OpenAI,Codex, 19,253
OpenAI,ToS (условия
обслуживания), 232
OpenAI,выбор между моделями
Gemini,Claude и OpenAI, 51
ОRМ (объектно-реляционное
отображение), 169,171
генерация классов моделей
или описаний схемы в веб­
приложениях, 174
OWASP Тор 10,список
уязвимостей, 202
OWASP (проект),поиск
уязвимостей, 201
PBR (Physically Based
Rendering). См. физически
корректный рендеринг (PBR)
Post-processing,пакет. См. пакет
постобработки
PR (пулл-реквесты), 220
и автономные агенты, 267
RAG (генерация,дополненная
поиском), 44
React, 162
советы по использованию, 168
ReAct (Reason + Act)
техника промпт-инжиниринга, 88
RESTful API,конечные точки, 168
Ruby on Rails, 170
SAST (средства статистического
анализа безопасности
приложений), 183
Semgrep, 199
Sequelize, 174
302 1 Алфавитный указатель

Singleton. См. класс-одиночка
Slerp. См. сферическая линейная
интерполяция
Snyk, 204
советы по использованию, 204
Sonnet,модели, 49
SQL
генерация миграций с помощью
ии, 174
составление запросов к базе данных
с помощью ии, 175
SQL-инъекции как возможная
опасность для сгенерированного ИИ
кода, 193
TODO,комментарии в прототипе для
последующей доработки, 160
UI. См. пользовательский интерфейс
UI- и UХ-дизайн (дизайн
пользовательского интерфейса
и пользовательского опыта), 58
быстрое прототипирование с ИИассистентами, 147
ИИ и исследования в этой
области, 277
инструменты генеративного
дизайна, 275
как направление развития
разработчиков среднего
уровня, 124
персонализированный
пользовательский опыт,создание
с помощью ии, 277
финальная доработка интерфейса
прототипа,созданного с помощью
ии, 159
Vercel vO, 150
VS Code (Visual Studio Code), 250
Cline,превращающий VSCode
в автономного агента с открытым
исходным кодом, 40
ИИ-расширения, 256
интеграция в Gemini, 49

Vue, 162
советы по использованию, 168
Windsurf, 150
WindsurfIDE, 44
вид Cascade, 44
интеграция с Gemini, 49
сильные стороны, 45
ZAP (OWASP), поиск уязвимостей, 201
zero-shot prompting, 78
zero to one,концепция, 52
автомат состояний. См. машина
состояний
автономные агенты по написанию
кода, 104
Cline в VSCode, 40
автономные фоновые агенты для
написания кода, 250
и будущее разработки ПО, 282
лучшие методы использования, 268
основные агенты, 263
принципы работы, 252
проблемы и ограничения, 266
сравнение с ИИ-ассистентами, 256
автономные фоновые агенты для
написания кода,описание, 250
авторизация
неправильная, в сгенерированном
коде, 194
автор сгенерированного ИИ кода, 232
авторство кода, 145,232
сгенерированного автономными
агентами, 268
автор черновика,роль ИИ, 105,106
агенты,интегрированные в рабочие
процессы, 264
адаптация и обучение,важность, 122
адаптация к переменам, 122
алгоритмы
необходимость их понимания для
младших разработчиков, 127
оптимизации производительности
сгенерированного ИИ кода, 211

анализ сгенерированного кода, 135
модульные, интеграционные
и сквозные тесты, 143
проблема самых распространённых
решений, 137
рефакторинг как способ поддержки
кода, 142
роль разработчика,как
ответственного за код лица, 145
стратегии отладки, 140
читаемость кода и его
структура, 138
антипаттерны запросов (промптов), 92
игнорирование запроса
на уточнение, 94
несогласованность, 95
отсутствие явного запроса, 93
перегруженный запрос, 93
размытые критерии успеха, 94
расплывчатые ссылки, 95
расплывчатый запрос, 92
архитекторы и редакторы,
роль старших разработчиков
и программистов, 115
архитектура
важность освоения для
разработчиков среднего
уровня, 123
необходимость человеческого
понимания, 123
паттерны для обеспечения
модульности и предотвращения
разрастания кода, 215
фундаментальные пособия
по архитектуре, 216
асимметрия генератор-рецензент, 259
асинхронные агенты, 251
парадокс асинхронной
координации, 267
атаки по времени, 197
атрибуция сгенерированного ИИ
кода, 238
Алфавитный указатель

303

аудит
безопасности, 183
регулярный аудит безопасности
и производительности кодовой
базы, 227
аутентификация
неправильная, в сгенерированном
коде, 193,195
создание REST API с помощью
Cline, 40
сценарий быстрого создания
авторизации для входа
пользователя в систему, 21
базы данных
в бэкенде веб-приложений, 162
запросы к базе данных, 174
интеграция с бэкендом вебприложений, 169
использование ОRМ, 174
оптимизация запросов к базе
данных, 213
проверка сгенерированного ИИ кода
запросов, 175
проектирование и интеграция в веб­
приложениях, 173
балансировка нагрузки, 123
безопасность, 191
аудит безопасности, 183
аудит сгенерированного ИИ
кода, 199
автоматизированные сканеры
безопасности, 199
вдумчивый подход, 204
использование актуальных моделей
и инструментов, 203
модульные тесты для проверки
безопасности, 202
обновление информации для
моделей, 202
оптимизация журналирования, 203
отдельный ИИ как рецензент, 200
пентестинг и фаззинг, 201
304

1

Алфавитный указатель

предупреждения в контексте, 204
ручная ревизия с акцентом
на безопасность, 201
необходимость сохранять
бдительность, 225
потенциальные уязвимости
в сгенерированном ИИ коде, 156
распространённые проблемы
безопасности в сгенерированном
ИИ коде, 192
неправильная аутентификация
и авторизация, 195
проблемы с пакетами, 198
библиотеки,использование
в сгенерированном ИИ коде, 139
бизнес-логика
в бэкенде веб-приложения, 169
в компонентах бэкенда веб­
приложения, 168
сложная,с СRUD-операциями, 54
большая куча грязи,архитектурный
антипаттерн, 215
большие языковые модели (LLM), 17,
261
интеграция возможностей
в Cursor, 41
мощные машины в мощных
руках, 133
обуч ение на обширных корпусах
знаний по программированию, 61
проблемы с неоднозначностью
запросов, 67
реакция на примеры
и исправления, 73
будущее разработки с помощью ИИ, 272
автоматическая генерация
тестов, 272
интеллектуальная отладка, 273
как автономные агенты изменят
разработку ПО, 282
как вайб-кодинг меняет
индустрию, 292

предиктивное сопровождение
и рефакторинг, 274
участие в определении будущего, 294
эволюция проджектменеджмента, 278
языки программирования
и возможность разработки
на естественном языке, 288
бэкенд
в неб-приложениях, 162
интеграция с фронтендом в веб­
приложении с помощью ИИ, 176
взаимодействие с ИИ в реальном
времени, 177
контрактное взаимодействие, 176
обработка ошибок
в сгенерированных ИИ
системах, 208
паттерны разработки бэкенда и API
с помощью ии, 168
бизнес-логика и валидация, 169
интеграция с базами данных, 169
использование фреймворков
и шаблонов, 170
реализация конечных точек, 168
усиление бэкенда для сервиса
конвертации СSV-файлов
в диаграммы, 158
вайб-кодинг
золотые правила, 110
как вайб-кодинг меняет
индустрию, 292
как фактор, определяющий
будущее, 294
настрой на эксперименты, 34
один из важных аспектов, 33
описание, 17
отличия от разработки с помощью
ИИ, 26
преимущества и ограничения,
нюансы, 52
недостатки и ограничения, 61

преимущества, 60
сочетание творческого настроя
и строгой дисциплины, 63
программирование посредством
диалога, 18
резкий скачок
производительности, 20
риски, 21
типичный цикл, 33
валидатор, роль ИИ, 106, 109
валидация
неб-приложений, созданных
с помощью ИИ, 181
в разработке бэкенда/API с помощью
ии, 169
неб-приложения, создание с помощью
ии, 162
весь рабочий процесс, 162
мультимодальная схема, 263
настройка проекта и создание
каркаса, 162
паттерны разработки бэкенда
и API, 168
паттерны разработки фронтенда, 165
полностековая интеграция, 176
взаимодействие с ИИ в реальном
времени, 177
контрактное взаимодействие
фронтенда и бэкенда, 176
проектирование и интеграция баз
данных, 173
тестирование и интеграция, 181
удачные примеры, 184
веб-сокеты и расширенная
интеграция, 178
верификация
автономным агентом, 254
сгенерированного ИИ кода, как
направление для младших
разработчиков, 128
внутренний корпоративный дашборд
(созданный с помощью ИИ), 184
Алфавитный указатель

305

вопрос при отладке, 142
вопросы лицензирования
и интеллектуальной
собственности, 198 ,230
вывод
выбор из нескольких вариантов, 87
инструкции в метапромптинге, 86
размытые критерии успеха, 94
выполнение кода,стадия работы
автономных агентов, 253
галлюцинации при работе
с пакетами, 198
гендерная предвзятость, 241
генерация,дополненная поиском, 44
генерация кода
генерация повторяющегося кода, 55
итеративный цикл и роль ИИ
в генерации кода, 31
не только для одного компонента, 24
гибридные команды «человек ИИ», 262
глубокое рассуждение,модели, 46
гонки. См. автомобиль
границы между компонентами
системы,умение их определять, 119
граничные случаи
нетипичные,в проектах,
разрабатываемых с помощью
ии, 210
обработка в прототипе, 156
проверка,обрабатывает ли ИИ, 136
данные GI. См. глобальное освещение,
данные
дашборды
пример создания внутреннего
корпоративного дашборда
с помощью ии, 184
два шага назад,антипаттерн, 102
движение. См. также анимация
двунаправленный перевод
(ChatGPT), 51
демократизация программирования, 22
306

1

Алфавитный указатель

диалоговый интерфейс,генерация
полных приложений, 150
диалог с состоянием и запрос
с примером, 91
дизайн
дизайн и персонализация
пользовательского опыта
с помощью ИИ, 275
инструменты генеративного
дизайна, 275
освоение навыков дизайна
специалистами среднего
уровня, 123
освоение UI- и UХ-дизайна
специалистами среднего
уровня, 124
персонализированный
пользовательский опыт, 277
UХ-исследования с помощью
ии, 277
дизайн,процесс превращения в код
с помощью ИИ-инструментов, 150
дискриминации
при использовании ИИ, 246
добросовестное использование, 231
документация
генерируемая ИИ для бэкенда веб­
приложений, 173
для баз данных,создание с помощью
ИИ, 218
добавление при работе над
прототипом, 156
доступность,улучшения в будущем
с помощью ии, 278
естественный язык в средах
разработки, 29
естественный язык как средство
разработки в будущем, 292
естственный язык как средство
составления запросов о статусе, 281
жёстко закодированные секреты или
учётные данные, 192,221

зависимости, 163
проверка библиотек по чек-листу
ответственного использования, 248
установка библиотек ИИагентами, 251
установка зависимостей, агент
CLine, 40
установка зависимостей
в будущем, 274
установка хуков в React, 168
зависимость от ИИ-инструментов,
проблемы, 103
заглушки в сгенерированном ИИ
коде, 140
Закон ЕС об искусственном
интеллекте, 238
запрос без примеров (Zero-Shot
Prompting), 78
запрос с одним или несколькими
примерами (One-Shot и Few-Shot
Prompting), 79, 91
запросы (промпты)
доработка (уточнение) запросов, 153
ответственное использование ИИ, 247
эффективная коммуникация
с ИИ, 65
итеративное уточнеие и цикл
обратной связи, 70
конкретность и ясность
намерения, 68
сравнение двух запросов, 74
как ИИ понимает запрос, 32
навыки работы с запросами для
младших разработчиков, 129
неоднозначность в запросах, 61
переход от роли мастеров
художественного промпта к роли
дирижёра оркестра, 29
проверка, насколько правильно ИИ
интерпретировал запрос, 135
с учётом сопровождаемости
сгенерированного ИИ кода, 214

формулировка запросов как форма
коммуникации, 131
защита конфиденциальных данных
пользователей, 243
знания и опыт в предметной области, 117
игнорирование запросов на уточнение
(антипаттерн промптинга), 94
идеальные сценарии вайб-кодинга, 52
идемпотентность, 207
избыточность в сгенерированном ИИ
коде, 138, 143
ИИ-инструменты программирования
генерация убедительного,
но неверного вывода, 100
задачи, с которыми они справляются
хорошо, 99
неспособность создавать абстракции
или стратегии, 101
предложения по интеграционным
тестам, 144
ситуации, в которых они
не сильны, 100
ИИ (искусственный интеллект)
автономные ИИ-агенты для
написания кода, 104
взаимодействие с ИИ в реальном
времени, 177
ИИ-помощники, 17
инженеры среднего уровня, 123
как автор черновика, 105, 106
как валидатор, 106, 109
как напарник-программист, 105, 108
лучшие практики, 109
не только генерация кода, 293
объединение нескольких ИИ­
моделей, 259
превосходство уверенности над
надёжностью, 100
спектр ИИ-кодирования, 18
с чем ИИ ещё не справляется, 57
тренировка решения задач и отладки
без ИИ, 127
Алфавитный указатель

307

ИИ как программист-напарник или
разработчик-помощник, 257
импортёры. См. скрипты импорта
инклюзивность,формулировка
запросов с учётом
инклюзивности, 242
инновации
как причина роста и расширения
возможностей, 133
инструменты
ИИ-инструменты
прототипирования, 149
использование актуальных моделей
и инструментов с акцентом
на безопасность, 203
нарождающаяся экосистема ИИ­
инструментов, 38
Cursor,редактор кода, 41
Windsurf IDE, 44
необходоимость развития навыков
работы с инструментами для
младших разработчиков, 129
упоминание инструментов,
с помощью которых был
сгенерирован код, 238
инструменты,охватывающие весь
спектр подходов к написанию кода, 29
инструменты совместной работы, 107
инструменты управления
секретами, 225
интеграционные тесты
для сгенерированного ИИ кода, 144
для сгенерированных ИИ веб­
приложений, 181
интеграция прототипов с реальными
системами, 160
интеграция с помощью вайб-кодинга, 54
интеллектуальная собственность
и сгенерированный ИИ код, 198,229
право на интеллектуальную
собственность,лицензии
и владение кодом, 230
308

Алфавитный указатель

серые зоны, 236
что делать при получении
сомнительного результата, 234
интернет-магазин,разработанный
ОДИНОЧКОЙ С ПОМОЩЬЮ ИИ, 184
интерпретация намерений
и требований, 59
инфраструктура как код,концепция
среды развёртывания, 224
исключения (необработанные)
в сгенерированном ИИ коде, 139
искусственный интеллект. См. ИИ
исполнение кода и команд
автономными агентами, 258
источники,указание для
сгенерированного ИИ кода, 237
итеративная доработка прототипа
с помощью ии, 151
итеративное уточнение запросов, 70
итеративный цикл в разработке
прототипа с помощью ИИ, 151
каркас, 22
создание каркаса с помощью
ии, 162
карты моделей, 245
каскадное удаление в базах данных, 176
качество
ловушка демо-качества, 104
нестабильное качество вывода ИИ
моделей, 61
качество,обеспечение качества
ИИ-инструменты и повышение
качества, 109
максимальное использование всех
возможностей ИИ и человека, 110
навыки,полезные для специалистов
среднего уровня, 120
обработка нетипичных
граничных случаев в проектах,
разрабатываемых с помощью
ии, 210
кеширование, 123

кодовая база
запросы к базе на естественном языке
с помощью Windsurf, 45
полная индексация с Windsurf, 44
командная интеграция автономных
агентов, 265
комбинаторика, 81
комментарии в сгенерированном ИИ
коде, 138,218
коммуникация
кросс-функциональная, 123
младших разработчиков с другими
членами команды, 131
чёткая формулировка при общении
сии, 154
контекст
предложения с учётом глобального
контекста (Windsurf), 45
конечные точки
в многоэтапных операциях,
оркестрация, 171
реализация для API бэкенда, 168
конкретика в запросах, 92
стратегии, 69
конкурентность, 212
контекст
как ИИ использует контекст, 32
нескольких файлов (Cursor), 43
окно контекста в вайб-кодинге, 37
понимание широкого контекста
(Claude), 50
контекстные запросы, 84
контроль над генерацией прототипов
с ПОМОЩЬЮ ИИ, 151
конфиденциальность,защита
данных пользователей и запрос
на использование данных, 243
конфиденциальность и безопасность
(сгенерированного ИИ кода), 62
концепция, возможность реализации
концепции, 147

критическое мышление и умение
думать наперёд, 119
культурные предрассудки, 239
добавление для улучшения
производительности
сгенерированного ИИ кода, 213
линтеры, 29,208,214
ловушка демо-качества, 104
логирование
интеграция и использование
в сгенерированных ИИ
системах, 208
оптимизация в целях
безопасности, 203
локализация и обучающие данные
ии, 240
максимальное раскрытие человеческого
потенциала, 114
автоматизация под контролем
человека, 227
младшие разработчики,адаптация
кии, 126
навыки и умения,которые
пригодятся в будущем, 132
оптимизация взаимодействия
человека и ИИ при полностековой
разработке, 179
разработчики среднего уровня,
адаптация и специализация, 118
старшие программисты,адаптация
к работе с ИИ, 115
маршруты,создание обработчиков
конечных точек с использованием
ии, 169
машина. См. автомобиль
межсайтовый скриптинг (XSS) в вебприложениях, 193
метапромптинг, 86
метод отладки, 50
механизмы отката в сгенерированном
ИИ коде, 217

Алфавитный указатель

309

минимально жизнеспособный
продукт, 25
младшие разработчики, 126
многозначные слова в запросах, 69
множитель программирования, роль
ии, 118
модели (ИИ), 46
выбор модели в зависимости
от задачи, 51
выбор подходящей для задачи
модели, 47
выбор тона для запросов, 78
категории моделей по подходам
и сильным сторонам, 46
мультимодальный подход
в разработке, 51
нестабильное качество вывода, 61
обновление информации для
моделей для преодоления порога
знаний, 202
объединение моделей для
максимального эффекта
гибридные команды «человек ИИ», 262
разграничение моделей по типу
задач, 261
системы оркестрации, 261
объединение моделей для
максимального эффекта, 259
ограничения модели, 91
окно контекста, 37
основные модели, 48
практические советы для работы
с любой моделью, 47
ChatGPT, 50
Claude, 49
Google Gemini, 48
сокращение разрыва в 30%, 285
модульность генерируемого ИИ кода, 215
модульные тесты
для сгенерированного ИИ кода, 144

З1 О

Алфавитный указатель

для сгенерированных ИИ
приложений, 181
написанные с помощью ИИ для
проверки сгенерированного ИИ
кода, 206
проверка безопасности
сгенерированного ИИ кода, 202
мониторинг, настройка для
сгенерированных ИИ систем, 208
мультимодальная обработка (ИИ­
модели), 46
наблюдаемость, настройка для
развёртывания, 224
навыки
долговечные навыки для карьерного
будущего, 132
эволюция навыков под влиянием
вайб-кодинrа, 293
нагрузочное тестирование, 207
надёжность, 205
надёжность инфраструктуры
и операционных процессов,
связанных с кодом, 227
намерение, приоритет над
реализацией, 292
намерение, программирование
с намерением, 18, 30, 148
от замысла к реализации, как понять
написанный ИИ код, 135
напарник, роль ИИ, 105, 108
лучшие практики
программирования, 109
наставничество
роль старших программистов, 116
небезопасные настройки или
конфигурации по умолчанию, 194
небезопасные настройки или
конфигурации сгенерированного ИИ
кода, 194
недетерминизм ИИ-систем, 209
несогласованность (в запросах), 95

несогласованность в сгенерированном
ИИ коде, 139
неудачные сценарии при работе
сии, 102
два шага назад, 102
ловушка демо-качества, 104
новые роли в командах
программистов, 287
нормативные требования в связи
с ИИ, 244
облачные агенты с командной
строкой, 264
обновления зависимостей,
добавленных в сгенерированный ИИ
код, 195
обработка ошибок
для сгенерированных ИИ систем, 207
с раскрытием конфиденциальной
информации, 194, 196
обратная связь
для младших разработчиков, 130
с автономными системами, 271
цикл обратной связи с ИИ, 70
обучение, важность обучения, 122
обучение на примерах ИИ, 220
объектно-реляционное
отображение, 169
обычный текстовый поиск, как им
пользуются автономные агенты, 253
ограничение по числу попыток
(механизм предотвращения
взлома), 196
ограничения по производительности
упоминание в запросах, 69
упоминание в запросе, 85
ожидания от вайб-кодинrа
и разработки с помощью ИИ, 26
окно контекста, 80
операции удаления
каскадное удаление в базах
данных, 175

оптимизация взаимодействия
человека и ИИ при полностековой
разработке, 179
оптимизация затрат, 123
организационные сложности
в использовании автономных ИИ­
аrентов, 268
оркестрация, системы для нескольких
ИИ-моделей, 261
ответственное использование ИИ
золотые правила, 243
чек-лист ответственного
использования ИИ, 247
ответственность и этика при
использовании ИИ, 293
откат, план отката, 224
открытые модели ИИ, 47
открытый исходный код
источники информации, 230
коллективный иск Doe v. GitHub,
Inc., 233
отличие от находящегося
в общественном достоянии, 230
отладка
без помощи ИИ, советы младшим
разработчикам, 127
интеллектуальная отладка с помощью
ии, 273
как навык, который будет
востребован всегда, 121
кода, созданного с помощью ИИ, 27
проблема с развитием навыков
отладки при вайб-кодинrе, 103
сгенерированного ИИ кода, 140
с помощью автономных агентов, 258
с помощью Cursor, 43
эффективные запросы для ИИ, 72
от нуля к единице (zero to one),
концепция, 52
отчёт работы автономных агентов, 254
ошибка на единицу, 139

Алфавитный указатель

311

ошибки
обучение на ошибках, 227
поиск и исправление ошибок
в сгенерированном ИИ коде, 140
пайплайны CI/CD (непрерывного
развёртывания и интеграции)
автоматизация, 223
автоматические агенты для
написания кода, 258
более частные развёртывания
сгенерированного ИИ кода, 228
вопросы безопасности, 225
пакеты,проблемы с пакетами
в сгенерированном ИИ коде, 198
память
оптимизация памяти
в сгенерированном ИИ коде, 212
парадокс знания, 103
параллелизм, 127,212
парное программирование
пара «человек - человек», 109
роль ИИ как напарника или как
ассистента, 257
совет для младших разработчиков
поработать в паре
со старшими, 130
парное программирование с ИИ, 109,
115
как противопоставление
программированию в паре
с человеком, 108
ревизии кода как инструмент
обуч ения, 221
пароли
использование bcrypt для
хеширования и сравнения
паролей, 197
криптографическое
хеширование, 197
потенциальные уязвимости, 196
партиционирование и репликация
данных, 123
312

Алфавитный указатель

пентестинr сгенерированного ИИ
кода, 201
перебор пользователей, 196
перегруженные запросы, 93
переключение из режима
быстрого прототипирования
в режим дисциплинированного
инженера, 157
переменные в сгенерированном ИИ
коде, 138
переменные,связанные с расой,полом,
возрастом и личными аспектами, 240
перемены на рынке труда, 37
персонализированный
пользовательский опыт, 277
планирование и контроль с помощью
автономных агентов, 269
планирование спринтов и составление
расписания с помощью ИИ, 279
планирование,стадия работы
автономных агентов, 252
плохие запросы,примеры, 75
улучшение запроса, 76
повторяющийся код,генерация
с помощью вайб-кодинrа, 55
повышение производительности
с помощью ии
ускорение циклов разработки, 60
поддержка принятия решений
в проектном менеджменте, 280
полностековая реализация с помощью
ИИ,пример, 178
полнотекстовый поиск как
универсальный метод ИИаrентов, 253
последовательность и стандартизация
в написании кода, 61
постобработка. См. эффекты
постобработки
пошаговое развёртывание, 224
правила согласованности данных, 175
правила стиля

проверка сгенерированного ИИ
кода на соответствие правилам
стиля, 138
рефакторинг кода для соответствия
правилам стиля, 142
право собственности
на сгенерированный ИИ код, 230, 232
материалы, попадающие под действие
права, 233
предвзятость в выводе ИИ, 62, 239, 246
предвзятость в результатах ИИ, 246
предметная область, важность
знаний, 118
предметная область, важность
знания предметной области для
разработчиков среднего уровня, 119
предметно-ориентированные
естественные языки, 289
принятие решения
А/В-тестирование. См. А/В­
тестирование
проблема 70%, 99
максимизация вклада человека
в оставшиеся 30%, 114
проверка сгенерированного ИИ кода
человеком, 33, 243
ИИ-инструменты
прототипирования, 151
эволюция прототипа на пути
к производству, 155
ручная ревизия кода с акцентом
на безопасность, 201
программирование
ИИ как множитель
программирования, 118
недостатки нового стиля
разработки, 37
программирование с намерением, 30,
148
производительность, доступность
и меняющася природа
прогаммирования, 35

программирование посредством
диалога в вайб-кодинге, 19
программисты
навыки, которые пригодятся
в будущем, 132
среднего уровня, адаптация
и специализация, 118
адаптация и постоянное
обучение, 122
важность навыков кросс­
функциональной
коммуникации, 123
важность освоения навыков
дизайна, 123
важность системного
мышления, 121
использование ИИ, 124
оптимизация производительности
и навыки DevOps, 120
освоение UI- и UХ-дизайна, 124
повышение знаний в предметной
области, 119
ревизии кода и внимание к его
качеству, 120
умение интегрировать системы
и определять их границы, 119
старшие программисты, адаптация
к работе с ИИ, 115
использование ИИ для ускорения
масштабных инициатив, 116
продолжение получения опыта
и новых знаний, 117
роль архитекторов и главных
редакторов, 115
роль наставника и регулятора
стандартов, 116
социальные навыки и навыки
лидера, 117
проджект-менеджмент, эволюция
с помощью ии, 278
прозрачность в использовании ИИ
в разработке ПО, 237
Алфавитный указатель

313

производительность
возможные недостатки
сгенерированного ИИ кода, 139
оптимизация производительности
в будущем, 275
оптимизация производительности
сгенерированного ИИ кода, 143,
210
направления оптимизации, 211
пример оптимизации, 213
проверка производительности
сгенерированного ИИ
прототипа, 158
регулярный аудит кодовой базы,
составленной с помощью ИИ, 227
сгенерированных ИИ запросов
к базам данных, 175
советы разработчикам среднего
уровня уделять особое внимание
производительности, 120
тестирование сгенерированных ИИ
систем на производительность, 207
промпт-инжиниринr, 65
промпт-инижиниринr
основы, 66
промпты, 61
просьба думать вслух как запрос для
ИИ-модели, 82
прототипирование
с использованием ИИ, инструменты
и техники, 147
быстрое прототипирование с ИИ­
ассистентами, 147
ИИ-инструменты
прототипирования, 149
от концепции к прототипу,
итеративная доработка, 151
проблемы, характерные для
прототипирования с помощью
ии, 159
эволюция прототипа на пути
к производству, 155

314

Алфавитный указатель

ускорение с помощью ИИ, 60
функций, 53
пулл-реквесты (PR), процесс ревизии
с помощью интегрированных
автономных агентов, 255
развёртывание
лучшие практические
рекомендации, 223
методы дальнейшей поддержки
по, 226
подготовка и собственно
развёртывание, 223
развитие зависимости от ИИ
и ухудшение навыков, 62
размытые критерии успеха
в запросах, 94
разнообразие, nоддержка разнообразия
в коллективе, 242
разработка
значительно ускорение разработки
с помощью ии, 20
использование ИИ на протяжении
всего жизненного цикла ПО, 22
с поддержкой ИИ и опорой
на предварительное
планирование, 23
с помощью ии, 18
ускорение циклов разработки, 60
разработка с помощью ИИ, 17
отличие от вайб-кодинга, 26
разработка с ИИ-партнёром, 22
генерация мини-приложения
на основе подробной
спецификации, 24
миграция и рефакторинr, 24
предположения, 26
рабочий процесс, 23
цели такой разработки, 25
разработчики, 223
изменение культуры разработки
и набора навыков при
использовании ИИ-аrентов, 286

сценарии, которые работают
на самом деле, 105
типичные неудачные сценарии, 102
эволюция прототипа с помощью
ии, 155
как авторы сгенерированного ИИ
кода, 232
как разработчики на самом деле
пользуются ИИ, 101
младшие разработчики, адаптация
кии, 126
младшие разработчики, польза от ИИ
коммуникация
и сотрудничество, 131
обращение за советами и обратной
связью, 130
обучение основам, 127
поддержка кода, 128
развитие навыков
работы с запросами
и инструментами, 129
смена мысленного настроя
от потребления к созиданию, 131
тренировка навыков без ИИ, 127
фокус на тестировании
и проверке, 128
ответственность разработчиков, 145
эволюция роли, не исчезновение, 114
разработчики среднего уровня, 118
разрастание кода, как не допустить при
генерации кода с помощью ИИ, 215
разрастание функционала, 159
ранбуки(руководства
по эксплуатации), 226
расовая дискриминация, 240
расплывчатые ссылки в запросах, 95
расплывчатый запрос, 92
рассуждай и действуй, техника
промптинга, 88
рассуждение, модели с глубоким
рассуждением, 46
ревизии(ревью) кода

для сгенерированных ИИ
приложений, 182
задача разработчиков среднего
уровня, 120
осложнение со стороны автономных
агентов, 267
отдельный ИИ как рецензент, 200
при ответственном использовании
ИИ, 247
сгенерированного ИИ, 259
со списком вопросов
безопасности, 201
стратегии ревизии кода, 220
ревизия кода, асимметрия, 259
редакторы кода
Cursor, 41
Gemini, интеграция с рабочими
процессами, 49
редкие решения в сгенерированном ИИ
коде, 217
режимы работы(Windsurf), 45
рефакторинг
запрос на упрощение кода, 221
ИИ будущего, 274
как способ поддержки( обеспечения
сопровождаемости) кода, 142
написанного ИИ кода после
тестирования, 209
созданной ИИ кодовой базы по мере
необходимости, 216
решение
смена мысленного настроя
от потребления к пониманию, 131
решение большинства, эффект, 137
решение проблем, без опоры на ИИ
совет младшим разработчикам, 127
решения
самые распространенные не равны
самым подходящим, 137
роль аналитика безопасности, запрос
для ии, 83
роль лидера и социальные навыки, 116
Алфавитный указатель

315

роль преподавателя, запрос для ИИ, 83
руководство по эксплуатации
(ранбук), 226
самосогласованность, 87
сбои, режимы и процедуры
восстановления, 123
связующий код и интеграция
с помощью вайб-кодинга, 54
серверы в бэкенде веб­
приложений, 162
серые зоны в вопросах права
на интеллектуальную собственность
в отношении сгенерированного ИИ
кода, 236
синтаксические ошибки
(незначительные) в сгенерированном
ИИ коде, 139
синхронизация и управление
состоянием в полностековом веб­
приложении, 177
система контроля версий при
разработке с помощью ИИ, 107
системы
важность освоения системного
дизайна и архитектуры, 123
важность системного мышления, 121
долговечные навыки для карьерного
будущего, 132
сквозные тесты, написание для
сгенерированного ИИ кода, 144
скорость, модели с оптимизированной
скоростью, 46
скриншоты как начальный этап
разработки прототипа, 150
сложность
анализ сложности сгенерированного
ИИ кода, 211
отказ от излишней сложности
в сгенерированном ИИ коде, 217
работа со сложной логикой
фронтенда, 167
316

Алфавитный указатель

разбиение сложных задач на более
мелкие, 91
смена подходов, умение вовремя
распознавать нужный момент, 56
смерть младших разработчиков, 126
смещение в выводе ИИ, 62
смещение данных, 240
совместная работа
ИИ как коллега, 292
сотрудничество младших
разработчиков с другими членами
команды, 131
сопровождаемость
кодовых баз, составленных
с помощью ии, 214
завершающий этап, 218
на этапе формулировки
запросов, 214
работа с результатами генерации
кода, 216
тестирование на сопровождаемость
сгенерированных ИИ систем, 208
рефакторинг сгенерированного ИИ
кода, 142
сопровождение кода,
предиктивное, 274
состояние, 91
управление состоянием
в полностековом вебприложении, 177
управление состоянием для
фронтенда веб-приложения, 166
социальная инженерия
и постоянные перемены, 132
как автономные агенты изменят
сферу разработки ПО, 282
социальные навыки и навыки
лидера, 117
спектр кодирования от разработки
с помощью ИИ до вайб-кодинга, как
найти своё место, 28

справедливость и результаты ИИ­
генерации, 239
спринты, планирование и составление
расписания, 279
среда, упоминание в запросах, 69
стандарты кода
поддержка стандартов
сгенерированного ИИ кода, 214
стартап минимально жизнеспособного
продукта в виде веб-приложения, 185
старшие разработчики, 115
статистический анализ, инструменты
(SAST), 199
стилизация и вёрстка веб-приложений
С ПОМОЩЬЮ ИИ, 166
страница авторизации,
прототипирование с помощью ИИ­
ассистента, 148
стратегический выбор задач для
автономных агентов, 269
стратегия сине-зелёного
развёртывания, 225
структуры данных, 127
теневое тестирование, 226
тестирование
автоматическая генерация
тестов, 272
важность для сгенерированного ИИ
кода, 120
веб-приложений, созданных
с помощью ии, 181
во время эксплуатации продукта, 226
генерация тестов API для бэкенда
веб-приложений, 173
ИИ-инструменты, помогающие
в тестировании, 109
интеграция подсказок в ИИ­
инструменты по написанию кода, 145
как важное направление для младших
разработчиков, 128
как средство обеспечения
сопровождаемости

сгенерированной ИИ кодовой
базы, 216
модульные, интеграционные
и сквозные тесты на важном этапе
тестирования, 143
модульные тесты для прототипа,
созданного с помощью ИИ, 158
при отладке, 141
прототипов, созданных с помощью
ии, 157
создание эффективных тестовых
фреймворков для сгенерированных
ИИ систем, 205
недетерминизм ИИ-систем, 209
проблемы, возникающие при
интеграции сгенерированных ИИ
компонентов, 209
типы тестов, 206
теневое тестирование при
развёртывании, 226
тестирование на разных примерах
данных, связанных с людьми, 241
тесты свойств, 206
техники запросов, 77
запрос без примеров, 78
запрос с одним или несколькими
примерами (One-Shot и Few-Shot
Prompting), 79
контекстные запросы (Contextual
Prompting), 84
метапромптинг (Metaprompting), 86
продвинутый промт-инжиниринг
сочетание техник
и ограничения модели, 91
сложные техники, 90
ролевые запросы (Role prompting), 83
самосогласованность (выбор
из нескольких сгенерированных
вариантов), 87
цепочка рассуждений (Chain-of­
Thought), 81
ReAct (Reason + Act), 88
Алфавитный указатель

317

точность воспроизведения
(соответствие сгенерированного
результата намерению), 150
традиционное парное
программирование
и программирование в паре
сии, 108
пара из старшего и младшего
разработчиков, 130
транзакции, реализация в бэкенде веб­
приложения, 171
требования
анализ требований, 131
интерпретация требований
искусственным интеллектом, 59
размышление о том, как донести их
до ИИ, 67
упоминание в запросе, 69
умение интегрировать системы
и определять их границы, 119
умение предвидеть последствия, 117,119
управление зависимостями и их
обновления, вопрос безопасности
сгенерированного ИИ кода, 195
управление и процессы, при
ответственном использовании
ии, 248
управление ключами, 225
управление командой с помощью
автономных агентов, 270
управление памятью, 127
управление параллельной работой
агентов, 270
управляемые агенты для написания
кода, 250
уровень всего проекта, область работы
автономных ИИ-агентов, 257
условия обслуживания (ToS) ИИ­
инструментов, 232
устойчивость, паттерны устойчивости
для сгенерированной ИИ кодовой
базы, 217
318

Алфавитный указатель

устойчивые навыки и практики,
важность для карьеры, 132
ухудшение навыков из-за пользования
ии, 62
фаззинг сгенерированного ИИ кода, 201
фоновые агенты для написания
кода, 250
формат вывода, упоминание
в запросе, 69
форматирование
единообразное форматирование
сгенерированного ИИ кода, 138
форматирование дат с помощью
ИИ, 106
несоответствие компонентов,
сгенерированных ИИ отдельно друг
от друга, 21О
форматтеры, 208,214
фреймворки
использование современных
фреймворков ИИ-ассистентами, 54
советы для разных фреймворков, 168
фронтенд
веб-приложений, 162
интеграция фронтенда и бэкенда
в веб-приложении с помощью
ИИ, 176
взаимодействие в реальном
времени, 177
контрактное взаимодействие, 176
обработка ошибок
в сгенерированных ИИ
системах, 208
паттерны (типовые приёмы)
разработки фронтенда с ИИ, 165
интеграция с API и управление
состоянием, 166
работа со сложной логикой, 167
реализация компонентов
по описанию, 165
советы по конкретным
фреймворкам, 168

стилизация и вёрстка, 166
рефакторинr созданноrо с помощью
ИИ прототипа конвертера СSV­
файлов в диаrраммы, 158
тестирование сrенерированных ИИ
веб-приложений, 182
фундаментальные знания и навыки
их важность для младших
разработчиков, 127
сохранение их, несмотря на смену
парадиrмы, 293
функции
избыточные функции,
сrенерированные ИИ, 138
оптимизация функций
в сrенерированном ИИ коде, 211,
213
рефакторинr сrенерированноrо ИИ
кода, 142
функционал
лёrкость добавления с помощью
ии, 159
удаление ненужноrо
сrенерированноrо ИИ
функционала, 136
хуки в React, 168
цели вайб-кодинrа и разработки
с помощью ии, 27
цепочка рассуждений (метод
запроса), 81
в сочетании с методом ReAct, 89

чат-интерфейсы, 29
чат-ориентированное
проrраммирование, 116
читаемость кода
сrенерированноrо ИИ,
потенциальные проблемы, 138
чувствительная реакция ИИ
на некоторые роли, 84
шаблоны в rенерируемом ИИ коде, 138
экспериментирование
блаrодаря ИИ, 34
улучшение с помощью ИИ, 60
эмоциональное состояние и здоровье
команды, 281
этические вопросы вайб-кодинrа, 229
в связи с интеллектуальной
собственностью, 230
этические вопросы вайб-кодинrа, 293
предвзятость и справедливость, 239
прозрачность и признание
авторства, 237
эффект растворения. См. растворение,
эффект
эффект ducking. См. приrлушение,
эффект
языки проrраммирования
будущее языков проrраммирования
в свете разработки с помощью
ии, 288
упоминание в запросах, 68

Барлыl( l(Vl(Ыl(Тap 1(0/Jfд/lFдH. Бул кiтапты басып ШЫFдрушыны11 рУl(сатынсыз онлайн немесе кез келген бас,;а жолмен
сканерлеу, жуктеп алу немесе за11сыз тарату за11 бойынша жазаланады / Все права защищены. Никакая часть
данной книги не может быть воспроизведена в какой бы то ни было форме с помощью каких-либо электронных
или механических средств, включая изготовление фотокопий, аудиозапись, репродукцию или любой иной
способ, или систем поиска и хранения информации без письменного разрешения издателя.

Аfылшын тiлiнен аударма / Перевод с английского
«Астана иностранная пресса»
O'REILLY. КНИГИ ПО ПРОГРАММИРОВАНИЮ
ЭддиОсмани

VIBECODING
ПРОГРАММИРОВАНИЕ С ПОМОЩЬЮ ИСКУССТВЕННОГО ИНТЕЛЛЕКТА
Бас редактор / Главный редактор
Ыс1<;афай РабиFа
БасуFа 09.07.2026 1<;ол 1<;ойылды / Подписано в печать 09.07.2026.
Пiшiнi 7Ох1ОО 1/ 6• К,аfазы офсеттiк. Офсеттiк басылыс /
Формат 7Ох1ОО / 6. Бумага офсетная. Печать офсетная.
Шартты баспа табаfы 25,93. Таралымы 1500 дана. Тапсырыс № 3527/26
Усл. печ. л. 25,93. Тираж 1500 экз. Заказ № 3527/26
1
1

1

Тауар белгiсi / Товарный знак: «Astana lnternational PuЫishing»
Сапасы женiнде мына мекемеге хабарласы�ыз / С претензиями по качеству обращаться:
«Астана иностранная пресса» ЖШС
К,Р, Алматы 1<;., Аль-Фараби да�F., 19/1, «Нурлы-Тау» БО, 3Б блогы, 12 офис.
ТОО «Астана иностранная пресса"
РК, г. Алматы, пр. Аль-Фараби, 19/1, БЦ, «Нурлы-Тау», блок 3Б, помещение 12.
Телефон:+7 (771) 276-41-09
E-mail: info@astanapuЫishing.kz
Кетерме сауда белiмi / Отдел оптовых продаж
Алматы 1<;., Аль-Фараби да�f., 19/1, «Нурлы-Тау» БО, 3Б блогы, 12 офис.
г. Алматы, пр. Аль-Фараби, 19/1, БЦ «Нурлы-Тау .. , блок 3Б, помещение 12.
E-mail: info@astanapuЫishing.kz
Тауар барлы1<; сапа жане 1<;ауiпсiздiк стандарттарына сай /
Товар соответствует всем стандартам качества и безопасности
Сертификация l<;ЭрастырылмаFан / Сертификация не предусмотрена
Са1<;тау мерзiмi шектелмеген / Срок годности не ограничен
0ндiрушi ел: 1<,аза1<;стан / Страна-изготовитель: Казахстан
К,аза1<;стан РеспубликасындаFы дистрибьютор: «РДЦ-Алматы"ЖШС /
Дистрибьютор в Республике Казахстан: ТОО «РДЦ-Алматы"
Алматы 1<;., Домбровский кешесi, 3«а», литер Б, офис 1. Тел.: 8 (727) 251-59-90/91/92
г. Алматы, ул. Домбровского, 3«а", литер Б, офис 1. Тел.: 8 (727) 251-59-90/91/92
К,азастан РеспубликасындаFы Дистрибьютор интернет-дукенi /
Интернет-магазин дистрибьютора в РК: www.book24.kz
«Можай полиграфиялыt<; комбинаты" ашыt<; акционерлiк t<;Оfамыны�
баспаханасында басылды. 143200, Маскеу облысы, Можайск 1<;аласы,
Мира кешесi, 93-уй.
Отпечатано в типографии ОАО «Можайский полиграфический
комбинат». 143200, Московская область, г. Можайск, ул. Мира, д.93.

QS

tarь.

international
puЬlishing