AX на всех этапах жизненного цикла разработки — от генерации кода

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

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

Я также использую AGENTS.md, чтобы заранее объяснить структуру и правила проекта и заставить ИИ работать в рамках этих правил. С помощью SKILL.md я предоставляю только контекст, необходимый для каждой задачи, позволяя ИИ сосредоточиться на ней. Если в AGENTS.md содержатся общие правила, которые всегда применяются ко всему проекту, то SKILL.md больше ориентирован на выборочное предоставление знаний и методов работы, необходимых для текущей задачи. Для одной задачи также можно комбинировать несколько Skills.

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

2. Огромный объём кода прошёл тесты — можно ли расслабиться?

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

Итак, можем ли мы теперь чувствовать себя в безопасности? Если немного подумать — не совсем. Код создал ИИ, и ИИ также решил, какие тесты необходимы. Тот факт, что программа прошла несколько тестов, которые ИИ счёл необходимыми, не означает, что она достаточно надёжна. Конечно, это проблема не только кода, сгенерированного ИИ. Даже когда мы создавали программы сами, идеального на 100% программного обеспечения не существовало. Непредвиденные проблемы возникали в рабочей среде даже после достаточного тестирования и развёртывания, поэтому мы проверяли журналы, анализировали причину и изменяли код. Затем мы добавляли тесты, чтобы та же проблема не возникала снова.

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

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

• Атаки с использованием аномальных входных данных

• Многократная обработка одного и того же запроса

• Ошибки данных, возникающие при одновременном поступлении нескольких запросов

• Проблемы, при которых суммы платежей или расчётов обрабатываются неправильно

• Порядок выполнения, который разработчик никогда не предусматривал

• Если способ создания кода меняется в соответствии с эпохой ИИ, то должен измениться и способ его проверки.

3. Давайте добавим ИИ и в автоматизацию тестирования

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

Это не означает, что нам нужно с нуля создавать огромную отдельную систему тестирования. Инструменты для написания кода с помощью ИИ уже умеют читать код проекта, выполнять команды, а также проверять результаты тестов и журналы ошибок. Можно начать с того, чтобы поручить им запускать уже используемые нами тесты JUnit, анализировать сбои и добавлять новые тестовые случаи. Для веб-интерфейсов можно использовать существующие инструменты автоматизации браузера, такие как Playwright или Selenium, а для проверки безопасности — такие инструменты, как ZAP. Также появляются инструменты, которые сами обеспечивают генерацию и изменение тестов на основе ИИ, например последние версии Playwright.

В конечном счёте вместо создания новых инструментов тестирования с нуля мы добавляем ИИ до и после уже используемых инструментов, таких как JUnit, Playwright, Selenium и ZAP. Так же как мы уже делаем при генерации кода, можно поручить процессу тестирования многократно создавать сценарии → выполнять их → проверять результаты → добавлять новые тесты там, где покрытие недостаточно.

Даже это само по себе может значительно сократить объём тестирования, который раньше разработчикам приходилось продумывать и писать самостоятельно. Однако одно ограничение сохраняется. Сколько бы тестов мы ни создавали, они всё равно работают в пределах того, что мы учитывали во время разработки. Так где же найти проблемы, которые мы не смогли предвидеть?

4. Можно ли передавать данные из рабочей среды обратно в тесты?

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

В эпоху ИИ нельзя ли также немного автоматизировать этот процесс?

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

5. Нужна ли нам огромная система, прежде чем мы сможем начать?

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

JUnit для тестирования Java

• Selenium или Playwright для автоматизации тестирования браузера

• ZAP для тестирования безопасности

• n8n в качестве инструмента автоматизации для соединения этапов рабочего процесса

• Локальная LLM, когда внутренний код или рабочие данные трудно отправить во внешнюю систему

• Например, в очень простой конфигурации локальная LLM создаёт сценарии тестирования, а такие инструменты, как JUnit, Playwright, Selenium или ZAP, выполняют их. Затем ИИ анализирует результаты и журналы и добавляет новые тесты. Если среда затрудняет передачу внутреннего кода или рабочих данных за её пределы, этот ИИ можно настроить как локальную LLM. Такой инструмент, как n8n, может соединить эти этапы.

Например, предельно простая схема может выглядеть так.

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

Заключение

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

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

Когда изменения, начавшиеся с генерации кода, шаг за шагом распространятся на проверку и эксплуатацию, разве сам процесс разработки наконец не войдёт в эпоху AX?

zacca

zacca