הנדסת אינטגרציה מבוססת בינה מלאכותית עם קלוד קוד: מפגש ניפוי שגיאות אמיתי
סיור מלא בהנדסת אינטגרציה מבוססת בינה מלאכותית, כולל הנחיות ממשיות

רוב סיפורי "בינה מלאכותית כתבה את הקוד שלי" הם הדגמות עם הנחיה נקייה ותוצאה נקייה. זה לא זה. זוהי סשן אמיתי על מוצר אינטגרציה אמיתי של APIANT, כולל ההנחיות בפועל, הפניות הלא נכונות, התיקונים והרגע שבו זיכרון אנושי ניצח את המכונה.
העניין הוא לא שבינה מלאכותית מרשימה. העניין הוא איך נראה שיתוף הפעולה בפועל כשיושבים ועושים את העבודה.
ההתקנה
המוצר הוא אחת מהאינטגרציות שלנו עם CRMConnect, מגוף-נפש להאבספוטלקוח דיווח שמכירות ששולמו ביותר מאמצעי תשלום אחד הסתנכרנו באופן שגוי. מכירה של 8,400 דולר המחולקת לשלוש אמצעי תשלום הופיעה ב-HubSpot כעסקה אחת של 400 דולר. 8,000 הדולר הנותרים חסרו בצינור המכירות.
אנו עוקבים אחר עבודות הנדסיות ב-GitHub Issues. שיחת הלקוחות נמצאת ב-HubSpot Service Hub. הסשן התחיל כאשר הקבלן כיוון את הבינה המלאכותית אל העבודה.
לְעוֹרֵר: "לבדוק את נושא התשלום"
הבינה המלאכותית חיפשה בבעיות GitHub של המאגר, מצאה את התקרית הפתוחה, שלפה את גוף הקובץ המלא וקראה אותו בחזרה: באג מכירות של תשלומים מרובים, עם שני מזהי ביצוע מוצר שצוינו כראיה. לא נדרשה החזקת יד. לאחר מכן היא ביקשה את הצעד הבא במילים פשוטות במקום לנחש.
לְעוֹרֵר: "מה עושה הלוגיקה ואילו אוטומציה/פעולות?"
הבינה המלאכותית טענה את האוטומציה הרלוונטית מהפלטפורמה, עברה על המבנה שלה שלב אחר שלב, והסבירה במדויק את הכשל. האוטומציה בונה מפתח מניעת כפילויות עבור כל עסקת HubSpot. עבור מכירות מרובות תשלומים, Mindbody מחזירה שורה אחת לכל אמצעי תשלום, כאשר כולן חולקות את אותו מפתח, כך ששורות שתיים ושלוש התנגשו בעסקה שנוצרה על ידי שורה אחת והסכומים שלהן בוטלו בשקט.
שימושי. אבל לבונה כבר היה יתרון חזק יותר.
הרמז שהפך את הכל מחדש
לְעוֹרֵר: "השווה את המזהה הייחודי הזה עבור העסקה לאופן שבו אנחנו עושים את זה עם פרויקט crmconnect-mindbody-zoho. חשבתי שפתרנו את זה שם. בצע השוואה ממוקדת לייזר."
משפט אחד זה שינה את צורת העבודה. הקבלן לא תיאר תיקון. הוא הצביע על מוצר אחר ואמר, למעשה, לכו לקרוא אותו.
אז הבינה המלאכותית עשתה זאת. היא פתחה את מיינדבודי לזוהו אינטגרציה, מוצר נפרד לחלוטין, איתרה את האוטומציה שמטפלת במכירות היסטוריות, וקראה אותה. לאחר מכן היא מצאה וקראה את תת-השגרה שכותבת רשומות תשלום. לא סיכומים. לוגיקת האוטומציה בפועל, שלב אחר שלב.
זה חזר עם השוואה ממוקדת. האינטגרציה של Zoho אכן פתרה את זה, אבל עם ארכיטקטורה שונה:
- מוצר HubSpot כותב עסקה אחת שטוחה לכל שורת מכירה, תוך שימוש בנקודת הקצה הישנה של Mindbody למכירות, אשר מחזירה שורות תשלום מפוצלות מראש.
- מוצר Zoho כותב רשומת רכישה ראשית בתוספת רשומות צאצא נפרדות עבור פריטי שורה ותשלומים, באמצעות נקודת הקצה החדשה יותר של Mindbody, שבה כל תשלום נושא מזהה תשלום אמיתי משלו.

הבינה המלאכותית הסיקרה ש-Zoho נקייה יותר מבחינה ארכיטקטונית, ותחילה הציעה להעביר את מודל שלושת האובייקטים כולו ל-HubSpot.
הקבלן מושך את ההיקף לאחור
זה המקום שבו האדם שמר על דברים מקורקעים.
לְעוֹרֵר: "עדיין לא מוכן לגרסה 4.0. שמור את זה לאחר כך, עכשיו אנחנו צריכים לתקן את הבעיות עם עסקאות חסרות שדווחו על ידי הלקוח."
הבינה המלאכותית נסחפה לעבר שכתוב ארכיטקטורה מספק. הקבלן קיצר את הבעיה לבעיה האמיתית: הלקוח זקוק לסכומי עסקה נכונים, לא למודל נתונים חדש. הבינה המלאכותית הסכימה, סגרה את הצעת השכתוב כפריט עתידי, והתמקדה מחדש בתיקון כירורגי של אוטומציות העסקאות הקיימות.
לתיקון הזה יש משמעות. בינה מלאכותית טובה במציאת פתרון אלגנטי כללי. היא לא תמיד טובה בידיעה מתי הפתרון האלגנטי עולה על מה שהרגע דורש. הקבלן סיפק את השיפוט הזה במשפט אחד.
לאחר מכן, הבינה המלאכותית עיבדה את העיקרון שמאחורי העיצוב של Zoho, מבלי להעתיק את המבנה שלו: ליישב עסקה אחת לכל פריט מכירה, לאסוף את הנתונים מנקודת הקצה העשירה יותר של Mindbody, ולצבור את הסכום בצורה נכונה בין אמצעי התשלום השונים במקום לתת לתשלום הראשון לדרוס את השאר. פלטפורמה שונה, פעולות שונות, אותו רעיון בסיסי.
תחושת הבטן
בזמן עיבוד מחדש של מפתח ביטול הכפילויות, הבינה המלאכותית בחנה אחד ממרכיביו: תאריך. ההיגיון שלה היה ברור. מזהה המכירה ומזהה פרטי המכירה כבר הופכים את המפתח לייחודי. התאריך מיותר. היא המליצה להשמיט אותו כדי לפשט את המפתח ולהסיר מקור לשבריריות בין שתי האוטומציות.
לבונה לא היה מקור קוד להתווכח איתו. היה לו זיכרון.
לְעוֹרֵר: "אני זוכר שהוספתי את התאריך כי היה צורך בכך (2 תשלומים באותה עסקה, או משהו מוזר כזה)?"
אף אחד מהם לא הצליח להוכיח זאת מהאוטומציה הנוכחית. אז הבינה המלאכותית נכנסה להיסטוריית הגרסאות של האוטומציה. לאוטומציה היו תשעים ושלוש גרסאות שמורות, החל משנת 2021. הבינה המלאכותית קראה את תיאורי השינויים עד שמצאה את הרלוונטיים.

מינואר 2022:
"נוסף EPOCH MILLIS לשמירת מזהה עסקה במסד הנתונים כדי לשמור על ייחודיותו כאשר מתבצעים תשלומים מרובים על אותו פריט"
מפברואר 2022:
"נוסף תאריך מכירה עבור חיפוש עסקה לפי נכס מותאם אישית כך שיעבד תשלומים על מכירות קודמות"
כך זה היה, במילותיו של הקבלן עצמו, ארבע שנים קודם לכן. כאשר לקוח מבצע תשלום מאוחר יותר כנגד מכירה קודמת, Mindbody משחזרת את המכירה הזו בתאריך החדש. ללא התאריך במפתח, התשלום המאוחר יותר מתנגש בעסקה המקורית ואינו יכול לקבל רישום משלו. התאריך לא היה מיותר. הוא היה נושא עומס, ונוסף במכוון כדי לטפל בתשלומים ובתשלומים אוטומטיים.

תגובת הבינה המלאכותית הייתה לבטל את המלצתה באופן מיידי ולומר זאת בבירור:
"תסמוך על הזיכרון הזה. אם הוספת את התאריך בכוונה, הוא נושא עומס, והסרה שלו אינה אפשרית. מצאתי את זה בהיסטוריית הגרסאות."
לאחר מכן זה הלך צעד קדימה. מכיוון שהתאריך היה צריך להישאר, שתי האוטומציות היו צריכות לייצר את אותו ערך תאריך בדיוק, אחרת המפתחות לא יתאימו ועסקאות כפולות היו מופיעות. האוטומציה המקורית בונה את התאריך משדה ספציפי של Mindbody. הבינה המלאכותית כיוונה מחדש את האוטומציה החדשה כדי לקרוא את אותו שדה, מאותה קריאה ל-API, עם אותה המרת אזור זמן. אותו קלט, אותו פלט, מפתחות תואמים מובטחים.
רגרסיה שהייתה מפרקת בשקט את הטיפול בתשלומים מעולם לא התרחשה. לא בגלל שהבינה המלאכותית הייתה זהירה, אלא בגלל שבן אדם זכר תחושה והבינה המלאכותית יכלה לאמת אותה מול ארבע שנות היסטוריה תוך שניות.
החלק הלא זוהר: לבנות, להריץ, לקרוא את המעקב, לתקן
לאחר שהעיצוב היה סגור, זה הפך להנדסה איטרטיבית. בניית השינוי בסביבת פיתוח, הרצתו, קריאת עקבות הביצוע, חיפוש הבעיה הבאה, תיקון, הרצתה מחדש. הבאגים האמיתיים היו רגילים:
- שלב יצירת העסקה נכשל עם שש עשרה
PROPERTY_DOESNT_EXISTשגיאות מכיוון שאיגודי השדות לא נשאו את שמות המאפיינים הפנימיים של HubSpot. הבינה המלאכותית קראה את המעקב, שלפה את סכמת השדות של המחבר, ושלחה כל שדה עם המזהה הנכון שלו. - לולאה רצה פעמיים כאשר הייתה צריכה לרוץ פעם אחת, מכיוון שהפלטפורמה ספרה איטרציות מהמערך הארוך ביותר בנתוני המקור, ומערך התשלומים היה ארוך יותר ממערך הפריטים. הבינה המלאכותית הוסיפה בקרת איטרציה מפורשת כך שהלולאה ספרה רק פריטי שורה.
- שלב "מצא עסקה" עצר את כל הריצה כאשר עדיין לא הייתה עסקה, מכיוון שמצב השגיאה המוגדר כברירת מחדל התייחס ל"לא נמצא" כאל גורם חמור. הבינה המלאכותית העבירה אותו למצב "המשך לאחר שגיאה" כדי שענף היצירה יוכל לפעול, בהתאם לאופן שבו אוטומציה אחים כבר טיפלה בו.

שום דבר מזה לא זוהר. זהו המרקם האמיתי של עבודת האינטגרציה. מה שהשתנה הוא מהירות הלולאה. הבינה המלאכותית יכלה לקרוא עקבת ביצוע מלאה שלב אחר שלב ולהצביע על השלב הכושל באופן מיידי, כך שכל מחזור תיקון היה דקות ספורות. שום דבר לא נשלח ללקוח עד שבדיקות הפיתוח עברו.

מה המשמעות עבור בוני בנייה
הסירו את הנרטיב וזהו מודל העבודה:
- הכוח של הבינה המלאכותית הוא קריאה. היא בחנה אינטגרציה שלמה של אחים, הצטלבה בין בעיה שכבר פתרנו, עיבדה ארכיטקטורה על פני שתי פלטפורמות שונות, וחפרה בתשעים גרסאות של היסטוריה כדי לאמת החלטת עיצוב אחת. אף אדם לא עושה זאת אחר צהריים אחד.
- כוחו של האדם הוא זיכרון ויכולת שיפוט. "אני חושב שהוספתי את זה מסיבה מסוימת" לא נמצא באף קובץ. "עדיין לא מוכן לגרסה 4.0" לא נמצא באף קובץ. שניהם נבעו מחוויית השימוש במוצר. כל אחד מהם שינה את התוצאה.
- המהירות מגיעה מהלולאה. קרא את המעקב, תקן את השלב, הרץ שוב. החיכוך שבדרך כלל מאט את ניפוי השגיאות, את שחזור מה שקרה, נעלם.
הנדסת אינטגרציה המבוססת על בינה מלאכותית אינה בינה מלאכותית שעובדת לבדה, ואינה האדם שעובד מהר יותר. זוהי הבינה המלאכותית שמבצעת את הקריאה שאין לאדם זמן לעשות, והאדם שמספק את ההקשר ללא רשומות בסיס קוד. חברו את כל אלה יחד ובאג חוזר בן ארבע שנים יובן, תוקן ואומת בסשן עבודה אחד.
זהו תהליך העבודה שכדאי לבנות לקראתו.


