ויברציות טובות - המדריך, פרק א'

מחבר: התלתל (@taltimes2)
תאריך פרסום: 15 בדצמבר 2025
קישור למקור: שרשור מקורי

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

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

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

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

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

הקוד שלכם נרקב. ומהר.

לתכונות האלו יש תוצאה עצובה. כל מפתח ותיק מכיר את התופעה:

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

• יש כפילויות קוד שעושה את אותה פונקציונליות.

• יש בלאגן! תיקיות utils, scripts, utilities, temp, outputs, delme.

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

• כיסוי בדיקות נמוך (מפחיד ממש).

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

• עודף אבסטרקציות או חוסר אבסטרקציות ובכלל ארכיטקטורת תוכנה גרועה.

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

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

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

• שמות לא טובים

  כידוע יש רק 2 בעיות קשות במדעי המחשב:

  1. ניהול זיכרון מטמון
  2. לתת שמות טובים
  3. באגים של OFF-BY-ONE

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

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

אז מה מנהל עושה?

1. נהלים ותרבות ארגונית

אתם חייבים נהלים. זה קריטי. הוראות האש נכתבו בדם. אף בנאדם לא אוהב לכתוב נהלים אבל אתם יודעים מי כן אוהב לכתוב אותם? נכון, הסוכן! הוא ישפריץ לכם דפים על דפים של נהלים. בקשו לתמצת את נהלי הפיתוח הכי חשובים ועברו על הקובץ כדי שיתאים לכם. ואז תכניסו אותם ל cursor rules, AGNETS.md, CLAUDE.md וכו'.

2. תחזוקה

אף בנאדם לא אוהב לעשות תחזוקה אבל אתם יודעים מי כן אוהב לעשות אותה? הפעילו את הסוכן:

• חפשו קוד מת ומחקו אותו באגרסיביות. גיט ישמור על ההיסטוריה.
• כיסוי בדיקות. תתחילו בשאלה - מה אחוז הכיסוי שלי? ואז אמרו לסוכן לשפר אותו. זה קריטי. אתם צריכים בדיקות כדי לא לפחד לעשות שינויים.
• אל תתביישו לעשות לכל באג ROOT CAUSE ANALYSIS. לא סתם - "תקן לי את הבאג", אלא תסביר למה הבאג לא כוסה בבדיקות! תקן את הבדיקות ורק אז תקן את הבאג.
• בדיקות כפולות - ¡Afuera!
• בדיקת שמות - קבצים, תיקיות, פונקציות ומשתנים - הסוכנים מעולים בזה!
• ארכיטקטורה - הסוכן יודע את כל הקללות: SOLID, DRY, YAGNI, KISS… בקשו סקירת קוד והמלצות.

3. משמעת

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

/code-coverage
/security-audit
/structure-review
/dedupe-pass
/ci-optimization
/dependency-check

4. ולסיום - תהיו מניאקים

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

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

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

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