מה אני בונה השבוע ואיך אני עושה זאת עם AI

הפרויקט הזה התחיל מבעיה אחת קטנה

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

מה שמתואר כאן הוא לא תיאוריה. זה תיעוד של שבוע עבודה אמיתי: מה בניתי, אילו כלים השתמשתי בהם, איפה ה-AI עזר ואיפה הוא בזבז לי זמן, ומה הייתי עושה אחרת.

מה בדיוק בניתי השבוע

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

השכבה הראשונה היא ה-ingestion: קבלת נתונים מ-webhook, ניקוי הטקסט, והכנתו לעיבוד. השכבה השנייה היא הקריאה ל-API של OpenAI עם פרומפט מובנה שמחזיר JSON מסודר עם קטגוריה, סיכום, ורמת עדיפות. השכבה השלישית היא הכתיבה ל-Notion דרך ה-API שלהם, כולל טיפול בשגיאות ו-retry logic.

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

איך מחלקים משימות בין AI לבין עצמך

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

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

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

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

הכלים שהשתמשתי בהם ולמה

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

Cursor IDE היה סביבת הפיתוח הראשית. היתרון שלו על פני שימוש ב-ChatGPT בנפרד הוא שהוא רואה את כל קובצי הפרויקט ויכול להציע שינויים בהקשר של הקוד הקיים. כשביקשתי ממנו להוסיף retry logic לקריאות ה-API, הוא הבין אוטומטית את מבנה הפונקציות הקיימות ולא הציע פתרון גנרי.

Claude 3.5 Sonnet שימש לכתיבת פרומפטים מורכבים. יש לו יכולת טובה יותר מ-GPT-4o בהבנת הוראות עם הרבה אילוצים בו-זמנית, וזה קריטי כשמנסים לקבל JSON מובנה עם שדות ספציפיים.

Make.com לחיבור בין השירותים. במקום לכתוב קוד לכל integration, Make מאפשר לבנות זרימות עבודה ויזואלית. זה חסך לי יום וחצי של עבודה על ה-webhook handling.

Perplexity לחקירה מהירה. כשנתקלתי בבעיה עם rate limiting של Notion API, חיפוש ב-Perplexity נתן לי תשובה מדויקת תוך שתי דקות, כולל קישור לתיעוד הרלוונטי.

איפה ה-AI עזר באמת ואיפה הוא בזבז זמן

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

לעומת זאת, כתיבת כל ה-boilerplate לחיבור ל-Notion API לקחה 20 דקות במקום שעתיים. הכלי ייצר קוד נקי עם error handling, type hints, ואפילו הוסיף הערות שמסבירות כל בלוק. זה הזמן שנחסך.

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

כתיבת פרומפטים שמחזירים תוצאות שמישות

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

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

שלושה עקרונות שעובדים בעקביות:

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

שלב הבדיקות: מה שרוב האנשים מדלגים עליו

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

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

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

שילוב AI בעבודה על אתרים ו-SEO

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

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

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

מה לא עבד ומה אשנה בשבוע הבא

שלושה דברים שלא עבדו כמצופה:

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

שנית, ניסיתי להשתמש ב-GPT-4o לניתוח לוגים ארוכים. הוא הגיע למגבלת ה-context window ו"שכח" את תחילת הלוג. הפתרון היה לפצל את הלוג לחלקים ולשאול שאלות ספציפיות על כל חלק, לא לבקש ניתוח כללי.

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

בשבוע הבא אני מתכנן להוסיף שלב של "performance review" מפורש בכל session, שבו אני שואל את ה-AI ספציפית: "מה בקוד הזה עלול להיות איטי בסקייל של אלף בקשות לדקה?"

כיצד לתעד תהליך בנייה עם AI

אחד הדברים שאני עושה שרוב האנשים לא עושים: אני שומר את ה-conversation history עם ה-AI כחלק מתיעוד הפרויקט. לא את כל השיחה, אבל את הפרומפטים שעבדו ואת ההחלטות שהתקבלו בעקבות שיחה עם המודל.

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

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

מה שבאמת שינה את הדרך שאני עובד

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

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

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