Интеграционная инженерия с приоритетом ИИ с использованием кода Claude: реальная сессия отладки

Большинство историй типа «ИИ написал мой код» — это демонстрации с понятным запросом и понятным результатом. Но это не тот случай. Это реальная сессия по реальному продукту интеграции APIANT, включая реальные запросы, ошибки, исправления и момент, когда человеческая память превзошла машину.

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

Настройка

Данный продукт является одной из наших интеграций с CRMConnect. От разума и тела до HubSpotКлиент сообщил, что продажи, оплаченные несколькими способами, синхронизировались неправильно. Продажа на сумму 8400 долларов, разделенная на три способа оплаты, отобразилась в HubSpot как одна сделка на 400 долларов. Остальные 8000 долларов отсутствовали в воронке продаж.

Мы отслеживаем работу инженеров в GitHub Issues. Взаимодействие с клиентом происходит в HubSpot Service Hub. Сессия началась с того, что разработчик указал ИИ на задачу.

Быстрый: «Рассмотрите вопрос оплаты»

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

Быстрый: «Что делает эта логика и какие именно действия/автоматизация выполняются?»

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

Полезно. Но у застройщика и так было более веское преимущество.

Подсказка, которая всё изменила.

Быстрый: «Сравните этот уникальный идентификатор сделки с тем, как мы это делаем в проекте crmconnect-mindbody-zoho. Я думал, мы уже решили эту проблему. Проведите целенаправленное сравнение».

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

Так и сделал ИИ. Он открыл Mindbody to Zoho Интеграция, совершенно отдельный продукт, обнаружила систему автоматизации, обрабатывающую историю продаж, и считала её данные. Затем она нашла и считала подпрограмму, которая записывает платежные записи. Не сводки. А саму логику автоматизации, шаг за шагом.

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

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

Искусственный интеллект посчитал, что Zoho имеет более чистую архитектуру, и первоначально предложил перенести всю трехкомпонентную модель в HubSpot.

Строитель сокращает объем работ.

Именно здесь человек сохранял связь с реальностью.

Быстрый: «Мы ещё не готовы к версии 4.0. Отложим это на потом, сейчас нам нужно исправить проблемы с отсутствующими сделками, о которых сообщал клиент».

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

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

Затем ИИ адаптировал принцип, лежащий в основе дизайна Zoho, не копируя его структуру: сверять каждую позицию в договоре, получать данные из более подробного источника Mindbody и корректно суммировать сумму по всем способам оплаты, вместо того чтобы первый платеж перезаписывал остальные. Разная платформа, разные действия, но та же основная идея.

Предчувствие

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

У строителя не было никаких ссылок на строительные нормы, чтобы спорить. У него была хорошая память.

Быстрый: «Кажется, я добавил дату, потому что она была необходима (два платежа по одной транзакции или что-то подобное)?»

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

С января 2022 года:

«Добавлена поддержка EPOCH MILLIS для сохранения идентификаторов сделок в базе данных, чтобы обеспечить их уникальность при совершении нескольких платежей по одному и тому же товару».

С февраля 2022 года:

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

Вот она, по словам самого застройщика, четыре года назад. Когда клиент вносит платеж позже по предыдущей сделке, Mindbody повторно регистрирует эту сделку на новую дату. Без даты в ключе, более поздний платеж конфликтует с первоначальной сделкой и не может получить собственную запись. Дата не была лишней. Она была основной, намеренно добавленной для обработки платежей в рассрочку и автоматических платежей.

В ответ ИИ немедленно отменил свою рекомендацию и прямо заявил об этом:

«Доверьтесь своей памяти. Если вы добавили дату намеренно, она является несущей, и удалять её не имеет смысла. Нашёл её в истории версий».

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

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

Самая неприятная часть: сборка, запуск, чтение трассировки, исправление.

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

• Этап заключения сделки провалился с шестнадцатью PROPERTY_DOESNT_EXIST Ошибки возникали из-за того, что привязки полей не содержали внутренних имен свойств HubSpot. Искусственный интеллект считал трассировку, получил схему полей коннектора и повторно привязал каждое поле с его правильным идентификатором.
• Цикл выполнился дважды вместо одного раза, потому что платформа считала итерации по самому длинному массиву в исходных данных, а массив платежей был длиннее массива позиций. Искусственный интеллект добавил явный контроль итераций, чтобы цикл считал только позиции.
• Этап «поиск сделки» останавливал весь процесс, когда сделки еще не существовало, поскольку в режиме обработки ошибок по умолчанию сообщение «сделка не найдена» рассматривалось как критическая ошибка. Искусственный интеллект переключил его в режим продолжения при ошибке, чтобы могла запуститься ветка создания, аналогично тому, как это уже обрабатывалось в смежных автоматизированных процессах.

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

Что это значит для строителей?

Отбросив повествование, получаем рабочую модель:

• Сильная сторона ИИ — это чтение. Оно изучило всю интеграцию родственных систем, сопоставило ее с уже решенной нами проблемой, адаптировало архитектуру для двух разных платформ и проанализировало девяносто версий истории, чтобы проверить одно из проектных решений. Ни один человек не делает этого за один день.
• Сильная сторона человека — это память и способность к суждению. Фраза «Думаю, я добавил это не просто так» отсутствует в любом файле. Фраза «Пока не готово к версии 4.0» также отсутствует в любом файле. Обе фразы появились в результате непосредственного использования продукта. Каждая из них повлияла на результат.
• Скорость обеспечивается за счёт замкнутого контура. Прочитайте трассировку, исправьте шаг, запустите заново. Исчезла проблема, обычно замедляющая отладку и восстановление произошедшего.

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

Именно к такому рабочему процессу стоит стремиться.