איך בונים כלי פנימי עם Claude Code ביומיים

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

איזה כלי פנימי עם Claude Code שווה לבנות קודם?

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

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

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

שאלה שעוזרת לבחור: אם הכלי ייעלם מחר, מי יצעק? אם התשובה היא “אף אחד”, זה לא הכלי הראשון. אם התשובה היא “צוות אחד, בקול רם”, מצאתם.

מה הכלי שבנינו ומה היה לפני?

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

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

הרכז מדווח על כשעה בשבוע במקום 10. שאלות “מה קורה עם הבקשה” ירדו ב-80%. הכלי בשימוש כבר 5 חודשים.

איך בונים את הכלי צעד אחרי צעד?

ככה זה נראה בפועל, עם הזמנים האמיתיים:

1. יום 1, בוקר: אפיון בעמוד אחד (שעה). ישבנו עם הרכז. כתבנו: מי המשתמשים, מה השדות בטופס, מה הסטטוסים, מתי נשלח מייל. זה הקובץ שהסוכן קיבל ראשון.
2. יום 1: קובץ הנחיות לפרויקט (20 דקות). קובץ טקסט קצר בתיקייה: מה הפרויקט, איזה סטאק, מה אסור (לא למחוק נתונים, לא לשנות סכמה בלי לשאול). Claude Code קורא אותו בכל הפעלה.
3. יום 1: גרסה ראשונה על נתוני דוגמה (3 שעות). ביקשנו טופס, טבלה ומסד נתונים. הסוכן הקים פרויקט, חיבר Supabase, בנה שני עמודים. בדקנו עם 20 בקשות מומצאות.
4. יום 1, אחר הצהריים: הרכז מנסה (שעה). הוא מצא שחסר שדה “דחיפות” ושהטבלה לא ממוינת לפי תאריך. שני סבבים עם הסוכן, 25 דקות.
5. יום 2, בוקר: התראות מייל (שעתיים). חיבור לשירות מייל, תבנית לכל שינוי סטטוס. הסוכן כתב גם בדיקה שמוודאת שמייל לא נשלח פעמיים.
6. יום 2: עמוד “הבקשות שלי” והרשאות (שעתיים). הפרדה בין מה שרואה עובד למה שרואה הרכז. זה החלק שביקשנו ממפתח לעבור עליו, 30 דקות שלו.
7. יום 2, אחר הצהריים: פריסה וניסוי עם 5 אנשים (שעתיים). העלינו לכתובת פנימית. חמישה עובדים שלחו בקשות אמיתיות. שני באגים קטנים, תוקנו באותו יום.
8. שבוע אחרי: מעבר מלא. המייל הישן קיבל תשובה אוטומטית עם קישור לטופס.

איזה סטאק טכנולוגי לבחור?

Claude Code לא מחייב סטאק. הכלל שלנו: הכי פשוט שעונה על הצורך.

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

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

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

איך דואגים שהכלי ישרוד אחרי שבוע?

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

• בעלים אחד עם שם. הרכז. הוא יודע להפעיל את Claude Code על התיקייה ולבקש שינויים קטנים בעצמו. בחמישה חודשים הוא עשה 6 שינויים בלי מפתח.
• קובץ README שהסוכן כתב. איך מריצים, איך משנים שדה, למי פונים. הסוכן עדכן אותו בכל שינוי.
• נקודת שמירה לפני כל שינוי. git, עם הודעות שהסוכן כותב. כשהשינוי החמישי שבר משהו, חזרנו אחורה בדקה.
• גבול ברור למה הכלי לא עושה. כשהבקשות להרחבה התחילו להגיע (אישורים, תקציב, הזמנה מספק), כתבנו בקובץ ההנחיות מה הכלי לא יעשה. כלי קטן שעובד עדיף על כלי גדול שאף אחד לא מתחזק.

כמה זה עלה ומה החיסכון?

העלות: יומיים של מי שבנה, חצי שעה של מפתח, כ-18 דולר בקריאות למודל, ואירוח בחינם ברמת השימוש הזאת. החיסכון: כ-9 שעות שבועיות של הרכז, ושעות לא מדודות של עובדים שהפסיקו לשאול “מה קורה עם הבקשה”. בחישוב שמרני, הכלי החזיר את עצמו בשבוע השלישי. עוד על מדידה כזאת במרכז הנושא ROI של AI.

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

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