איידר / Aider

מה זה איידר ולמה הוא עובד אחרת מכולם?

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

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

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

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

הפיצ'רים המרכזיים של איידר

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

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

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

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

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

כמה זה עולה?

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

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

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

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

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

איידר מול קלוד קוד ומול העוזר שבתוך העורך

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

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

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

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

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

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

הפיצ'ר שעושה את ההבדל: היסטוריה שאפשר לבטל

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

# קובץ ההגדרות של הכלי, נשמר בשורש המאגר בשם .aider.conf.yml
# ---------------------------------------------------------------
# המודל הראשי, זה שמבצע את השינויים בפועל
model: sonnet
# מודל מתכנן נפרד, לשימוש במצב אדריכל
editor-model: sonnet
weak-model: haiku          # לסיכומים ולהודעות התחייבות, זול יותר

auto-commits: true         # התחייבות נפרדת לכל שינוי
dirty-commits: false       # לא לגעת בשינויים שלא אני עשיתי
attribute-author: false    # לא לשנות את שם מחבר ההתחייבות

auto-test: true            # להריץ בדיקות אחרי כל שינוי
test-cmd: "pytest -q"
lint-cmd: "ruff check --fix"

read:                      # קבצים שנכנסים להקשר לקריאה בלבד
  - docs/architecture.md
  - CONVENTIONS.md

# ---------------------------------------------------------------
# רצף עבודה טיפוסי במסוף

# 1. פותחים שיחה עם הקבצים שבאמת ישתנו, ולא יותר
#    aider src/billing/calculator.py tests/test_calculator.py

# 2. מבקשים תכנון לפני ביצוע, במשימה שנוגעת בכמה קבצים
#    /architect  split the discount rules into a separate module

# 3. בודקים מה נכנס להקשר ומה זה עולה
#    /tokens

# 4. אם השינוי לא מוצלח, חוזרים אחורה בפקודה אחת
#    /undo

# 5. משנים מודל באמצע העבודה, בלי לצאת מהשיחה
#    /model gemini/gemini-2.5-pro

# 6. סוגרים את המשימה ופותחים שיחה נקייה לבאה אחריה
#    /drop  ואז  /clear

# ---------------------------------------------------------------
# מצב מעקב: כותבים הערה בעורך והכלי מטפל בה לבד
#    aider --watch-files
# ובקובץ עצמו מוסיפים הערה שמסתיימת בסימן קריאה,
# למשל: add input validation for negative amounts AI!

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

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

חסרונות שאתם צריכים לדעת

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

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

היתרונות שעושים את איידר שווה

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

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

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

מתי לבחור איידר ומתי לבחור אחרת?

הכול מתנקז לשאלה אחת: האם אתם רוצים שליטה או שאתם רוצים שקט. הנה המסגרת המעשית.

# עץ החלטה לבחירת עוזר קוד
שאלה 1: כמה נוח לכם במסוף?
    זו הסביבה הטבעית    -->  איידר
    עובדים בו לפעמים    -->  שווה שבוע ניסיון
    מעדיפים ממשק גרפי   -->  עוזר בתוך העורך

שאלה 2: מה חשוב יותר, שליטה או שקט?
    שליטה במודל ובעלות  -->  איידר
    חוויה שעובדת לבד    -->  סוכן מסחרי
    שילוב של השניים     -->  שניהם, לפי סוג המשימה

שאלה 3: איך אתם רוצים לשלם?
    לפי צריכה בפועל     -->  איידר מול מודל מסחרי
    מנוי חודשי קבוע     -->  סוכן מסחרי או מסלול מנוי
    אפס עלות משתנה      -->  איידר מול מודל מקומי

שאלה 4: מה גודל המשימה הטיפוסית?
    שורות בקובץ אחד     -->  עוזר בעורך מספיק
    שינוי בכמה קבצים    -->  איידר במצב אדריכל
    משימה שלמה לבד      -->  סוכן אוטונומי בענן

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

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

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

השורה התחתונה: האם איידר שווה?

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

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

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

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