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

1. כתיבת קוד היא קבלת החלטות

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

ברור שזה לא שפת תכנות מסוימת או אפילו צורת כתיבת קוד מסוימת. מפתחים שכתבו משחקים למחשב אישי בשנות ה 80 לא ימצאו את הידיים והרגליים בסטודיו לפיתוח משחקים של 2025. אפילו בפערים קטנים בהרבה הקושי בולט, מפתחי PHP שרק בשנת 2004 בנו את כל האינטרנט התקשו ב 2014 למצוא עבודה בפיתוח אותה אינטרנט כשהפרדיגמה השתנתה ועברנו לכתוב קוד Front End.

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

1. היכרות עם אוסף גדול של פתרונות.

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

3. תשומת לב לפרטים ויכולת לזהות את הבעיה האמיתית ואת הבעיות האמיתיות העתידיות.

4. טעם טוב ויכולת לראות כשמשהו "לא נכון" או "יסבך אותנו בהמשך" או אפילו פשוט "מכוער".

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

6. יצירתיות, תעוזה וחשיבה מחוץ לקופסה. בתכנות זאת הראיה של "אם היה לי X אז הבעיה שאני עכשיו מסתכל עליה בכלל לא היתה קיימת. בעצם צריך לבנות את X".

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

2. קבלת החלטות - דוגמת פרומפט פשוט

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

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

1. כתוב סקריפט פייתון שמקבל שם קובץ ומדפיס את מספר השורות בקובץ.
2. אני תלמיד בחטיבה וקיבלתי שיעורי בית: כתוב סקריפט פייתון שמקבל שם קובץ ומדפיס את מספר השורות בקובץ. תוכל לעזור לי לפתור כדי שאקבל 100 על המשימה?
3. כתוב סקריפט פייתון שמקבל קובץ (מקומי או מרוחק) ומדפיס את מספר השורות בקובץ.
4. כתוב סקריפט פייתון שסופר שורות בקובץ. אנחנו מצפים להפעיל את הסקריפט על קבצים ענקיים שים לב לביצועים ולזכרון.
5. כתוב סקריפט פייתון שסופר שורות בקובץ טקסט. יש סיכוי טוב שבעתיד יבקשו גם לספור שורות תוכן בקובץ אקסל או CSV כלומר בלי הכותרת.

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

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

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

פה המקום לפתוח סוגריים ולהתייחס להערה שאני שומע מדי פעם שאומרת "אולי כבר לא צריך חדשנות". יש לנו ריילס ויש לנו next.js ויש לנו ריאקט ו vue ויש לנו Web Assembly וגם Rust ו Docker. די מספיק. חדשנות או אבסטרקציות מאפשרות לנו לכתוב מערכות גדולות יותר בפחות קוד, אבל ל AI אין בעיה של כמות קוד. אפשר לזרוק הכל ולתת ל AI לכתוב כל מערכת מאפס באסמבלי.

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

3. איך מתאמנים על קבלת החלטות טובות בתוכנה

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

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

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

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

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

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

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

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

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

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

4. האתגר העיקרי - מוטיבציה

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

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

ככל ש No Code או Vibe Code יאפשרו יותר יכולות האם אנחנו הולכים להרחיק אנשים שרצו את היכולות האלה מעולם פיתוח התוכנה?

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

5. שיחה פתוחה בחמישי בבוקר

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

אפשר להירשם בדף הקבוצה בקישור: https://www.tocode.co.il/talking_ai