Copilot ב-GitHub.com — Coding Agent, Review, Spaces

מה זה Coding Agent — הסוכן שחי בענן

עד עכשיו, כל האינטראקציה שלכם עם Copilot הייתה מקומית. פתחתם VS Code, כתבתם פרומפט, וצפיתם ב-Agent Mode עובד על הקבצים שלכם בזמן אמת. זה חזק — אבל זה גם אומר שאתם צריכים להיות שם. לפתוח את העורך, לאשר פעולות, לחכות.

Coding Agent הוא הגרסה העננית. במקום לעבוד אצלכם על המחשב, הוא רץ בסביבה מבודדת (sandbox) בענן של GitHub, מבוססת GitHub Actions. אתם נותנים לו משימה — והוא עובד עליה ברקע, גם כשאתם לא מול המסך.

הרעיון פשוט: אתם פותחים Issue ב-GitHub, מקצים אותו ל-Copilot, ומקבלים Pull Request מוכן כשהוא מסיים. בדרך, אתם יכולים לעקוב אחרי ההתקדמות, להכווין אותו עם תגובות, ולבקש שינויים.

Coding Agent זמין למנויי Copilot Pro+ (39$/חודש) ו-Copilot Enterprise. הוא לא זמין ב-Pro הרגיל (10$/חודש) — זו אחת הסיבות המרכזיות לשדרוג.

מה הוא טוב בו? משימות של רמת מורכבות נמוכה-עד-בינונית ב-codebases עם tests: הוספת פיצ'רים, תיקון באגים, הרחבת tests, refactoring, ושיפור תיעוד. הוא לא מחליף את Agent Mode — הוא משלים אותו. Agent Mode לאינטראקטיבי, Coding Agent לאסינכרוני.

מה חדש ב-2026

Coding Agent השתדרג משמעותית מאז ההשקה. הנה הפיצ'רים המרכזיים שנוספו:

• Model Picker: עכשיו אפשר לבחור מודל לכל משימה. משימה פשוטה? מודל מהיר וזול. משימה מורכבת? מודל חזק יותר. בחירת המודל נמצאת בפאנל ה-Agents, זמינה לכל מנויי Pro/Pro+/Business/Enterprise.
• Self-Review: לפני שהסוכן פותח PR, הוא סוקר את השינויים שלו עצמו באמצעות Copilot Code Review. הוא מזהה בעיות, מתקן, ורק אז מתייג אתכם. התוצאה: פחות עבודת review בשבילכם.
• Custom Agents: אפשר ליצור סוכנים מותאמים בקבצי .github/agents/. למשל: סוכן שמריץ benchmarks לפני ואחרי שינוי ביצועים, או סוכן שמוודא תאימות לערכת בדיקות ספציפית.
• Security Scanning: הסוכן מריץ אוטומטית CodeQL (סריקת vulnerabilities), secret scanning (זיהוי מפתחות API), ובדיקת dependencies מול GitHub Advisory Database — לפני שהוא פותח את ה-PR.
• CLI Handoff: אפשר להתחיל עבודה ב-Copilot CLI ולהעביר אותה ל-Coding Agent, או להיפך. זה מאפשר לעבור בצורה חלקה בין עבודה מקומית לעננית.

חשוב להבין: Coding Agent הוא לא חידוש חד-פעמי שהושק ונשכח. GitHub מעדכנת אותו כל כמה שבועות עם יכולות חדשות — וזו אחת הסיבות שהפרק הזה מסומן כ-freshness-sensitive. מה שכתוב כאן נכון לאפריל 2026 — שווה לבדוק את GitHub Changelog לעדכונים.

דרישות והגדרה

לפני שמתחילים — ודאו שהכל מוגדר:

1. מנוי: Copilot Pro+ ($39/חודש) או Copilot Enterprise. Pro הרגיל ($10/חודש) לא כולל Coding Agent.
2. GitHub Actions: חייב להיות מופעל בריפוזיטורי. אם Actions מכובה — Coding Agent לא יוכל לעבוד.
3. הרשאות: בארגון, ה-Admin צריך לאפשר Coding Agent. ב-Settings → Copilot → Policies בדקו ש-"Coding Agent" מופעל.
4. ריפוזיטורי עם tests: לא חובה, אבל Coding Agent עובד טוב בהרבה כשיש test suite שהוא יכול להריץ כדי לוודא שהקוד שלו עובד.

הקצאת Issue ל-@copilot — מכל מקום

הדרך הישירה ביותר להפעיל את Coding Agent היא מתוך GitHub.com: פותחים Issue, לוחצים על Assignees בצד ימין, ובוחרים Copilot מהרשימה. זהו. הסוכן מתחיל לעבוד.

אבל זה לא הערוץ היחיד. Coding Agent נגיש מכמה מקומות:

כשאתם יוצרים את ה-Issue, שימו לב לשדה Optional prompt — כאן אפשר להוסיף הנחיות ספציפיות: דפוסי קוד, frameworks מועדפים, דרישות testing, סגנון קוד, קבצים שמותר או אסור לשנות. ככל שה-Issue מפורט יותר — ה-PR יהיה טוב יותר.

הקצאה מ-Slack — דוגמה מעשית

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

@GitHub Fix the signup form validation bug in src/components/SignupForm.tsx.
The email field accepts invalid formats. Add zod validation schema and
corresponding unit tests.

Copilot יוצר Issue מהתיאור, מקצה את עצמו, ומתחיל לעבוד. כשה-PR מוכן — ההודעה חוזרת ל-Slack thread עם קישור. אפס החלפת הקשרים.

דרישה: אפליקציית GitHub for Slack חייבת להיות מותקנת ומחוברת לארגון שלכם. ההגדרה נעשית דרך Settings → Integrations ב-GitHub. שימו לב: ההקצאה מ-Slack יוצרת Issue חדש ב-GitHub ומקצה אותו ל-Copilot — אותו תהליך, רק מנקודת כניסה שונה. כל ה-session logs, ה-PR, וה-steering comments נמצאים ב-GitHub כרגיל.

הקצאה מ-Linear

אם הצוות שלכם מנהל פרויקטים ב-Linear (ולא ב-GitHub Issues), יש אינטגרציה ישירה. כשמקצים Issue ב-Linear ל-Copilot:

• Copilot מנתח את תיאור ה-Issue מ-Linear
• פותח Draft PR ב-GitHub
• עדכוני התקדמות חוזרים לתוך ה-activity timeline של Linear
• כשה-PR מוכן — ה-Issue ב-Linear מתעדכן

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

מה קורה אחרי ההקצאה — מ-Sandbox עד Draft PR

ברגע שהקצתם Issue ל-Copilot, מתחילה שרשרת אוטומטית. הנה מה שקורה מאחורי הקלעים:

שלב 1 — Sandbox: Copilot מפעיל סביבת GitHub Actions runner מבודדת. הסביבה הזו מגיעה עם גישה מוגבלת לאינטרנט, הרשאות מצומצמות לריפוזיטורי, וסביבת פיתוח נקייה. אם יצרתם קובץ copilot-setup-steps.yml — השלבים שם ירוצו קודם (התקנת dependencies, הגדרת databases וכו').

שלב 2 — Plan: הסוכן מנתח את הריפוזיטורי, קורא את ה-Issue, מבין את מבנה הפרויקט, ובונה תוכנית ביצוע.

שלב 3 — Code: הסוכן כותב קוד, עורך קבצים קיימים, ומוסיף קבצים חדשים לפי התוכנית. הוא דוחף commits ל-branch חדש.

שלב 4 — Test: הסוכן מריץ את ה-tests וה-linters שלכם. אם משהו נכשל — הוא מנסה לתקן ולהריץ שוב (בדיוק כמו Agent Mode מקומי, רק בענן).

שלב 5 — Security scan: מ-2026, הסוכן מריץ אוטומטית סריקות אבטחה: CodeQL לבדיקת vulnerabilities, secret scanning לזיהוי מפתחות API, ו-dependency check מול GitHub Advisory Database.

שלב 6 — Self-review: לפני פתיחת ה-PR, הסוכן סוקר את השינויים שלו עצמו באמצעות Copilot Code Review. הוא מזהה בעיות, מתקן אותן, ורק אז פותח את ה-Draft PR ומתייג אתכם לסקירה.

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

הסביבה המבודדת — Sandbox

הסביבה שבה Coding Agent עובד היא מבודדת לחלוטין. מה זה אומר בפועל:

• גישה מוגבלת לאינטרנט: הסוכן לא יכול לגלוש חופשי באינטרנט. הוא יכול לגשת ל-registries כמו npm ו-PyPI כדי להתקין packages, אבל לא יכול לקרוא מאתרים שרירותיים.
• הרשאות ריפוזיטורי מצומצמות: הסוכן יכול לקרוא ולכתוב לריפוזיטורי שהוקצה אליו — אבל לא לריפוזיטורים אחרים.
• סביבה נקייה: כל סשן מתחיל מאפס — אין state שנשמר בין סשנים. זה אומר שאם הפרויקט שלכם צריך הגדרות מיוחדות — חובה להגדיר אותן ב-copilot-setup-steps.yml.
• אין גישה ל-secrets ברירת מחדל: אם הסוכן צריך API keys או credentials — צריך להגדיר אותם כ-environment variables דרך ה-setup steps.

הבידוד הזה הוא feature, לא bug. הוא מבטיח שהסוכן לא יכול לגרום נזק לסביבות production, לא יכול לגנוב secrets, ולא יכול לגשת למשאבים שלא אושרו.

עוד משהו שכדאי לדעת: כל סשן מתחיל עם git clone של הריפוזיטורי. הסוכן עובד על branch חדש ודוחף commits לאורך התהליך. אם בשלב כלשהו הוא נתקע או שאתם רוצים שיתחיל מחדש — אפשר לבקש rollback. ערך ה-fetch-depth ב-checkout נדרס אוטומטית כדי לאפשר את זה.

הסוכן גם מריץ את ה-tests שלכם — אם יש test failures, הוא ינסה לתקן אותם בעצמו. כמה ניסיונות? זה תלוי במורכבות, אבל בדרך כלל 2-3 ניסיונות תיקון לפני שהוא פותח את ה-PR עם הערה שמשהו נכשל. אם ה-tests עוברים — ה-PR נפתח כ-"ready for review". אם לא — הוא מצוין כ-draft עם תיעוד של הבעיה.

copilot-setup-steps.yml — התאמת הסביבה

הקובץ .github/workflows/copilot-setup-steps.yml מאפשר לכם להגדיר את הסביבה לפני שהסוכן מתחיל לעבוד. הוא נראה כמו workflow רגיל של GitHub Actions, אבל חייב להכיל job אחד בשם copilot-setup-steps:

name: Copilot Setup Steps
on: workflow_dispatch

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npx playwright install --with-deps

כל מה שתשימו כאן ירוץ לפני שהסוכן מתחיל לכתוב קוד. אפשר להתקין dependencies, להגדיר databases, להריץ migrations — כל מה שנדרש כדי שהקוד יעבוד בסביבה נקייה.

טיפים ל-copilot-setup-steps.yml אפקטיבי:

• שימו cache: אם ה-dependencies שלכם כבדים — השתמשו ב-actions/cache כדי לא להתקין אותם מחדש בכל סשן.
• השתמשו ב-larger runners אם צריך: אם ה-build שלכם דורש הרבה RAM או CPU — הגדירו runs-on: ubuntu-latest-large. אבל זכרו שזה צורך יותר Actions minutes.
• בדקו ש-הכל עובד: הקובץ רץ אוטומטית כ-workflow כשמשנים אותו. בדקו ב-Actions tab שהריצה הצליחה לפני שמקצים Issues.
• אל תשימו secrets ישירות: השתמשו ב-secrets של GitHub Actions, לא בטקסט גלוי.

דוגמה מורחבת לפרויקט Python + PostgreSQL:

name: Copilot Setup Steps
on: workflow_dispatch

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
          POSTGRES_DB: myapp_test
        ports:
          - 5432:5432
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install -r requirements.txt
      - run: python manage.py migrate
        env:
          DATABASE_URL: postgresql://postgres:test@localhost:5432/myapp_test

Steering Comments — הכוונת הסוכן תוך כדי עבודה

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

Steering comments (תגובות הכוונה) הם תגובות על ה-PR שמתייגות @copilot. הסוכן קורא אותן, מבצע את השינויים, דוחף commits נוספים, ומתייג אתכם מחדש.

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

• @copilot Please add JSDoc comments to all exported functions
• @copilot The error handling in processOrder() should use a try-catch, not .catch()
• @copilot Please add edge case tests: empty input, null, and very long strings
• @copilot Use the existing logger from src/utils/logger.ts instead of console.log

הכלל: תהיו ספציפיים. "Make it better" לא עוזר. "Add input validation for the email field using regex pattern" — כן.

כמה דברים חשובים על steering comments:

• כל תגובה = commit חדש: הסוכן מבצע את השינוי ודוחף commit ל-branch. אתם יכולים לראות כל שלב ב-history של ה-PR.
• הסוכן ממשיך את אותו הסשן: הוא לא מתחיל מחדש. הוא יודע מה כבר עשה, מה שיניתם, ומה ביקשתם — כל הקונטקסט נשמר.
• אפשר לבקש rollback: אם הסוכן עשה שינוי שלא מוצא חן בעיניכם — אפשר לבקש @copilot please revert the last change.
• תגובות ספציפיות לשורה: אפשר להשתמש ב-line comments של GitHub (לסמן שורות ספציפיות ב-diff) ולתייג @copilot — הוא יבין בדיוק על מה אתם מדברים.

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

עלות ותקציב — Premium Requests + Actions Minutes

Coding Agent הוא לא חינמי. כל סשן צורך שני סוגי משאבים:

שימו לב: Premium Request אחד לכל סשן — זה יחסית זול. אבל ה-Actions minutes יכולים להצטבר, במיוחד אם הסוכן צריך להריץ test suites כבדים או build processes ארוכים. אם אתם משתמשים ב-larger runners (מכונות חזקות יותר) — הם צורכים דקות ביחס גבוה יותר.

חריגה מהמכסה? Premium requests עולים $0.04 ליחידה. Actions minutes — לפי טבלת המחירים של GitHub.

המלצה: הגדירו budget alerts ב-Settings → Billing כדי לקבל התראה לפני שאתם חורגים.

חישוב ROI מהיר

בואו נחשב: אם Coding Agent חוסך לכם 30 דקות של עבודת פיתוח על Issue — ועולה 1 premium request ($0.04 חריגה, או חלק מהמכסה) + כ-10 דקות Actions — ה-ROI הוא חיובי מאוד. שעת מפתח עולה בישראל בממוצע 200-400 ש"ח. חצי שעה חסכון = 100-200 ש"ח ערך. עלות Coding Agent לסשן: שקלים בודדים.

אבל שימו לב: ה-ROI חיובי רק כשהמשימה מוגדרת היטב. אם אתם מקצים Issue עמום שנכשל אחרי 20 דקות Actions — שרפתם משאבים בלי תוצאה. הכלל: השקיעו 5 דקות בכתיבת Issue טוב כדי לחסוך 30 דקות בתוצאה.

Code Review — ביקורת קוד אוטומטית

ביקורת קוד (Code Review) היא אחד הכלים החזקים ביותר של Copilot — ולפעמים הכי לא מנוצל. במקום לחכות שעמית צוות ייפנה לסקור את ה-PR שלכם, Copilot יכול לעשות סבב ראשון תוך דקות.

מה Copilot בודק ב-Code Review:

• באגים: בעיות לוגיות, race conditions, null references
• אבטחה: SQL injection, XSS, hardcoded secrets
• ביצועים: לולאות לא יעילות, queries כבדים
• קריאות: שמות לא ברורים, פונקציות ארוכות מדי
• תאימות: האם השינוי משתלב עם הארכיטקטורה הקיימת

Code Review זמין לכל מנויי Copilot — מ-Pro (10$/חודש) ועד Enterprise. זה אחד הדברים שלא צריך Pro+ בשבילם.

הפעלת Code Review על PR

שתי דרכים:

1. ידנית: בדף ה-PR, לחצו Reviewers → הוסיפו Copilot. תוך דקות תקבלו תגובות.
2. אוטומטית: הגדירו ש-Copilot יסקור כל PR באופן אוטומטי (ראו בהמשך).

הגדרת Review אוטומטי

אפשר להגדיר Code Review אוטומטי בשלוש רמות:

הגדרת review אוטומטי ברמת ריפוזיטורי נעשית דרך הגדרות הריפוזיטורי → Code review → Copilot. ברמה ארגונית — דרך הגדרות הארגון.

עובדה מרשימה: עד מרץ 2026, Copilot ביצע 60 מיליון ביקורות קוד — צמיחה של פי 10 מאז ההשקה באפריל 2025.

מה Code Review לא עושה

חשוב להבין את הגבולות:

• לא מחליף review אנושי: Code Review של Copilot הוא סבב ראשון — לא סבב אחרון. הוא מצוין לתפוס באגים טכניים, אבל לא יכול להעריך האם הפיצ'ר מתאים ל-product או האם הארכיטקטורה נכונה ברמה העסקית.
• לא בודק runtime behavior: הוא מנתח קוד סטטי — לא מריץ את הקוד. בדיקות ביצועים, memory leaks, ובעיות שמתגלות רק בריצה — זו עדיין אחריות שלכם.
• לא מבין business logic: הוא יכול לתפוס null reference, אבל לא יידע שהנחה עסקית שהטמעתם שגויה.

הגישה הנכונה: Copilot Code Review כ-שומר סף אוטומטי שתופס 70-80% מהבעיות הטכניות, ו-reviewer אנושי שמתמקד בהיגיון עסקי, ארכיטקטורה, ו-UX.

סוגי הערות שתקבלו

בפועל, הערות Code Review מגיעות במספר קטגוריות. הנה מה שאתם עשויים לראות:

עם custom instructions, אתם יכולים לכוון את Copilot להתמקד בקטגוריות הרלוונטיות. לרוב צוותים, הערכה טובה היא: "תמיד Bug + Security, לרוב Performance, תתעלם מ-Style (יש לנו Prettier/ESLint)."

Agentic Code Review — סקירה עם הקשר מלא

במרץ 2026, GitHub שדרגה את Code Review לארכיטקטורה אגנטית (Agentic Code Review). מה זה אומר בפועל?

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

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

Custom Instructions לביקורת קוד

אפשר לכוון את ה-Code Review עם הנחיות מותאמות. הקובץ .github/copilot-instructions.md (אותו קובץ שלמדנו בפרק 4) משפיע גם על ביקורת קוד. Copilot קורא את 4,000 התווים הראשונים של הקובץ — אז תהיו ממוקדים.

דוגמה לתוכן אפקטיבי:

# Code Review Instructions

## Focus Areas
- Always check for proper error handling (try-catch in async functions)
- Flag any hardcoded API keys or secrets
- Verify that new functions have JSDoc comments
- Check for missing null/undefined guards

## Ignore
- Formatting issues (handled by Prettier)
- Import ordering (handled by ESLint)
- Minor naming preferences

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

חשוב: Copilot קורא רק את 4,000 התווים הראשונים של קובץ ה-instructions. אם הקובץ שלכם ארוך יותר — מה שאחרי 4,000 תווים לא ישפיע על ה-review. לכן:

• שימו את הכללים הכי חשובים בראש הקובץ
• היו ממוקדים — 10 כללים טובים עדיפים על 50 כללים מפוזרים
• השתמשו בנקודות קצרות, לא בפסקאות ארוכות
• נסו, מדדו, שפרו — בדקו אם ההערות משתפרות אחרי כל עדכון ב-instructions

אפשר גם להשתמש בקבצי *.instructions.md עם applyTo (שלמדנו בפרק 4) כדי ליצור הנחיות שונות לסוגי קבצים שונים. למשל: הנחיות מחמירות יותר לקבצי API (אבטחה!) והנחיות רכות יותר לקבצי UI.

תיקון אוטומטי מהמלצות Review

הערת Code Review היא לא רק טקסט — היא מגיעה עם הצעת תיקון שאפשר להחיל בלחיצה. שלוש אופציות:

האופציה השלישית — Pass to Coding Agent — היא ב-public preview. היא מאפשרת לקחת המלצה מסקירה ולהפוך אותה למשימה של Coding Agent, שיפתח PR חדש עם התיקון. זה סוגר את הלולאה: סקירה → זיהוי בעיה → תיקון אוטומטי → PR חדש.

PR Summaries — סיכום אוטומטי

בנוסף ל-Code Review עצמו, Copilot גם יוצר PR Summary — סיכום אוטומטי של השינויים ב-PR. הסיכום מופיע בתיאור ה-PR וכולל:

• מה השתנה ולמה (ברמה גבוהה)
• אילו קבצים הושפעו
• סיכום השפעה על הפרויקט

זה חוסך זמן ל-reviewers — במקום לקרוא diff ארוך כדי להבין "מה הולך כאן", הם מקבלים סיכום מהיר ויכולים להתמקד ב-deep review של החלקים הקריטיים. בפרויקטים גדולים עם PRs של מאות שורות — PR Summary חוסך 10-15 דקות לכל סקירה. כפול 5 PRs ביום כפול צוות של 10 מפתחים — זה כבר ימים שלמים שנחסכים בשבוע.

PR Summary נוצר אוטומטית כש-Copilot הוא ה-reviewer, אבל אפשר גם לבקש אותו ידנית מתוך Copilot Chat.

Batch Suggestions — איחוד תיקונים

כשמקבלים 5-10 הערות Code Review, לא נוח להחיל כל אחת בנפרד — זה יוצר 10 commits קטנים ומלכלך את ההיסטוריה. כאן נכנס Add to batch.

התהליך:

1. עברו על ההערות של Copilot בדף ה-PR
2. לכל הערה שרוצים לקבל — לחצו Add to batch (במקום Commit suggestion)
3. אחרי שבחרתם את כל ההצעות הרלוונטיות — לחצו Commit batch
4. כל ההצעות מוחלות ב-commit אחד נקי

זה שומר על היסטוריית Git נקייה ומאפשר review מסודר של כל התיקונים יחד.

Copilot Spaces — קונטקסט מתמשך לפרויקט

כשאתם שואלים את Copilot שאלה ב-Chat — הוא רואה את הקובץ הפתוח, אולי כמה קבצים סביבו, ואת ההיסטוריה של השיחה. אבל הוא לא יודע שיש לכם design doc ב-Notion, Issue פתוח שמתאר באג קריטי, או README שמסביר את הארכיטקטורה.

Copilot Spaces (מרחבי Copilot) פותרים את הבעיה הזו. Space הוא אוסף מתמשך של קונטקסט — קוד, תיעוד, Issues, קבצים — שחי מעבר להיסטוריית הצ'אט. כשאתם משתמשים ב-Space, Copilot לא מנחש — הוא יודע.

Spaces הושקו במאי 2025 כמרחבים פרטיים, הגיעו ל-General Availability בספטמבר 2025, ומדצמבר 2025 אפשר גם לשתף אותם עם אחרים. הם זמינים לכל מנויי Copilot — מ-Pro ומעלה — ללא עלות נוספת.

הבעיה ש-Spaces פותרים היא בעיית הקונטקסט. בלי Spaces, כל אינטראקציה עם Copilot היא "שיחה חד-פעמית" — הוא רואה את הקובץ הנוכחי, אולי כמה קבצים סמוכים, ואת היסטוריית הצ'אט (שנמחקת כשפותחים שיחה חדשה). Spaces יוצרים שכבת זיכרון מתמשכת שחיה מעבר לשיחה בודדת.

חשבו על זה כך: כל פרויקט תוכנה הוא מערכת מורכבת עם עשרות החלטות ארכיטקטוניות, conventions לא כתובים, ידע שבועי שנצבר, ו-context שהולך לאיבוד כל פעם שמישהו חדש מצטרף. Spaces הם הדרך להפוך את הידע הזה ל-נגיש אוטומטית — לא רק לבני אדם, אלא גם ל-AI שעובד על הפרויקט. במקום שכל שאלה ל-Copilot תתחיל מ"תן לי להסביר לך מה הפרויקט הזה..." — ה-Space כבר מכיר הכל.

מה אפשר לשים ב-Space:

• ריפוזיטורים שלמים — כל הקוד מקושר
• קבצים ספציפיים — README, config files, architecture docs
• Pull Requests — כולל ה-diff והשיחה
• Issues — באגים, פיצ'רים, תכנון
• טקסט חופשי — תמלולים, הערות, תיעוד לא רשמי
• תמונות — דיאגרמות, wireframes, צילומי מסך
• קבצים מהמחשב — העלאה ישירה

הדבר הכי חזק: קבצים מ-GitHub מתעדכנים אוטומטית. שיניתם README? ה-Space יודע. מזגתם PR? ה-Space מעודכן. זה קונטקסט חי, לא צילום מסך של רגע מסוים.

למה Spaces הם game-changer

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

עם Spaces, אתם בונים פעם אחת "מוח" שמכיל את כל מה שחשוב על הפרויקט. כל שאלה — בין אם ב-GitHub.com, ב-VS Code, או ב-CLI — נהנית מהקונטקסט הזה. זה כמו ההבדל בין לשאול שאלה לעמית חדש שהגיע היום, לבין לשאול את הארכיטקט הבכיר שמכיר כל פינה בפרויקט.

כמה דוגמאות לשאלות ש-Space הופך ממשהו גנרי למשהו שימושי:

שיתוף Spaces

מדצמבר 2025, אפשר לשתף Spaces:

• פרטי (Private): רק אתם רואים — ברירת מחדל
• צוותי: שתפו עם חברי צוות ספציפיים — מצוין ל-onboarding
• ציבורי (Public): כל אחד יכול לראות — מצוין ל-open source

השיתוף הצוותי הוא בעל ערך מיוחד ל-onboarding. במקום לכתוב מדריך ארוך לעובד חדש, תנו לו גישה ל-Space שמכיל את כל הקונטקסט. הוא יכול לשאול את Copilot שאלות ולקבל תשובות מבוססות על הידע המרוכז — כמו mentor אוטומטי.

יצירת Space — קוד, Docs, Issues וקבצים

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

שלב 1: הוסיפו את הריפוזיטורי

לחצו Add content → Repository → בחרו את הריפוזיטורי. כל הקבצים מקושרים ומתעדכנים אוטומטית.

שלב 2: הוסיפו קבצים מרכזיים

גם אם הריפוזיטורי כבר שם — שווה להדגיש קבצים ספציפיים. הוסיפו URLs של קבצים כמו README.md, ARCHITECTURE.md, קובץ config ראשי, או package.json.

שלב 3: הוסיפו Issues

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

שלב 4: הוסיפו טקסט חופשי

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

# Architecture Notes
- We use a monorepo with Turborepo
- API is in /apps/api (Express + TypeScript)
- Frontend is in /apps/web (Next.js 14)
- Shared types in /packages/types
- All API routes must validate input with Zod
- We deploy to Vercel (frontend) and Railway (API)

שלב 5: העלו קבצים מקומיים

יש לכם wireframe ב-PNG? design doc ב-PDF? תמלול פגישה? העלו ישירות ל-Space. זה מרחיב את ההקשר מעבר למה שנמצא ב-GitHub.

טיפים ל-Space אפקטיבי

• פחות הוא יותר — בהתחלה: אל תנסו לשים הכל ב-Space. התחילו עם 5-10 פריטים ממוקדים, ובדקו אם Copilot נותן תשובות טובות יותר. הוסיפו בהדרגה.
• עדכנו את הטקסט החופשי: זה המקום שהכי מהר מתיישן. אם שיניתם ארכיטקטורה, convention, או כלי — עדכנו את הטקסט. קבצים מ-GitHub מתעדכנים אוטומטית, אבל טקסט חופשי לא.
• צרו Space נפרד לכל פרויקט: Space אחד שמכיל שלושה פרויקטים יהיה מבולגן. Space ממוקד = תשובות ממוקדות.
• שתפו עם הצוות: אם אתם עובדים בצוות — שתפו את ה-Space. זה חוסך לכל חבר צוות את הזמן ליצור Space משלו, ומבטיח שכולם עובדים עם אותו הקשר.

Spaces ב-IDE — גישה דרך GitHub MCP Server

Spaces לא חיים רק ב-GitHub.com. אפשר לגשת אליהם גם מתוך ה-IDE — VS Code ו-Copilot CLI — דרך GitHub MCP Server (שלמדנו בפרק 5).

כדי להשתמש ב-Spaces מתוך ה-IDE:

1. ודאו ש-GitHub MCP Server מוגדר: ב-VS Code, פתחו Copilot Chat ובדקו שהכלים get_copilot_space ו-list_copilot_spaces מופיעים ברשימת הכלים הזמינים.
2. עברו ל-Agent Mode: Spaces נגישים רק ב-Agent Mode — לא ב-Ask או Edit. בחרו "Agent" מתפריט המצבים.
3. שאלו שאלה שמתייחסת ל-Space: Copilot יוכל לשלוף קונטקסט מה-Space כחלק מתהליך ה-tool-calling.

אפשר גם להגדיר גישה ישירה ל-Spaces בלבד, בלי שאר כלי ה-GitHub MCP, דרך כתובת ייעודית:

https://api.githubcopilot.com/mcp/x/copilot_spaces

מגבלה חשובה: Spaces שמכילים רק ריפוזיטורי (ללא קבצים ספציפיים, Issues, או טקסט) לא נגישים כרגע מתוך ה-IDE. כדי להשתמש ב-Spaces ב-IDE — הוסיפו לפחות פריט קונטקסט אחד נוסף (קובץ, Issue, או טקסט חופשי).

דוגמה מעשית: Space לפרויקט Node.js

נניח שיש לכם פרויקט Express + TypeScript + PostgreSQL. הנה Space אפקטיבי:

עם Space כזה, כששואלים את Copilot "Where should I add the new /users endpoint?" — הוא יודע בדיוק איפה ולמה, כולל conventions הספציפיים של הפרויקט.

Coding Agent מול Agent Mode — טבלת החלטה

זו אולי השאלה הכי חשובה בפרק הזה: מתי להשתמש ב-Coding Agent (הענן) ומתי ב-Agent Mode (המקומי)? הם לא מתחרים — הם משלימים.

התבנית המנצחת: השתמשו ב-Agent Mode לתכנון ו-spec — תנו לו לנתח את הקוד, לכתוב design doc, לחקור את הבעיה. ואז צרו Issue מפורט מהתוצאות והקצו אותו ל-Coding Agent ליישום. כך Agent Mode עושה את "החשיבה" ו-Coding Agent עושה את "העשייה".

דוגמה מעשית: Workflow משולב

הנה דוגמה לתהליך שמשלב את שני המצבים:

1. Agent Mode (מקומי): "Analyze the current authentication flow and write a design doc for adding OAuth2 with Google and GitHub providers."
2. Agent Mode מנתח את הקוד, מזהה את ה-auth middleware הקיים, וכותב design doc מפורט.
3. אתם: סוקרים את ה-design doc, מתקנים, מוסיפים הערות.
4. Coding Agent (ענן): יוצרים 3 Issues נפרדים:
   • Issue 1: "Add Google OAuth2 provider (see design doc in docs/oauth2-design.md)"
   • Issue 2: "Add GitHub OAuth2 provider (same design doc)"
   • Issue 3: "Add OAuth2 tests for both providers"
5. מקצים את שלושת ה-Issues ל-Copilot — הם יכולים לרוץ במקביל!
6. אתם: עושים Code Review על שלושת ה-PRs, מוסיפים steering comments אם צריך, ומזגים.

התהליך הזה לוקח שעות ספורות במקום ימים — ורוב הזמן שלכם מושקע ב-review (שממילא הייתם צריכים לעשות) ולא בכתיבה.

מתי Coding Agent מתקשה — ומתי Agent Mode עדיף

Coding Agent לא פותר הכל. הנה מצבים שבהם Agent Mode עדיף בבירור:

• חקירת באג שלא ברור: כשאתם לא יודעים מה הבעיה, צריך חקירה אינטראקטיבית — להריץ קוד, לבדוק logs, לנסות שינויים קטנים. Agent Mode מאפשר הלוך-חזור מהיר. Coding Agent צריך Issue מוגדר — אם לא יודעים מה לכתוב ב-Issue, עדיין לא הזמן בשבילו.
• עבודה עם שירותים מקומיים: אם הקוד שלכם צריך Docker containers, מיקרו-שירותים, או databases שרצים על המחשב — Agent Mode ניגש ישירות. Coding Agent מוגבל לסביבת Actions.
• Prototyping מהיר: כשאתם רוצים לנסות רעיון מהר — Agent Mode בעורך הוא מיידי. Coding Agent צריך זמן ל-spin up סביבה.
• שינויים שדורשים ראייה ויזואלית: אם אתם עובדים על UI וצריכים לראות את התוצאה בזמן אמת — Agent Mode עם browser preview. Coding Agent לא יכול להציג UI.

מצד שני, Coding Agent עדיף כש:

• יש לכם backlog של Issues קטנים: הקצו 5 Issues בבת אחת, תנו ל-Coding Agent לעבוד על כולם, וסקרו את ה-PRs כשהם מוכנים. זה כמו צוות שעובד בשבילכם.
• אתם צריכים PR-based workflow: כל שינוי עובר review, tests, CI — מובנה. עם Agent Mode צריכים לעשות commit ו-push ידנית.
• אתם רוצים לנצל זמן מת: הולכים לפגישה? הקצו Issue לפני. חוזרים — PR מחכה. Coding Agent עובד 24/7.

דפוסי שימוש מומלצים לפי תפקיד

השימוש המיטבי תלוי בתפקיד שלכם ובסוג העבודה:

הנקודה המרכזית: אתם לא צריכים לבחור אחד מהשניים. הצירוף שלהם — Agent Mode לחשיבה ותכנון, Coding Agent לביצוע — הוא הדרך החזקה ביותר לעבוד עם Copilot ב-2026. חשבו על זה כמו ההבדל בין מנהל פרויקט (שמתכנן ומנתח) לבין מפתח (שמבצע). Agent Mode הוא המנהל, Coding Agent הוא המבצע — ואתם מפקחים על שניהם.

שימו לב גם לעלות: Agent Mode צורך premium requests לפי אורך השיחה והמודל, בעוד Coding Agent צורך תמיד בקשה אחת לסשן + Actions minutes. למשימות ארוכות, Coding Agent יכול להיות דווקא זול יותר — כי הסשן שלו לא תלוי באורך השיחה.

הקצאת Security Alerts ל-Copilot

פיצ'ר נוסף שכדאי להכיר: אפשר להקצות code scanning alerts (התראות אבטחה) ישירות ל-Copilot. כשיש לכם vulnerability שזוהה ע"י CodeQL או Dependabot — אפשר ללחוץ "Assign to Copilot" במקום לתקן ידנית.

מה קורה: Copilot מנתח את ה-vulnerability, בונה תוכנית תיקון, ופותח Draft PR. לפי הנתונים של GitHub, הזמן הממוצע לתיקון אוטומטי הוא 28 דקות — לעומת 1.5 שעות בתיקון ידני. ל-SQL injection ספציפית — התיקון מהיר פי 12.

הפיצ'ר הזה ב-public preview (מאוקטובר 2025) ונדרשת רישיון GitHub Code Security בנוסף ל-Copilot.

סיכום: ארבעת ה-Agents של GitHub Copilot

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

כל אחד מהם פועל בצורה שונה ומתאים לתרחישים שונים. הבחנה ברורה ביניהם היא מפתח לשימוש יעיל ב-Copilot.