@yaniveytani איך אני מתגעגע לפוגים...
כשתבוא לפרודקט ותתמחר לו משימה בערמות של זמן כי היה שם שלשול לאורך הדרך בהחלטות שה-ai לקח ואתה זרמת איתו זה גם לא יהיה הכי כיף
@saararbel1 אחי זה סיפורי פוגי. כשיש משהו אמיתי שיפגע בביזנס ותבוא עם זה לפרודקט ותדע להגיד מה הערך של זה, הם ידעו לתמחר ולתת את הזמן אם יחשבו שכדאי. על כל השאר אני קורא בולשיט.. כמו שאומרים. זה דברים בעיקר בשבילך..
@saararbel1 או שכן או שלא. אני יכול לחשוב על משברים יותר כואבים אבל אז כמות ההייטרים שלי תגדל אקספוננציאלית , אני אוהב לצרוך הייטרים חדשים במנות קטנות :)
@saararbel1 אבל עוד שנה שנתיים מהיום, כאשר הבינה תתחזק עוד יותר, היא תוכל לפתור לך את זה תוך דקות. זה מה שאנשים לא מבינים. אז הסיבוכיות עכשיו עולה ועדיין צריך לשמרטף את התוצרים, אבל בקרוב מאוד היא תיעלם לחלוטין.
@saararbel1 כל הדיבורים על טק דבט זה ממהנדסים שרוצים לעשות מה שהם אוהבים במקום מה שהביזנס באמת צריך. כשמשהו חשוב באמת אז עושים אותו..
אז לא יהיה משבר והמודלים באים ינהלו את הכל הרבה יותר טוב בלעדינו.
@itainathaniel@boazbe סמכות להגיד לא, אם כל מה שיישאר למפתח זה להזיז משימות בבקלוג בזמן שהמכונה ממשיכה לפרק קוד, הוא לא מנהל את הארכיטקטורה הוא רק מתעד את הקריסה
@eaglescode מעניין, איך אתם שומרים על mental model אחיד של הארכיטקטורה? כמה מהמפתחים באמת מסוגלים לדבאג תקלה באמצע הלילה בלי לבקש מהמודל להסביר להם את הקוד של עצמם ולהיכנס לפאניקה?
@sanonymou_ העקרונות האלה לא מתו, הם פשוט הפכו ללוקסוס. החשבון יגיע כשהמערכת תצטרך לעבור סקייל או שינוי ביזנס בסיסי, ואף מפתח לא יבין איפה הצימוד התפוצץ
@saararbel1@boazbe מדגם התגובות כאן מאוד לא מייצג את המציאות שתיארת (בה אתה כנראה צודק). כאן יש אנשים חזקים שמבינים איך להשתמש נכון בכלים, והצוותים שתיארת כנראה חברה פחות חזקים שנותנים לוייב לשלוט בכיוון
החודש החלטתי פעם ראשונה לנסות וויב קוד (עד היום נשמע לי מטורף לא להסתכל על הקוד בכלל) - נתתי למודל (אמנם לא קלוד) לבנות פיצ׳ר שאני מתכנן כבר שנים ובאמת תוך יום של מריבות היה לי פרוטוטייפ. בינתיים אני כבר יותר משבועיים עובד על להכניס גרסה ״תואמת פרודקשן״ שעומדת בסטנדרטים שלנו ובבחירות שהייתי עושה כשהקריטריון הוא לא רק ״שזה עובד״.
@ron_mizrahio@boazbe מסכים ש specs ו harnessing זה הדרך לשלוט על זה בצורה מסוימת, הבעיה גם שרוב הצוותים לא עובדים ככה וגם שאם אתה כן עובד ככה לאורך הזמן אתה לא מכיר מלא מיקרו-החלטות שהמודל קיבל לאורך הדרך
@saararbel1@boazbe זה ממש לא נכון. אם אתה עובד עם specs מסודרים ומשקיע זמן בלתכנן את המשימות והארכיטקטורה - זה לא קורה. אם אתה מבצע פרומפטינג כל הדרך לפתרון אז זו הבעיה.
@gilinachum@boazbe ה"דיאלוג" הזה הופך מהר מאוד לאשליה של שליטה. ברגע שהמכונה גם מפיקה את הקוד, גם כותבת את הטסטים וגם עושה לעצמה code review, האדם הוא כבר לא ארכיטקט אלא חותמת גומי שמאבדת קונטקסט.
@saararbel1@boazbe בחירות ארכיטקטוניות עדיין באחריות האדם, בדיאלוג עם המכונה.
קידוד זה רק הבינה.
גם עושה טסטים מכל הסוגים וקוד ריויו מצויין ותיקונים, וגם ריפקטורינג מקיף אם החלטתם שצריך.
@mo8ase להשתמש בהם נכון" זה לרוב ביטוי מכובד ללג'נרט יותר קוד בפחות זמן. המשבר הוא לא ברמת הסינטקס של הפונקציה הבודדת, אלא ב-cognitive debt שנוצר כשאתה מציף את ה-codebase בלוגיקה שאף מפתח אנושי לא תכנן מהיסוד
@saararbel1@boazbe צודק.
כל קוד שנוסף לקודבייס קיים מסבך אותו ומגדיל את התלויות עד שהכל נתקע והמחיר לכל שינוי נוסף מזנק. הנדסת תוכנה קפדנית והשקעה יכולים למזער את השיפוע של ההגעה למצב הזה אבל עדיין כל תוספת גורעת.. עם הבינה מלאכותית גם יש פחות השקעה וגם כמות הקוד שנוצרת גבוהה יחסית לעבודה אנושית.