AI: מורה נבוכים. מאמר 3 - לתכנת, בלי לתכנת!
הקדמה
אנחנו לא מתכנתים - וזה בסדר.
לעולם לא נהיה מתכנתים - וזה גם בסדר.
היכולת החזקה ביותר שהבינה המלאכותית מביאה איתה, היא היכולת לייצר תוכנה מבלי לכתוב קוד.
זוהי דלת לעולם חדש של בניית יישומים בכמה משפטים פשוטים, ואתם תגלו גם שהתהליך עצמו כיפי מאוד (ואפילו ממכר…זהירות!).
כדי שנוכל לעשות את זה נכון, אנחנו צריכים להכיר את המתכנת שאנחנו “מחליפים": להבין איך הוא חושב, איך הוא עובד, ומה אנחנו יכולים ללמוד ממנו.
במאמר הזה נפתח צוהר לעולם פיתוח התוכנה, ונראה איך אפשר ליישם את אותם העקרונות מול הבינה המלאכותית.
אתם תגלו שעולם הפיתוח לא כל כך רחוק מעולם ההנדסה האזרחית - הוא פשוט משתמש בשפה אחרת.
נשמע מפתיע? בואו נצא לדרך ונראה.
איך מתכנתים חושבים (ומה אפשר ללמוד מהם)
הקונוטציה הראשונה כשהמילה "הייטק" נזרקת היא מערכון 24 טעמי גלידה של "ארץ נהדרת", ואנשים שיושבים מול 4 מסכים מלאים בשורות קוד. הקשר בין העולם הזה לבין עולם ההנדסה האזרחית שידוע דווקא בצעקות, קפה שחור וקסדות בטיחות נראה מקרי בהחלט.
בפועל, יש דימיון לא קטן בין העולמות ולסוגי התפקידים השונים בהייטק יש מקבילה בעולם ההנדסה האזרחית.
בואו נכיר אותם:
את החלוקה הבסיסית בתכנון אתם כבר מכירים: הקונסטרוקטור מתכנן את המבנה, האדריכל אחראי על העיצוב, הקבלן מבצע, והמפקח בודק שהביצוע תואם לדרישות.
בעולם התוכנה זה כמעט אותו דבר - בשמות אחרים.
המתכנת (Developer) הוא הקבלן.
היינו מצפים שהוא יהיה ה"מוח" שמאחורי הפיתוח, אך בהכללה גסה הוא רק מבצע הוראות.
מישהו אחר כבר הגדיר עבורו את הדרישות, מישהו אחר עיצב את הממשק - כל מה שהוא צריך לעשות זה לתרגם את ההנחיות הללו לקוד.
במובן הזה, הוא דומה מאוד לקבלן שמוציא לפועל תכניות: לפעמים עם יצירתיות ופתרונות שטח (ולפעמים עושה שטויות ומגלה "יוזמה" כשהתכנון לא מהודק), אבל מסגרת גבולות המותר והאסור מאוד ברורה.
המתכנת הוא המשאב הכי יקר, וכל טעות שלו בפיתוח יכולה לעלות המון (גם בשכר שלו עצמו, וגם במוצר בעייתי).
מנהל המוצר (Product Manager) הוא גם המתכנן וגם מנהל הפרויקט.
הוא זה שמגדיר מה בדיוק צריך להיבנות, למה זה חשוב, ולמי זה מיועד.
הוא מחליט על סדרי עדיפויות, לוחות זמנים, משימות לביצוע, ומוודא שהתוצר הסופי עונה על הצורך שהוגדר. באחריותו לכתוב מפרט מדויק (בדומה לתכנית הנדסית), שאותה יממש המתכנת.
המעצב (Designer) הוא האדריכל של התוכנה.
הוא מתכנן איך המערכת תיראה (UI: User Interface) ואיך המשתמש יחווה אותה (UX: User eXperience): צבעים, מיקומים, מסכים, כפתורים - מה תהיה הזרימה ותחושת השימוש במוצר.
המטרה שלו היא להפוך את המוצר לנוח, ברור ונעים לעין, ממש כמו אדריכל שדואג שהמבנה לא רק יעמוד בדרישות מאמצים, אלא שיהיה גם מזמין ונעים לשהות בו.
ה-QA הוא המפקח בשטח (Quality Assurance).
הוא עובר על כל המערכת, בודק שהכול עובד כמו שנכתב במפרט, שאין תקלות, שהלחצנים עושים מה שצריך לעשות ושהם לא עושים מה שהם לא צריכים לעשות, ושהמוצר עומד בסטנדרט שהוגדר.
בדיוק כמו מפקח בשטח - הוא עובר, בודק, מאתר ליקויים, ודואג שהכול תקין לפני מסירה.
במבט נוסף, אנחנו מבינים שהתהליך כמעט זהה לתהליך התכנון ההנדסי שאנחנו מכירים:
- תכנון+עיצוב
- ביצוע
- בקרה
אותה חשיבה הנדסית, רק עם שפה שונה.
זה בדיוק מה שאנחנו הולכים ללמוד לעשות עם הבינה המלאכותית: לא לכתוב קוד בעצמנו, אלא לנהל את הפרויקט כך שהיא תכתוב אותו בשבילנו.
כדי שזה יצליח, אנחנו חייבים להתחיל מהצעד הראשון - תכנון מדויק.
למה חשוב לתכנן לפני שמתחילים
בעולם הבנייה אף טרקטור לא יירד לשטח לפני שיש תוכנית מאושרת.
בעולם הפיתוח ההתנהלות זהה, רק שבמקום שרטוטים וחתכים עובדים עם אפיון (Specifications).
לפני שמבקשים מהבינה המלאכותית לבנות משהו, צריך להסביר לה מה בונים, למי זה מיועד, ואיך נדע שהגענו לתוצאה הנכונה.
זאת לא “שיחת נימוסים", אלא הכרח.
בינה מלאכותית אמנם מבוססת על ניחוש, אבל היא לא יכולה לנחש את המחשבות והרצונות שלנו אם לא שיתפנו אותה בהם.
כמו קבלן שמקבל תכניות לא ברורות, גם היא תעשה כמיטב הבנתה - והתוצאה תהיה בהתאם.
תכנון טוב חוסך גם כסף אמיתי: בדיוק כמו שמתכנת הוא משאב יקר, גם הבינה המלאכותית “לוקחת שכר לפי שעה" - רק שבמקום כסף, היא צורכת טוקנים. מי שניגש בלי תכנון מגלה מהר מאוד שהפרויקט מתארך, שהקרדיטים נעלמים, ושהוא נאלץ לפתוח את הארנק כדי לקנות עוד ועוד קרדיטים רק כדי לסיים משהו שהיה אפשר להגדיר נכון מלכתחילה.
במילים אחרות: אם אתם רוצים שהבינה המלאכותית תעבוד בשבילכם כמו קבלן מקצועי,
אתם חייבים להיות המתכנן המושלם: להגדיר נכון, לצפות מראש ולנהל את המשאבים שלכם בחוכמה. תכנון טוב חוסך זמן, כסף ותסכול מתמשך.
אוטומציה: מתי זה מספיק, ומתי צריך יותר
לפעמים אנחנו לא באמת צריכים לפתח מערכת חדשה, אלא פשוט צריכים שהדברים יעבדו לבד.
לא בכל בעיה צריך להמציא פתרון חדש, לפעמים מספיק לחבר נכון את מה שכבר קיים.
בעולם הבינה המלאכותית זה נקרא אוטומציה.
כלים כמו Zapier, Make או N8N מאפשרים לחבר בין אינספור סוגים של מערכות שונות כך שפעולות שקורות במקום אחד יפעילו תגובה (טריגר) במקום אחר.
זו הדרך להפוך רצף פעולות ידני, סיזיפי ויומיומי, לתרשים זרימה שעובד בשבילכם ברקע.
לדוגמה, שימוש מעולה באוטומציה שנתקלתי בו לאחרונה הוא של הורה שבנה מערכת לזיהוי תוכן פוגעני בוואטסאפ של הילדים שלו:
הוא חיבר את הוואטסאפ של הילדים ל-N8N. את ה-N8N הוא חיבר בנוסף גם למודל AI שקורא את ההודעות ומנתח אותן, ואת המודל הוא חיבר למערכת התראות ששולחת הודעה להורה רק כשהיא מזהה שפה פוגענית או בריונית.
התוצאה: הילדים מרגישים חופשיים בלי שמחטטים להם בטלפון, וההורים רגועים.
זו דוגמה לאוטומציה חכמה: פתרון פשוט, בלי לכתוב שורת קוד אחת.
אבל לא כל בעיה ניתנת לפתרון בצורה כזו.
כלים אוטומציה עובדים מצוין כשמדובר בתהליכים ליניאריים וברורים, למשל: “אם הגיע מייל, תעתיק את הקובץ לתיקייה ותשלח הודעה בוואטסאפ", אבל הם מוגבלים בגמישות (על פי תהליך הזרימה שהגדרתם להם).
בנקודה שבה אנחנו רוצים יישום שמתנהג כמו אתר אמיתי, עם משתמשים, ממשקים ומידע שנשמר נכנסים לתמונה כלים של וויב קודינג (Vibe Coding): כלים שמאפשרים לבנות ממשק או יישום שלם בעזרת פרומפטים פשוטים, בלי לדעת לתכנת.
במילים אחרות:
אוטומציה מתאימה כשהמטרה היא להפעיל דברים.
וויב קודינג מתאים כשהמטרה היא לבנות דברים.
החדשות הטובות הן שאין צורך לבחור בין השניים.
אפשר לחבר בין כלי אוטומציה לכלי וויב קודינג, ולתת לכל אחד לעשות את מה שהוא יודע הכי טוב.
על ידי יצירת נקודת חיבור (Endpoint), מתקבל מעין “שער" דיגיטלי שבו כלי האוטומציה יודעים "לדבר" עם כלי הוויב קודינג.
האוטומציה תבצע את המשימות, והוויב קודינג יספק למשתמש ממשק לעבוד בו.
וייב קודינג: הפרומפט עליך, הקוד עלינו
את המונח "וייב קודינג" תשמעו הרבה בדיונים על שימושים של בינה מלאכותית (לפעמים בצורה קצת מוגזמת…) והוא מייצג שינוי תפיסה משמעותי.
קודם כל, איך זה עובד: זוכרים שאמרנו שהבינה המלאכותית החדשה יודעת לקחת טקסט ו"לנחש" מה תהיה התשובה? אז אותה בינה מלאכותית עברה על אינספור שורות קוד ובאותה שיטה רכשה את היכולת להכין קוד בהתאם לפרומפט של המשתמש.
כדי לקחת את זה כמה צעדים קדימה, פותחו כלים ייעודיים (Loveable או Base44 הישראלי למשל), שיכולים לא רק לכתוב קוד אלא גם להריץ אותו בסביבה מותאמת אישית מלאה, בדיוק כפי שדמיינתם (כי אתכם כמשתמש לא מעניין מה נכתב בקוד, אלא דבר אחד בלבד - שהוא יעשה בדיוק את מה שאתם צריכים).
אותם כלים מייצרים את כל מה שנדרש כדי לענות על הדרישות שלכם: איך היישום נראה, ואיך הוא עובד מאחורי הקלעים.
זו מהות הוייב קודינג: במקום ללמוד איך להשתמש בכלי ממוחשב ספציפי או שפת תכנות, לומדים איך לייצר את הכלי עצמו.
שני צידי המטבע: Frontend ו-Backend
כשכלי הוויב קודינג בונה עבורכם סביבה מותאמת אישית, ברוב המקרים הוא בעצם מייצר שני חלקים במקביל.
לחלקים אלו שם מקובל בעולם התכנות, והם נקראים Backend ו-Frontend (לפעמים יופיע גם כ-BE/FE).
הדרך הכי קלה להבין אותם היא לחשוב על רכב:
ה-Frontend הוא כל מה שאתם חווים כנהגים ברכב, וכל מה שאתם יכולים לשלוט עליו: סימנים בדשבורד, כפתורים שונים, ידיות, דוושות וכו'.
ה-Backend הוא כל מה שקורה מתחת למכסה המנוע: מערכות הרכב (הנעה, חשמל, דלק, מים), מחשב הרכב, והחיבורים בין המערכות השונות.
החיבור ביניהם הוא מה שמייצר את פעולת הרכב.
נבין זאת בדוגמה פשוטה: אתם לוחצים על דוושת האיתות כדי לבצע פנייה, מקבלים חיווי (הבהוב בדשבורד ותקתוק קולי), ועם השלמת הסיבוב הדוושה חוזרת למקומה והחיווי נפסק - זהו ה-Frontend, שבו אתם שולטים ומקבלים משוב.
באותו הזמן, מתחת למכסה המנוע מתבצעות פעולות רבות: לחיצה על דוושת האיתות מפעילה ממסר שמפעיל את התקתוק בקצב קבוע, מחשב הרכב מציג חיווי של איתות בתדירות קבועה במקביל לתקתוק, וסיבוב ההגה שולח פקודה להפסיק את האיתות - זהו ה-Backend שמפעיל את המערכת בפועל.
השילוב ביניהם הוא המפתח ליישום מוצלח: החיווי והשליטה צריכים להיות ברורים ונוחים, ומתחת למכסה המנוע הדברים צריכים להיעשות בצורה שקטה, חכמה ויעילה.
הצעד הבא
ראינו איך מתנהל עולם התכנות, ואיך כלי הוייב קודינג יודעים לתרגם רעיון למערכת שלמה, הכוללת חזית (Frontend) ומנוע (Backend) שעובדים יחד.
במאמר הבא והאחרון בסדרה נלמד את השלב המעשי: איך לבקש נכון.
נראה איך כותבים פרומפט מדויק לכלי וייב קודינג כך שהוא יבין גם את הדרישות שלנו כמשתמשים, וגם את עקרונות העבודה של עולם הפיתוח שהוא עצמו מכיר כך שהתוצר שתקבלו יהיה גם יפה וגם יעיל.
לכל המאמרים של ניר דוזנר
אין תגובות