Claude Code ile Yapay Zeka Odaklı Entegrasyon Mühendisliği: Gerçek Bir Hata Ayıklama Oturumu

Çoğu "yapay zeka kodumu yazdı" hikayesi, temiz bir komut istemi ve temiz bir sonuç sunan demolar şeklindedir. Bu ise öyle değil. Bu, gerçek bir APIANT entegrasyon ürünü üzerinde yapılan gerçek bir oturum; gerçek komut istemleri, yanlış adımlar, düzeltmeler ve insan hafızasının makineyi yendiği an da dahil.

Mesele yapay zekanın etkileyici olması değil. Mesele, masaya oturup işi yaptığınızda iş birliğinin gerçekte nasıl göründüğüdür.

Kurulum

Bu ürün, CRMConnect entegrasyonlarımızdan biridir. Mindbody'den HubSpot'aBir müşteri, birden fazla ödeme yöntemiyle yapılan satışların yanlış senkronize edildiğini bildirdi. Üç ödeme yöntemiyle yapılan 8.400 dolarlık bir satış, HubSpot'ta tek bir 400 dolarlık işlem olarak göründü. Geri kalan 8.000 dolar ise işlem hattında yoktu.

Mühendislik çalışmalarını GitHub Issues üzerinden takip ediyoruz. Müşteri görüşmeleri HubSpot Service Hub'da gerçekleşiyor. Oturum, geliştiricinin yapay zekayı işe yönlendirmesiyle başladı.

Çabuk: “Ödeme sorununa bakın”

Yapay zeka, deponun GitHub sorunlarını aradı, açık olayı buldu, tüm içeriği çekti ve geri okudu: iki üretim yürütme kimliği kanıt olarak gösterilen çoklu ödeme satış hatası. Hiçbir yönlendirmeye gerek kalmadı. Ardından, tahmin etmek yerine, bir sonraki adımı açık ve net bir şekilde sordu.

Çabuk: “Mantık ne yapıyor ve hangi otomasyon/eylemler gerçekleştiriliyor?”

Yapay zeka, platformdan ilgili otomasyonu yükledi, yapısını adım adım inceledi ve hatayı tam olarak açıkladı. Otomasyon, her HubSpot işlemi için bir tekilleştirme anahtarı oluşturuyor. Çoklu ödeme satışlarında Mindbody, her ödeme yöntemi için aynı anahtarı paylaşan bir satır döndürüyor; bu nedenle ikinci ve üçüncü satırlar, birinci satır tarafından oluşturulan işlemle çakıştı ve tutarları sessizce silindi.

Faydalı. Ancak müteahhit zaten daha büyük bir avantaja sahipti.

Her şeyi yeniden yönlendiren ipucu

Çabuk: “Bu anlaşma için kullanılan benzersiz tanımlayıcıyı, crmconnect-mindbody-zoho projesinde kullandığımız yöntemle karşılaştırın. Orada sorunu çözdüğümüzü sanıyordum. Lazer odaklı bir karşılaştırma yapın.”

Bu tek cümle, işin gidişatını değiştirdi. İnşaatçı bir çözümden bahsetmedi. Benzer bir ürüne işaret ederek, aslında "Gidip okuyun" dedi.

Yapay zeka da öyle yaptı. Kapıyı açtı. Mindbody'den Zoho'ya Tamamen ayrı bir ürün olan entegrasyon, geçmiş satışları işleyen otomasyonu buldu ve okudu. Ardından ödeme kayıtlarını yazan alt programı buldu ve okudu. Özetler değil. Adım adım, gerçek otomasyon mantığı.

Odaklanmış bir karşılaştırma ile geri döndü. Zoho entegrasyonu gerçekten de bu sorunu çözmüştü, ancak farklı bir mimariyle:

• HubSpot ürünü, Mindbody'nin eski satış uç noktasını kullanarak, her satış satırı için tek bir sabit fiyatlı işlem kaydı oluşturur; bu uç nokta, önceden bölünmüş ödeme satırlarını döndürür.
• Zoho ürünü, Mindbody'nin yeni uç noktasını kullanarak, ana satın alma kaydının yanı sıra, her ödemenin kendi gerçek ödeme kimliğine sahip olduğu, kalemler ve ödemeler için ayrı alt kayıtlar oluşturur.

Yapay zekanın vardığı sonuç, Zoho'nun mimari olarak daha temiz olduğu yönündeydi ve başlangıçta üç nesneden oluşan modelin tamamını HubSpot'a aktarmayı önerdi.

İnşaatçı kapsamı daraltıyor.

İşte burada insan her şeyi dengede tuttu.

Çabuk: “4.0 sürümüne henüz hazır değiliz. Bunu sonraya bırakalım, şu anda müşteriler tarafından bildirilen eksik fırsatlarla ilgili sorunları çözmemiz gerekiyor.”

Yapay zeka, tatmin edici bir mimari yeniden yazım yönünde ilerlemişti. Geliştirici, sorunu asıl probleme indirgedi: Müşterinin yeni bir veri modeline değil, doğru işlem tutarlarına ihtiyacı vardı. Yapay zeka da bunu kabul etti, yeniden yazım önerisini gelecekteki bir madde olarak kapattı ve mevcut işlem otomasyonlarında cerrahi bir düzeltmeye odaklandı.

Bu düzeltme önemlidir. Yapay zeka, zarif genel çözümü bulmakta iyidir. Ancak zarif çözümün o anın gerektirdiğinden fazla olup olmadığını her zaman iyi bilemez. Geliştirici bu değerlendirmeyi tek bir cümleyle yaptı.

Yapay zeka daha sonra Zoho tasarımının ardındaki prensibi, yapısını kopyalamadan uyarladı: her satış kalemi için bir anlaşmayı uzlaştırmak, verileri Mindbody'nin daha zengin uç noktasından almak ve ilk ödemenin diğerlerini geçersiz kılmasına izin vermek yerine tutarı ödeme yöntemleri arasında doğru şekilde toplamak. Farklı platform, farklı işlemler, aynı temel fikir.

Önsezi

Tekrarlanan kayıtları kaldırma anahtarını yeniden düzenlerken, yapay zeka bileşenlerinden birine, yani tarihe baktı. Mantığı açıktı. Satış kimliği ve satış detay kimliği zaten anahtarı benzersiz kılıyor. Tarih gereksiz. Anahtarı basitleştirmek ve iki otomasyon arasındaki kırılganlık kaynağını ortadan kaldırmak için tarihi kaldırmayı önerdi.

İnşaatçının itiraz edebileceği bir kod referansı yoktu. Hafızası vardı.

Çabuk: "Sanırım tarihi eklememin sebebi gerekli olmasıydı (aynı işlemde 2 ödeme veya buna benzer garip bir durum)?"

İkisinin de mevcut otomasyondan bunu kanıtlayamadığı görüldü. Bu yüzden yapay zeka, otomasyonun sürüm geçmişine baktı. Otomasyonun 2021 yılına kadar uzanan doksan üç kayıtlı sürümü vardı. Yapay zeka, ilgili olanları bulana kadar değişiklik açıklamalarını okudu.

Ocak 2022'den itibaren:

"Aynı ürün için birden fazla ödeme yapıldığında benzersiz kalması için EPOCH MILLIS işlem kimliği kaydetme özelliği veritabanına eklendi."

Şubat 2022'den itibaren:

"Özel mülke göre fırsat bulma özelliğine satış tarihi eklendi, böylece önceki satışlara ilişkin ödemeler işleniyor."

İşte orada, inşaatçının kendi sözleriyle, dört yıl önce. Bir müşteri daha önceki bir satışa karşılık daha sonra ödeme yaptığında, Mindbody bu satışı yeni tarihte yeniden kaydeder. Anahtarda tarih olmadığı için, daha sonraki ödeme orijinal anlaşmayla çakışır ve kendi kaydını oluşturamaz. Tarih gereksiz değildi. Taksitli ve otomatik ödeme işlemlerini yönetmek için bilerek eklenmiş, yük taşıyıcı bir unsurdu.

Yapay zekânın yanıtı, tavsiyesini derhal geri çekmek ve bunu açıkça belirtmek oldu:

“Hatırladığınıza güvenin. Tarihi bilerek eklediyseniz, bu önemli bir bilgidir ve kaldırmak söz konusu bile olamaz. Sürüm geçmişinde buldum.”

Sonrasında işler daha da ileri gitti. Tarihin aynı kalması gerektiğinden, iki otomasyonun da tam olarak aynı tarih değerini üretmesi gerekiyordu, aksi takdirde anahtarlar eşleşmez ve mükerrer işlemler ortaya çıkardı. Orijinal otomasyon, tarihi belirli bir Mindbody alanından oluşturuyordu. Yapay zeka, yeni otomasyonu aynı API çağrısından, aynı saat dilimi dönüşümüyle, aynı alanı okuyacak şekilde yeniden yönlendirdi. Aynı girdi, aynı çıktı, anahtarların eşleşmesi garanti edildi.

Taksit ödeme işlemlerini sessizce bozacak bir gerileme yaşanmadı. Bunun nedeni yapay zekanın dikkatli olması değil, bir insanın sezgisini hatırlaması ve yapay zekanın bunu saniyeler içinde dört yıllık geçmiş verilerle doğrulayabilmesiydi.

İşin en zor kısmı: derle, çalıştır, hata izini oku, düzelt.

Tasarım tamamlandıktan sonra, süreç yinelemeli mühendisliğe dönüştü. Değişikliği geliştirme ortamında oluşturun, çalıştırın, yürütme izini okuyun, bir sonraki sorunu bulun, düzeltin, tekrar çalıştırın. Gerçek hatalar sıradandı:

• On altı kişiyle yapılan anlaşma oluşturma aşaması başarısızlıkla sonuçlandı. PROPERTY_DOESNT_EXIST Alan bağlamaları HubSpot'un dahili özellik adlarını taşımadığı için hatalar oluştu. Yapay zeka izleme kaydını okudu, bağlayıcının alan şemasını aldı ve her alanı doğru kimliğiyle yeniden bağladı.
• Platform, kaynak verilerdeki en uzun diziyi temel alarak yinelemeleri saydığı için ve ödeme dizisi satır öğeleri dizisinden daha uzun olduğu için, döngü bir kez çalışması gerekirken iki kez çalıştı. Yapay zeka, döngünün yalnızca satır öğelerini saymasını sağlayacak açık bir yineleme kontrolü ekledi.
• "Anlaşma bul" adımı, henüz bir anlaşma olmadığı halde tüm çalışmayı durdurdu çünkü varsayılan hata modu "bulunamadı" durumunu ölümcül bir hata olarak ele alıyordu. Yapay zeka, kardeş otomasyonun zaten nasıl ele aldığına uygun olarak, oluşturma dalının çalışabilmesi için bunu "hata durumunda devam et" moduna geçirdi.

Bunların hiçbiri göz alıcı değil. Bu, entegrasyon çalışmalarının gerçek özü. Değişen şey döngü hızıydı. Yapay zeka, adım adım yürütme izini tam olarak okuyabiliyor ve başarısız olan adımı anında belirleyebiliyordu, bu nedenle her düzeltme döngüsü dakikalar sürüyordu. Geliştirme testleri geçene kadar hiçbir şey müşteriye gönderilmiyordu.

Bu durum inşaatçılar için ne anlama geliyor?

Anlatıyı bir kenara bırakırsak, işte çalışma modeli:

• Yapay zekanın güçlü yönü okuma yeteneğidir. Tüm kardeş entegrasyonunu inceledi, daha önce çözdüğümüz bir sorunu çapraz referansla ele aldı, mimariyi iki farklı platforma uyarladı ve bir tasarım kararını doğrulamak için doksan farklı geçmiş sürümünü inceledi. Hiçbir insan bunu bir öğleden sonra yapamaz.
• İnsanın gücü hafıza ve muhakeme yeteneğindedir. “Bunu bir sebeple eklediğimi düşünüyorum” ifadesi hiçbir dosyada yok. “Henüz V4.0 için hazır değil” ifadesi de hiçbir dosyada yok. Her ikisi de ürünü deneyimlemekten kaynaklandı. Her biri sonucu değiştirdi.
• Hız, döngüden kaynaklanıyor. Hata izini okuyun, adımı düzeltin, yeniden çalıştırın. Genellikle hata ayıklamayı yavaşlatan, ne olduğunu yeniden oluşturmayı zorlaştıran engel ortadan kalktı.

Yapay zekâ odaklı entegrasyon mühendisliği, yapay zekânın tek başına çalışması veya insanın daha hızlı çalışması anlamına gelmez. Yapay zekâ, insanın zamanının olmadığı okuma işlemlerini yaparken, insan da kod tabanında bulunmayan bağlamı sağlar. Bunları bir araya getirdiğinizde, dört yıldır tekrar eden bir hata tek bir çalışma oturumunda anlaşılır, düzeltilir ve doğrulanır.

İşte hedef olarak belirlemeye değer iş akışı budur.