בקשת מידע | בניית תוכנה שלימה עם AI

[ישראל123]

@עידו300 https://chatgpt.com/share/6acac8b9-cafc-83eb-90ab-f141b6f84709

יותר מעודכן
https://chatgpt.com/share/6acac8f9-5330-83ed-bf1d-90b16302d455

[123 דג מלוח]

@ישראל123 אולי תעתיק לפה.
שמא יעזור לעמ"י

[ישראל123]

@123-דג-מלוח

Spoiler

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

המשימה היא בדיקה בלבד. אסור לך לבצע שום שינוי בקוד.

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

1. גבולות מחייבים

• אל תערוך, תיצור, תמחק, תזיז או תפרמט קבצים במאגר — כולל קוד, בדיקות, תיעוד, הגדרות, תלויות ו־lockfiles.
• אל תתקין או תשדרג תלויות במאגר. אל תפעיל autofix, migrations, seed או פקודות שמשנות את הסביבה הקיימת.
• אל תיצור commits, ענפים, PRs, מיזוגים או פריסות.
• אל תשנה נתונים קיימים או הגדרות בשירותים חיצוניים. אין לבצע פעולות כתיבה, בדיקות עומס או ניסיונות ניצול בייצור.
• מותר ליצור כלי בדיקה, נתוני ניסוי ותוצרים רק בתיקייה זמנית נפרדת מחוץ למאגר ובסביבה מבודדת, בלי לשנות את המימוש הנבדק.
• לפני הרצת פקודה, בדוק אם היא עלולה לכתוב קבצים, להפעיל hooks או לפנות לשירות אמיתי. הפנה פלט וקבצים זמניים אל מחוץ למאגר. אם אינך יכול להבטיח בידוד, אל תריץ אותה ודווח על החסימה.
• קרא את הוראות המאגר. אם הן דורשות שינוי שסותר את המשימה, אל תבצע אותו.
• בדוק את מצב המאגר בתחילת העבודה ובסיומה, כולל שינויים קיימים וקבצים לא מנוהלים. אל תבטל שום שינוי של המשתמש.
• מסור את הדוח בשיחה; אם נדרש קובץ, שמור אותו מחוץ למאגר.
• אל תחשוף סודות או מידע אישי בדוח. השתמש בהשחרה ובנתונים סינתטיים.

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

2. הבן את הפרויקט לפני הביקורת

זהה ותעד:

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

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

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

3. בדוק את איכות המערכת

א. נכונות ותפקוד אמיתי

בדוק שהמערכת מבצעת את מה שהיא מציגה למשתמש:

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

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

ב. אבטחה

בדוק את מנגנוני האבטחה בפועל:

• אימות זהות והרשאות בצד השרת לכל פעולה ומשאב רגיש.
• גישה ללא התחברות, בהרשאה נמוכה ובהרשאת משתמש אחר.
• בידוד בין משתמשים, קבוצות או ארגונים, ככל שרלוונטי.
• נקודות API, קבצים ופעולות ניהול שאפשר להגיע אליהם ישירות.
• ולידציה של קלט, הזרקות, XSS, CSRF, SSRF, path traversal והעלאות קבצים — בהתאם לארכיטקטורה.
• סשנים, cookies, tokens, ניהול סודות וחשיפת מידע בשגיאות ובלוגים.
• הגבלות שימוש ומשאבים בפעולות שעלולות לאפשר ניצול משמעותי.

הסתרת כפתור או כתובת שקשה לנחש אינן בקרת הרשאות.

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

ג. ביצועים וצריכת זיכרון

חפש ומדוד כשאפשר:

• שאילתות N+1, שליפות מיותרות וטעינות ללא גבול.
• pagination, אינדקסים ויעילות שאילתות בזרימות משמעותיות.
• חישובים חוזרים, רינדורים מיותרים וחסימת תהליכים.
• חיבורים, מאזינים, timers ומשאבים שאינם משתחררים.
• מטמונים, תורים ואוספים הגדלים ללא גבול.
• זמני תגובה וצריכת משאבים תחת עומס מייצג בסביבה מבודדת.

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

ד. כפילויות, פשטות ותחזוקה

בדוק:

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

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

ה. ספריות ותלויות

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

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

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

ו. איכות הבדיקות הקיימות

בדוק אם הבדיקות:

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

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

4. כללי ראיות: אין ממצא בלי ביסוס

סווג כל מסקנה לאחת מארבע קטגוריות:

1. תקלה מוכחת — ראיות מספיקות לכשל.
2. חשד — הסבר סביר, אך חסר אימות.
3. הצעת שיפור — אין כשל מוכח; יש תועלת אפשרית.
4. לא נבדק / חסום — אין בסיס למסקנה.

לכל תקלה מוכחת הצג:

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

לפני שאתה מאשר ממצא, נסה להפריך אותו: חפש הגנות קיימות, בדוק את ההקשר ואת הנחותיך. אם התברר שהוא שגוי, הסר אותו מרשימת התקלות.

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

5. אופן העבודה

הכן מפת בדיקה קצרה והתחל לבצע מיד. התקדם עצמאית בבדיקות המותרות.

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

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

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

6. הדוח הסופי

מסור דוח ברור הכולל:

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

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

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

Spoiler

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

**המשימה היא בדיקה בלבד. אסור לך לבצע שום שינוי בקוד.**

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

## 1. גבולות מחייבים

- אל תערוך, תיצור, תמחק, תזיז או תפרמט קבצים במאגר — כולל קוד, בדיקות, תיעוד, הגדרות, תלויות ו־lockfiles.
- אל תתקין או תשדרג תלויות במאגר. אל תפעיל autofix, migrations, seed או פקודות שמשנות את הסביבה הקיימת.
- אל תיצור commits, ענפים, PRs, מיזוגים או פריסות.
- אל תשנה נתונים קיימים או הגדרות בשירותים חיצוניים. אין לבצע פעולות כתיבה, בדיקות עומס או ניסיונות ניצול בייצור.
- מותר ליצור כלי בדיקה, נתוני ניסוי ותוצרים **רק בתיקייה זמנית נפרדת מחוץ למאגר ובסביבה מבודדת**, בלי לשנות את המימוש הנבדק.
- לפני הרצת פקודה, בדוק אם היא עלולה לכתוב קבצים, להפעיל hooks או לפנות לשירות אמיתי. הפנה פלט וקבצים זמניים אל מחוץ למאגר. אם אינך יכול להבטיח בידוד, אל תריץ אותה ודווח על החסימה.
- קרא את הוראות המאגר. אם הן דורשות שינוי שסותר את המשימה, אל תבצע אותו.
- בדוק את מצב המאגר בתחילת העבודה ובסיומה, כולל שינויים קיימים וקבצים לא מנוהלים. אל תבטל שום שינוי של המשתמש.
- מסור את הדוח בשיחה; אם נדרש קובץ, שמור אותו מחוץ למאגר.
- אל תחשוף סודות או מידע אישי בדוח. השתמש בהשחרה ובנתונים סינתטיים.

**גם תיקון קטן וברור אסור. מצאת תקלה — הוכח ותעד אותה בלבד.**

## 2. הבן את הפרויקט לפני הביקורת

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

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

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

## 3. בדוק את איכות המערכת

### א. נכונות ותפקוד אמיתי

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

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

### ב. אבטחה

בדוק את מנגנוני האבטחה בפועל:
- אימות זהות והרשאות בצד השרת לכל פעולה ומשאב רגיש.
- גישה ללא התחברות, בהרשאה נמוכה ובהרשאת משתמש אחר.
- בידוד בין משתמשים, קבוצות או ארגונים, ככל שרלוונטי.
- נקודות API, קבצים ופעולות ניהול שאפשר להגיע אליהם ישירות.
- ולידציה של קלט, הזרקות, XSS, CSRF, SSRF, path traversal והעלאות קבצים — בהתאם לארכיטקטורה.
- סשנים, cookies, tokens, ניהול סודות וחשיפת מידע בשגיאות ובלוגים.
- הגבלות שימוש ומשאבים בפעולות שעלולות לאפשר ניצול משמעותי.

הסתרת כפתור או כתובת שקשה לנחש אינן בקרת הרשאות.

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

### ג. ביצועים וצריכת זיכרון

חפש ומדוד כשאפשר:
- שאילתות N+1, שליפות מיותרות וטעינות ללא גבול.
- pagination, אינדקסים ויעילות שאילתות בזרימות משמעותיות.
- חישובים חוזרים, רינדורים מיותרים וחסימת תהליכים.
- חיבורים, מאזינים, timers ומשאבים שאינם משתחררים.
- מטמונים, תורים ואוספים הגדלים ללא גבול.
- זמני תגובה וצריכת משאבים תחת עומס מייצג בסביבה מבודדת.

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

### ד. כפילויות, פשטות ותחזוקה

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

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

### ה. ספריות ותלויות

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

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

### ו. איכות הבדיקות הקיימות

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

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

## 4. כללי ראיות: אין ממצא בלי ביסוס

סווג כל מסקנה לאחת מארבע קטגוריות:
1. **תקלה מוכחת** — ראיות מספיקות לכשל.
2. **חשד** — הסבר סביר, אך חסר אימות.
3. **הצעת שיפור** — אין כשל מוכח; יש תועלת אפשרית.
4. **לא נבדק / חסום** — אין בסיס למסקנה.

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

לפני שאתה מאשר ממצא, נסה להפריך אותו: חפש הגנות קיימות, בדוק את ההקשר ואת הנחותיך. אם התברר שהוא שגוי, הסר אותו מרשימת התקלות.

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

## 5. אופן העבודה

הכן מפת בדיקה קצרה והתחל לבצע מיד. התקדם עצמאית בבדיקות המותרות.

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

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

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

## 6. הדוח הסופי

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

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

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

[ישראל123]

@עידו300 כשיהיה לי מכסה פנויה אני אריץ את הפרומפט הזה ויעדכן

[123 דג מלוח]

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

[NH.LOCAL]

@עידו300 כתב:

@ישראל123 לא כפול, כתוב נכון, עושה את העבודה שלו באמת ולא בכאילו

כל מה שציינת קיים תקופה ארוכה

אופטימזציה נכונה (לא יוצר זליגות זכרון וכדומה)

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

מאובטח

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

שימוש בספריות עדכניות.

בעיה פתורה לפחות שנה וחצי.

לא יוצר ערימות של קוד בשביל דבר פשוט או שיש ספריות טובות בשבילו.

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

בקיצור:

אופטימיזציה נכונה

אבטחה גבוהה

שימוש בספריות עדכניות

קוד נקי וממוקד

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

[עידו300]

@NH.LOCAL כתב:

שימוש בספריות עדכניות.

בעיה פתורה לפחות שנה וחצי.

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

@NH.LOCAL כתב:

מאובטח

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

כן הוא יצר לי אפליקציה לשרת וAPI שפתוח לכל דורש.

[עידו300]

@NH.LOCAL כתב:

אופטימזציה נכונה (לא יוצר זליגות זכרון וכדומה)

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

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

[ישראל123]

@עידו300 הפרומפט נשלח לקודקס ממתין לתוצאות

[עידו300]

@NH.LOCAL כתב:

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

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

[NH.LOCAL]

@עידו300 כתב:

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

לא קרה לי בשנתיים האחרונות.

אם זה קרה אצלך, נראה שיש משהו ממש שגוי ברתמה או בהגדרות. או שאתה משתמש בקלוד הייקו 3.5.

@עידו300 כתב בבקשת מידע | בניית תוכנה שלימה עם AI:

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

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

[עידו300]

@NH.LOCAL לא רתמה ולא מודל, VSC או קלוד קוד עם מודלים הכי גבוהים שיש משתדל גם על חשיבה גבוה

[עידו300]

@NH.LOCAL יתכן ויש עוד בעיות, אני כתבתי את הבעיות שאני נתקלתי בהן, לא לפני שנתיים, בשנה האחרונה ואפילו בחצי שנה האחרונה.

אגב, חל' מהדברים מגובים בצ'אטים שאני יכול לצטט מהן אם צריך.

[ישראל123]

@NH.LOCAL מה הבעיות שיש לדעתך?

[NH.LOCAL]

@עידו300 כתב:

@NH.LOCAL לא רתמה ולא מודל, VSC או קלוד קוד עם מודלים הכי גבוהים שיש משתדל גם על חשיבה גבוה

מוזר להפליא. זה פשוט לא מייצג את היכולות של המודלים כיום.

אני מניח שמספיק להכניס הנחיה לקובץ AGENTS.md להקפיד להשתמש בגרסת הספריה העדכנית ביותר לכל משימה. אני בטוח שתראה נפלאות.

@ישראל123 כתב בבקשת מידע | בניית תוכנה שלימה עם AI:

@NH.LOCAL מה הבעיות שיש לדעתך?

כתבתי לעיל מהחוויה שלי.

@עידו300 כתב בבקשת מידע | בניית תוכנה שלימה עם AI:

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

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

[עידו300]

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

[NH.LOCAL]

@עידו300 כתב:

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

אז תתקין סקילס מומלצים.

שאל את GPT על superpowers למשל או סט סקילס מומלץ אחר. אולי יפתור לך חלק מהבעיות

[עידו300]

@NH.LOCAL כתב:

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

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

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

Spoiler

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

[פתרון AI]

@עידו300 מה התוכנה אנחנו כבר במתח

[NH.LOCAL]

@עידו300 המלצה אחת יש לי:
תפסיק להשתמש בתוספים על VSC ותעבור לממשק שממוקד בסוכן כמו קודקס או קלוד קוורק.

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

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

@עידו300 כתב:

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

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

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

התשובה ברורה: אפשר לבנות תוכנה או אתר ללא שום ידע. הכל תלוי בכלים ובהיקף.

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

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

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

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

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