# Jak sztuczna inteligencja może edytować kod bez ponownego generowania całego programu?

Canonical HTML: https://aogavrilov.com/pl/research/discrete-latent-generation/

Document language: pl

Praktyczny przewodnik badawczy po lokalnych modyfikacjach kodu z użyciem modeli generatywnych: co powinno pozostać ustalone, co może się zmienić i jakie dowody są potrzebne, zanim transformację będzie można uznać za zachowującą strukturę.

Opublikowano 25 lipca 2026 Zaktualizowano 30 lipca 2026 [Alexey Gavrilov](https://aogavrilov.com/about/)

## Na czym w istocie polega problem

Edycja kodu nie jest jedynie jego generowaniem na podstawie krótszego polecenia. Edytor otrzymuje istniejący artefakt, zamierzoną zmianę oraz niejawny kontrakt zachowania. Zasadnicze pytanie ma zatem dwa aspekty: **który obszar może się zmienić i które właściwości pozostałej części muszą zachować stabilność?**

Przewodnik jest przeznaczony dla czytelników o przygotowaniu technicznym, którzy rozpoczynają pracę z edycją oprogramowania wspomaganą przez AI. Odróżnia intuicyjne pojęcie zmiany lokalnej od silniejszych twierdzeń o zachowaniu składni, struktury, semantyki i funkcji programu.

## Główna idea

Edytor o ograniczonym zakresie wymaga jawnej granicy zachowania, a nie jedynie celu generowania.

### Co musi pozostać niezmienne

Może to być fragment tekstu, gramatyka, sygnatura API, obszar AST, zachowanie sprawdzane testem, kontrakt zależności albo wyuczona reprezentacja zgrubna. Każdy wybór chroni inne rozumienie stabilności.

### Co może się zmienić

Obszar edytowalny musi zapewniać wystarczającą swobodę do wykonania żądanego zadania. Metoda kontroli, która wszystko kopiuje, jest stabilna, lecz bezużyteczna; metoda, która wszystko przepisuje, zapewnia swobodę bez lokalności.

## Intuicyjny model: wyremontuj jedno pomieszczenie, zachowaj budynek

Wyobraźmy sobie remont jednego pomieszczenia z zachowaniem konstrukcji nośnej, przyłączy instalacyjnych i sąsiednich pomieszczeń w nienaruszonym stanie. Pełne ponowne generowanie przypomina odbudowę domu na podstawie opisu słownego. Edycja lokalna polega natomiast na oznaczeniu chronionej struktury, wyznaczeniu ograniczonego obszaru roboczego, wprowadzeniu zmiany i sprawdzeniu wyniku przed jego zaakceptowaniem.

**Gdzie kończy się trafność analogii.** Wyuczony kod ukryty nie jest certyfikowanym planem architektury. Ustalenie kodu zgrubnego może zwiększyć zmierzoną stabilność strukturalną, ale nie gwarantuje, że konkretny węzeł AST, zachowanie lub interfejs pozostaną niezmienione.

## Precyzyjniejsze ujęcie częściowej regeneracji

Niech enkoder odwzoruje program `x` do ustrukturyzowanej reprezentacji latentnej `z` . Maska zachowania wskazuje pozycje `L` które mają pozostać niezmienne. Generator próbkuje wyłącznie pozycje dopełniające, jednocześnie wymuszając `z'l = zl` dla każdej zablokowanej pozycji. Następnie dekoder odwzorowuje kompletną reprezentację `z'` z powrotem do kodu źródłowego.

Mechanizm ten tworzy ponad poziomem tokenów powierzchnię kontroli poddającą się inspekcji. Jej znaczenie trzeba jednak ustalić empirycznie: badacze muszą sprawdzić, co zablokowane pozycje zachowują po dekodowaniu oraz czy pozycje edytowalne zachowują wystarczającą swobodę.

## Czteroetapowy tok edycji

1. Określ granicę zachowania Wskaż chronione obszary lub właściwości i zdefiniuj zamierzoną zmianę.
2. Utwórz reprezentację artefaktu Należy wykorzystywać tekst, składnię, kontekst pozyskany przez wyszukiwanie albo wyuczone kody zgrubne i szczegółowe.
3. Generuj ponownie w sposób selektywny Próbkuj wyłącznie pozycje edytowalne, zachowując wybrane ograniczenia.
4. Zweryfikuj przed zaakceptowaniem Należy mierzyć lokalność, składnię, strukturę, zachowanie oraz niezamierzone skutki uboczne.

## Edycja kodu, naprawa programów i generowanie z ograniczeniami nie są tym samym zadaniem

| Podejście | Cel główny | Typowy mechanizm zachowania | Co nadal wymaga weryfikacji |
| --- | --- | --- | --- |
| Generowanie pełnego kodu | Wytworzenie kompletnego artefaktu | Polecenie i kontekst | Wszystko poza zakresem żądanej zmiany |
| Automatyczna naprawa programów | Usuń zdiagnozowaną usterkę | Lokalizacja usterek, testy, szablony lub poprawki | Poprawność wykraczająca poza dostępne testy oraz minimalność łatki |
| Modele uzupełniania lub edycji | Modyfikowanie wybranych obszarów tekstu | Widoczny prefiks, sufiks, diff lub kontekst edycji | Niezamierzone zmiany struktury i działania programu |
| Dekodowanie z ograniczeniami gramatycznymi | Utrzymuj wyniki w obrębie języka formalnego | Stany dekodowania zgodne z gramatyką | Znaczenie programu, poprawność realizacji zadania i lokalność zmian |
| Hierarchiczna kontrola przestrzeni utajonej | Wygeneruj ponownie wybrane wyuczone pozycje | Zablokowane zgrubne lub szczegółowe kody reprezentacji utajonej | Co kody te zachowują po dekodowaniu |

## Jak mierzyć lokalność i zachowanie struktury

## Która powierzchnia kontroli odpowiada danemu zadaniu edycyjnemu?

„Nie przepisuj całej funkcji” to wymaganie, a nie kompletna metoda. Najpierw należy określić wynik, który musi być przewidywalny, a następnie dobrać powierzchnię sterowania i odpowiadające jej dowody.

| Wymagana gwarancja | Lepiej dopasowana powierzchnia sterowania | Wymagane dowody |
| --- | --- | --- |
| Wspomagana przez AI refaktoryzacja zachowująca zachowanie | Pozwól LLM zidentyfikować lub zaproponować transformację, a następnie — gdy to możliwe — wykonaj ją za pomocą zaufanego mechanizmu refaktoryzacji. Zobacz [RefactoringMirror](https://arxiv.org/abs/2411.04444) . | Kompilacja, testy, analiza statyczna i wykrywanie refaktoryzacji. [SWE-Refactor](https://arxiv.org/abs/2602.03712) jawnie definiuje te kontrole na poziomie repozytorium. |
| Lokalna modyfikacja kodu bez przepisywania całej funkcji | Ponownie wykorzystuj niezmienione fragmenty kodu źródłowego i generuj wyłącznie regiony proponowanych zmian, tak jak w [EfficientEdit](https://arxiv.org/abs/2506.02780) . | Różnica poza wyznaczonym obszarem, powodzenie zadania, ponowne wykorzystanie zaakceptowanych tokenów oraz to, czy pominięty kontekst prowadzi do przeoczenia zmian między plikami. |
| Generowanie kodu z ograniczeniami na potrzeby inżynierii oprogramowania | Wymuś własność formalną podczas dekodowania, jak w [dyfuzja z ograniczeniami gramatycznymi](https://arxiv.org/abs/2508.10111) , albo zapisywać punkty kontrolne poprawnych prefiksów i wycofywać zmiany wyłącznie w obszarze odpowiedzialnym za błąd, jak w [Hydra](https://arxiv.org/abs/2605.15238) . | Spełnienie wymagań gramatyki, kompilatora lub narzędzia do kontroli typów, wraz z testami funkcjonalnymi, lokalnością, opóźnieniem naprawy i ilością ponownie wygenerowanego poprawnego kodu. |
| Selektywna regeneracja funkcji w języku Python z równowagą między lokalnością a różnorodnością | Zablokuj wybrane zgrubne lub szczegółowe pozycje w reprezentacji utajonej i próbkuj wyłącznie pozostałe. | Lokalność po dekodowaniu, składnia, niezmienniki strukturalne, swoboda edycji, różnorodność i niepewność. Samo blokowanie reprezentacji ukrytych nie gwarantuje refaktoryzacji. |
| Przewidywalne generowanie kodu na podstawie jawnego kontraktu zachowania | Przed generowaniem zdefiniuj obserwowalne chronione właściwości oraz testy zaliczenia lub odrzucenia, a następnie wybierz najwęższy mechanizm, który może je wyegzekwować lub ujawnić. | Po dekodowaniu należy zmierzyć dokładnie te właściwości oraz podać odsetki akceptacji, odrzucenia i niepowodzeń w wielokrotnych przebiegach. Samo próbkowanie deterministyczne nie gwarantuje zachowania. |

## Pytania badawcze, na które odpowiada ten przewodnik

Te zwięzłe odpowiedzi wyznaczają granice twierdzeń i materiału dowodowego przyjęte w całym przewodniku.

1. Jak model generatywny może modyfikować kod bez przepisywania całej funkcji? Przed generowaniem wyznacz granicę obszaru edytowalnego, zachowaj lub ponownie wykorzystaj kod źródłowy poza nią, generuj wyłącznie proponowane zmiany i odrzucaj wyniki, które nie realizują zadania lub modyfikują obszary chronione. Hierarchiczne blokowanie reprezentacji ukrytych stanowi jeden z eksperymentalnych interfejsów sterowania, lecz nie gwarantuje identyczności fragmentów kodu źródłowego. [Porównaj interfejsy sterowania edycją lokalną](https://aogavrilov.com/pl/research/discrete-latent-generation/#control-surface) .
2. Jakie wyniki dowodzą, że zmiana kodu jest lokalna, a nie jedynie poprawna składniowo? Różnicę poza żądanym obszarem należy mierzyć łącznie z powodzeniem zadania, zmianą w obszarze edytowalnym, niezmiennikami strukturalnymi, testami lub analizami statycznymi oraz zmiennością między powtórzeniami. Sam odsetek poprawnego parsowania potwierdza jedynie poprawność składniową. [Zapoznaj się z listą kontrolną materiału dowodowego dotyczącego lokalności](https://aogavrilov.com/pl/research/discrete-latent-generation/#measurement) .
3. Jak zrównoważyć lokalność edycji kodu z różnorodnością generowania? Raportuj stabilność regionu chronionego wraz ze swobodą w regionie edytowalnym i unikatowością rozwiązań kandydujących. Kopiowanie danych wejściowych może maksymalizować stabilność, nie przybliżając realizacji zadania; nieograniczone przepisywanie może maksymalizować skalę zmian kosztem utraty lokalności. [Zobacz dowody dotyczące ograniczonej równowagi między stabilnością a swobodą](https://aogavrilov.com/pl/research/discrete-latent-generation/#evidence) .
4. Czym różnią się lokalna edycja kodu, generowanie z ograniczeniami i naprawa programów? Edycja lokalna akcentuje to, co musi pozostać niezmienione; generowanie z ograniczeniami wymusza formalną właściwość wyniku, taką jak przynależność do gramatyki; naprawa programu zaś wymaga, by zmiana spełniała specyfikację usterki lub zadania. Sama składnia nie dowodzi równoważności semantycznej, poprawności funkcjonalnej, powodzenia zadania ani lokalności. [Porównaj trzy funkcje celu](https://aogavrilov.com/pl/research/discrete-latent-generation/#comparison) .
5. Jak ponownie wygenerować wybrane części funkcji w języku Python, zachowując stabilność pozostałych? Przed generowaniem wyznacz obszary chronione i edytowalne, modyfikuj wyłącznie reprezentację edytowalną, przeprowadź dekodowanie i odrzuć kandydatów, którzy zmieniają chroniony kod albo nie spełniają wymagań składni, testów, analizy statycznej lub niezmienników właściwych dla zadania. Opisany eksperyment z hierarchicznymi reprezentacjami ukrytymi mierzy probabilistyczną stabilność funkcji 64-tokenowych; nie gwarantuje niezmienności fragmentów ani zachowania programu. [Przeanalizuj procedurę selektywnego ponownego generowania](https://aogavrilov.com/pl/research/discrete-latent-generation/#workflow) .
6. Która strategia kontroli odpowiada refaktoryzacji zachowującej działanie programu i wspomaganej przez AI? Model należy wykorzystać do rozpoznania lub zaproponowania transformacji, a następnie — o ile to możliwe — przeprowadzić ją za pomocą zaufanego mechanizmu refaktoryzacji oraz zweryfikować kompilację, testy, analizę statyczną i zgodność z zamierzoną refaktoryzacją. Wiarygodnie wyglądająca wygenerowana poprawka nie stanowi wystarczającego dowodu. [Otwórz wiersz decyzji dotyczącej refaktoryzacji](https://aogavrilov.com/pl/research/discrete-latent-generation/#control-surface) .
7. Co sprawia, że generowanie kodu jest przewidywalne, a nie tylko sterowalne? Przed wyborem generatora należy określić obserwowalny kontrakt zachowania i kryteria akceptacji. Przewidywalność zależy od tego, co pozostaje stabilne po dekodowaniu i weryfikacji, a nie tylko od ustalenia promptu, maski, gramatyki lub kodu w przestrzeni ukrytej. [Zdefiniuj kontrakt zachowania](https://aogavrilov.com/pl/research/discrete-latent-generation/#core-idea) .

## Co pokazuje obecny eksperyment — a czego nie wykazuje

W [*Kontrola poddająca się inspekcji w ponownym generowaniu oprogramowania z zachowaniem struktury*](https://aogavrilov.com/pl/publications/inspectable-control/) , hierarchiczny model VQ-VAE odwzorowuje funkcje Pythona o długości 64 tokenów na 16 dyskretnych pozycji najwyższego poziomu i 32 pozycje niższego poziomu. Zablokowanie czterech kodów najwyższego poziomu zwiększa odsetek poprawnego parsowania z **od 0.453 do 0.591** , podczas gdy niezablokowane pozycje nadal zmieniają się ze współczynnikiem **0.936** a próbki warunkowe pozostają **0.998 unikatowych** .

Jest to wynik pomiaru kompromisu między stabilnością a swobodą w jednej niewielkiej konfiguracji. Nie stanowi on gwarancji dokładnego zachowania AST, równoważności semantycznej, poprawności funkcjonalnej, skutecznej naprawy ani działania w skali repozytorium.

Badanie towarzyszące [*Gdzie pogarsza się jakość w generowaniu skompresowanych krótkich tekstów*](https://aogavrilov.com/pl/publications/where-quality-breaks/) wnosi istotny wniosek dotyczący ewaluacji: poprawa miar zastępczych w przestrzeni ukrytej nie musi prowadzić do poprawy zdekodowanych wyników. Reprezentację, generowanie i zachowanie po dekodowaniu należy badać jako odrębne etapy.

Procedurę decyzyjną wielokrotnego użytku przedstawiono w towarzyszącym przewodniku dotyczącym [oddzielenie straty rekonstrukcji kodeka od straty generatora](https://aogavrilov.com/pl/research/codec-bottleneck-diagnosis/) .

## Częste nieporozumienia

### „Skoro kod się parsuje, jest poprawny”.

Parsowanie dowodzi jedynie poprawności składniowej. Program może nadal naruszać testy, kontrakty lub zamierzone działanie.

### „Kod zgrubny jest węzłem AST”.

Nie, o ile nie wykazano jawnego dopasowania. Wyuczone kody mogą łączyć kilka czynników powierzchniowych i strukturalnych.

### „Zablokowane zmienne ukryte oznaczają niezmieniony tekst źródłowy”.

Dekodowanie jest globalne i wyuczone. Ustalone pozycje ukryte mogą zwiększać stabilność, nie gwarantując identycznego fragmentu tekstu.

### „Mniejsza zmiana jest zawsze lepsza”.

Edytor kopiujący dane wejściowe osiąga doskonałą stabilność, ale nie wykonuje zadania. Lokalność i powodzenie edycji muszą być mierzone łącznie.

## Co warto przeczytać dalej

Pokrewne prace wykorzystują odmienne mechanizmy sterowania; żadnej z nich nie należy uznawać za wymienny punkt odniesienia bez dopasowania do zadania.

1. [Self-Edit: Fault-Aware Code Editor for Code Generation](https://arxiv.org/abs/2305.04087) Traktuje generowanie jako proces podlegający edycji i wykorzystuje wykryte błędy do ukierunkowania korekty.
2. [Coeditor: Leveraging Contextual Changes for Multi-round Code Auto-editing](https://arxiv.org/abs/2305.18584) Modeluje kontekstowe zmiany kodu w kolejnych rundach edycji, zamiast generować go od nowa.
3. [PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair](https://arxiv.org/abs/2604.03113) Jawnie uwzględnia zachowanie i minimalny zakres zmian w uczeniu naprawy programów.
4. [Constrained Decoding of Diffusion LLMs with Context-Free Grammars](https://arxiv.org/abs/2508.10111) Pokazuje, jak ograniczenia formalne mogą zapewniać gwarancje poprawności składniowej podczas dekodowania dyfuzyjnego.
5. [Neural Discrete Representation Learning](https://arxiv.org/abs/1711.00937) Przedstawia VQ-VAE — podstawowy mechanizm wyuczonych dyskretnych reprezentacji utajonych.
6. [Simple and Effective Masked Diffusion Language Models](https://arxiv.org/abs/2406.07524) Przedstawia metodę maskowanej dyskretnej dyfuzji zastosowaną jako generator reprezentacji ukrytych w uzupełniającym badaniu diagnostycznym.
7. [An Empirical Study on the Potential of LLMs in Automated Software Refactoring](https://arxiv.org/abs/2411.04444) Wykrywa niebezpieczne refaktoryzacje zaproponowane przez LLM i ocenia ponowne zastosowanie rozpoznanych przekształceń za pomocą zaufanych mechanizmów refaktoryzacji.
8. [SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring](https://arxiv.org/abs/2602.03712) Ocenia zachowującą działanie refaktoryzację na poziomie repozytorium za pomocą kompilacji, testów i wykrywania refaktoryzacji.
9. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) Ponownie wykorzystuje niezmienione segmenty kodu źródłowego i przewiduje miejsca edycji, zamiast traktować edycję jako pełne regenerowanie autoregresyjne.
10. [Hydra: Efficient, Correct Code Generation via Checkpoint-and-Rollback Support](https://arxiv.org/abs/2605.15238) Wykorzystuje analizę statyczną, punkty kontrolne i ukierunkowane wycofywanie zmian, aby po wystąpieniu błędu uniknąć ponownego generowania już poprawnych prefiksów.

## Krótkie podsumowanie

Lokalne ponowne generowanie kodu jest kontraktem między **zmiana** i **zachowanie** . Hierarchiczne dyskretne zmienne ukryte pozwalają wyrazić ten kontrakt w sposób poddający się inspekcji, lecz reprezentacja jest użyteczna tylko wtedy, gdy zdekodowane programy ocenia się pod względem lokalności, składni, struktury, zachowania, różnorodności i niepewności.

## Publikacje z tego kierunku badań

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

Gdzie załamuje się jakość w generowaniu skompresowanych krótkich tekstów: etapowa lokalizacja wąskiego gardła

Metodyka diagnostyczna FRUCT 39 2026 Konferencja główna

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

Kontrola poddająca się inspekcji w regeneracji oprogramowania z zachowaniem struktury

Metoda sterowania w przestrzeni utajonej FSE Companion '26 2026 Plakat towarzyszący