Автор: Марк Уинтерингэм (Mark Winteringham)
Оригинал статьи
Перевод: Ольга Алифанова

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

Какое влияние эти инструменты окажут на качество работы разработчиков и создаваемых ими продуктов? Я решил исследовать этот вопрос, создав проект с использованием двух популярных ИИ-IDE для разработки — Cursor и Windsurf. Ниже – то, чему я научился, и мои наблюдения, как эти всё более популярные инструменты могут повлиять на нашу работу как инженеров по качеству.

Понимание контекста разработки и тестирования

Начнём с самого проекта. В последние несколько лет я разрабатывал веб-сайт для практики автоматизации тестирования и других тестовых задач, известный как restful-booker-platform. Развернутую версию можно найти по адресу https://automationintesting.online.

Этот сайт служил основой для многих моих тренингов. Однако за последние годы он начал немного устаревать. Долгое время я хотел обновить фронтенд сайта с использованием более современного фреймворка.

Когда я впервые сделал инструмент публичным, фронтенд работал, как показано на схеме ниже:

Схема 1: Изначальная архитектура restful-booker-platform. Пользователь подключается к rbp-proxy, который, в свою очередь, получает React-компоненты из assets-api. rbp-proxy также может подключаться к другим API.

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

Архитектура NextJS, которую я хотел создать, показана на схеме 2:

Схема 2: Предлагаемая архитектура NextJS для restful-booker-platform. Пользователь подключается к API на NextJS, который предоставляет React-компоненты и маршруты к другим API. Это упрощает процесс рендеринга UI и доступа к другим API.

Учитывая это, вот мои критерии успеха:

1. UI должен работать так же, как до перехода.
2. Все автоматизированные тесты должны успешно отработать.
3. Я должен добиться понимания, как работает NextJS.

Поставив цель, я выбрал первую ИИ-IDE для разработки, загрузил проект и приступил к работе.

Что такое Cursor and Windsurf?

Прежде чем перейти к моему опыту работы с Cursor и Windsurf, стоит обсудить, что это за инструменты и чем они отличаются от других IDE.

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

ИИ-IDE, такие как Cursor и Windsurf, интегрируют эти функции (и не только) прямо в IDE, чтобы пользователь мог быстро к ним обратиться. Обе IDE построены на базе открытой Visual Studio ("VS") Code, но в отличие от «обычной» VS Code, эти инструменты предлагают:

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

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

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

Начало работы с Cursor

С учетом моих целей я начал миграцию с Cursor. И Cursor, и Windsurf предлагают пробные версии, которые позволяют использовать определённое количество автодополнений и вызовов их ИИ-агентов. План был такой: сначала использовать Cursor, пока не исчерпаю все бесплатные кредиты, а затем перейти к Windsurf.

Миграция проекта с Cursor: шаг за шагом, пока не научусь бегать

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

Я начал с создания минимального проекта NextJS в стиле «hello-world». Просьба к агенту сделать это прошла без проблем, и через несколько минут у меня был рабочий проект NextJS с базовым процессом.

Далее я перенёс один компонент из старого проекта в новый и сосредоточился на том, чтобы он мог получать данные из моих бэкенд-API. И снова успех!

Я начал обретать уверенность и постепенно переносил всё больше компонентов за один запрос, всё больше полагаясь на ИИ-агента в Cursor. Сначала я просил перенести один компонент, потом два вместе, потом четыре и так далее. Всё шло отлично: я экономил время, и новый фронтенд постепенно собирался.

И тут всё пошло наперекосяк.

Справляемся с последствиями применения Cursor: самоуверенность и прочие проблемы

Вначале я довольно быстро справлялся с миграцией, но затем одновременно возникли две серьёзные проблемы. Во-первых, я исчерпал лимит пробной версии Cursor. Во-вторых, в мигрировавшем фронтенде начали происходить странные вещи.

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

Например, три разных файла, а не один, занимались маршрутизацией к моему Room API. Хуже всего было то, что я до сих пор не понимал, как работает NextJS. Я слишком полагался на Cursor.

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

Когда настало время попробовать Windsurf, я решил замедлиться и сосредоточиться на небольших, внятных задачах. Я также чаще пользовался автодополнением, чтобы перестроить код проекта в более разумную структуру. И я расширял объём работы ТОЛЬКО тогда, когда был уверен в происходящем и доволен организацией проекта.

Переход на Windsurf: миграция unit-тестов

Наконец, когда я правильно организовал проект и перенёс все компоненты, я начал переносить unit-тесты. Сначала я решил не волноваться о том, проходят они или нет — мне просто нужно было их запустить. Затем я работал с агентом Windsurf, исправляя каждый не прошедший тест.

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

Тем не менее, тесты проходили, новый фронтенд выглядел хорошо. Всё, что оставалось, — это провести быстрое исследовательское тестирование, когда я обнаружил…

Баг кэширования! Работа с Windsurf и Claude

Ах, «баг кэширования», который вылез на финальном этапе проекта и чуть не сорвал всю работу.

После того как я завершил миграцию рабочего кода и тестов, исправил тесты и собрал всё в Docker-образ, появилась необычная ошибка. Что должно было происходить: каждый раз, когда на restful-booker-platform открывается непрочитанное сообщение, счётчик непрочитанных сообщений уменьшается на один, а индикатор в навигационном меню уменьшается на один или исчезает, если счёт равен нулю. Это точно работало при запуске приложения локально, но при запуске через Docker… счётчик всегда оставался прежним!

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

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

К счастью, мои усилия по отладке дали результат. Если хотите «погрузиться» в мои мучения, можно посмотреть переписку с Claude, либо ознакомиться с чатом в прикреплённом PDF.

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

Чему я научился

Возможно, вы встречали термин «vibe coding». Суть его в том, что разработчик полностью отдает контроль ИИ при разработке проектов или новых функций. Когда я начинал свой проект по миграции, я не знал этого термина. Однако оглядываясь назад, я вполне мог заниматься vibe coding, не осознавая этого.

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

Vibe coding будет до какой-то степени жизнеспособен, что приводит меня к моему первому наблюдению как инженера по качеству:

Понимание активности применения ИИ в командах

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

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

И здесь возникает вопрос…

Чем ответить на увеличение скорости разработки при помощи ИИ

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

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

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

Тем не менее, не стоит отказываться от этих инструментов и отвергать все их преимущества. Команды должны научиться использовать их эффективно. Это значит, что нам, как инженерам по качеству, придётся:

Поддерживать команды в правильном использовании ИИ для подходящих задач

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

В заключение

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

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

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

Дополнительная информация

• Supercharging Your Test Automation Code With AI Assistance In Your IDE, Valentin Agapitov
• Testing The Quality Of ChatGPT Responses: A Report From The Field, Paul Maxwell-Walters
• In-Sprint Test Automation On Agile Teams: Yes You Can!, Swathika Visagn