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

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

בזמן האחרון קמה לה קבוצה חדשה בשם Artcraft שהחליטה לעשות מעשה: לקחת את האפליקציות של אדובי, אופיס של מיקרוסופט, אוטוקאד, לבצע תהליך שנקרא decomp (או ״הנדסה לאחור״) ולבנות את המערכות הללו מחדש, בשפת rust, והכל עם Claude Code. כל התוכנות זמינות כאן וכמובן ב-Github שלהם.

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

  • העובדה שהתוכנות שרבים רוצים פתאום יהיו זמינות לכל מערכת הפעלה, לא חשוב איזה מעבד (כולל arm) – זה מדהים!
  • העבודה כולה נעשית ב-vibe coding, ופתאום הדרישות להתחיל לבצע דבר כזה קשורות לזמינות אפליקציית מקור, כתיבת מספר קבצי md, תיאורים וצילומים שונים ועוד – ולאט לאט מתחיל לקום מתחרה. נכון, כמות הבאגים והביצועים הנמוכים מראים שיש עוד הרבה עבודה עד שזה יהיה ממש שמיש, אך כבר עתה זה נראה מרשים!
  • והבעיה שאני חושבת עליה ולא עלתה עד כה בשום וידאו: בעיות אבטחה ענקיות! מכיוון שכל הפרויקט רץ ב-vibe coding ואף אחד בעצם לא קורא את הקוד וכל אחד יכול לתרום בלי בדיקה, יכול כל גוף עוין ״לתרום״ מספר ״שיפורי קוד״ שיכילו קוד זדוני שיוכל לגנוב ממך תוכן יקר וחשוב! תחשבו על מפתחות ssh ומפתחות רבים נוספים, ארנקים, וכל מידע אישי, ויהיה קשה מאוד לעלות על כך, ובנוסף – הקוד הזדוני יהיה גם בתוך הקבצים הבינאריים ללינוקס, למערכות דסקטופ מבוססות ARM ועוד, ועד שיעלו על כך – הנזק שיכול להיווצר מכך – הוא אדיר!

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

  • קניין רוחני: פטנטים, סימנים רשומים ושאר דברים שנכללים תחת קטגוריית ״קניין רוחני״ יכולים בהחלט לעצור כל פרויקט כזה עם מכתב cease & desist ל-github או לכל אתר שמארח קוד או קבצי התקנה. בד״כ אם ״יוצר התוכנה״ לא יעצור עם אותו vibe coding,המחלקה המשפטית של אותן חברות תתחיל לטפל בנושא.
  • בעיית תיקוני קוד – קוד vibe coding במקרים רבים אינו נקרא ולכן קשה גם למצוא את השורות או החלקים השונים אם יש באגים שאנו מגלים. אפשר כמובן לומר למודל ש״לחיצה על כפתור X מגיבה לאט״, ואולי קלוד/צ׳אטgpt יוכלו לחפש ולנסות את הבאג, אך אם התוכנה עצמה בנויה ממאות אלפי שורות קוד, האבחון, תיקון, וידוא שלא נשבר מאומה כתוצאה מהשינוי – יעלו בקרדיטים רבים, ולפעמים מנוי לתוכנה המקורית יהיה יותר זול
  • סכנת אבטחה: כפי שציינתי לעיל – זו בעיה רצינית שיכולה לגרום לנזק מהותי.

לסיכום: vibe coding זה דבר מהפכני ושיכול לעזור פה ושם, אבל בשורה התחתונה, כשאנחנו זקוקים לתוכנה בשביל העסק או בשביל לקוח שלנו, אינני חושבת שבניית/התקנת תוכנה הכתובה ב-vibe coding – זה רעיון טוב.

שימוש ב-LLM בתחומי ה-IT

בשנתיים האחרונות אנו צופים בפריצה רצינית של כל עולם ה-LLM (כלומר Large Language Models), במיוחד בתצורות מסחריות כגון Open AI, Anthropic, Gemini ואחרים. אין ספק שכלים ופלטפורמות אלו משנים הן את עולם הפיתוח והעולמות הנלווים (IT ועוד) מהקצה לקצה, ולכן חשבתי להתייחס ל-LLM ספציפית בתחום ה-IT.

נתחיל בשאלה הראשונה: האם שרות כמו ChatGPT או Claude יכול לסייע בתחומי IT?

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

  • אין ספק שסייען כמו קלוד או ChatGPT יכול לסייע – כל עוד אתה מבין את הנושאים בהם אתה מבקש עזרה. אם אתה צריך עזרה בנושאים הקשורים ללינוקס ואינך לדוגמא מבין מה-הם ספריות, שרותים או דברים כאלו, יכול להיות שתקבל סיוע והסבר מהסייען, אבל באותו בטחון שתקבל סיוע, יכול להיות שתקבל מידע שגוי, מוטעה או פשוט ישן, כי הסייען לא טרח לחפש מידע ברשת ושילב אותו בתשובה.
  • במקרים רבים, יכול להיות שתופתע מהתשובות או שתיכנס ל״סחרחורת״ הואיל והסייען ״נתקע״ בתקלה שולית שלא קשורה לבעיה שבגינה פנית, ויכול להיות שתיקון אותה תקלה שולית – תדפוק לך את המערכת, ולכן אתה חייב ״לפקס״ את הסייען אך ורק בנושא הבעיה שבגינה פנית.
  • לא חשוב כמה מנגנונים יש לסייען ״לזכור״ דברים – לפעמים הוא שוכח, וגם כשהוא מחפש ב״זכרון״ שלו (או בקבצי md) יכול להיות שהוא ימצא אזכור ו״יזכר״, אך הזכרון הוא על מקרה אחר שאינו קשור לבעיה הנוכחית, ושוב אתה עלול למצוא את עצמך צופה ב״תיקון״ שיכול להיות שידפוק לך את המערכת.
  • אם לא הקמתם עד היום, מומלץ להקים: שרת git פנימי (לא, לא github או שרות git בענן ציבורי). הסייען במקרים רבים משנה קבצים או מתקין/מסיר חבילות או משנה קוד (באישורך כמובן), ולפעמים קשה מאוד לעשות rollback (אלא אם אתה רוצה להתחבר למערכת הגיבוי ולשחזר vm מהגיבוי האחרון, לדוגמא). שילוב git יחד עם הסייען כך שכל שינוי הכי קטן ירשם ב-git מיידית, יוכל לעזור לחזור אחורה (או לעבור קדימה) בין בשימוש בסייען ובין בהרצת פקודות git ידניות. זו השיטה הכי טובה לעקוב אחר שינויים.
  • רבים לא יודעים – במקרים רבים הסייען פשוט מרים ידיים כשאתה מבקש דברים נדירים או שלא נעשו או שקשה למצוא מידע עליהם, או שהוא פשוט טוען שזה לא אפשרי. אם יש לך ידע שהדבר אפשרי, פה יהיה המקום שלך ״להתווכח״ (push back) ולציין דברים מסויימים, על מנת שהסייען ילך ויחפש יותר מידע.
  • להכיר את הקוד – ביקשת מהסייען לכתוב אפליקציה או תוכנית או סקריפט. אם אינך מכיר את השפה, בקש מהסייען שיכתוב את זה בשפת תכנות או סקריפטים שאתה מבין. ככל שתקרא את הקוד, תמצא במקרים רבים כל מיני בעיות של כתיבה יותר מדי קצרה וחסרה או ארוכה של הקוד ובמקרים רבים גם השמטות של פונקציות שביקשת.
  • יכול להיות מאוד קל לפרוץ אליכם: רבים מבקשים כל מיני אפליקציות שהסייען כותב בפלטפורמות JS שונות ובמקרים רבים הסייען יתקין חבילות שאינן חדשות ושכוללות בעיות אבטחה. במקרים כאלו, מספיק יהיה להריץ התקנה  ואת האפליקציה – והמערכת שלכם חשופה לפרצות, שימוש בטוקנים של הסייען, השתלטות על מערכות ועוד, ולכן – הסייען כתב לכם משהו שרציתם? שניה לפני שהמערכת מריצה npm. npx, pnpm וכו׳ – בקשו מהסייען לוודא שאלו הגרסאות האחרונות וגם לאחר ההתקנה – לוודא שאין שום חבילה פרוצה מותקנת. טיפ קטן: כל סייען ישמח לכתוב לכם סקריפט קצר שירוץ ב-cron/scheduler ויסרוק יומית את החבילות המותקנות אם התגלו בעיות אבטחה – ויוכל לשלוח אליכם התראה בדרך שתרצו (טלגרם, אימייל וכו׳).

נקודה אחרונה שאני מעוניינת להתייחס אליה וקשורה לקיצוץ/פיטורים עקב אינטגרציה של סייען דיגיטלי כזה או אחר: מי שעוקבים אחרי חברות טכנולוגיה רבות, רואה שכשחברה אחת מפטרת עקב שילוב AI, חברות אחרות שוכרות יותר, ובצדק: הסייען הוא כלי שמחירו עולה ועולה, הוא גרוע ביצירתיות והוא מצריך ״שליטה״ מצד הארגון. אם יש לארגון 6 אנשי IT שמטפלים בתשתית, במקום לפטר לדוגמא מחצית ״כי יש AI״, יהיה אפשר לשנות לחלק מהאנשים את התפקיד לכך שיבצעו פרויקטים אחרים תוך שימוש מפוקח ב-AI וניצול הידע והנסיון של אותם אנשי IT- כדי לקדם את התשתיות בחברה. דוגמאות: הקמת ובדיקת פלטפורמות נסיוניות חדשות, ביצוע אופטימיזציה לקיימות, מעבר חלקים מסויימים לענן וחלקים אחרים מהענן, בדיקות לגבי multi cloud, בדיקה אם אפשר להחליף פתרונות SAAS יקרים (שהאמת הפשוטה: אין לכם מושג ירוק מה החברה שנותנת שרות מריצה) בפתרונות ״ביתיים״ ועוד ועוד. היצירתיות שיש לאותם אנשי IT תעזור מאוד לארגון יחד עם הסייען כדי להקים את אותם דברים.

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