דווין / Devin

מה זה דווין ובמה הוא שונה מעוזר קוד רגיל?

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

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

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

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

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

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

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

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

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

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

כמה זה עולה?

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

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

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

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

דווין מול קרסר ומול הסוכן בטרמינל

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

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

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

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

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

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

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

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

# הפעלת סוכן קוד על משימה מוגדרת, והמתנה לתוצאה
import os
import time
import requests

API = "https://api.devin.ai/v1"
HEADERS = {
    "Authorization": "Bearer " + os.environ["DEVIN_API_KEY"],
    "Content-Type": "application/json; charset=utf-8",
}

# מפרט משימה: מה לשנות, איך נדע שזה עבד, ומה אסור לגעת בו
SPEC = '''
Goal: {goal}
Repository: {repo}
Definition of done:
  - {done}
  - all existing tests keep passing
  - no changes outside the paths listed below
Allowed paths: {paths}
Do not touch: build config, dependency versions, CI files.
Open a pull request when finished and describe what changed and why.
'''

def start(goal, repo, done, paths):
    body = {"prompt": SPEC.format(goal=goal, repo=repo, done=done, paths=paths)}
    r = requests.post(API + "/sessions", json=body, headers=HEADERS, timeout=60)
    r.raise_for_status()
    return r.json()["session_id"]

def wait(session_id, timeout_minutes=90, poll_seconds=30):
    deadline = time.monotonic() + timeout_minutes * 60
    while time.monotonic() < deadline:
        r = requests.get(API + "/session/" + session_id, headers=HEADERS, timeout=60)
        r.raise_for_status()
        data = r.json()
        if data.get("status_enum") in ("blocked", "stopped", "finished"):
            return data
        time.sleep(poll_seconds)
    return {"status_enum": "timeout"}

# תור משימות תחזוקה: כל אחת נפתחת בנפרד ורצה במקביל
BACKLOG = [
    {"goal": "Migrate the legacy date helpers to the new time library",
     "done": "no module imports the deprecated helper", "paths": "src/utils"},
    {"goal": "Add unit tests for the billing calculator",
     "done": "line coverage of the module is above 80 percent", "paths": "tests/billing"},
]

def run_backlog(repo):
    sessions = [start(t["goal"], repo, t["done"], t["paths"]) for t in BACKLOG]
    return [wait(s) for s in sessions]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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