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

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

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

רוב השינויים במערכת הם לא כאלה.

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

זה לא היה במסגרת הנושאים של הוובינר (אולי יתאים למפגש אחר), אבל הנה כמה פיצ'רים שבניתי ב langlets שבזכות ה AI לקחו הרבה הרבה פחות זמן ממה שהיו צריכים לקחת.

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

Implement the courses#index page based on the attached HTML file, matching the design to our system #file:show.html.erb

List of courses in top row is taken from current_user.recommended_for_me. If the list is empty or user is not signed in do not show the first row

List of learning path in the second row is LearningPath.all

Use swiper js library to handle swiping (it's already installed in the project). Add a stimulus controller to handle the JS

When writing JavaScript use stimulus best practice that is data-target for element querying and data-action for events

Provide only filter by language (use course's language) for this one

Use our existing site's top bar for user authentication. Ignore the top bar in the provided HTML

Use only tailwind native classes

Design to integrate:
...

זה פרומפט ארוך ולא הדבקתי כאן את כולו כי סיימתי אותו ממש בדוגמת HTML/CSS שעיצבתי עם Gemini למסך בית מקביל, אבל שימו לב לעיקרי הדברים - הפרומפט לוקח דף קונספט בעיצוב שונה לגמרי מהמערכת שלי ואוטומטית מתאים את העיצוב לשאר הדפים במערכת, הוא משלב ספריית צד-לקוח בשם swiper וחוסך לי לחפש את ה API שלה. הפרומפט יצר קובץ HTML, קובץ JavaScript ושינה כמה קבצי רובי, שינוי של כמה מאות שורות סך הכל. אחרי ההרצה עדיין היו תקלות והייתי צריך להמשיך עוד כמה איטרציות של תיקונים ושיפורים אבל הארכיטקטורה של הפיתרון היתה נכונה מההפעלה הראשונה בגלל שדברים השתלבו במבנה הפרויקט הקיים.

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

2. יצירת דפי פעילות חדשים - אם תכנסו לאחד הקורסים בלאנגלטס תראו שהם מורכבים מדפי פעילויות מסוגים שונים כמו התאמת משפט לתרגום, הרכבת משפט מבנק מילים, התאמת מילים לתרגומים ועוד. בעבר השקעתי הרבה מחשבה בבניית אבסטרקציות כדי שאפשר יהיה לבנות "דפי פעילות" חדשים בקלות. זה היה מאתגר כי מצד אחד צריך קומפוננטות משותפות שנראות דומה (Design System אחיד) אבל מצד שני ההתנהגות של כל מסך יכולה להיות מאוד שונה. בעזרת AI אני יכול היום ליצור דפי פעילויות חדשים בפרומפט אחד וכמעט תמיד מקבל תוצאה טובה מהפרומפט הראשון. כל מה שצריך זה להדביק את הקוד של 3-4 דפי פעילויות ולבד ה AI מבין את התבנית, מה משותף, לפי איזה סטנדרטים כותבים את הקוד ומאיפה מגיע המידע. כן לכל דף יש את האתגרים שלו אבל היתרון שאני מצליח בכתיבת דף פעילות חדש לקבל בסיס ראשוני שנראה מעוצב לפי המבנה של המערכת ואז אני יכול להתמקד ב JavaScript וב CSS של אותו דף פעילות כדי לסדר אותו.

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

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

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

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