הבלוג של ינון פרק

האם ללמוד לחשוב על שאלות קטנות עוזר לנו ללמוד לחשוב על שאלות גדולות?

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

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

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

1. הרבה בעיות של תוכניות קטנות לא קיימות בתוכניות גדולות ולהיפך.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

צריכים עזרה לשלב AI בתהליך הפיתוח? מרגישים שלא מקבלים את התוצאות שבפרסומת? תשאירו לי הודעה

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

הוא התחיל את קובץ הבדיקות בהגדרת אוביקט mock:

mockContext = {
  clearRect: vi.fn(),
  fillRect: vi.fn(),
  fillText: vi.fn(),
  measureText: vi.fn(() => ({ width: 100 })),
  beginPath: vi.fn(),
  arc: vi.fn(),
  fill: vi.fn(),
  stroke: vi.fn(),
  moveTo: vi.fn(),
  lineTo: vi.fn(),
  textAlign: 'left',
  textBaseline: 'alphabetic',
} as unknown as CanvasRenderingContext2D;

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

הצעד הבא זה איפה שדברים הופכים מעניינים עם בדיקות כמו:

it('should update snake head position correctly', () => {
  render(<Home />);
  const initialCalls = mockContext.fillRect.mock.calls.length;

  act(() => {
    vi.advanceTimersByTime(150);
  });

  expect(mockContext.fillRect.mock.calls.length).toBeGreaterThan(initialCalls);
});

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

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

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

3. היא משתמשת בפרוקסי - מספר הקריאות ל fillRect במקום לבדוק את הדבר האמיתי.

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

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

קלוד קוד יודע לפתור את כל Advent Of Code של השנה בשעתיים. זה בטוח יותר מהר ממני וכנראה יותר מהר מרוב בני האדם שניסו. וככל שהכלים האלה משתפרים אנחנו מבינים טוב יותר את העבודה שלנו כמהנדסי תוכנה:

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

2. תושיה - למצוא דרכים בטוחות וטובות לעשות דברים גם כשהרעיון הראשון לא עובד.

3. עבודת צוות.

4. תקשורת טובה עם עמיתים ומנהלים.

5. אמינות.

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

7. הבנת המסגרת, המגבלות, היכולות, הארגון.

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

1. האם AI יכול לבנות את זה?

2. אם לא, איך צריכה להיראות המערכת כדי ש AI יוכל לבנות את זה?

איך מבלבלים את קלוד? מסתבר שבקלות ואפילו בלי להתכוון. זה הקוד שהיה צריך לכתוב:

token_translations.each do |tt|
  word = tt.original_text
  translation = tt.translation

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

token_translations.each do |tt|
  word = tt.original_text
  translation = tt.translation_text

ואני אפילו לא יכול להאשים אותו. זה נראה כל כך יותר נכון ככה.

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

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

התומכים בגישה הראשונה כבר יצרו שיטת עבודה מלאה שנקראת Spec Driven Development. הרעיון הוא לדחות את כתיבת הקוד כמה שיותר, להשתמש בסוכני AI כדי לכתוב אפיונים ולבנות אפיון כל כך טוב שאפילו סוכן קידוד יוכל להשתמש בו כדי לבנות את הפיצ'ר. אחד הכלים שמקדמים גישה זו נקרא Agent OS ואפשר לקרוא עליו ולהתקין אותו (לגמרי בחינם) מהאתר:

https://buildermethods.com/agent-os

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

אחרי התקנת Agent OS לתוך פרויקט הסוכן ישקיע דקות ארוכות בניתוח קוד הפרויקט כדי להבין מה המטרה שלו, מה הסטאק הטכנולוגי, מה החלקים המרכזיים שבו ויבנה לעצמו שלושה קבצי טקסט שהולכים ללוות אותנו לכל אורך חיי הפרויקט: mission.md, roadmap.md ו tech-stack.md. הוא באמת כותב המון שם המון. הבעיה הראשונה בעיניי עם כמות הטקסט הזאת היא שמישהו צריך לתחזק את זה. תיאורטית אולי מישהו תכנן שסוכן הקידוד יתחזק את הקבצים האלה כשהגדרת המוצר משתנה אבל במציאות אנחנו יודעים שטקסט מיותר בפרומפטים רק מסבך סוכני קידוד ולבני אדם קשה לתחזק קבצי טקסט.

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

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

2. ממסמך הדרישות הסוכן יוצר מסמך אפיון שכולל כותרות כמו "מטרת הפיצ'ר", "User Stories", "עיצוב ויזואלי", "קוד קיים שכדאי להשתמש", ו"מחוץ לסקופ".

3. אחרי מסמך האפיון הסוכן מייצר מסמך משימות שבנוי כמו Checklist וכל פעם שהוא מסיים משימה הוא מסמן לעצמו x לידה.

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

מסקנות בפועל:

1. בניית פיצ'ר ניסיון לקחה לי יותר זמן מאשר פיתוח של הפיצ'ר בעצמי.

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

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

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

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

רוצים לראות Spec Driven Development עם Agent OS בפעולה? הצטרפו אליי לזום בחמישי בבוקר וננסה לכתוב איתו מערכת לא טריוויאלית או לפחות פיצ'ר או שניים ממנה. מצטרפים בדף הוובינרים בקישור הזה:

https://www.tocode.co.il/talking_ai

חבר שואל - אני רוצה ללמוד תכנות אבל לא בטוח אם יש טעם. אני רוצה לעבוד בפיתוח אבל כל מה שאני רוצה לכתוב ה AI כותב טוב יותר. מי צריך אותי שם בכלל?

בואו נתחיל בלשים את הקלפים על השולחן: ג'מיני יודע היום לכתוב משחק סנייק יותר טוב ויותר מהר ממה שאני כותב. קלוד כתב לי משחק כרטיסיות ללימוד ספרדית עם מנגנון Spaced Repetition כשכל המידע שמור בקבצי טקסט והתרגול משורת הפקודה (ראסט כמובן). לא יהיה הזוי להגיד שכבר היום או בעתיד המאוד קרוב מנועי AI יוכלו לפתור כל תרגיל תכנות של בית ספר יותר טוב מהתלמידים וכנראה גם יותר טוב מהמורה.

עכשיו מה זה אומר עלינו?

אתמול כתבתי על בדיקת cover? של רובי והיום נראה איך היא עוזרת לנו לפתור בעיה אמיתית מתוך Advent Of Code האחרון ואני מתכוון לחלק השני של יום 5. מה שאהבתי בחלק הזה היה שכשניסיתי לקחת את הפתרון של חלק 1 ולהרחיב אותו לחלק 2 זה פשוט לא עבד וכך הבנתי את הטעות שהיתה לי בחלק 1. אבל בואו לא נקדים את המאוחר ונלך לראות את התרגיל.

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

3.3.5 :007 > (1..10).include?(5)
 => true

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

3.3.5 :010 > (1..10).include?(4.5)
 => true

כשברור שאם ננסה לעבור איבר-איבר לא נמצא את ארבע וחצי:

3.3.5 :011 > (1..10).to_a.include?(4.5)
 => false

השבוע נתקלתי במקרה בפונקציה conver? שנראתה כאילו עושה אותו דבר:

3.3.5 :008 > (1..10).cover?(5)
 => true
3.3.5 :009 > (1..10).cover?(4.5)
=> true

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

3.3.5 :013 > ('a'..'z').class
 => Range

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

3.3.5 :014 > ('a'..'z').include?('t')
 => true
3.3.5 :015 > ('a'..'z').cover?('t')
 => true

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

3.3.5 :018 > ('a'..'d').to_a
 => ["a", "b", "c", "d"]
3.3.5 :019 > ('a'..'d').include?('bob')
 => false
3.3.5 :020 > ('a'..'d').cover?('bob')
 => true

עכשיו צודקים מי שיגידו שזה לא הוגן כלפי השברים עם הנקודה העשרונית, הרי הם היו צריכים לקבל את אותו יחס של מחרוזות. צודקים גם אם תגידו שזה מבלבל שאותה פונקציה include? לפעמים מחזירה תוצאה ב O(1) ופעמים אחרות מחזירה את התוצאה ב O(n). אני יכול רק לענות שהחיים לא הוגנים ורובי באמת יכולה להיות לא עקבית אבל טוב שגיליתי את cover? שייחודית לטווחים ותמיד מחזירה תשובה ב O(1).

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

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

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

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

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

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

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

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