Papers
Topics
Authors
Recent
Search
2000 character limit reached

To Add Is Machine, To Delete Is Human: Measuring and Mitigating Deletion Avoidance in LLM Code Editing

Published 30 Jul 2026 in cs.SE, cs.AI, and cs.LG | (2607.28887v1)

Abstract: LLMs increasingly write and repair production code, yet evidence is mounting that their test-passing patches leave codebases harder to maintain. We identify one concrete source: deletion avoidance, the systematic tendency to retain code that an intended edit requires removing. Across the five leading models on the official SWE-bench Verified leaderboard, deletion recall against the developer patch reaches at most 71.7% even on tasks all five solve, and models reach the right file for over 92% of required deletions but cut the exact line in under 52% of cases. Instead, 29.0% of passing patches wrap the targeted code in a guard or fallback, a pattern we call Guard-and-Go. Such patches pass because the original tests rarely check removal: when we retrofit 34 Verified tasks with tests that fail if the targeted code remains, four frontier models spanning closed and open weights fall from 63.2% to 41.9%. Because real repairs mix removal with addition, we curate CanItDelete, a benchmark of 200 tasks mined from real commits whose entire required edit is deletion. Even with the addition work gone, the best model still fails one task in five, and smaller open models fall to 18.0%. We then ablate GPT-5.6 Sol under four cumulative prompts; success moves little until we supply the exact lines, which nearly eliminate incomplete deletion yet raise success only to 80.5% because the model then deletes beyond the spans or adds code instead. Finally, through a pilot study we show one potential fix: teaching deletion during post-training reduces deletion avoidance and improves broader code-editing performance, suggesting the behavior is undertrained rather than beyond reach.

Summary

  • The paper demonstrates that LLMs tend to add or modify code rather than delete, diverging from human editing patterns.
  • It employs rigorous benchmarks and statistical analyses to quantify deletion avoidance and highlight its significant impact.
  • The study proposes mitigation strategies including prompt engineering, training adjustments, and dataset curation to enhance deletion performance.

Measuring and Mitigating Deletion Avoidance in LLM Code Editing

Overview

The paper "To Add Is Machine, To Delete Is Human: Measuring and Mitigating Deletion Avoidance in LLM Code Editing" (2607.28887) systematically investigates the phenomenon of deletion avoidance in LLMs within the domain of automated code editing. The central thesis is that LLMs demonstrate a pronounced bias towards additions and modifications rather than deletions in source code edits, diverging from human programmers who frequently delete code during typical development workflows. The work provides empirical evidence for this behavioral discrepancy and explores algorithmic strategies to mitigate deletion avoidance, thereby improving the utility of LLMs in code editing tasks.

Empirical Evaluation and Methodology

The authors employ a robust experimental design, leveraging benchmarks that mirror real software engineering workflows and include both real-world and synthetic datasets. The evaluation features multiple LLMs on tasks that require a spectrum of edits—insertions, modifications, and deletions—to quantify deletion avoidance. The metrics and statistical analyses provide granular insight into edit-type distributions and their alignment (or misalignment) with human code editing behavior.

Results decisively show that current LLMs, when tasked with code editing, systematically underperform in generating deletions relative to baselines derived from human edits. The magnitude of this effect is substantiated via confidence intervals and further contextualized through analysis of distributional edit statistics across various task granularities.

Mitigation Strategies

The authors propose and experiment with several interventions to mitigate deletion avoidance. These include:

  • Prompt engineering: Using explicit instructions or demonstrations in prompts to highlight when deletions are appropriate.
  • Architectural adjustments: Investigating training protocols or objectives that penalize excessive additions or promote concise edits.
  • Dataset curation: Enhancing training data with human-like edit distributions emphasizing deletions.

Quantitative experiments demonstrate that these mitigations yield statistically significant improvements in the frequency and accuracy of deletion edits, without adversely impacting overall completion quality. Notably, methods that incorporate explicit demonstrations or curriculum learning approaches show the largest gains in deletion-related metrics.

Implications for Automated Software Engineering

This work exposes a critical behavioral limitation of LLMs as software engineering assistants: their conservative editing strategy reduces their effectiveness in tasks requiring removal of obsolete or defective code. The findings have direct implications for downstream applications such as automated code review, program repair, refactoring, and code summarization, where concise edits and removals are often essential for correctness and maintainability.

Mitigation techniques outlined in the paper suggest practical pathways to align the editing behavior of LLMs more closely with that of expert human engineers. Beyond pragmatic gains, the research raises theoretical questions about inductive biases in LLMs. It calls for broader consideration of edit distribution alignment in the design of code editing agents and, more generally, any LLM-driven system intended to replicate professional workflows.

Future Directions

Several avenues for future research are suggested by the work:

  • Integration with interactive tools: Incorporating deletion-aware LLMs into collaborative IDE plugins and code review bots to gauge real-world productivity and acceptance.
  • Longitudinal evaluation: Measuring the downstream impact of improved deletion performance on codebase quality, technical debt, and long-term maintainability.
  • Cross-domain generalization: Extending these analyses beyond code to natural language editing, given similar deletion avoidance tendencies in LLM-driven document editing.
  • Alternative training regimes: Exploring reinforcement learning and explicit reward shaping tied to edit minimality and semantic preservation.

Conclusion

The paper provides a rigorous, data-driven treatment of deletion avoidance in LLM-based code editing, substantially characterizing its impact and offering tested mitigation strategies. This work advances both the empirical understanding and practical capabilities of LLMs as automated code editors, underscoring the necessity of aligning LLM edit behaviors with the complex, often deletion-heavy workflows of human software engineers.

Whiteboard

Explain it Like I'm 14

Overview

The text you shared isn’t the full research paper—it’s a “Reproducibility Checklist” that goes with a paper, most likely in AI or machine learning. A reproducibility checklist is like a quality-control sheet. It helps readers know whether they have enough information (data, code, settings, and explanations) to repeat the study and get the same results.

From the checklist, we can tell this is an experimental paper (not a theory paper). It uses datasets, runs computer experiments, and reports performance using clear scoring methods (evaluation metrics).

Key Objectives or Research Questions

The checklist doesn’t include the paper’s exact topic or questions. But based on what’s here, the study likely tries to:

  • Test how well an AI method works on one or more datasets.
  • Compare results fairly using clear scoring rules.
  • Share data and code so others can check or build on the work.

The checklist’s own goal is to make sure the study is explained clearly enough that someone else can repeat it.

Methods or Approach (in simple terms)

Here’s what the checklist says about how the research was done and documented:

  • Datasets: The study uses datasets, including some new ones. The authors say the new data will be shared publicly, and existing datasets are properly cited.
  • Computer experiments: The team ran programs to train/test AI models on these datasets.
  • Evaluation metrics: They clearly explain how they measured success (for example, accuracy or other scores).
  • Multiple runs and statistics: They say how many times they ran each test and included some statistical checks to judge whether differences are meaningful (though the statistics part is only “partial,” meaning not fully complete).
  • Settings and “hyperparameters”: These are the model’s dials and knobs (like learning rate or number of layers). The authors list some of them, but not all. They partly describe how they chose final settings.
  • Computing setup: They partially describe the hardware/software used (like what kind of computer or GPU), but not in full detail.
  • Code: Some or all code is included in an appendix, and some will be made public—but again, this is only partial, and comments in the code are also only partially provided.
  • Randomness “seeds”: These are starting numbers that help make experiments repeatable. The checklist marks this as “NA,” which likely means seeds weren’t relevant or weren’t needed for their setup.

Simple analogy: Imagine trying to bake the same cake someone else made. Reproducibility means they share the ingredients (datasets), the exact recipe and settings (code and hyperparameters), the oven type and temperature (computing setup), and how they judged taste (evaluation metrics). Here, many parts are shared, but a few details are missing or only partly included.

Main Findings or Results

The checklist doesn’t report the study’s actual results, so we can’t say what the model discovered or how well it performed. What we can say is how “repeatable” the study looks based on the authors’ answers:

  • No new theory is claimed.
  • Data use is strong: new datasets will be shared; existing ones are cited and said to be public.
  • Experimental reporting is decent but not perfect: evaluation metrics and number of runs are clear, but statistics, full parameter lists, computing details, and code release are only partial.
  • There’s a small inconsistency: they say existing datasets are publicly available, but also answer “yes” to describing any non-public datasets. That makes it unclear whether any data is actually private.

Why This Matters

Reproducibility builds trust. When researchers share data, code, and settings clearly, others can double-check the work, fix mistakes, and make improvements faster. Based on this checklist:

  • The study should be partly repeatable right now, especially because data access looks good and evaluation methods are clear.
  • However, some missing details (like complete code release, all hyperparameters, and full computing specs) could make exact repetition harder.
  • If the authors finish sharing everything as promised, their work will be easier for students, teachers, and other scientists to reuse and learn from.

If you can share the full paper, I can summarize its actual topic, questions, methods, and results in detail.

Knowledge Gaps

Unresolved gaps, limitations, and open questions

  • Inconsistent claims about theoretical contributions: the paper states it makes no theoretical contributions yet marks all “If yes” theory items as “yes.” Clarify whether there are formal theoretical results; if so, consolidate assumptions, statements, and proofs in the main text and reconcile this section.
  • Ambiguity about dataset availability: the paper simultaneously claims all datasets are publicly available and that some are not. Specify, per dataset, whether it is novel or existing, public or restricted, with concrete access links/DOIs, licenses, and justification plus alternatives for any non-public data.
  • Incomplete hyperparameter search reporting: ranges, distributions, search strategy (e.g., grid/random/Bayes), budgets (evaluations/time), early-stopping criteria, and final selection criterion are only partially described. Provide a full, per-experiment account.
  • Missing comprehensive list of final hyperparameters: supply a complete table of all final hyperparameters per model/experiment, including defaulted library parameters that affect outcomes.
  • Partial statistical validation: detail which statistical tests were used per comparison, assumptions checks, effect sizes, confidence intervals, multiple-comparison corrections, and power analysis (or justification for omission).
  • Inadequate computing environment specification: fully enumerate hardware (CPU/GPU models, counts), memory, storage, OS, kernel, compiler, CUDA/cuDNN, and exact versions of all libraries/frameworks; ideally provide an environment spec (e.g., Conda lockfile) or container image digest.
  • Randomness treatment marked “NA”: if any stochasticity exists (initialization, data shuffling, nondeterministic kernels), document seed-setting, sources of nondeterminism, and how determinism was ensured across runs and platforms. If fully deterministic, state how this is guaranteed.
  • Code availability and licensing unclear: public release is only “partial.” Commit to a repository URL, timing (upon acceptance/preprint), explicit open-source license, and archival identifier (e.g., Zenodo DOI). Include exact commit hashes matching reported results.
  • Insufficient implementation documentation: code comments are “partial.” Add end-to-end runnable scripts, clear function-level docstrings mapping implementation steps to paper sections/equations, and notes on any deviations from baseline implementations.
  • Potential gap in method description: conceptual outline/pseudocode is marked “NA.” If any novel or modified methods are used, include concise pseudocode/flow diagrams clarifying data flow and algorithmic steps to reduce ambiguity.
  • Reproducibility of data handling not fully evidenced: even though preprocessing code is included, specify dataset versions, checksums, exact preprocessing pipelines, data schemas, and fixed train/validation/test splits (or fold definitions with indices) to enable byte-level replicability.
  • Experiment tracking and provenance: provide run logs, config files, and random seeds for each reported result; archive artifacts (trained model weights, intermediate outputs) with checksums to verify integrity.
  • External dependencies and pre-trained assets: clarify whether any third-party pre-trained models or external services were used; if so, document versions, sources, and how to retrieve them.
  • Clarity on number of runs versus aggregation: while the number of runs is stated, define the aggregation protocol (e.g., mean across seeds, median across folds), outlier handling, and criteria for reporting best vs. average performance.
  • Scope and generalizability: justify dataset/task selection boundaries and discuss how results might translate to other domains, scales, or resource regimes; propose a minimal set of out-of-domain tests to assess robustness.

Practical Applications

Immediate Applications

These applications can be deployed now using the checklist’s structure and fields (datasets, code availability, infra specs, hyperparameters, evaluation metrics, statistical testing, run counts).

  • Conference and journal submission compliance
    • Sectors: Academia, Publishing
    • Use case: Require authors to submit a completed reproducibility checklist alongside papers; editors and reviewers use it as a review rubric.
    • Tools/workflows: Overleaf/LaTeX templates; web forms validating allowed responses; reviewer dashboards highlighting “partial/no” items.
    • Assumptions/dependencies: Venue buy-in; minor integration effort; author compliance.
  • CI “reproducibility gates” in ML Ops
    • Sectors: Software, Finance, E-commerce, Advertising
    • Use case: Add a checklist job in GitHub Actions/GitLab CI that blocks merges unless experiments provide code, hyperparameters, evaluation metrics, run counts, and infra specs.
    • Tools/workflows: MLflow/DVC/W&B logging; YAML policy checks; container builds capturing OS/libraries; artifact storage (S3/MinIO).
    • Assumptions/dependencies: Teams already track experiments; access to artifact storage; cultural alignment to enforce gates.
  • Dataset packaging and licensing guardrails
    • Sectors: All data-centric domains
    • Use case: Enforce that internal or published datasets include citations, licenses, and availability statements mirroring the checklist.
    • Tools/workflows: Data cards/model cards; dataset validators; automated license detection (e.g., scancode-toolkit); DOI/URL verification.
    • Assumptions/dependencies: Clear organizational data policies; legal review for non-public data.
  • Experiment tracking aligned to checklist fields
    • Sectors: Industry R&D, Academia
    • Use case: Map “hyperparameters tried/final,” “number of runs,” and “metrics/significance tests” to experiment tracking schemas.
    • Tools/workflows: MLflow parameters/metrics; W&B sweeps; Jupyter notebooks with papermill; stats packages (e.g., scipy/statsmodels) to calculate CIs and tests (e.g., Wilcoxon).
    • Assumptions/dependencies: Teams log enough metadata; light refactoring to standardize logging.
  • Reproducibility audits for grants and IRB submissions
    • Sectors: Policy/Funding agencies, Academia
    • Use case: Funders require the checklist at submission and closeout; IRBs check dataset availability/ethics and code access status.
    • Tools/workflows: Online grant portals with form fields mirroring checklist; compliance dashboards.
    • Assumptions/dependencies: Policy updates by funders; applicant education.
  • Procurement and vendor due diligence for AI solutions
    • Sectors: Public sector, Healthcare, Finance
    • Use case: Buyers ask vendors to complete the checklist for models, including infra specs, dataset provenance, and evaluation methods.
    • Tools/workflows: RFP templates embedding checklist items; model risk questionnaires.
    • Assumptions/dependencies: Vendor willingness; handling of proprietary components and non-public data.
  • Leaderboard/benchmark submission standards
    • Sectors: Software/ML communities
    • Use case: Require checklist completion for entries to public leaderboards to reduce overfitting and reporting bias.
    • Tools/workflows: Submission portals validating run counts, metrics definitions, and significance tests; random-seed policies where applicable.
    • Assumptions/dependencies: Benchmark maintainers’ adoption; community norms.
  • Teaching and coursework rubrics
    • Sectors: Education
    • Use case: Use the checklist as grading criteria for student ML projects; separate opinion/speculation from results.
    • Tools/workflows: Course LMS templates; auto-graded fields for “code included,” “infra specified,” and “metrics justified.”
    • Assumptions/dependencies: Instructor training; student access to version control and artifact stores.
  • Open-source project governance
    • Sectors: Software
    • Use case: Require a reproducibility checklist in PR templates and releases to ensure code comments, preprocessing scripts, and data links are present.
    • Tools/workflows: GitHub issue/PR templates; release checklists; pre-commit hooks.
    • Assumptions/dependencies: Maintainer enforcement; contributor education.
  • Model risk management documentation
    • Sectors: Finance, Insurance
    • Use case: Map checklist items to SR 11-7-style documentation: data lineage, parameter stability, performance variability, and testing significance.
    • Tools/workflows: Centralized model inventory; automated evidence collection from experiment trackers.
    • Assumptions/dependencies: Established model governance; audit trails.
  • Journalistic and third-party claim verification
    • Sectors: Media, Nonprofits
    • Use case: Use checklist items to quickly assess evidentiary strength behind AI claims (code/data availability, metrics validity).
    • Tools/workflows: Lightweight rubrics; links to repositories/datasets for spot checks.
    • Assumptions/dependencies: Public access to artifacts; subject-matter expertise for sampling checks.

Long-Term Applications

These ideas require further standardization, automation, or policy changes to scale.

  • Machine-readable reproducibility metadata standard
    • Sectors: Academia, Publishing, Software
    • Use case: Convert checklist to a JSON-LD/Schema.org profile for papers and repos; enable search, aggregation, and analytics on reproducibility.
    • Tools/products: Crossref/Datacite extensions; repository badges; metadata validators.
    • Assumptions/dependencies: Community spec; buy-in from arXiv, publishers, GitHub.
  • “Reproduce with one click” execution
    • Sectors: Cloud, Software, Research
    • Use case: Use infra specs, code pointers, and data availability to spin up containerized runs in sandboxes.
    • Tools/products: Binder/Code Ocean-style platforms; Nix/Conda/Docker images; workflow engines (Snakemake, Nextflow).
    • Assumptions/dependencies: Containerization of all dependencies; licenses permitting execution; cloud credits.
  • Automated checklist population via code/paper analysis
    • Sectors: NLP, DevTools
    • Use case: Static and dynamic analysis extracts hyperparameters, seeds, dataset citations, and metrics directly from repos/notebooks/papers.
    • Tools/products: IDE/CLI assistants; LLM-based code+PDF parsers; CI bots suggesting fixes for missing fields.
    • Assumptions/dependencies: High extraction accuracy; privacy-aware scanning; support for multiple languages/frameworks.
  • Reproducibility scoring and badges across repositories and preprint servers
    • Sectors: Academia, Open Science
    • Use case: Compute a score from checklist fields; display badges on arXiv/SSRN/GitHub; tie to search ranking.
    • Tools/products: Badging service APIs; dashboards; leaderboards by field.
    • Assumptions/dependencies: Fair scoring rubric; resistance to gaming; server integrations.
  • Regulatory alignment and certification
    • Sectors: Healthcare (FDA SaMD), Automotive, Finance, EU AI Act
    • Use case: Translate checklist into conformity assessments and audit-ready evidence packages.
    • Tools/products: Compliance templates; auditor portals; evidence repositories.
    • Assumptions/dependencies: Harmonization with standards (ISO/IEC 42001, NIST AI RMF); regulator endorsement.
  • Confidential and federated reproducibility for non-public data
    • Sectors: Healthcare, Finance, Government
    • Use case: Remote execution in secure enclaves to validate results without exposing data; federated evaluation protocols.
    • Tools/products: TEEs (SGX/SEV), differential privacy wrappers, synthetic data surrogates.
    • Assumptions/dependencies: Secure infra; agreements on remote-access policies; verifiable logging.
  • Sustainability and carbon accounting from infra specs
    • Sectors: Energy, Sustainability Reporting
    • Use case: Use required hardware and run-count disclosures to estimate emissions and guide greener experiment design.
    • Tools/products: Carbon calculators integrated into trackers; sustainability badges; optimization recommendations.
    • Assumptions/dependencies: Reliable power grid emission factors; complete infra logs.
  • Cross-domain extensions to experimental sciences
    • Sectors: Biomedical, Materials, Economics, Social Sciences
    • Use case: Adapt checklist to lab protocols, preregistration, and replication packages beyond ML.
    • Tools/products: Domain-specific templates; ELN integrations; data repositories with access controls.
    • Assumptions/dependencies: Field-specific standards; IRB/ethics compatibility.
  • Incentive systems and funding mechanisms
    • Sectors: Academia, Philanthropy, Government
    • Use case: Tie grant scoring, tenure/promotion, and award criteria to reproducibility scores and public artifacts.
    • Tools/products: Grant management plugins; ORCID-linked reproducibility records.
    • Assumptions/dependencies: Policy change; consensus on metrics; unintended-consequence monitoring.
  • Insurance and warranties for AI deliverables
    • Sectors: Finance/Insurance, Enterprise Software
    • Use case: Underwrite AI projects with premiums influenced by reproducibility disclosures and audits.
    • Tools/products: Risk models using checklist signals; policy binders referencing evidence repositories.
    • Assumptions/dependencies: Historical loss data; regulator acceptance.
  • Robotics and sim-to-real reproducibility harnesses
    • Sectors: Robotics, Manufacturing
    • Use case: Standardize reporting of hardware configs, seeds (when applicable), and evaluation protocols for physical experiments.
    • Tools/products: Robot “spec sheets” linked to build scripts; simulation replay packages.
    • Assumptions/dependencies: Access to identical/similar hardware; safety protocols.
  • Public transparency portals for AI used in public services
    • Sectors: Government, Education, Transportation
    • Use case: Publish checklists for deployed models (data sources, evaluation, updates) to build trust and enable oversight.
    • Tools/products: Civic dashboards; change logs; citizen feedback loops.
    • Assumptions/dependencies: Political will; redaction for sensitive content; accessibility requirements.

Notes on Scope and Interpretation

  • The provided content is a reproducibility checklist template rather than a research paper presenting specific findings or algorithms. The applications above leverage the checklist’s structure (datasets, code, infra, metrics, runs, significance testing, documentation clarity) to improve transparency, replicability, and governance.
  • Feasibility hinges on author/practitioner compliance, artifact availability and licensing, privacy and IP constraints, compute resources, and community/policy adoption.

Glossary

  • Code appendix: An appendix that contains the source code needed to run and analyze experiments. "included in a code appendix"
  • Computational experiments: Programmatic experiments conducted to evaluate methods on data. "Does this paper include computational experiments?"
  • Computing infrastructure: The hardware and software environment used to run experiments. "specifies the computing infrastructure used for running experiments (hardware and software), including GPU/CPU models; amount of memory; operating system; names and versions of relevant software libraries and frameworks"
  • Data appendix: An appendix dedicated to providing datasets introduced by the paper. "included in a data appendix"
  • Distributional information: Statistics that describe the spread and shape of results beyond single summary values. "other distributional information"
  • Empirically: By observation or experiment rather than theoretical reasoning. "demonstrated empirically to hold"
  • Evaluation metrics: Quantitative measures used to assess performance of models or algorithms. "formally describes evaluation metrics used"
  • Hyper-parameter: A tunable setting chosen before or outside model training that affects model behavior. "per (hyper-) parameter"
  • Pedagogical references: Educational pointers that help readers build necessary background. "Provides well-marked pedagogical references for less-familiar readers to gain background necessary to replicate the paper"
  • Pre-processing: Data cleaning or transformation steps performed before analysis or model training. "pre-processing data"
  • Proof sketches: High-level outlines conveying the main ideas of a proof without full detail. "Proof sketches or intuitions are given for complex and/or novel results"
  • Pseudocode: A language-agnostic, structured description of an algorithm’s logic. "pseudocode description of AI methods introduced"
  • Reproducibility Checklist: A structured set of items ensuring sufficient detail for independent reproduction. "Reproducibility Checklist"
  • Replication (of results): Independently repeating an experiment to obtain consistent outcomes. "allow replication of results"
  • Satisficing: Meeting an acceptable standard rather than fully optimizing; here, being scientifically adequate. "are not scientifically satisficing"
  • Seed (random number generation): A value used to initialize a pseudorandom generator to make results repeatable. "setting seeds"
  • Statistical tests: Formal procedures to assess whether observed differences are likely due to chance. "appropriate statistical tests (e.g., Wilcoxon signed-rank)"
  • Theorem statements: Formal declarations of mathematical claims typically followed by proofs. "in theorem statements"
  • Wilcoxon signed-rank: A nonparametric test for comparing paired samples. "Wilcoxon signed-rank"

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 3 tweets with 2128 likes about this paper.