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

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

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

מה הפסדנו פה? אני לא בטוח. שלחתי את לאבבל לבנות לי משחק תרגול צלילים בגיטרה. זה כאן אם אתם רוצים לנסות. המעניין שם זה שאת צוואר הגיטרה לאבבל צייר לבד באמצעות SVG. בעולם הישן ציור צוואר גיטרה ב SVG היה בעיניי האופציה האחרונה. קודם הייתי מחפש ספריית קוד פתוח ובמקרה הגרוע מצייר את זה ב HTML ו CSS. הסוכן יצר קומפוננטה של גיטרה שנראית ממש אחלה ועובדת עבור המשחק לא פחות טוב מ react-fretboard או react-guitar, עם קוד ציור יפה ב SVG. אפשר לראות את הקוד שלו כאן:

https://github.com/ynonp/fret-play-learn/blob/main/src/components/GuitarFretboard.tsx

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

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

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

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

import httpx
from timeit import timeit
from multiprocessing.dummy import Pool
import asyncio

book_urls = [
        "https://www.gutenberg.org/cache/epub/84/pg84.txt",
        "https://www.gutenberg.org/cache/epub/45304/pg45304.txt",
        "https://www.gutenberg.org/cache/epub/2701/pg2701.txt",
        "https://www.gutenberg.org/cache/epub/1342/pg1342.txt"
        ]

הפונקציה הראשונה פשוט מפעילה get ארבע פעמים אחת אחרי השניה:

def download_and_print_size(client, url):
    r = client.get(url, timeout=60.0)
    size = len(r.text)
    print(f"Url: {url}; size: {size}")

def serial():
    print("=== serial ===")
    for url in book_urls:
        download_and_print_size(httpx, url)

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

פונקציה שניה כבר משתמשת ב client של httpx שזה מנגנון שלהם ששומר את החיבור לאתר פתוח כדי להוריד מספר קבצים:

def client_serial():
    print("=== client_serial ===")
    with httpx.Client() as client:
        try:
            for url in book_urls:
                download_and_print_size(client, url)

        finally:
            client.close()

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

def parallel():
    print("=== parallel ===")
    with Pool(5) as p:
        p.map(lambda url: download_and_print_size(httpx, url), book_urls)

def client_parallel_threads():
    print("=== client_parallel_threads ===")
    with httpx.Client() as client:
        try:
            with Pool(5) as p:
                p.map(lambda url: download_and_print_size(client, url), book_urls)

        finally:
            client.close()

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

async def download_and_print_size_async(client, url):
    r = await client.get(url, timeout=60.0)
    size = len(r.text)
    print(f"Url: {url}; size: {size}")


async def client_parallel():
    print("=== client_parallel ===")
    async with httpx.AsyncClient() as client:
        try:
            await asyncio.gather(*[download_and_print_size_async(client, url) for url in book_urls])

        finally:
            await client.aclose()

לסיום פונקציית main שמריצה את כל העסק וגם מודדת זמנים:

def main():
    print(timeit(lambda: serial(), number=1))
    print(timeit(lambda: client_serial(), number=1))
    print(timeit(lambda: parallel(), number=1))
    print(timeit(lambda: client_parallel_threads(), number=1))
    print(timeit(lambda: asyncio.run(client_parallel()), number=1))


if __name__ == "__main__":
    main()

אלה התוצאות:

=== serial ===
Url: https://www.gutenberg.org/cache/epub/84/pg84.txt; size: 446583
Url: https://www.gutenberg.org/cache/epub/45304/pg45304.txt; size: 1356681
Url: https://www.gutenberg.org/cache/epub/2701/pg2701.txt; size: 1260594
Url: https://www.gutenberg.org/cache/epub/1342/pg1342.txt; size: 763083
32.953853541985154
=== client_serial ===
Url: https://www.gutenberg.org/cache/epub/84/pg84.txt; size: 446583
Url: https://www.gutenberg.org/cache/epub/45304/pg45304.txt; size: 1356681
Url: https://www.gutenberg.org/cache/epub/2701/pg2701.txt; size: 1260594
Url: https://www.gutenberg.org/cache/epub/1342/pg1342.txt; size: 763083
12.404891041107476
=== parallel ===
Url: https://www.gutenberg.org/cache/epub/84/pg84.txt; size: 446583
Url: https://www.gutenberg.org/cache/epub/1342/pg1342.txt; size: 763083
Url: https://www.gutenberg.org/cache/epub/45304/pg45304.txt; size: 1356681
Url: https://www.gutenberg.org/cache/epub/2701/pg2701.txt; size: 1260594
6.713048083242029
=== client_parallel_threads ===
Url: https://www.gutenberg.org/cache/epub/1342/pg1342.txt; size: 763083
Url: https://www.gutenberg.org/cache/epub/84/pg84.txt; size: 446583
Url: https://www.gutenberg.org/cache/epub/45304/pg45304.txt; size: 1356681
Url: https://www.gutenberg.org/cache/epub/2701/pg2701.txt; size: 1260594
11.749367957934737
=== client_parallel ===
Url: https://www.gutenberg.org/cache/epub/84/pg84.txt; size: 446583
Url: https://www.gutenberg.org/cache/epub/45304/pg45304.txt; size: 1356681
Url: https://www.gutenberg.org/cache/epub/2701/pg2701.txt; size: 1260594
Url: https://www.gutenberg.org/cache/epub/1342/pg1342.txt; size: 763083
7.422760541085154

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

=== serial ===
Url: https://www.gutenberg.org/cache/epub/84/pg84.txt; size: 446583
Url: https://www.gutenberg.org/cache/epub/45304/pg45304.txt; size: 1356681
Url: https://www.gutenberg.org/cache/epub/2701/pg2701.txt; size: 1260594
Url: https://www.gutenberg.org/cache/epub/1342/pg1342.txt; size: 763083
24.061222000047565
=== client_serial ===
Url: https://www.gutenberg.org/cache/epub/84/pg84.txt; size: 446583
Url: https://www.gutenberg.org/cache/epub/45304/pg45304.txt; size: 1356681
Url: https://www.gutenberg.org/cache/epub/2701/pg2701.txt; size: 1260594
Url: https://www.gutenberg.org/cache/epub/1342/pg1342.txt; size: 763083
14.5340595417656
=== parallel ===
Url: https://www.gutenberg.org/cache/epub/84/pg84.txt; size: 446583
Url: https://www.gutenberg.org/cache/epub/1342/pg1342.txt; size: 763083
Url: https://www.gutenberg.org/cache/epub/45304/pg45304.txt; size: 1356681
Url: https://www.gutenberg.org/cache/epub/2701/pg2701.txt; size: 1260594
8.315202291123569
=== client_parallel_threads ===
Url: https://www.gutenberg.org/cache/epub/1342/pg1342.txt; size: 763083
Url: https://www.gutenberg.org/cache/epub/84/pg84.txt; size: 446583
Url: https://www.gutenberg.org/cache/epub/45304/pg45304.txt; size: 1356681
Url: https://www.gutenberg.org/cache/epub/2701/pg2701.txt; size: 1260594
7.089039749931544
=== client_parallel ===
Url: https://www.gutenberg.org/cache/epub/1342/pg1342.txt; size: 763083
Url: https://www.gutenberg.org/cache/epub/84/pg84.txt; size: 446583
Url: https://www.gutenberg.org/cache/epub/45304/pg45304.txt; size: 1356681
Url: https://www.gutenberg.org/cache/epub/2701/pg2701.txt; size: 1260594
5.17865683324635

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

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

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

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

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

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

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

context 'when multi-part SMS - first chunk' do
  it 'stores in Redis and schedules delayed job' do
    allow(Vonage::InboundSmsService).to receive(:new).and_return(double(create_message: nil))
    allow(described_class).to receive(:set).and_return(described_class)
    allow(described_class).to receive(:perform_later)

    freeze_time

    described_class.handle_concatenated_chunk(params)

    expect(described_class).to have_received(:set).with(wait: 2.minutes)
  end
end

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

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

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

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

כלומר בגישה הראשונה נכתוב את הבדיקה הזו:

context 'when multi-part SMS - first chunk' do
  it 'stores in Redis and schedules delayed job' do
    allow(Vonage::InboundSmsService).to receive(:new).and_return(double(create_message: nil))
    allow(described_class).to receive(:set).and_return(described_class)
    allow(described_class).to receive(:perform_later)

    described_class.handle_concatenated_chunk(params)

    expect(described_class).to have_received(:set).with(wait: 2.minutes)
  end
end

ובגישה השנייה נכתוב את הבדיקה הזו:

context 'when multi-part SMS - first chunk' do
  it 'stores in Redis and schedules delayed job' do
    freeze_time

    expect do
      described_class.handle_concatenated_chunk(params)
    end.to have_enqueued_job(described_class).at(2.minutes.from_now)
  end
end

והגישה המעורבבת? רק עוד סימן לקוד שנכתב בלי השגחה.

בני אדם אומרים "אני לא יודע".

בני אדם שואלים לשלומי ומתכוונים לזה.

בני אדם לא נכנסים ללולאה ובדרך כלל לא מוחקים את כל בסיס הנתונים מתוך יאוש.

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

בני אדם מוצאים פתרונות יצירתיים שאף אחד אף פעם לא חשב עליהם.

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

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

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

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

https://github.com/skorokithakis/stavrobot

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

נתחיל בהצגת קוד הפונקציה כמו שמצאתי אותה בפרויקט:

export function serializeMessagesForSummary(messages: AgentMessage[]): string {
  const lines: string[] = [];

  for (const message of messages) {
    if (message.role === "user") {
      let textContent: string;
      if (typeof message.content === "string") {
        textContent = message.content;
      } else {
        const content = Array.isArray(message.content) ? message.content : [];
        textContent = content
          .filter((block): block is TextContent => block.type === "text")
          .map((block) => block.text)
          .join("");
      }
      lines.push(`User: ${textContent}`);
    } else if (message.role === "assistant") {
      const content = Array.isArray(message.content) ? message.content : [];
      const textContent = content
        .filter((block): block is TextContent => block.type === "text")
        .map((block) => block.text)
        .join("");
      if (textContent) {
        lines.push(`Assistant: ${textContent}`);
      }
      for (const block of content) {
        if (block.type === "toolCall") {
          const toolCall = block as ToolCall;
          const args = Object.entries(toolCall.arguments)
            .map(([key, value]) => {
              if (typeof value === "string") {
                return `${key}=${JSON.stringify(value)}`;
              }
              if (typeof value === "object" && value !== null) {
                return `${key}=${JSON.stringify(value)}`;
              }
              return `${key}=${String(value)}`;
            })
            .join(", ");
          lines.push(`Assistant called ${toolCall.name}(${args})`);
        }
      }
    } else if (message.role === "toolResult") {
      const content = Array.isArray(message.content) ? message.content : [];
      const textContent = content
        .filter((block): block is TextContent => block.type === "text")
        .map((block) => block.text)
        .join("");
      lines.push(`Tool result (${message.toolName}): ${textContent}`);
    }
  }

  return lines.join("\n");
}

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

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

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

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

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

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

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

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

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

async def worker(..., queue, visited, ...):
    while True:
        try:
            url, depth = await queue.get()
        except asyncio.CancelledError:
            break

        try:
            ...
        except Exception as e:
            logger.error(f"Error processing {url}: {e}")
        finally:
            queue.task_done()
            if stop_event.is_set():
                break

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

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

https://github.com/new

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

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

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

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

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

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

allowed_non_write_users: "*"
claude_args: >-
  --allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch"
prompt: |
  **Issue:** #${{ github.event.issue.number }}
  **Title:** ${{ github.event.issue.title }}

ראיתם את הבעיה? אני בטוח שכן. לוקחים את ה title של ה Issue ושולחים אותו לסוכן שיכול להריץ פקודות Shell ולגשת לאינטרנט.

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

הסיפור הטכני המלא למתעניינים נמצא בלינק הזה: https://neciudan.dev/cline-ci-got-compromised-here-is-how#what-is-openclaw-and-why-should-you-care

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