Разработка ПО с использованием ИИ-ассистента

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

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

Содержание

• Правило №1. Делаем тщательный review
• Правило №2. Стремитесь к чистому коду
• Правило №3. Сужайте контекст
• Правило №4. Точнее описывайте задачу
• Правило №5. Описывайте как проверить результат
• Правило №6. Просите предложить разные варианты
• Правило №7. Проверяйте то, чему учит вас ИИ
• О вайбкоддинге
• О приросте производительности
• Заключение

Правило №1. Делаем тщательный review

Это, пожалуй, самое важное правило. Код, который выдает ИИ-ассистент — не ваш. Относитесь к нему так, как будто он был получен от младшего сотрудника (junior). Код может содержать грубые ошибки, уязвимости, проблемы с производительностью. Он может вовсе не решать поставленную задачу. Он может выглядеть как лапша («спагетти»-код).

Ваша задача не допустить всего этого. Обязательно проводите тщательную проверку кода (review). Не бегло, не «по-диагонали». Делайте это внимательно, проходите строку за строкой. Если вам не ясно что-то в коде, то разберитесь как оно работает. Не включайте в проект код, работа которого вам не полностью понятна.

Есть еще один побочный эффект от чтения кода. Дело в том, что когда мы позволяем машине думать за нас, мы перестаем тренировать себя. И со временем думать становится сложнее. Читая код и разбираясь в нем досконально мы заставляем свой мозг работать. Деградация если и есть, то по крайней мере, не такая быстрая.

Правило №2. Стремитесь к чистому коду

Нельзя позволять включать в проект нерациональный код. Код должен быть чистый. Длинная лапша и дублирование не должны попадать в проект.

С одной стороны код создается ассистентом за секунды. И кажется, что нет разницы напишет ассистент 100 строк для какого-то класса или 500 строк. Кажется, что не важно есть дублирование или нет. Использовали ли мы какой-то паттерн, готовую библиотеку или же написали свой «велосипед». Ведь при следующей задаче для этого кода у нас всё еще будет этот неутомимый ассистент, который будет продолжать генерировать код и обрабатывать все дубли и лишние строки прошлой итерации.

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

Следуя правилу №1 нам придется внимательно знакомиться со всем этим кодом. И тут нам будет проще, если код будет разбит на мелкие, хорошо читаемые и хорошо организованные кусочки. При чтении каждого участка кода нам не придется удерживать в голове слишком много.

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

Правило №3. Сужайте контекст

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

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

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

Правило №4. Точнее описывайте задачу

Это, наверное, самое очевидное правило. Но часто в спешке мы можем забывать о нем. Задачу нужно описывать четко, так чтобы у ассистента не было необходимости угадывать детали задачи.

Здесь нужно излагать все так, как если бы вы хотели ввести в курс дела человека. Привести исходные данные, четко изложить какой результат вы хотите получить.

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

Правило №5. Описывайте как проверить результат

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

Например, помощник может запускать тест обращаясь к локальному npm, а он у вас в проекте в докер-контейнере. Таким образом итоговая команда для запуска тестов будет отличаться.

Если ассистент запустит ваши тесты и все проверки, то сможет тут же исправить появившиеся ошибки без ваших просьб. Это позволит получать рабочий вариант кода быстрее.

Правило №6. Просите предложить разные варианты

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

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

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

Правило №7. Проверяйте то, чему учит вас ИИ

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

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

О вайбкоддинге

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

Без соблюдения Правила №1 (проведения тщательного review) приложение очень быстро превратится в «черный ящик», который живет по своим правилам. По мере разрастания приложения ошибки и уязвимости будут накапливаться в коде. Хорошо, если такой код не приведет в итоге к убыткам или потере важных данных.

О приросте производительности

Возникает еще один вопрос. В интернете можно найти массу утверждений от разных людей о том, что у них 90 — 99% процентов кода создают нейросети. О том, что производительность выросла в разы.

Но не понятно как они это посчитали. А ощущения — штука обманчивая.

На самом деле, уже проводились исследования на группах программистов, в которых эти показатели описывали и замеряли. В итоге данные о росте производительности были гораздо скромнее (20%). В других иследованиях даже было отмечено замедление.

Можно сделать выводы, что кричащие приросты были получены на совсем уж простых проектах. Чем выше сложность того, что вы делаете, тем прирост производительности будет меньше.

Также, стоит отметить, для части языков (и стеков) ассистенты показывают себя хуже чем для других.

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

Заключение

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

Чем сложнее проект, тем важнее сохранять инженерную дисциплину: делать review, держать код чистым, осознанно работать с контекстом и постоянно проверять результаты. В этом смысле работа с ИИ не отменяет привычных практик разработки, а наоборот — делает их еще более значимыми.

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