בקצרה: בפוסט הזה אני מסביר על כמה טכניקות מתקדמות יחסית לשלב LLM (בלשון העם AI) בקוד מהניסיון שלי כמתכנת שעובד על מוצרים בפרודקשן, לא ״משפיען AI״ ולא ״הכלי הזה יכתוב את כל המוצר ישירות מהפיגמה״. הפוסט מיועד למי שעוד לא ניצל את הכוח של LLM Agents ואינטגרציות איתו.
זו תקופה מאד מבלבלת ומלחיצה. אני חושב שאין כבר מתכנתים שלא משתמשים ב-LLM באיזשהו אופן. יש כאלו שסתם שואלים את ChatGPT, יש כאלו שמשתמשים בקופיילוט, בקורסור או בכלים אחרים. יש המון כלים חדשים כל הזמן ויש באמת הרגשה של עומס וטירוף. על זה תוסיפו המון לחץ מצד כל מיני משפיעני AI שמראים איך בשניות בודדות מקבלים מוצרים מדהימים ו״המוצר הזה ישנה את עולם הפיתוח! שימו לייק ועוקב ולימדו עוד״.
בפוסט הזה אני מבקש לסייע למי שכן משתמש ב-LLM לפיתוח אבל מרגיש שהוא מוכן לשלב הבא, כדי ללמוד פרקטיקות יותר מתקדמות ובדוקות לעבוד עם AI מצד אחד. אבל בלי ססמאות וקשקושים מהצד השני. אני ארכיטקט ומתכנת שעובד על מוצרים שרצים על פרודקשן בחברה גדולה ופה אני אפרט על דברים שעזרו לי לעשות את הקפיצה ומשמשים אותי ביומיום במוצרים עובדים.
ההבדל בין LLM ל-Agent
בגדול מה שחשוב להבין ש-Agent זה LLM אבל LLM עם איטרציה. כן, כן, האיטרציות שאנחנו מכירים. כלומר אם בעבר היינו הולכים ל-ChatGPT וחבריו ומבקשים קוד שעושים משהו, מדביקים אותו ומריצים אותו ואז מתחילים לשחק. או לחלופין, בונים על ההשלמה האוטומטית של קופיילוט. עם סוכן זה אחרת. הסוכן בעצם מבצע את הפעולות הבאות:
- מקבל בקשה מהמשתמש ובונה תוכנית לביצוע.
- עובר על סעיפי התוכנית ומבצע אותם לפי הסדר.
זה הכל. יש לי פוסט הסבר שמסביר ממש מבחינת קוד איך LLM Agent נראה למי שרוצה להעמיק, אבל הבסיס הוא פשוט. אם העבודה שלכם עם LLM היא דרך ממשק צ׳אט והרבה ״לך ושוב״ והרבה פעמים שלכם מריצים בדיקות, לינטרים או מריצים את הקוד כדי לראות שזה עובד – סוכן יכול לחסוך לכם הרבה מהעבודה. אתם צריכים להגדיר לו במפורש מה לעשות, הוא יפרק את העניין למשימות ויעשה.
איך Agent נראה בפועל? אם יש לכם קופיילוט, יש חץ קטן לידו שבו אפשר לעבור ל Agent mode. אם יש לכם Cursor, אז כנ״ל. עם כלים אחרים זה אותו הדבר.
ברגע שאני כותב משהו, ה-LLM בעצם לוקח אותו, בונה תוכנית ומעביר את זה ל-instances אחרים של LLM לחשיבה, ניתוח או ביצוע. כאשר ה-instances יכולים להריץ כלים במחשב המקומי או אפילו מרחוק כדי לעשות דברים. אם אני ארצה לראות את זה בדיאגרמה, זה ייראה ככה (לא להבהל!)
באופן אישי כשמראים לי משהו כזה אני חוטף אלם והלם אם אני לא מכיר את הנושא, אבל אם תשקיעו כמה שניות, תבינו שבסופו של דבר זה אותו LLM שאתם מכירים, רק כזה שעובד באיטרציה ויכול להפעיל כלים על המחשב המקומי שלכם. אגב, גם הפעלת כלים נשמעת כמו מדע בדיוני אבל היא לא ומי שרוצה יכול לקפוץ לסרטון שלי פה על MCP שבחלקו הראשון אני מראה איך LLM מפעיל כלים. בתור מתכנת, ברגע שאני רואה את הקוד שעובד, אני מבין שזה לא קסם.
הוראות – אי אפשר בלעדיהן
באופן אישי, הבנתי את הכוח שיש מאחורי ה-Agents בפיתוח רק כשהכנסתי הוראות. למה? כי בכל פרויקט גדול או אפילו קטן יש כל מיני טוויקים. למשל, יש לי פרויקט עם פייתון ובקופיילוט ה-LLM הטיפש כל פעם התעקש להריץ את הלינטר שלא עם uv או עם poetry, הפקודה נכשלה וצעקות אימים. שלא לדבר על זה שהוא לא תמיד הריץ את הלינטר. הבדיקות? אולי הוא כתב בדיקות אבל לא טרח להריץ את כל הבדיקות או את ה-E2E ואז הבילדים נפלו לי ועוד כל מיני שטיקים. נכון, אני יכול לעשות את זה ידנית או להורות לו, אבל באמת מבינים את הכוח של ה-LLM Agents כשהוא מבצע את הדרישות ואז גם מריץ לינטרים מסוגים שונים, את כלל הבדיקות בסביבה הנכונה ועם הגרסה הנכונה ואולי גם מדפלט לסביבת בדיקות ומריץ אינטגרציה ו-E2E בפיצ׳רים גדולים. לכל פרויקט וכל אחד מאיתנו יש את השטיקים שלו ואני חושב שזה חובה להכניס הוראות. חובה. ההוראות נכנסות לקובץ שתלוי בכלי שלכם. בקורסור כדאי להתחיל באופן פשוט עם הוראות בראשי בקובץ .cursorrules ובקופיילוט זה בתיקית .github/copilot-instructions.md בפורמט md .
איזה הוראות? האמת היא שלא נעים לי לומר – אפשר לבקש מהאייג׳נט גרסה ראשונית ואז להוסיף את הדברים שלכם. הוראות זה דבר מורכב ואפשר לעשות גם סוגי הוראות שונים לפרויקטים שיש להם בק אנד או פרונט אנד. אני עושה להן כמובן commit כי הן חלק מהפרויקט. בהוראות אני מפרט, למשל:
- הפרויקט עובד עם uv.
- חובה לעשות Lint בסוף כל משימה באמצעות uv run pylint
- חובה להריץ בדיקות בסוף כל משימה באמצעות uv run pytest
- הרצת e2e היא באמצעות uv run ./deploy.py ואחרי שהוא מסתיים RUN_E2E=true uv run pytest
וכך הלאה. בכל פעם שה-LLM Agent מטריף אותי עם משהו, אני מוסיף לחוקים.
חוקים זה עולם ומלואו ואפשר באמת להתפרע, אבל זה הבסיס. באמת אל תזוזו בלעדיהם ואם לא הבנתם מה הקטע עם ה-Agent mode או עם קורסור או כלים אחרים, שימו חוקים וזה ישנה את הזווית שלכם.
השלב הבא – חיבור כלים! (כן, גם בסביבת אנטרפרייז)
הכוח של LLM Agents הוא בהפעלת כלים. זה לא קסם ולא וודו, הכלים מופעלים בסביבה המקומית שלכם על ידי קורסור, VScode ודומיהם ומי שמורה להם להריץ את הכלים זה ה-LLM באמצעות ממשק שנקרא tools. ליטרלי API. מה שכן, זה די מדהים כמתכנת לראות את ה-LLM Agent מריץ כל מיני פקודות ב-CLI של בדיקות וכו׳ וכו׳. את זה מקבלים out of the box עם LLM Agents אבל הכוח האמיתי הוא בחיבור לכלים אקסטרניים. למשל לגיטהאב.
חלק מכם קופצים עכשיו ואומרים (בצדק) – טוב, הוא הולך לדבר על MCP ואינטגרציות ואנחנו… אנחנו עובדים בחברה גדולה ואם אני אפילו חושב בטעות להתקין איזו תוכנה או אינטגרציה אנשי ה-IT חוסמים אותה כאילו הם נטורי קרתא על סטרואידים. בשביל להפעיל איזו אינטגרציה עם גיטהאב אני אצטרך לפתוח בקשות, לצרוח, להשתולל, למכור כליה וגם זה לא יעזור. חבוב, אני לא יכול לזוז מילימטר פה במחשב של העבודה. אמרנו שלא תהיה משפיען AI!
אז זה נכון, א-ב-ל – יש לכם משהו שלרוב ה-IT לא חוסם וזה ה-CLI. אתם יכולים להורות ל-AI Agents להשתמש בפקודות CLI שלכם. למשל… פקודות CLI שמפעילות את גיטהאב. בלי MCP, התקנות או בלגנים. אתם יכולים לעשות push לגיטהאב? אתם יכולים לעשות הכל כולל לפתוח, לערוך, לשנות ולעדכן פול ריקווסטים. כן! עם כלי ל-CLI שנקרא Github CLI והוא רשמי של גיטהאב ומותקן כמו כל כלי CLI אחר ולרוב לא נחסם. הוא משתמש במפתח שלכם בגיטהאב ואפשר דרך ה-CLI לפתוח פול ריקווסט לבראנץ׳ מסוים ולערוך אותו. אתם יכולים? גם ה-LLM Agent יכול!
מה שצריך לעשות זה להתקין את ה-CLI. לוודא שהוא עובד (עניין של דקות) ואז לכתוב בקובץ ההוראות שאפשר לעבוד עם ה-CLI הזה ולתת דוגמאות לפקודות. מהשלב הזה, ה-LLM Agent יכול ליצור לכם PR. כלומר אתם נותנים לו משימה, הוא מסיים ויוצר את ה-PR עם תיאור מדויק של מה נעשה ואיך נעשה. בפורמט שאתם רוצים (אפשר להפנות אותו אל pull_request_template.md וזה עובד יפה!). אתם נכנסים בהנאה לממשק של גיטהאב ואז יכולים לבחון את השינויים. משהו לא טוב? לבקש מהאייג׳נט את התיקון והוא כבר יעדכן גם את ה-PR וגם את הטקסט של ה-PR!
זה די מדהים לראות את זה בפעם הראשונה. אני מקליד את הבקשה, עדיף מפורטת ככל האפשר ואחרי כמה דקות הקוד נוצר עם PR מסודר ובהתאם להנחיות. אם הקפדתם על הנחיות טובות אז הקוד יעבור לינט, בדיקות ואפילו E2E. וכל זה בלי לריב עם ה-IT, בלי MCP ובאופן שקצת מעמעם את הוודו. הוא פשוט מפעיל CLI, זה הכל.
רגע, למה לעצור בזה? ג׳ירה!
אם יש כלי שאני מתעב ושונא הוא הג׳ירה, שם חיבה: ג׳ורה. כלי ניהול הבאגים החביב. הבעיה היא שלא מעט פעמים כן צריך לעשות איתו דברים. למשל, אם גיליתי תקלה, אני צריך לפתוח טיקט עם כל הנושאים המתאימים, להתפלל שהוא יגיע לבורד המתאים ולא ילך לאיבוד כי שכחתי לסמן משהו באיזה שדה שכוח אל שרק PMים מכירים. אם אני מתחיל לעבוד על טיקט, אני צריך לגרור אותו ל In progress ואחרי שאני מסיים, להעביר אותו ל In review ולשים קישור ממנו אל ה-PR וב-PR קישור אל הטיקט בג׳ירה. והכל בממשק של ימי הביניים שיציב כמו אפרוח בן יומו בסופת טורנדו.
רגע, למה? הידעתם שאפשר להתחבר לג׳ירה עם CLI? כן! כל מה שצריך זה טוקן שאותו משיגים מהממשק של ג׳ירה ו… זהו! כלי ה-CLI מותקן כמו כל כלי אחר. זו לא תוכנה חדשה, אלא פשוט מודול של פייתון. אני ממליץ על ה-CLI הזה שגם אטלסיאן תומכת בו. זה קצת יותר טריקי, כי יש תמיד מלא שדות מיוחדים שמוגדרים בג׳ירה שצריך לעשות להם mapping. למשל לבורד שיש בו active sprint שבו צריך ליצור טיקטים חדשים, או רשימות ש epics. בגדול, אני ממליץ לתשאל טיקט או issue שמכירים היטב, לראות את השדות שלו ולאז להגדיר אותם כברירת מחדל בהוראות של ה-Agent. זה קצת עבודה אבל… הי, אפשר לתת את זה ל-Agent.
כמעט לסיכום
שימוש באינטגרציה יכול מאד לעזור והאינטגרציה הזו היא פשוטה, מפרקת את הוודו ואת הקסם כי בסופו של דבר היא לא עובדת דרך MCP אלא דרך CLI שכל מתכנת מכיר ונותנת תוצאות כמעט מיידיות שנראות לעין. אם אתם רוצים לקחת את ה-LLM לשלב הבא, זה איפה שהייתי מתחיל.
ועכשיו מילת אזהרה
הכוח של ה-LLM נראה בהתחלה אדיר. כיוון שה-LLM Agent מביא תוצאות טובות ואם הוא גם קורא את ה-JIRA ופותח PR וגם יודע לעשות (עם אייג׳נט אחר) בדיקה שלו. למה צריך את המתכנתים? התשובה היא שעדיין חובה לבדוק את הקוד. למרות שלכאורה אני יכול לשבת על הישבן ולא לעשות כלום, אני בוחן את הקוד, שומר על איטרציות קצרות (כלומר PR קטנים) ובוחן כל שורה. לא תאמינו כמה בעיות מצאתי או כמה צרות נגרמו כי נתתי ל LLM Agent לרוץ. נדרשת הרבה פעמים ההנחיה שלי אבל גם הבחינה שלי. אנגלית היא שפה לא פורמלית עם הרבה כפל משמעות בניגוד לשפת קוד שהיא שפה פורמלית שאין בה מקום לכפל משמעות. כשאני מבקש מה-LLM Agent לכתוב Secure, הקוד שיוצא יכול להיות שונה לגמרי מהכוונה. זו הבעיה עם Agent LLM, הם לא עושים מה שאנחנו רוצים שהם יעשו אלא תוצאה סבירה סטטיסטית של מה שאנחנו מבקשים. עדיין יש חשיבות עצומה לידע הטכני ודווקא מתכנתים מנוסים יכולים לנצל את הכוח האדיר של ה-LLM ולהתקדם לכיוונים חדשים. העבודה עם סוכנים ואינטגרציה חכמה יכולה להאיץ מאד את העבודה והניסיון גם מאפשר להנחות את הכל ולבדוק את הכל מאד בקלות.
כמובן שעבודה עם ה-CLI היא לא תמיד הכי יעילה, אבל זו התחלה מעולה, במאמרים הבאים אני אנסה להרחיב יותר על פתרונות טובים יותר. אבל רק כאלו שניסיתי ובדקתי בעצמי כמובן בעבודה אמיתית מול מוצרים אמיתיים.
