Graft: איך הייתי חוסך לסוכן AI חיפושים חוזרים בקוד

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

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

לפני שאני מחליף מודל, הייתי בודק על מה הוא מבזבז זמן

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

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

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

מה אני מחפש במפת הקוד

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

בדוגמת אפליקציית התורים, הייתי רוצה לראות מסלול כזה:

Cancellation button
  -> cancellation handler
  -> booking service
  -> database update
  -> notification

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

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

הייתי מתחיל מהמיפוי הבסיסי

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

כאן חשוב לי להפריד בין שני מצבים: graft build אינו דורש מפתח למודל; graft build --deep מוסיף שכבת הסברים דרך ספק שהוגדר. לא הייתי מניח שמנוי קיים לסוכן מכסה אוטומטית את השכבה הזאת. התיעוד הרשמי של Graft.

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

איך הייתי מגדיר אותו בפרויקט

לאחר התקנת Node.js ו־npm, אלה הפקודות שהייתי מתחיל איתן לפי התיעוד:

npm install -g @nanonets/graft

לאחר מכן הייתי פותח טרמינל בתיקיית הפרויקט:

graft init --dry-run
graft init

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

בתוך פרויקט קיים, הייתי בודק גם את השינויים בהגדרות הסוכן. במיוחד ב־Codex, התיעוד מציין אפשרות לשינויים בהגדרות המשתמש שמחוץ לריפו; --no-global נועד לדלג עליהם. זו אחת הסיבות שאני מעדיף לעבור קודם על ה־dry run.

מתי אני רוצה מידע אוטומטי, ומתי שאלה מפורשת

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

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

הייתי נותן לסוכן משימה כזאת:

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

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

איך אני קורא את מספרי החיסכון

מפתחי Graft מדווחים על בדיקה מבוקרת של 162 ריצות בשני ריפוזיטוריז. בהשוואה המרכזית שלהם פורסמו בממוצע 42% פחות טוקנים, 46% פחות קריאות לכלים, 60% פחות זמן ו־32% פחות עלות. שיעור הנכונות באותה השוואה היה 93% בשני הצדדים. אלה נתוני המפתחים, לא תוצאות של בדיקה אישית שלי. פירוט הבדיקה.

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

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

אם הסוכן סיים מהר יותר אבל פספס מסלול קיים, אין מבחינתי חיסכון.

המפה צריכה להישאר שימושית גם אחרי עריכה

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

לא הייתי מניח שכל קשר מופיע במפה. קוד דינמי, קבצים שלא נכללו והבדלים בתמיכה בשפות יכולים להשאיר חלק מהתמונה בחוץ. הייתי משתמש בתוצאה כדי לכוון את הבדיקה, ומשלים אותה בקריאת קוד ובדיקות.

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

איפה הייתי מנסה את Graft קודם

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

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

פרטי הכלי והתיעוד נבדקו ב־9 בספטמבר 2026.