שאלת בגרות – האקתון פיתוח מונחה-AI
Disclaimers
אינני תומך במתן גישה ל-GenAI לתלמידי יסודות במהלך בחינת הבגרות. מהלך כזה שומט את הקרקע מתחת לעצם האפשרות לבחון ידע ומיומנויות בסיסיות בתחום, ולכן אינו מאפשר הערכה תקפה. אם תיכפה פתיחת גישה כזו, יהיה צורך בשינוי מהותי ועמוק של אופי הבחינה, בדומה למתואר להלן (או בגישה חלופית אחרת). עם זאת, גם במצב כזה אני צופה התנגדות מצדי, שכן אינני סבור שלמשרד קיימות כיום היכולות המערכתיות הנדרשות למהלך כולל בקנה מידה זה — לרבות הכשרת בוחנים, מנגנוני בדיקה מתאימים, ותשתיות הערכה המזכירות יותר בדיקת פרויקט גמר ברמת 5 יחידות.
אינני בוחן פרויקטים באופן שוטף, אך אני סבור כי בדיקת ספר פרויקט ותוצר תוכנתי בעת הזו צריכה לכלול יותר היבטים מן המתואר כיום, ובהם גם רכיבים מן הסוג המוצע להלן. זאת בנוסף לבדיקת הבנה קלאסית, כפי שנהוג כיום, רכיב חשוב שלא בא לידי ביטוי בהצעה זו, בעיקר בשל מגבלות משך הבחינה (אך גם הזמן שהקדשתי לרעיון)
שילוב AI בהערכה הוא נושא מורכב ורב־פנים, וקיים בו פוטנציאל גבוה לאי-הבנות באשר למה בדיוק “נפתח” לתלמידים ובאילו כלים מותר לעבוד. נקודת המוצא במסמך זה היא שכאשר נאמר GenAI מלא, הכוונה היא לגישה לכלים המתקדמים ביותר הקיימים כיום בקצה העליון של המעטפת — כגון Codex, Claude Code, Anti-Gravity, Cursor ואחרים. בהתאם לרמת ההגבלות שתיקבע בפועל, יהיה הכרח להתאים מחדש גם את תוכני הלימוד, מטרות ההערכה ואופי הבחינה.
תיאור כללי
במסגרת בחינה זו התלמיד ישתתף בהאקתון קצר (2–3 שעות), שבו עליו לתכנן, לפתח, לתעד ולהציג תוצר תוכנתי סביב נושא שיוגדר לו בתחילת הבחינה. לתלמיד מותר ואף מצופה להשתמש בכלי AI (כגון Codex / Claude Code / Gemini), אך האחריות על קבלת ההחלטות, הבקרה, וההבנה – היא של התלמיד.
הדגש בבחינה הוא לא רק על הקוד, אלא על ניהול תהליך פיתוח מקצועי, קבלת החלטות מושכלת, ותיעוד מלא של העבודה.
נושא ההאקתון (יינתן בתחילת הבחינה)
דוגמה לנושאים אפשריים:
- מערכת ניהול פשוטה (משימות, תלמידים, מלאי, אירועים).
- משחק קטן עם לוגיקה ברורה.
- כלי אוטומציה / ניתוח נתונים.
- API פשוט + לקוח.
- יישום המדגים מבנה נתונים / אלגוריתם בצורה אינטראקטיבית.
הנושא יוגדר כך שיתאים להיקף של מספר שעות, ולא ידרוש ידע חיצוני מתקדם.
דרישות חובה
1. ניהול פיתוח באמצעות Git (KPI מרכזי)
על התלמיד:
- לעבוד עם Repository ייעודי.
- לבצע Commits משמעותיים לאורך הזמן (לא Commit אחד בסוף).
-
להקפיד על:
- הודעות Commit ברורות.
- חלוקה הגיונית לשלבים (setup, core logic, refactor, docs, polish וכו’).
דוגמאות לנקודות ציון רצויות:
- Commit ראשוני – הגדרת שלד הפרויקט.
- Commit – מימוש לוגיקה מרכזית.
- Commit – שינוי ארכיטקטוני / refactor.
- Commit – הוספת תיעוד ובדיקות.
2. מסמכולוגיה מלווה תהליך
יש להגיש תיקיית /docs (או קובץ Markdown מרכזי) הכוללת:
א. מסמך אפיון קצר
- מה הבעיה שנפתרת.
- מה כולל התוצר.
- מה לא נכלל (Scope).
ב. תכנון ראשוני
- מבנה כללי של המערכת.
- חלוקת רכיבים / מחלקות / קבצים.
- בחירות טכנולוגיות (ולמה).
ג. תיעוד תהליך
- אילו בעיות עלו במהלך הפיתוח.
- אילו שינויים נעשו ביחס לתכנון הראשוני.
- החלטות חשובות שנלקחו לאורך הדרך.
3. מסמכי Prompting (KPI קריטי)
על התלמיד להציג התמודדות מודעת עם AI, ולא שימוש עיוור.
יש להגיש:
-
מסמך
prompting.md(או דומה) הכולל:- Prompts עיקריים שניתנו ל-AI.
- תמצית התשובות שהתקבלו.
-
החלטות התלמיד בעקבות התשובות:
- מה אומץ.
- מה נדחה.
- מה שונה.
בנוסף:
-
יש לצרף צילומי מסך (screenshots) של עבודה מול Codex / Claude / Gemini, המדגימים:
- ניסוח בעיה.
- קבלת הצעה ארכיטקטונית.
- דיון/התלבטות (למשל: “למה לא בחרתי בפתרון הזה”).
הערכה תינתן על איכות השיח עם ה-AI, לא על “כמה הוא כתב בשבילי”.
תוצר סופי
- קוד עובד (או אב-טיפוס ברור).
- ניתן להרצה / הדגמה.
-
כולל README קצר עם:
- הוראות הרצה.
- תיאור כללי.
קריטריונים להערכה (KPIs)
| תחום | משקל |
|---|---|
| ניהול פיתוח בגיט (תהליך, commits) | 15% |
| מסמכולוגיה ותיעוד תהליך | 30% |
| שימוש מושכל ב-AI ו-Prompting | 35% |
| איכות התוצר והקוד | 20% |
דגשים חשובים
- אין ציפייה לתוצר “מושלם”. אבל צריכים להיות לפחות 2-3 commits עובדים.
- יש ציפייה להבנה, בקרה וחשיבה ביקורתית שמודגמת בדיאלוג עם ה-AI
- תלמיד שאינו מיומן בעבודה עם AI – יתקשה לעמוד בדרישות.
- תלמיד שנתן ל-AI “לעבוד במקומו” ללא תיעוד והחלטות – יקבל ציון נמוך.
מטרת הבחינה
לבחון את יכולת התלמיד לפעול כמפתח עצמאי בעולם מודרני:
תכנון, פיתוח, תיעוד, קבלת החלטות – בשיתוף AI, ולא במקומו.