דילוג לתוכן הראשי
ניסיון מקצועי

הובלת מיגרציה של אינטגרציות של ספקי נתונים פיננסיים בסיוע AI

מהנדס עיקרי במיגרציה בסיוע סוכן, עם אימות ב-shadow לפני כל cutover, בלי כתיבה מחדש של המנוע

מקור
Intuit, Senior Backend Engineer, Data Exchange Platform / IDX
Tech Stack
Java · Kotlin · Claude · Model Context Protocol · AWS · Kubernetes
פיתוח Backend, מערכות מבוזרות, AI Engineering, Agentic Systems, אמינות,

אמל״ק

הבעיה
אינטגרציות של ספקי מוסדות פיננסיים מ-Tier-1 עדיין רצו על מסלולי הרצה ישנים, והיה צריך להעביר אותן למנוע מודרני בלי שסטייה בהתנהגות תגיע לנתוני לקוחות.
התרומה שלי
כמהנדס העיקרי בקבוצה הזו, המרתי את לוגיקת האינטגרציה של ספקים שמכסים גם בנקאות וגם מס באמצעות סוכן מבוסס Claude, הייתי אחראי על מיגרציית בדיקות היחידה של שלושה pipelines ועל ה-flow של העלאת הסוכן. המנוע והתוכנית הרחבה לא היו באחריותי.
תוצאה וראיות
כל ספק בהיקף אומת ב-shadow מול מסלול ה-Legacy שלו לפני ה-cutover, וסוויטות בדיקות היחידה שמוגרו עוברות. לא נמדדו נתוני השפעה עסקית.
להעמקה בפרטים הטכניים

הבעיה

מנוע ההרצה של Intuit מריץ אינטגרציות של ספקי נתונים עבור מוצרים כמו TurboTax, QuickBooks ו-Credit Karma. קבוצה של אינטגרציות של ספקי מוסדות פיננסיים מ-Tier-1 עדיין רצה על מסלולי הרצה ישנים. היה צריך להעביר אותן למנוע המודרני, שמבוסס על DSL פנימי. חלק מהספקים מכסים נתוני מס בלבד. אחרים מכסים גם בנקאות וגם מס.

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

הקשר

זו הייתה פלטפורמה קיימת, לא בנייה מאפס. המנוע המודרני כבר היה מבוסס סביב DSL פנימי, עם חוזים של ספקים ב-Production, צרכנים ב-downstream ומוסכמות עבודה של הצוות. הצטרפתי לצוות שאחראי על העבודה הזו. לא אני התחלתי אותה.

workstream נפרד טיפל ב-pipeline הסקריפטים ה-Legacy למס, בן 15 שנה. יש לו קייס סטאדי משלו. ה-workstream הזה עוסק באינטגרציות הספקים מ-Tier-1 ובכלים ששימשו להעברתן.

אילוצים

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

התפקיד שלי

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

  • המרתי את לוגיקת האינטגרציה של הספקים שמכסים גם בנקאות וגם מס באמצעות סוכן מיגרציה מבוסס Claude.
  • תרמתי לבניית הסוכן הזה. לא הייתי אחראי עליו.
  • הייתי אחראי על מיגרציית בדיקות היחידה האוטומטית של ה-pipelines של TurboTax, QuickBooks ו-Credit Karma.
  • הייתי אחראי על ה-flow של העלאת הסוכן באינטגרציית Model Context Protocol (MCP) הפנימית. היא מאפשרת לסוכני AI להעלות שינויים שנוצרו אל כלי authoring פנימי, שבו מהנדסים מנהלים אינטגרציות של ספקים.

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

ארכיטקטורה וגישה

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

אימות ב-shadow לפני כל cutover. לכל ספק, מסלול ה-Legacy והמסלול המודרני רצו במקביל, והפלט שלהם הושווה. ספק עבר למסלול המודרני רק אחרי שאימות ה-shadow הושלם בהצלחה. ספקים שעוד לא אומתו המשיכו לרוץ ללא שינוי. החשיפה לסיכון התרחבה בהדרגה, ספק מאומת אחד בכל פעם.

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

מיגרציית בדיקות לצד האינטגרציות. מיגרתי את בדיקות היחידה האוטומטיות של ה-pipelines של TurboTax, QuickBooks ו-Credit Karma. הסוויטות שמוגרו עברו במלואן.

החלטות מרכזיות

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

שיקולים ופשרות

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

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

תוצאות ואימות

התנהגות שמומשה. אינטגרציות הספקים מ-Tier-1 שבהיקף מוגרו אל המנוע המודרני, וכל אחת אומתה ב-shadow מול מסלול ההרצה ה-Legacy שלה לפני ה-cutover. ספקים שמכסים גם בנקאות וגם מס הומרו דרך סוכן המיגרציה, וסקריפטים של ספקי מס בלבד מוגרו ידנית.

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

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

מה למדתי

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

הבחירה בשיטה לפי סוג הספק הייתה חשובה יותר מההתחייבות לגישה אחת לכל דבר.