Codex הופך ל-workspace, לא רק לסוכן כתיבת קוד
· 2 min read · Filippo Spinella · AI, Codex, Developer Tools, Productivity
מה שנשאר איתי מההכרזה החדשה על Codex לא היה המילה plugin. זו הייתה התחושה ש-Codex מנסה להפוך למקום שבו עבודה מקבלת צורה.
OpenAI פרסמה ב-2 ביוני 2026 את Codex for every role, tool, and workflow. החידושים הבולטים הם plugins לפי תפקיד, Sites ו-annotations. אבל השאלה החשובה פשוטה יותר: האם סוכן יכול לקחת context מפוזר בחברה ולהפוך אותו לדבר שצוות יכול לפתוח, לדון בו ולשפר?
השינוי האמיתי
הרבה זמן היה קל להסביר את Codex: הוא עוזר למפתחים לשנות קוד. העדכון הזה הופך את ההסבר לצר מדי. ה-plugins החדשים מדברים גם אל analytics, sales, product design, creative production, public equity investing ו-investment banking.
כלומר Codex לא קורא רק repository. הוא יכול לקרוא dashboards, הערות CRM, מסמכים, spreadsheets, design briefs או מקורות פיננסיים, וליצור מהם ארטיפקט עבודה.
שם זה נהיה פרקטי. רוב הצוותים לא צריכים עוד תשובה בצ'אט. הם צריכים דף, launch room, review board, planner, אפליקציה פנימית קטנה או dashboard שכולם יכולים לפתוח.
Sites הוא החלק שהייתי עוקב אחריו
Sites נראה כמו החלק הכי מוחשי. תשובת צ'אט נעלמת בגלילה. ל-site יש URL. אפשר לשתף, להגיב, לפתוח שוב אחרי כמה ימים ולבקש מ-Codex לעדכן רק את מה שהשתנה.
אני רואה את זה עובד ל-product launches, customer reviews, weekly business reviews, investor memos ו-internal tooling. לא כי הגרסה הראשונה תהיה מושלמת. היא לא תהיה. הערך הוא שלצוות יש אובייקט משותף.
Annotations מקטינות את הפידבק
Annotations חשובות גם הן. אם אני אומר הפוך את זה לברור יותר, הסוכן יכול לשנות יותר מדי. אם אני מצביע על גרף, פסקה או section, המשימה קטנה וברורה יותר.
כך עובדת עריכה אמיתית. נדיר שרוצים לכתוב הכל מחדש. בדרך כלל רוצים משפט חד יותר, גרף פחות מבלבל, slide פחות עמוס, טבלה מסודרת יותר.
איך הייתי בודק את זה
לא הייתי מחבר את כל הכלים ביום הראשון. הייתי בוחר workflow משעמם עם owners ברורים. Weekly business review מתאים: כמה metrics, כמה notes, output משותף ו-human review לפני שליחה.
Checklist קצר:
- להחליט אילו מקורות Codex יכול לקרוא;
- להחליט מה הוא יכול לכתוב;
- לדרוש links למקורות חשובים;
- להצמיד owner לכל artifact;
- לארכב או למחוק מה שכבר לא מועיל.
הסיכון הוא לא first draft גרוע. צוותים יודעים לחיות עם drafts גרועים. הסיכון האמיתי הוא sprawl: עשרה sites שנוצרו, אין owner, אין source trail, ואף אחד לא יודע איזו גרסה נכונה.
הקריאה שלי
ההכרזה הזו מראה שסוכנים יוצאים משלב הדמו. הסוכנים השימושיים לא יהיו אלה שעושים הכי הרבה רעש. הם יהיו אלה שנכנסים לקצב של הצוות: אוספים context, יוצרים draft, שומרים trace, מקבלים feedback מדויק ונשארים בגבולות.
למפתחים זה לא הופך engineering לפחות חשוב. זה הופך אותו ליותר חשוב. מישהו עדיין צריך לתכנן permissions, defaults, נקודות review ומה המשמעות של done.