Transcription
Привет. Я уже больше 3 лет пользуюсь искусственным интеллектом для разработки кода. А вообще разработкой профессионально занимаюсь уже лет 25. В этом видео я дам несколько советов и лайфхаков, как писать код с помощью ИИ. И в конце объясню, чем мой подход отличается от классического вайб-кодинга.
Начну с самого главного. Искусственный интеллект - это не гений, не оракул, это ваш помощник. И, честно говоря, он похож больше на какого-то странноватого джуна. Очень странного, но быстрого джуна. И вы им руководите. И первое, что нужно понимать, ответственность полностью 100% лежит на вас. Всё, что выходит из этих инструментов - это ваш код, и вы полностью за него отвечаете.
У меня была история, когда я просто скопировал сгенерированный код и отправил его на ревю. Там нашлось несколько ошибок в стиле. Например, модель писала в одну строчку, а в нашей команде это считается плохой практикой. И хотя формально код был написан не мной, мне было неловко. Возможно, все понимают, что мы используем ИИ для кода, но когда разработчик пропускает такие явные ляпы от ИИ, это значит, что он даже на код не посмотрел, что, вообще говоря, неправильно.
И раз уж мы говорим об ответственности, переходим ко второму пункту. И это джуниор, поэтому ему нужно очень ясно ставить задачу. Недостаточно просто сказать: "Сделай". Это нужно объяснить контекст, зачем это вообще нужно, какие есть ограничения, когда вообще задача считается выполненной. И вот в чём проблема. Большинство из нас знают, как правильно формулировать задачи, но иногда всё равно получается, ну, не получается. В общем, у меня было несколько случаев, когда я просил написать, скажем, браузерную игру. Я занимаюсь этим в свободное время. У меня есть несколько стримов на канале на эту тему. В общем, я излагаю смутную идею, отправляю запрос и создаёт что-то совершенно не то. Вот в этом и вся суть. Чтобы получить то, что вы хотите, надо сначала точно знать, что вы хотите. И это, кстати, проблем не только с ИИ, но здесь она проявляется во всей красе.
Теперь немножко про структурирование работы. Это касается особенно старых инструментов, таких как, скажем, чат GPT. Задачи нужно разбивать на этапы. Вместо того, чтобы просить всё сразу, попросите: "Сначала спроектируй это, распиши архитектуру, но код не пиши". Модель напишет план, потом теперь напиши код. И только потом добавь тесты. Почему это работает лучше? Потому что моделям проще думать, когда им даёшь поменьше работы за один раз. Ещё, если вы не просто говорите: "Напиши функции", расписывайте подробно. Может быть, даже с указанием типов и структур классов результат получается гораздо лучше.
Дальше о новых инструментах. Сейчас появились агентские инструменты. Например, я пользовался Cloud Console, Open AI Codex, GitHub Copilot Agent. Так вот, эти агенты уже сами внутри себя разбивают задачи на шаги. Они дольше думают над запросом, самостоятельно проектируют, потом пишут код. Но, в принципе, остаётся тот же. Разбитие на шаги всегда работает лучше, чем попросить написать всё с первого раза. Ну и поскольку мы начали разбивать работу на шаги, то давайте поступим ещё умнее. Например, сначала можно спросить у модели или у инструмента, как это будет выглядеть с точки зрения пользовательского интерфейса, затем подумать над архитектурой, какие классы нужны, может ли понадобиться база данных. И на каждом этапе вы проверяете, куда движетесь.
И ещё одна штука может хорошо помочь. Просите не один вариант решения, а, ну, например, три. И для каждого распишите плюсы и минусы. Почему это помогает? Потому что, во-первых, ИИ может что-то упустить, а глядя на варианты, вы сразу быстро поймёте, какой из этих вариантов лучше. Ну и, например, ИИ предлагает иногда варианты, которые мне, скажем, и в голову не приходили. И, в-третьих, если попросить больше вариантов, то модель будет дольше думать. И, например, первый вариант может быть самый очевидный и простой, но как обычно неправильный, а второй, третий, четвёртый, там уже может быть что-то более интересное.
И последний совет в этой части: всегда уточняйте цели. Если у вас есть кусок кода, который не нравится, можно, конечно, просто сказать: "Улучши его". Ну и можешь не понять, что конкретно нужно. А вот если вы говорите: "У меня есть два компонента в разных файлах. Давай вынесем дублирующий код в третий файл". Вот тут и срабатывает отлично. Или, например, "Давайте отрефакторим эту функцию так, чтобы она не зависела от базы данных, а потом покроем её тестами". В общем, с конкретными целями всё работает гораздо лучше.
Ну и давайте теперь поговорим о самом мощном инструменте - это об агентах. Что такое агент? Это не просто языковая модель. Это целая программа, которая работает так: модель решает, что нужно сделать, а потом обращается к инструментам. Потом опять решает, что дальше делать. И так в цикле. Инструменты могут быть самыми разными: прочитать файл, изменить файл, запустить тесты, скачать документацию. Модель сама выбирает, когда остановиться и когда использовать эти инструменты.
Первая и самая важная особенность агентов, они планируют. Когда вы работаете с такими инструментами, как, например, GitHub Copilot Agent или Cloud Console, агент сначала создаёт список того, что нужно сделать, to-do list, и по ходу работы он ставит галочки. И вот что ещё удобно. Перед тем, как запустить агента в работу, вы можете отдельным запросом попросить его составить план, проверить этот план и только потом запустить его выполнять задачу.
Второй важный совет: ограничивайте область, где может копаться агент. Как это делается? Вы можете в промте написать: "Меняй файл только в такой-то директории". Но в большинстве инструментов есть ещё специальный параметр контекст. Вы можете указать отдельный файл или папку, и агент будет работать только там. Например, у меня на работе большой монорепозиторий, который состоит из нескольких подпроектов, и я всегда указываю корневую папку того проекта, в котором работаю. Агент не полезет в другие папки, не будет искать, нужно ли ему менять что-то в других местах, просто установится на указанной границе. Это не только безопаснее, но ещё быстрее, потому что агент тратит меньше времени на анализ лишних файлов.
Следующий лайфхак. Я иногда прошу агента объяснить, почему он делает именно так. Например, бывает, что он создаёт структуру данных, а я не сразу понимаю логику. Обычно я разбираюсь сам, прочитав код код внимательнее, но иногда я просто спрашиваю, почему именно такая структура, а не другая. И он объясняет, может быть, ссылается на какую-то библиотеку, которую он использует, или на особенности работы. И это очень помогает, потому что, ещё раз, вы ответственны за этот код, и нужно его понимать до конца.
Есть ещё одна очень удобная фишка, которая, я так понимаю, совсем недавно появилась в агентах. Вы можете остановить агент на промежуточном этапе и что-то добавить. В обычном чат GPT такого нет. Ты его попросишь, он начал писать, и ты можешь его только остановить полностью. А вот в chat GPT Codex или Cloud Console агент может работать долго, делая много-много шагов. И вот ты его в любой момент можешь поставить на паузу. Во время этой паузы ты можешь прямо в чате написать что-то вроде: "Погоди, я забыл, добавь ещё вот это". Вот. Эту возможность спасает в ситуациях, когда ты через 5 секунд после того, как нажал Enter, понимаешь, что кое-что упустил. И в этом случае не надо переделывать всё заново.
Теперь переходим к следующей очень важной вещи - это система контроля версии. Да, я говорю про Git. Всё, что делает ИИ, должно делаться поверх кода, который лежит в гите. Почему? Потому что потом вы можете увидеть ровно то, что изменилось. То есть как это работает? У вас должен быть чистый репозиторий. Все ваши изменения закоммичены. Потом вы даёте агенту новую задачу, он работает, меняет файлы. Когда он закончит, у вас будет diff, и вы увидите только то, что агент реально добавил или изменил. Иногда после первого раунда работы вам нужны дополнительные изменения. Вы добавляете те изменения, которые уже есть в staging, а потом просите агента внести ещё какие-то правки. Когда агент работает со вторым раундом изменений, вы можете опять же посмотреть diff и увидеть, что он добавил дополнительно. Такой подход позволяет контролировать изменения на каждом этапе. Может быть, кому-то это покажется очевидным, но вот я работаю именно так, и мне это помогает.
Следующий совет. Пусть агент к своему собственному коду ещё пишет тесты. Современные агенты справляются с тестами куда лучше, чем раньше. Это я на себе ощутил, потому что они сейчас ищут существующие тесты в вашем проекте, понимают стиль, видят, какие библиотеки вы используете: Jest, Vitest, Cypress, что-то ещё, и пишут новые тесты в том же стиле. Плюс агент сам понимает, какие кейсы важны, какие ограниченные случаи нужно покрыть. Короче, тесты у них сейчас получаются такие, какие я сам бы не написал. Если бы ИИ умел только одно - писать тесты, я бы уже был безумно счастлив.
Следующий момент. Я рекомендую использовать агентов для проектирования типов и моделей. То есть на первом шаге просто попросите его спроектировать типы данных, потом посмотрите, всё ли вам нравится, и только потом генерируете код. И из-за этого вы можете избежать переделок потом. Ну и ещё один совет. Однотипные задачи тоже можно спихивать на агентов: это какие-нибудь миграции, рефакторинг, переименование чего-то, что сложно сделать с помощью обычных регулярных выражений, потому что надо понимать код, его семантику, а агенты с этим очень хорошо справляются.
Ну и самое главное с этими агентами - это убедиться в качестве кода. И тут я хочу поподробнее остановиться. Процесс проверки должен быть двухуровневым. Первый уровень - это вы. Человеческий мозг, ну или там человеческий глаз должен посмотреть на код. А второй уровень - это инструменты: линтеры, тесты, type checkers - это всё, что вы используете при обычной разработке.
Первый и самый простой совет это: "Никогда не мержите код от ИИ, не прочитав его, даже если он совсем простой, даже если он огромный, потому что если вы начнёте это делать, вы потеряете контроль полностью. Это вообще путь в никуда".
Второй совет: естественно, запускайте тесты после того, как ИИ что-то сделал. Идеально, если у вас есть процесс, который перезапускает тесты при каждом изменении исходного кода. Если проект небольшой, просто запустить тесты в отдельной консоли. Например, в Vitest по умолчанию есть режим, когда при каждом сохранении файла автоматически перезапускаются тесты для изменённых файлов. Это сразу покажет, что где-то что-то сломалось. Но в больших проектах все тесты обычно прогоняются на CI-сервере. При каждом пуше в GitHub прогоняются unit-тесты, интеграционные, End-to-end. Ну и в нормальных командах вы в Main ветку вообще не смержитесь, если тесты не прошли. Если тестов нет вообще, ну попросите ИИ их написать. Я это уже говорил, но ещё раз повторяю, агенты с этим справляются отлично.
Ещё один трюк: попросите ИИ объяснить, почему он делает именно так. Если объяснения получаются мутными, непонятными, значит, это красный флаг. Если ИИ не может толком объяснить, почему он так написал, возможно, он галлюцинирует. И если это объяснение смутное, то и код получится какой-то смутный.
Ещё одно полезное упражнение: попросить ИИ подумать об ограниченных случаях, когда переменная, например, равна нулю, когда она очень большая, когда она NaN или undefined. Попросите написать тест именно на эти случаи. Но, правда, вы сами должны будете решить, что в этих случаях должно произойти. Нужно выбросить ошибку или как-то по-другому. Но проверить граничные случаи - это очень важно.
Следующая тема - это безопасность. Иногда ИИ забывают про неё полностью. У меня было несколько случаев, когда я писал Backend endpoint и создавал код вообще без проверки, принадлежит ли объект текущему юзеру или нет. Один раз такая дыра даже прошла в продакшн. К счастью, мы её быстро закрыли, но это, вообще-то говоря, было неприятно. Так что обязательно говорите с ИИ про безопасность.
Теперь про статический анализ и линтеры. Я уже несколько лет пишу на TypeScript и люблю его именно за типизацию. И вот что интересно. Код, который генерирует ИИ, часто не проходит type-чекинг. Всплывают какие-то мелкие ошибки с типами. Они не всегда означают, что это баг. Это может быть просто косяк с типизацией, который на runtime вообще никак не проявляется, но может и проявиться. Поэтому просто посмотрите на подсветку ошибок в вашем редакторе. Если её нет, прогоняйте линтер из командной строки, и это будет ещё один уровень защиты.
Следующий момент. Если код от ИИ выглядит плохо, он какой-то запутанный, некрасивый, не расслабляйтесь просто потому, что он работает. Переписывайте его, даже если все тесты проходят, даже если type-чекинг прошёл, потому что вам или вашим коллегам это потом поддерживать через год или два вы посмотрите на этот код и пожалеете или там, что о вас коллеги подумают.
Ещё один важный момент: ИИ любит галлюцинировать. Он может очень уверенно написать код, используя библиотеку, которая вообще не существует. Ну или существует, но он неправильно использует функции. Плюс библиотеки постоянно меняются, разные версии могут быть несовместимы, и в этом может запутаться. Что помогает? Опять всё тот же type-чекинг, тесты, просмотр кода, практически всё можно отловить, но иногда полезно открыть документацию функций, которую использовал ИИ, и проверить, правильно ли он их вызывает. Например, я не раз видел, как ИИ передавал кучу ненужных параметров, которые и так стоят по умолчанию, и это просто засоряет код. Удалите эти параметры, и код станет намного чище.
Теперь давайте поговорим о том, как вообще организовать рабочий процесс, как правильно структурировать сессию разработки с ИИ. Первый совет - это касается не только ИИ. Чётко понимаете, какую задачу вы сейчас решаете. Когда вы пишете промт агенту, описывайте только текущую задачу. Решили её, закончилась сессия, начинайте новую. В большинстве инструментов есть понятие сессии. Агент получает задачу, пытается её решить. И я обычно довожу сессию до какого-то логического завершения, когда у меня уже есть какой-то код. И может быть, он даже не совсем работает, но это о'кей. Главное, что он, допустим, проходит статические проверки. Тесты могут быть сломанные, но это неважно. Я делаю коммит, бранч, и это получается промежуточное состояние. И потом я обычно начинаю свежую сессию, вместо того, чтобы продолжать старую. Почему? Потому что долгие сессии обычно означают, что может быть переполнен контекст. У всех моделей есть ограничение на размер контекста, то есть на количество входных токенов, которые они могут обработать. И когда сессия оказывается слишком длинной, промежуточных результатов становится слишком много. Агент начинает пытаться их суммировать. Он может что-то потерять, может в этом всём запутаться. Поэтому я предпочитаю начинать с чистого листа.
И ещё один совет. Просите агента писать документацию каждой функции. Я обычно пишу в формате JSDoc - это индустриальный стандарт. Можно даже попросить прямо в комментариях добавить примеры использования этой функции. Это потом помогает в разработке.
Ещё один полезный use case - это попросить агента подобрать хорошие имена для функций или там для переменных. Сейчас агенты могут шерстить по разным файлам и смотреть, где используется эта функция. Можно, например, попросить у него несколько вариантов и выбрать лучший. И ещё попросите его объяснить, почему эти имена хорошие. Например, ИИ может рассказать про какие-то стандарты наименования. Ну, там, скажем, что название функции должно начинаться с глагола или что-то в этом роде. И даже если вы этого не знали, вы сами потом можете использовать эти знания. И вот как бы это вот очень ценно. Вы не просто переименовываете, вы ещё и учитесь.
Дальше по поводу понятия вайп-кодинг. Вы, наверное, слышали это название. Его популяризировал Андрей Карпатый в 2025 году в своём знаменитом твите в феврале. Но когда он впервые про это написал, он имел в виду процесс, когда ИИ пишет код, а вы на него вообще не смотрите. Как он там написал, вы вообще забываете, что код существует. И мне кажется, что в текущий момент при текущем уровне развития технологий такой подход в профессиональной разработке пока использовать нельзя. Я уже несколько раз это повторял. Вы отвечаете за этот код, вы должны на него смотреть. И всё, о чём я сейчас рассказываю, требует вашего активного участия. Это не вайп-кодинг, это скорее взвешенное, контролируемое разделение труда между вами и ИИ. Поэтому я призываю вас писать код именно так. Умение пользоваться этими инструментами даёт вам преимущество по сравнению с другими разработчиками. А в наше время, когда сами знаете, какая ситуация с рынком труда, это очень важно. Пишите софт, используйте искусственный интеллект. Если я что-то упустил, комментарии внизу. Ну и подпишитесь на канал, если ещё нет. И спасибо, что досмотрели это видео до конца. С вами был Лёша Крепанов. Всем пока-пока.