Rekayasa Integrasi Berbasis AI dengan Claude Code: Sesi Debug Nyata

Sebagian besar cerita "AI menulis kode saya" adalah demo dengan perintah yang jelas dan hasil yang jelas. Ini berbeda. Ini adalah sesi nyata pada produk integrasi APIANT yang sebenarnya, termasuk perintah aktual, kesalahan yang terjadi, koreksi, dan momen ketika ingatan manusia mengalahkan mesin.

Intinya bukanlah bahwa AI itu mengesankan. Intinya adalah seperti apa kolaborasi sebenarnya ketika Anda duduk dan mengerjakan pekerjaan tersebut.

Pengaturan

Produk ini adalah salah satu integrasi CRMConnect kami, Mindbody ke HubSpotSeorang pelanggan melaporkan bahwa penjualan yang dibayar dengan lebih dari satu metode pembayaran mengalami sinkronisasi yang salah. Penjualan sebesar $8.400 yang dibagi ke dalam tiga metode pembayaran muncul di HubSpot sebagai satu transaksi tunggal sebesar $400. Sisa $8.000 hilang dari pipeline.

Kami melacak pekerjaan rekayasa di GitHub Issues. Percakapan pelanggan berlangsung di HubSpot Service Hub. Sesi dimulai dengan pengembang mengarahkan AI ke pekerjaan tersebut.

Mengingatkan: “Perhatikan masalah pembayarannya”

AI tersebut mencari di GitHub issues repositori, menemukan insiden yang terbuka, mengambil seluruh isi laporan, dan membacanya kembali: sebuah bug penjualan multi-pembayaran, dengan dua ID eksekusi produksi yang dikutip sebagai bukti. Tidak perlu bimbingan. Kemudian, AI tersebut menanyakan langkah selanjutnya dengan bahasa yang jelas, bukan menebak-nebak.

Mengingatkan: “Apa fungsi logika tersebut dan otomatisasi/tindakan apa yang harus dilakukan?”

AI tersebut memuat otomatisasi yang relevan dari platform, menelusuri strukturnya langkah demi langkah, dan menjelaskan kegagalan tersebut secara tepat. Otomatisasi tersebut membangun kunci deduplikasi untuk setiap transaksi HubSpot. Untuk penjualan multi-pembayaran, Mindbody mengembalikan satu baris per metode pembayaran, semuanya berbagi kunci yang sama, sehingga baris kedua dan ketiga bertabrakan dengan transaksi yang dibuat oleh baris pertama dan jumlahnya dihilangkan secara diam-diam.

Berguna. Tapi pembangun itu sudah memiliki keunggulan yang lebih besar.

Petunjuk yang mengalihkan segalanya

Mengingatkan: “Bandingkan pengidentifikasi unik untuk kesepakatan ini dengan cara kita melakukannya pada proyek crmconnect-mindbody-zoho. Saya kira kita sudah menyelesaikannya di sana. Lakukan perbandingan yang sangat terfokus.”

Satu kalimat ini mengubah bentuk pekerjaan tersebut. Sang pembangun tidak menjelaskan solusi. Ia menunjuk pada produk sejenis dan berkata, pada intinya, bacalah produk itu.

Jadi, AI pun melakukannya. AI membuka Mindbody ke Zoho Integrasi, sebuah produk yang sepenuhnya terpisah, menemukan otomatisasi yang menangani riwayat penjualan, dan membacanya. Kemudian ia menemukan dan membaca subrutin yang menulis catatan pembayaran. Bukan ringkasan. Logika otomatisasi yang sebenarnya, langkah demi langkah.

Hasilnya berupa perbandingan yang lebih terfokus. Integrasi Zoho memang telah menyelesaikan masalah ini, tetapi dengan arsitektur yang berbeda:

• Produk HubSpot membuat satu kesepakatan tetap per baris penjualan, menggunakan endpoint penjualan lama dari Mindbody, yang mengembalikan baris pembayaran yang sudah dibagi sebelumnya.
• Produk Zoho membuat catatan pembelian utama ditambah catatan anak terpisah untuk item baris dan untuk pembayaran, menggunakan endpoint terbaru dari Mindbody, di mana setiap pembayaran memiliki ID pembayaran sebenarnya.

Hasil analisis AI menunjukkan bahwa Zoho memiliki arsitektur yang lebih bersih, dan awalnya AI mengusulkan untuk memindahkan seluruh model tiga objek tersebut ke HubSpot.

Kontraktor mengurangi cakupan proyek.

Di sinilah manusia menjaga agar semuanya tetap berpijak pada kenyataan.

Mengingatkan: “Belum siap untuk V4.0. Simpan saja untuk nanti, sekarang kita perlu memperbaiki masalah terkait kesepakatan yang hilang yang dilaporkan oleh pelanggan.”

AI tersebut telah mengarah pada penulisan ulang arsitektur yang memuaskan. Pembangun mempersempitnya kembali ke masalah sebenarnya: pelanggan membutuhkan jumlah transaksi yang benar, bukan model data baru. AI setuju, menutup proposal penulisan ulang sebagai item di masa mendatang, dan mempersempit ruang lingkup ke perbaikan tepat sasaran pada otomatisasi transaksi yang ada.

Koreksi itu penting. AI pandai menemukan solusi umum yang elegan. Namun, AI tidak selalu pandai mengetahui kapan solusi elegan tersebut lebih dari yang dibutuhkan saat itu. Pembuatnya menyampaikan penilaian itu dalam satu kalimat.

AI tersebut kemudian mengadaptasi prinsip di balik desain Zoho, tanpa meniru strukturnya: merekonsiliasi satu transaksi per item penjualan, mengambil data dari endpoint Mindbody yang lebih kaya, dan menggabungkan jumlah dengan benar di seluruh metode pembayaran alih-alih membiarkan pembayaran pertama menimpa yang lainnya. Platform berbeda, tindakan berbeda, ide dasar yang sama.

Firasat

Saat mengerjakan ulang kunci deduplikasi, AI melihat salah satu komponennya: tanggal. Alasannya jelas. ID penjualan dan ID detail penjualan sudah membuat kunci unik. Tanggal tersebut berlebihan. AI merekomendasikan untuk menghapusnya guna menyederhanakan kunci dan menghilangkan sumber kerentanan antara kedua otomatisasi tersebut.

Tukang bangunan itu tidak memiliki referensi kode untuk diperdebatkan. Dia hanya memiliki ingatan.

Mengingatkan: “Sepertinya saya menambahkan tanggal karena diperlukan (2 pembayaran dalam transaksi yang sama, atau hal aneh semacam itu)?”

Tak satu pun dari mereka dapat membuktikannya dari otomatisasi saat ini. Jadi, AI memeriksa riwayat versi otomatisasi tersebut. Otomatisasi tersebut memiliki sembilan puluh tiga versi yang tersimpan, sejak tahun 2021. AI membaca deskripsi perubahan hingga menemukan yang relevan.

Mulai Januari 2022:

“Menambahkan EPOCH MILLIS ke penyimpanan ID transaksi di basis data agar tetap unik saat beberapa pembayaran dilakukan untuk barang yang sama”

Mulai Februari 2022:

“Menambahkan tanggal penjualan untuk pencarian kesepakatan berdasarkan properti khusus sehingga memproses pembayaran pada penjualan sebelumnya”

Beginilah penjelasannya, menurut keterangan sang pengembang sendiri, empat tahun sebelumnya. Ketika pelanggan melakukan pembayaran di kemudian hari untuk penjualan sebelumnya, Mindbody akan mencatat kembali penjualan tersebut pada tanggal baru. Tanpa tanggal yang tercantum, pembayaran di kemudian hari akan bertabrakan dengan transaksi awal dan tidak dapat tercatat sendiri. Tanggal tersebut bukanlah hal yang sia-sia. Tanggal itu merupakan penopang, sengaja ditambahkan untuk menangani pembayaran cicilan dan pembayaran otomatis.

Respons AI tersebut adalah segera membatalkan rekomendasinya dan menyatakannya dengan jelas:

“Percayai ingatan itu. Jika Anda menambahkan tanggal dengan sengaja, itu penting, dan menghapusnya tidak mungkin. Ditemukan di riwayat versi.”

Kemudian prosesnya berlanjut. Karena tanggal harus tetap sama, kedua otomatisasi tersebut perlu menghasilkan nilai tanggal yang persis sama, jika tidak, kunci tidak akan cocok dan akan muncul transaksi duplikat. Otomatisasi asli membangun tanggal dari bidang Mindbody tertentu. AI mengarahkan ulang otomatisasi baru untuk membaca bidang yang identik tersebut, dari panggilan API yang sama, dengan konversi zona waktu yang sama. Input yang sama, output yang sama, kunci dijamin cocok.

Kesalahan yang seharusnya secara diam-diam merusak penanganan pembayaran cicilan tidak pernah terjadi. Bukan karena AI berhati-hati, tetapi karena manusia mengingat firasat dan AI dapat memverifikasinya dengan data empat tahun dalam hitungan detik.

Bagian yang tidak glamor: membangun, menjalankan, membaca jejak, memperbaiki

Setelah desain disepakati, proses selanjutnya menjadi rekayasa iteratif. Buat perubahan di lingkungan pengembangan, jalankan, baca jejak eksekusi, temukan masalah berikutnya, perbaiki, jalankan lagi. Bug sebenarnya adalah bug biasa:

• Langkah pembuatan kesepakatan gagal dengan enam belas orang. PROPERTY_DOESNT_EXIST Terjadi kesalahan karena pengikatan bidang tidak membawa nama properti internal HubSpot. AI membaca jejak, mengambil skema bidang konektor, dan mengikat ulang setiap bidang dengan ID yang benar.
• Sebuah perulangan berjalan dua kali padahal seharusnya hanya sekali, karena platform menghitung iterasi berdasarkan array terpanjang dalam data sumber, dan array pembayaran lebih panjang daripada array item baris. AI menyisipkan kontrol iterasi eksplisit sehingga perulangan hanya menghitung item baris.
• Langkah "cari kesepakatan" menghentikan seluruh proses ketika belum ada kesepakatan, karena mode kesalahan default-nya menganggap "tidak ditemukan" sebagai kesalahan fatal. AI kemudian mengubahnya menjadi lanjutkan jika terjadi kesalahan sehingga cabang pembuatan dapat berjalan, sesuai dengan cara otomatisasi sebelumnya menanganinya.

Semua ini tidaklah glamor. Inilah tekstur sebenarnya dari pekerjaan integrasi. Yang berubah adalah kecepatan perulangan. AI dapat membaca jejak eksekusi langkah demi langkah secara lengkap dan langsung menunjukkan langkah yang gagal, sehingga setiap siklus perbaikan hanya membutuhkan beberapa menit. Tidak ada yang dikirim ke pelanggan sampai pengujian pengembang berhasil.

Apa artinya ini bagi para Pembangun?

Singkirkan narasi yang bertele-tele, dan inilah model kerjanya:

• Kelebihan AI ini adalah kemampuan membaca. Proses itu mempelajari seluruh integrasi antar sistem, membandingkan masalah yang sudah kami selesaikan, mengadaptasi arsitektur di dua platform berbeda, dan menelusuri sembilan puluh versi riwayat untuk memverifikasi satu keputusan desain. Tidak ada manusia yang bisa melakukan itu dalam satu sore.
• Kekuatan manusia terletak pada ingatan dan penilaian. “Saya rasa saya menambahkan itu karena suatu alasan” tidak ada dalam file mana pun. “Belum siap untuk V4.0” juga tidak ada dalam file mana pun. Keduanya berasal dari pengalaman menggunakan produk tersebut. Masing-masing mengubah hasilnya.
• Kecepatan tersebut berasal dari putaran. Baca jejaknya, perbaiki langkahnya, jalankan ulang. Hambatan yang biasanya memperlambat proses debugging dan merekonstruksi apa yang terjadi, kini hilang.

Rekayasa integrasi berbasis AI bukanlah AI yang bekerja sendirian, dan bukan pula manusia yang bekerja lebih cepat. Ini adalah AI yang melakukan pembacaan yang tidak sempat dilakukan manusia, dan manusia yang menyediakan konteks yang tidak tercatat dalam kode program. Gabungkan keduanya, dan bug berulang yang sudah berusia empat tahun dapat dipahami, diperbaiki, dan diverifikasi dalam satu sesi kerja.

Itulah alur kerja yang layak untuk diupayakan.