תכנן ב-ChatGPT Pro, בצע ב-Codex: מדריך מסירת מסמך העיצוב

תהליך העבודה ששווה לגנוב החודש אינו מודל, אלא חלוקת עבודה. אתה מוסר GPT-6 Pro ב-ChatGPT כתובת URL של מאגר, מבקש ממנו מסמך עיצוב ולא טלאי, ומוסר את המסמך הזה ל-Codex או Claude Code כדי ליישם אותו. המתכנן פועל על GPT-6 Astra — GPT-6 Pro הוא השם שבו מגבלות השימוש של ChatGPT מכנות אותו — ו-Astra הוא מודל מ-2026-09-03, כך ששום דבר כאן אינו סיקור השקה או הצהרת מהדורה. מה שהשתנה בשבעת הימים האחרונים מצומצם יותר, וראוי לומר אותו במדויק: ב-2026-09-17 דיווחו אנשי מקצוע שתוסף GitHub הרשמי ב-ChatGPT Chat הרגיל, לא ב-ChatGPT Work ולא ב-Codex, יכול לערוך קבצים במאגר, לבצע קומיט ולפתוח בקשות משיכה בלי לצרוך מהמכסה של Codex/Work. זוהי טענה קהילתית, לא תיעוד של הספק — דפי העזרה הרשמיים עדיין מתארים את אפליקציית GitHub כקריאה בלבד ומנתבים כל כתיבה דרך Codex — וההסתייגויות המצורפות לכך חשובות לא פחות מהטענה עצמה. כל מה שלהלן מסומן כדיווח ספק, כדיווח קהילה, או כנקרא מהדפים הרשמיים ב-2026-09-19.

תהליך העבודה, במעבר אחד

אנשי מקצוע מתארים את אותה לולאה עם וריאציות קטנות. זו שחוזרת על עצמה: להדביק כתובת GitHub ב-ChatGPT, לבקש ממנו לקרוא את הקוד ולהפיק מסמך עיצוב, ואז להוריד את המסמך הזה ולהזין אותו לסוכן מבצע. חלקם מבקשים גם pull request; אחרים עוצרים במסמך ומשאירים את הכתיבה למבצע. כך או כך, הצורה זהה — התכנון במוצר הצ׳אט, הבנייה במוצר הסוכן — והסיבה שכדאי להעתיק אותה היא ששני החצאים נמדדים בנפרד.

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

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

• ארטיפקט סקירה — ה־diff, שהוא הדבר היחיד שאמור אי־פעם להגיע לסוקר.

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

למה מבנה שני הדליים הוא כל הטריק

ChatGPT לא מחייב את זרימת העבודה הזו מקופה אחת. ל-Chat, ל-ChatGPT Work ול-Codex יש מכסות נפרדות, כאשר Work ו-Codex חולקים ביניהם מאגר אחד; ומפתח OpenAI API הוא חיוב נפרד משל עצמו. המבנה הזה הוא מה שהופך את העברת המשימה לחסכונית: החשיבה מתרחשת בדלי של Chat, הביצוע מתרחש בדלי של הסוכן, ומסמך עיצוב עולה הודעת Chat אחת בעוד שהמימוש עולה שימוש בסוכן.

המספרים, כפי ש-OpenAI מפרסמת אותם עבור צד ה-Chat — נתונים שמדווח הספק בתיעוד התוכנית של הספק עצמו, לא מדידות:

• ChatGPT Pro ב-200 דולר לחודש — 200 הודעות GPT-6 Pro בשבוע; GPT-5.6 Sol Pro מאפשר בנוסף 170 הודעות ביום, כאשר שני המודלים יחד מוגבלים ל-200 הודעות ביום.

• ChatGPT Pro ב-100 דולר לחודש — 50 הודעות GPT-6 Pro בשבוע, מתוך מכסה משותפת עם GPT-5.6 Sol Pro.

• Business Standard — 15 הודעות GPT-6 Pro בחודש, משותפות עם Sol Pro; Business Premium — 50 בשבוע על אותו בסיס משותף.

• ChatGPT Plus — אין GPT-6 Pro ב-Chat בכלל. Astra מגיעה ל-Plus רק דרך ChatGPT Work ו-Codex, שזה בדיוק הפלח שהמדריך הזה מנסה להגן עליו.

בצד של Work/Codex, OpenAI מפרסמת אומדנים ולא מגבלות, ואומרת זאת במפורש: בערך 5 עד 45 הודעות Astra לכל חלון של חמש שעות ב-Plus, 25 עד 225 ב-Pro 5x, ו-100 עד 900 ב-Pro 20x, כאשר באותו עמוד מצוין שהצריכה בפועל משתנה בהתאם למורכבות המשימה, ההקשר, הפלט והשימוש בכלים, ושמגבלות שבועיות עשויות לחול בנוסף. הטווחים האלה עומדים על בערך מחצית מהמספרים המקבילים של Sol, וזו הסיבה האריתמטית לכך שמודל חזיתי בכלל משתלם להריץ כסוכן.

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

מסלול הכתיבה: מה שהמחבר עושה, ומה שאנשים טוענים שהוא עושה

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

תיעוד העזרה של OpenAI עצמה הוא חד-משמעי: אפליקציית GitHub ב-ChatGPT קוראת את המאגרים שלך לצורכי ניתוח וחיפוש, ואילו יצירת קוד, עריכתו ודחיפתו ל-GitHub הם הייעוד של Codex. זו עמדת הקריאה בלבד, והיא זו שלפיה יש לתכנן אם אתה מכניס את זה לתהליך צוותי, משום שהיא זו שיש מאחוריה ספק.

עמדת הקהילה, מיום 2026-09-17, היא שתוסף GitHub של גרסת הווב במצב Chat יערוך קוד, יבצע קומיטים ויפתח pull requests, וכיוון שזהו תוסף רשמי ולא שרת MCP של צד שלישי, הוא אינו צורך את מכסת Codex או Work. באותו שרשור מקפידים על היקף הפעולה: כלים קטנים, עריכות קטנות, באגים קטנים — ריפקטורים גדולים ודיבוג קשה עדיין שייכים ל-Codex. המגיבים בשרשור עצמו מוסיפים הסתייגויות שכדאי לחזור עליהן, משום שהן אלו שנושכות:

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

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

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

כתיבה יפנית עצמאית של אותו דפוס מגיעה למסקנה תואמת ללא טענת המכסה: אם אינטגרציית GitHub תומכת בפעולות כתיבה, צ׳אט רגיל יכול לקרוא מאגר, לשנות קבצים, ליצור ענף ולפתוח בקשת משיכה; חלות מגבלות הקצב הרגילות של הצ׳אט; ו-Codex ו-Work נשענים על מאגר הסוכנים המשותף, כך שצ׳אט רגיל מיועד לעריכת קומץ קבצים ו-Codex למשימות תוכנה ארוכות. היכן ששני הדיווחים מסכימים, ההסכמה היא החלק השימושי: צ׳אט הוא ערוץ לשינויים קטנים, Codex הוא ערוץ לסשנים ארוכים, והמאגרים נפרדים.

קיימים שרתי MCP של צד שלישי שחושפים תהליך עבודה אמיתי עם git — branch, diff, commit, push, פתיחת pull request — עם הרשאות שאפשר לדרג מקריאה בלבד ועד ל-push. אם אתם רוצים שנתיב הכתיבה יהיה דטרמיניסטי וניתן לביקורת, ולא התנהגות שאתם מקווים לה, זו הדרך; אם אתם רוצים להישאר בתוך מה ש-OpenAI מתעדת, תכננו ב-Chat וכתבו ב-Codex.

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

המסירה, צעד אחר צעד

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

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

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

• שמור את המסמך במאגר במקום להדביק אותו בכלי הבא. מבצע שקורא קובץ יכול לקרוא אותו שוב; מבצע שקיבל הדבקה יש לו הזדמנות אחת בלבד.

• הפעילו את המבצע (executor) עם המסמך כהוראה שלו, והגבילו pull request אחד לסעיף אחד במסמך. הפעלות ארוכות הן המקום שבו איכות הסוכן דועכת בשקט.

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

איפה זה נשבר

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

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

• הפתעת מכסה בכיוון הלא נכון — שיחת תכנון בת עשרים דקות זולה בהודעות Chat ויקרה בקשב; הרצת סוכן ארוכה היא ההפך. תקצב את הדלי שאתה מוציא ממנו בפועל.

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

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

הרצת חצי ה-executor דרך נקודת קצה אחת

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

לשם כך נועדה שכבת ניתוב.openai/gpt-6-astra נמצא מאחורי אותה נקודת קצה תואמת OpenAI כמו 200+ דגמים אחרים, כאשר מחיר המחירון של הספק מועבר הלאה בתוספת של 0% — כך שכאשר ספק משנה מחיר, המחיר בצד שלנו משתנה באותו יום ולא בחידוש החוזה הבא. מעבר אוטומטי מאפשר לך לשים דגם לא מוכח על נתח מהתעבורה עם דגם מוכח מתחתיו, וזו הדרך הכנה לגלות אם מבצע זול טוב מספיק עבור הבדיקות שלך. וה-DSL של הניתוב מרכיב מספר דגמים לקריאה אחת, כך שדגם סוקר יכול לבדוק את ה-diff של המבצע על אותו מפתח, באותו נתיב בקשה, בלי אינטגרציה שנייה.

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

מי צריך להריץ את זה עכשיו, ומי צריך לחכות

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

אם אתה ב-Plus, מתֵן את הציפייה. אסטרה מגיעה אליך דרך Work ו-Codex אבל לא דרך Chat, כך שחצי התכנון של ספר המשחק הזה אינו זמין לך בצורה המתוארת — היית מתכנן ומבצע מאותו מאגר, מה שמסיר את הטיעון הכלכלי ומשאיר רק את המשמעת של כתיבת המסמך תחילה. המשמעת הזו עדיין שווה. ההנחה לא.

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

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