Embedded Files
Prompt Auto-tuning
Prompt Auto-tuning
Input:
Training dataset, where each sample contains a pair of edit hunk, and their edit partial order label
A large language model
Randomly split training dataset into batches;
Feed each batch into large language model, summarize an initial prompt for each batch;
Select the optimal prompt by evaluating each initial prompt candidate on the training set;
For each epoch:
Split training set into 2 subset: one where the current prompt’s prediction is correct (S+), and one where it is incorrect (S-);
Re-split the training dataset into batches, where each batch contains samples from both S+ and S-;
For each batch:
Query LLM to generate a feedback regarding why model successed/failed to predict the correct answer;
Query LLM to regenerate a prompt based on feedbacks from this batch;
Select the optimal prompt by evaluating each prompt candidate on the training set;
Output: An optimial prompt that recovers the edit order between any 2 edit hunk
Learned prompt
Learned prompt
# Zero-Shot Code Edit Neighbour Classification Criteria (Optimized)
A pair of code edits are "neighbours in mental flow" if, and only if, making one edit creates an **immediate, mechanically obvious, code-driven prompt for the other as the next contiguous action, within a single uninterrupted micro-task**. This linkage exists only when there is a direct, explicit code dependency or a mirrored, structurally identical substitution between the changed lines themselves—not merely due to shared conceptual, feature, or thematic context.
---
## 1. Core Criteria
### **A. Explicit, Immediate Code Linkage**
- The changed line(s) in one edit must create a concrete, visible, and direct syntactic or structural prompt for the other—such as a newly undefined symbol, changed signature, altered import, or mirrored/duplicated pattern—making the companion edit the next mechanically required step.
- The relationship must be at the **locus of change**: that is, the specific symbol, parameter, import, or structural element referenced, assigned, or called in the changed lines must be the same in both edits.
- **Critical distinction**: The changed lines must reference, assign, call, or import the **exact same symbol** (function name, variable name, class name, etc.), not merely symbols with the same name in different scopes.
### **B. Unbroken Micro-task Flow**
- Both edits would naturally occur in one contiguous, uninterrupted micro-task, with no context switch, pause for deliberation, or shift in editing intent.
### **C. Structural or Syntactic Dependency**
- The code linkage must be evident in the changed lines themselves—via explicit reference, assignment, call, or uniform substitution—not merely by affecting the same symbol elsewhere or sharing the same feature.
### **D. Not Neighbours: No Conceptual, Thematic, or Feature-Based Linking**
- **Do NOT** label edits as neighbours if their only relationship is conceptual or thematic (e.g., both relate to the same feature, add a similarly named variable, or are part of the same logical change) without a direct code dependency or mirrored substitution in the changed lines.
---
## 2. Neighbouring Patterns (with Language-Specific Guidance)
### **A. Definition–Usage / Import–Usage / Signature–Caller**
- **Bi-directional**:
- If each edit's changed lines reference the **exact same fully qualified symbol** (e.g., function, parameter, import, class), where after making either edit, the other edit becomes the next immediate, code-driven step.
- Applies to:
- Function/class signature change ↔ call-site update for the **same function/class**
- Import ↔ usage **within the same file**
- Parameter rename ↔ in-body reference update **within the same function**
- Method definition change ↔ test assertion update **for the exact same method**
- **Cross-file definition-usage**: Only label as bi-directional if:
- One edit defines a function/class and another edit calls that **exact same function/class**, AND
- Both edits appear to be part of the same development session where the symbol is being introduced and immediately used
- **Ordered ("X before Y")**:
- Use **only if** the second edit cannot be parsed, saved, or staged *at all* until the first is present—e.g., syntax error, parser error, or language-level blockage.
- **Do NOT** use ordered if the only consequence is a runtime or import-time error (e.g., NameError, AttributeError, TypeError)—if both edits can be written and parsed in either order, the relation is bi-directional.
- **Language-specific (Python)**:
- In Python, referencing an undefined variable, attribute, or symbol (including in function bodies, attribute access, or type annotations) is allowed at parse time and only fails at runtime or upon execution/import.
- Therefore, definition–usage, import–usage, or signature–caller edits are **bi-directional** unless the second edit would produce a parser-level syntax error if staged before the first.
- Adding a symbol to `__all__` is bi-directional with defining that symbol (not ordered) since `__all__` is processed during import resolution, not execution.
### **B. Bulk-Edit & Pattern Synchronization**
- **Bi-directional**:
- If both edits perform an **identical textual or structural substitution** (same before→after pattern) AND target the **same type of syntactic construct** (e.g., both import lines, both function signatures, both parameter lists).
- Must be clearly part of a single, contiguous refactor or search-and-replace sweep.
- **Examples**: Changing "datetime.datetime" to "datetime" in multiple locations, adding the same parameter to multiple function signatures of the same class.
### **C. Mirrored/Synchronized Additions Within Same Context**
- **Bi-directional**:
- Simultaneous addition of parameters/attributes with the same name and structure in the **same function, class, or closely related context** (e.g., adding a parameter to both a constructor and its corresponding mock assertion **within the same test method**).
- Parameter threading: Adding a parameter to an outer function signature and adding the same parameter to an inner function signature **when both changed lines explicitly reference the parameter**.
### **D. Test-Production Code Synchronization**
- **Bi-directional** when:
- One edit changes a method signature/behavior and another edit updates test assertions **for that exact same method**
- One edit changes implementation return values and another edit updates test expectations **for that exact implementation**
- Adding parameters to both constructor calls and their corresponding mock assertions **within the same test function**
### **E. Configuration-Implementation Synchronization**
- **Bi-directional** when:
- Adding identical parameters to both a configuration class and its corresponding implementation class **where both classes form a direct config-implementation pair**
- Parameter additions that create synchronized API contracts between classes that directly depend on each other
---
## 3. Not Neighbours ("no relation")
Label as "no relation" if:
- The only connection is conceptual, thematic, or feature-based.
- Both edits affect code with the same identifier name, but the changed lines reference **different symbols** (same name, different scopes/contexts).
- Edits add, remove, or alter code with the same name in different scopes, functions, classes, or files, without the **exact same symbol** being referenced in both changed lines.
- One hunk changes a usage or call, and the other changes a definition or import **for a different symbol** (even if names match).
- Cross-file edits where one file defines something and another file uses something with the same name, unless both are part of a uniform, synchronized multi-file substitution or the same development session.
- Parameter additions to unrelated functions/classes that happen to use the same parameter name.
- Documentation changes and code changes that merely reference the same concept without direct symbol linkage.
- Removing identical helper functions from separate files (cleanup operations).
- Adding the same parameter name to different functions without direct call relationships.
---
## 4. Label Assignment
- **Bi-directional:**
- Either edit can be staged first, and after making either, the other is the immediate, code-driven next step due to explicit code linkage or synchronized pattern.
- The **exact same symbol** is referenced, assigned, called, or imported in both changed lines.
- Use for definition–usage of the same symbol, import–usage in same file, signature–caller for same function, parameter threading with explicit references, test-production synchronization for same methods.
- **Ordered ("X before Y"):**
- Use **only** when the second edit cannot be written, parsed, or staged at all until the first is present (i.e., parser-level syntax break, missing required definition at parse time, language-level blockage).
- **Do NOT** use for runtime-only errors or cases where both hunks can be staged regardless of order.
- Cut-and-paste moves (remove symbol from one location, add to another location).
- **No Relation:**
- Use when the linkage is only conceptual or thematic, or when the changed lines reference **different symbols** (even if they have the same name), or when there is no direct, explicit code dependency or synchronized substitution at the locus of change.
---
## 5. Disambiguation & Special Cases
- **Same Name, Different Symbols:**
- If edits involve identifiers with the same name but in different scopes (different functions, classes, files), they reference **different symbols** and should be labeled "no relation" unless there is explicit cross-reference in the changed lines.
- **Parameter/Attribute Usage vs. Definition:**
- Only label as neighbours when the **exact same parameter/attribute symbol** is being defined in one edit and referenced in another edit's changed lines.
- Adding a parameter to a function signature and using a different variable with the same name = "no relation".
- **Cross-file Relationships:**
- Generally "no relation" unless: (1) part of uniform multi-file substitution, (2) same development session with immediate definition-usage, or (3) direct symbol reference between changed lines.
- **Test Helper and Production Code:**
- Only bi-directional when test code directly asserts on or calls the **exact same symbol** being modified in production code.
- **Bulk Substitutions:**
- Must involve **identical before→after patterns** on the **same type of syntactic construct**. Different construct types (e.g., docstring vs. validation dict) = "no relation".
- **Documentation vs. Code:**
- Generally "no relation" unless both edits reference the **exact same symbol** and the documentation change directly corresponds to the code change for that symbol.
---
> **KEY PRINCIPLE: The changed lines must reference, assign, call, or import the EXACT SAME SYMBOL. Symbols with identical names in different scopes are DIFFERENT SYMBOLS.**
>
> **When in doubt, ask:** Do the changed lines reference the exact same symbol? If not, label as "no relation".
---
## 6. Summary Table
| Scenario | Label | Notes |
|-----------------------------------------------------|-----------------|-----------------------------------------------------------------------------------------|
| Function signature change ↔ call-site update (same function) | Bi-directional | Unless call-site update causes a parse error (rare in Python; then ordered) |
| Import ↔ usage (same file, Python) | Bi-directional | Usage before import is allowed (runtime NameError only) |
| Parameter addition ↔ body reference (same function) | Bi-directional | No parser error in either order |
| Cross-file definition ↔ usage (same symbol, same session) | Bi-directional | Only when both edits reference the exact same symbol |
| Bulk uniform substitution (same construct type) | Bi-directional | Only if before→after pattern and construct type are identical |
| Cut-and-paste move (delete here, insert there) | Ordered | Removal must occur before relocation |
| Same name, different scopes | No relation | Different symbols despite identical names |
| Cross-file usage ↔ import (no synchronization) | No relation | Unless part of uniform, mirrored multi-file substitution |
| Conceptual or feature-based link only | No relation | No explicit, code-driven linkage between exact same symbols |
| Parameter additions to unrelated functions | No relation | Even with identical parameter names |
| Documentation ↔ code (different symbols) | No relation | Unless both reference the exact same symbol |
---
**Remember:**
- The label is determined by whether the changed lines reference, assign, call, or import the **exact same symbol**.
- "Ordered" is rare in Python and applies **only** when the second edit cannot be written, parsed, or staged before the first.
- "Bi-directional" applies when both edits reference the same symbol and either naturally prompts the other as the next mechanical step.
- "No relation" applies when edits reference different symbols or lack direct code linkage, regardless of conceptual similarity.
Flow-aware Optimization
Flow-aware Optimization
The flow-aware optimization technique aims to improve the continuity of AI-assisted code editing by aligning recommendations with the developer’s ongoing mental flow.
It operates as a post-processing layer on top of existing coding assistants, filtering and re-ranking their outputs according to inferred edit-order coherence.
Input Source and Setup
The system takes as input a sequence of prior edits (the developer’s current editing context) and the raw next-edit recommendations from a baseline assistant (e.g., Cursor, Claude Code, or CoEdPilot).
Each edit hunk (both prior edit and recommended) is represented structurally using XML-style tags that encode contextual information, including the file path, syntactic scope, and dependency relations.
Flow-Aware Filtering and Re-Ranking
For each new candidate recommendation h_{pred}, EditFlow evaluates its flow continuity with the current set of visited edits \mathbb{H}’ based on the instruction of the learned prompt.
Candidates crossing or reverting current flow boundaries (e.g., flow-breaking, flow-jumping and flow-reverting) are filtered out.
Remaining candidates are re-ranked by a flow-coherence score, extracted from average log probability of the edit order label tokens predicted by LLM, emphasizing temporal and structural continuity with prior edits.
Edits inferred as flow-violating ones are deferred and may be reconsidered in future iterations when the user’s editing context evolves and they eligible for recommendation as flow-aligned suggestions.
Optimization Wrapper
This mechanism is implemented as a unified optimization wrapper that sits between the user interface and the underlying assistant.
It requires no retraining of the base model—only a single prompt-based inference step to recover the edit-order structure and guide ranking.
Page updated
Google Sites
Report abuse