# כיצד יכולה בינה מלאכותית לערוך קוד בלי ליצור מחדש את התוכנית כולה?

Canonical HTML: https://aogavrilov.com/he/projects/discrete-latent-generation/

Document language: he

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

פורסם 25 ביולי 2026 עודכן 30 ביולי 2026 [Alexey Gavrilov](https://aogavrilov.com/about/)

## מהי הבעיה בפועל

עריכת קוד אינה רק יצירת קוד באמצעות הנחיה קצרה יותר. כלי עריכה מקבל תוצר קיים, שינוי רצוי וחוזה שימור משתמע. לפיכך, לשאלה המרכזית שני צדדים: **איזה אזור רשאי להשתנות, ואילו תכונות של השאר חייבות להישאר יציבות?**

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

## הרעיון המרכזי

עורך תחום זקוק לגבול שימור מפורש, ולא רק ליעד יצירה.

### מה חייב להישאר קבוע

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

### מה רשאי להשתנות

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

## מודל אינטואיטיבי: לשפץ חדר אחד ולשמר את הבניין

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

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

## מבט מדויק יותר על יצירה חלקית מחדש

נניח למקודד למפות תוכנית `x` לייצוג חבוי מובנה `z` . מסכת שימור בוחרת מיקומים `L` שיישארו קבועים. המחולל דוגם רק את המיקומים המשלימים תוך אכיפת `z'l = zl` לכל מיקום נעול. לאחר מכן מפענח ממפה את הייצוג שהושלם `z'` בחזרה לקוד המקור.

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

## תהליך עריכה בן ארבעה שלבים

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

## עריכת קוד, תיקון תוכניות ויצירה תחת אילוצים אינן אותה משימה

| גישה | מטרה עיקרית | מנגנון שימור טיפוסי | מה עדיין טעון אימות |
| --- | --- | --- | --- |
| יצירת קוד מלא | הפקת תוצר שלם | הנחיה והקשר | כל מה שמחוץ לשינוי המבוקש |
| תיקון תוכניות אוטומטי | הסרת תקלה שאובחנה | איתור תקלות, בדיקות, תבניות או טלאים | נכונות מעבר לבדיקות הזמינות ומזעריות התיקון |
| מודלים להשלמת קטעים או לעריכה | שינוי אזורי טקסט נבחרים | תחילית, סיומת, הבדל או הקשר עריכה גלויים | שינויים מבניים והתנהגותיים לא מכוונים |
| פענוח מוגבל־דקדוק | יש להבטיח שהפלטים שייכים לשפה פורמלית | מצבי פענוח תקינים מבחינה דקדוקית | משמעות התוכנית, נכונות המשימה ומקומיות |
| בקרה היררכית במרחב הסמוי | יצירה מחדש של מיקומים נלמדים שנבחרו | קודים גסים או עדינים נעולים במרחב הסמוי | מה משמרים קודים אלה לאחר הפענוח |

## כיצד למדוד מקומיות ושימור המבנה

## איזה משטח בקרה מתאים למשימת העריכה?

„אין לשכתב את הפונקציה כולה” היא דרישה, לא שיטה שלמה. יש להתחיל בתוצאה שחייבת להיות צפויה, ולאחר מכן לבחור משטח שליטה וראיות תואמות.

| הערובה הנדרשת | משטח שליטה מותאם יותר | הראיות שיש לדרוש |
| --- | --- | --- |
| ארגון קוד מחדש בסיוע AI תוך שימור התנהגות | יש לאפשר ל־LLM לזהות או להציע התמרה, ולאחר מכן, ככל האפשר, לבצע אותה באמצעות מנוע שכתוב מבני מהימן. ראו [RefactoringMirror](https://arxiv.org/abs/2411.04444) . | הידור, בדיקות, בדיקות סטטיות וזיהוי שכתוב. [SWE-Refactor](https://arxiv.org/abs/2602.03712) מגדיר בדיקות אלה במפורש ברמת המאגר. |
| שינוי מקומי של קוד ללא שכתוב הפונקציה כולה | יש לעשות שימוש חוזר במקטעי מקור שלא השתנו וליצור רק אזורי עריכה מועמדים, כמו ב־ [EfficientEdit](https://arxiv.org/abs/2506.02780) . | הבדל מחוץ לאזור, הצלחת המשימה, שימוש חוזר באסימונים שהתקבלו, והאם השמטת ההקשר גורמת להחמצת שינויים בין קבצים. |
| יצירת קוד תחת אילוצים להנדסת תוכנה | יש לאכוף תכונה פורמלית במהלך הפענוח, כפי שנעשה ב־ [דיפוזיה מוגבלת־דקדוק](https://arxiv.org/abs/2508.10111) , או ליצור נקודות ביקורת לקידומות תקפות ולחזור לאחור רק עד האזור האחראי, כמו ב־ [Hydra](https://arxiv.org/abs/2605.15238) . | הצלחה בבדיקות דקדוק, מהדר או בודק טיפוסים, לצד בדיקות פונקציונליות, מקומיות, זמן השהיה לתיקון וכמות הקוד התקין שנוצר מחדש. |
| יצירה בררנית מחדש של פונקציית Python תוך איזון בין מקומיות לגיוון | יש לנעול מיקומים גסים או עדינים נבחרים במרחב הסמוי ולדגום רק את היתר. | מקומיות לאחר פענוח, תחביר, אינווריאנטים מבניים, חופש עריכה, גיוון ואי־ודאות. נעילה לטנטית לבדה אינה מבטיחה שכתוב. |
| יצירת קוד ניתנת לחיזוי בכפוף לחוזה שימור מפורש | הגדירו לפני היצירה תכונות מוגנות הניתנות לצפייה ובדיקות עובר/נכשל, ולאחר מכן בחרו במנגנון הצר ביותר המסוגל לאכוף או לחשוף אותן. | יש למדוד לאחר הפענוח את המאפיינים המדויקים הללו ולדווח על שיעורי הקבלה, הדחייה והכשל בהרצות חוזרות. דגימה דטרמיניסטית לבדה אינה מבטיחה שימור. |

## שאלות המחקר שמדריך זה משיב עליהן

תשובות תמציתיות אלה מגדירות את גבולות הטענות והראיות המשמשים לאורך מדריך זה.

1. כיצד יכול מודל גנרטיבי לשנות קוד בלי לכתוב מחדש את הפונקציה כולה? הגדירו את הגבול הניתן לעריכה לפני היצירה, שמרו את קוד המקור שמחוץ לו או השתמשו בו מחדש, צרו רק שינויי מועמדים ודחו פלטים שנכשלים במשימה או משנים אזורים מוגנים. נעילה לטנטית היררכית היא ממשק שליטה ניסויי אחד, אך היא אינה מבטיחה טווחים זהים בקוד המקור. [השוואת ממשקי שליטה לעריכה מקומית](https://aogavrilov.com/he/projects/discrete-latent-generation/#control-surface) .
2. אילו ראיות מראות שעריכת קוד היא מקומית ולא רק תקפה מבחינה תחבירית? יש למדוד את ההבדל מחוץ לאזור המבוקש לצד הצלחת המשימה, השינוי באזור הניתן לעריכה, אינווריאנטים מבניים, בדיקות או ניתוחים סטטיים, והשונות בין הרצות חוזרות. שיעור הניתוח התחבירי לבדו מעיד רק על תקינות תחבירית. [עיון ברשימת התיוג לראיות בדבר מקומיות](https://aogavrilov.com/he/projects/discrete-latent-generation/#measurement) .
3. כיצד יש לאזן בין מקומיות עריכת הקוד לבין גיוון ביצירה? יש לדווח על יציבות האזור המוגן לצד חופש הפעולה באזור הניתן לעריכה וייחודיות המועמדים. העתקת הקלט עשויה למקסם יציבות בלי לקדם את המשימה כלל; שכתוב בלתי מוגבל עשוי למקסם שינוי תוך הרס המקומיות. [לעיון בראיות התחומות ליציבות ולחופש](https://aogavrilov.com/he/projects/discrete-latent-generation/#evidence) .
4. במה נבדלים עריכת קוד מקומית, יצירה תחת אילוצים ותיקון תוכניות? עריכה מקומית מדגישה את מה שחייב להישאר ללא שינוי; יצירה תחת אילוצים אוכפת תכונה פורמלית של הפלט, כגון השתייכות לדקדוק; ותיקון תוכניות מחייב שהשינוי יעמוד במפרט של ליקוי או משימה. תחביר לבדו אינו מוכיח שקילות סמנטית, נכונות תפקודית, הצלחה במשימה או מקומיות. [השוואת שלוש המטרות](https://aogavrilov.com/he/projects/discrete-latent-generation/#comparison) .
5. כיצד אפשר ליצור מחדש חלקים נבחרים של פונקציית Python, תוך שמירה על יציבות שאר הפונקציה? הגדירו לפני היצירה אזורים מוגנים ואזורים הניתנים לעריכה, שנו רק את הייצוג הניתן לעריכה, פענחו ודחו מועמדים שמשנים קוד מוגן או נכשלים בתחביר, בבדיקות, בבדיקות סטטיות או באינווריאנטים ייחודיים למשימה. הניסוי המדווח במשתנים לטנטיים היררכיים מודד יציבות הסתברותית בפונקציות בנות 64 אסימונים; הוא אינו מבטיח שטווחי הקוד או ההתנהגות יישארו ללא שינוי. [בחינת תהליך העבודה ליצירה בררנית מחדש](https://aogavrilov.com/he/projects/discrete-latent-generation/#workflow) .
6. איזו אסטרטגיית בקרה מתאימה לשכתוב קוד בסיוע AI המשמר התנהגות? יש להשתמש במודל כדי לזהות התמרה או להציעה, ולאחר מכן, ככל האפשר, לבצע אותה באמצעות מנוע שכתוב קוד מהימן ולאמת הידור, בדיקות, ניתוחים סטטיים ואת השכתוב המיועד. טלאי שנוצר ונראה סביר אינו בגדר ראיה מספקת. [פתיחת שורת ההחלטה על ארגון הקוד מחדש](https://aogavrilov.com/he/projects/discrete-latent-generation/#control-surface) .
7. מה הופך יצירת קוד לצפויה ולא רק לניתנת לבקרה? לפני בחירת המחולל יש להגדיר חוזה שימור הניתן לצפייה ובדיקות קבלה. יכולת החיזוי תלויה במה שנותר יציב לאחר הפענוח והאימות, ולא רק בשאלה אם קובעו הנחיה, מסכה, דקדוק או קוד לטנטי. [הגדרת חוזה השימור](https://aogavrilov.com/he/projects/discrete-latent-generation/#core-idea) .

## מה מראה הניסוי הנוכחי — ומה אינו מראה

בתוך [*בקרה פתוחה לבחינה ביצירה מחדש של תוכנה תוך שימור המבנה*](https://aogavrilov.com/he/publications/inspectable-control/) , ‏VQ-VAE היררכי ממפה פונקציות Python בנות 64 טוקנים ל־16 מיקומים בדידים ברמה העליונה ול־32 ברמה התחתונה. נעילת ארבעה קודים ברמה העליונה מעלה את שיעור הניתוח התחבירי מ־ **0.453 עד 0.591** , ואילו המיקומים שלא ננעלו עדיין משתנים בשיעור **0.936** והדגימות המותנות נותרות **0.998 ייחודיים** .

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

המחקר הנלווה [*היכן נפגעת האיכות ביצירת טקסט קצר ודחוס*](https://aogavrilov.com/he/publications/where-quality-breaks/) מוסיף לקח חשוב להערכה: שיפור במדדים עקיפים במרחב הלטנטי אינו משפר בהכרח את הפלטים המפוענחים. יש לבדוק בנפרד את הייצוג, היצירה וההתנהגות לאחר הפענוח.

להליך קבלת החלטות הניתן לשימוש חוזר, ראו את המדריך הנלווה בנושא [הפרדת אובדן הקודק מאובדן המחולל](https://aogavrilov.com/he/projects/codec-bottleneck-diagnosis/) .

## אי־הבנות נפוצות

### „הקוד עובר ניתוח תחבירי, ולכן הוא נכון.”

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

### „קוד גס הוא צומת AST.”

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

### „משתנים לטנטיים נעולים פירושם שטקסט המקור לא השתנה.”

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

### „פחות שינוי הוא תמיד עדיף.”

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

## מה לקרוא בהמשך

מחקרים קרובים משתמשים בממשקי בקרה שונים; אין להתייחס לאף אחד מהם כאל קו בסיס בר-החלפה ללא התאמה למשימה.

1. [Self-Edit: Fault-Aware Code Editor for Code Generation](https://arxiv.org/abs/2305.04087) מתייחס ליצירה כתהליך הניתן לעריכה ומשתמש בתקלות שהתגלו כדי להנחות את התיקון.
2. [Coeditor: Leveraging Contextual Changes for Multi-round Code Auto-editing](https://arxiv.org/abs/2305.18584) ממדל שינויי קוד תלויי הקשר לאורך סבבי עריכה, במקום ליצור את הקוד מחדש מאפס.
3. [PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair](https://arxiv.org/abs/2604.03113) מגדיר במפורש שימור ושינוי מזערי באימון לתיקון תוכניות.
4. [Constrained Decoding of Diffusion LLMs with Context-Free Grammars](https://arxiv.org/abs/2508.10111) מדגים כיצד אילוצים פורמליים יכולים לספק ערבויות תחביר במהלך פענוח דיפוזיוני.
5. [Neural Discrete Representation Learning](https://arxiv.org/abs/1711.00937) מציג את VQ-VAE, המנגנון היסודי לייצוגים סמויים בדידים נלמדים.
6. [Simple and Effective Masked Diffusion Language Models](https://arxiv.org/abs/2406.07524) מציג את מסגרת הדיפוזיה הבדידה הממוסכת המשמשת כמחולל הסמוי במחקר האבחוני הנלווה.
7. [מחקר אמפירי על הפוטנציאל של LLMs בארגון אוטומטי מחדש של תוכנה](https://arxiv.org/abs/2411.04444) מאתר פעולות ארגון מחדש לא בטוחות שהציע LLM, ומעריך יישום חוזר של ההתמרות שזוהו באמצעות מנועי ארגון מחדש מהימנים.
8. [SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring](https://arxiv.org/abs/2602.03712) מעריך ארגון קוד מחדש ברמת המאגר תוך שימור ההתנהגות, באמצעות הידור, בדיקות וזיהוי פעולות ארגון מחדש.
9. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) עושה שימוש חוזר במקטעי מקור שלא השתנו ומנבא את מיקומי העריכה, במקום להתייחס לעריכה כאל יצירה אוטורגרסיבית מלאה מחדש.
10. [Hydra: יצירת קוד יעילה ונכונה באמצעות תמיכה בנקודות ביקורת ובחזרה לאחור](https://arxiv.org/abs/2605.15238) משתמש בבדיקה סטטית, בנקודות ביקורת ובחזרה ממוקדת לאחור כדי להימנע מיצירה מחדש של תחיליות שכבר נמצאו תקפות לאחר שגיאה.

## סיכום קצר

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

## פרסומים בכיוון מחקר זה

### [Where Quality Breaks in Compressed Short-Text Generation: Staged Bottleneck Localization](https://aogavrilov.com/he/publications/where-quality-breaks/)

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

מתודולוגיית אבחון FRUCT 39 2026 הכנס הראשי

### [Inspectable Control for Structure-Preserving Software Regeneration](https://aogavrilov.com/he/publications/inspectable-control/)

בקרה פתוחה לבחינה ביצירה מחדש של תוכנה תוך שימור המבנה

שיטת בקרה במרחב הסמוי FSE Companion '26 2026 כרזה נלווית