REVIEW 3 major objections 5 minor 49 references
Spatio-Temporal Pruning for Compressed Spiking Large Language Models
T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash
Pith's one-line read A spiking-LLM compression framework is announced in the abstract, but the supplied full text is a different study.
desk verdict The abstract advertises a SpikingBERT pruning study; the body is an unrelated LLM-agent microservice paper, so the central claim is absent. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The load-bearing machinery is a pair of sparsity mechanisms applied inside a spiking transformer: a spatial pruning step that masks neurons and attention heads based on activation statistics, and a temporal pruning step that assigns each layer a dynamically adjusted number of timesteps. The named testbed is SpikingBERT, a spiking version of BERT, with the GLUE benchmark as the claimed evaluation. The work these mechanisms are meant to do is to replace dense compute with sparse event-driven compute and to stop layers that have already converged from consuming extra timesteps. Because the body text supplies no derivations, the mechanisms exist only as described in the abstract.
What would settle it
Reading the supplied full text settles the mismatch: it contains no equations, no SpikingBERT, no GLUE results, and instead studies LLM agents building microservices. For the method itself, apply the claimed spatio-temporal pruning to a pretrained SpikingBERT and check whether GLUE accuracy stays within an agreed tolerance while measured inference operations and latency drop; if accuracy falls or latency does not decrease, the central claim fails.
Extended reading notes
Core claim
On the paper's own terms, the discovery is a spatio-temporal pruning framework for SpikingBERT. Spatial pruning removes inactive neurons and attention heads, lowering per-timestep compute; temporal pruning lets different layers run for different numbers of timesteps, cutting inference latency; and these are combined with extreme quantization and knowledge distillation. The abstract asserts this is the first work in spiking LLMs to combine all four, and reports that extensive GLUE evaluation shows reduced computational operations and latency. No equations, algorithms, ablations, or numeric results appear in the supplied full text, so the discovery cannot be verified from the material provided
Load-bearing premise
The claim stands on two premises: that the supplied full text is the actual paper, which it is not, and that pruning masks and per-layer timestep schedules derived from SNN activation statistics preserve GLUE accuracy without re-derivation.
Editorial extensions
If this is right
- If the framework works as claimed, spiking BERT models could run on edge hardware with tight energy and latency budgets.
- Spatial and temporal pruning together target the two axes of SNN cost: compute per timestep and the number of timesteps per layer.
- Combining extreme quantization with knowledge distillation could let compressed spiking LLMs approach the accuracy of full-precision models while running on inexpensive hardware.
- Per-layer timestep schedules would replace fixed-time inference, reducing latency for real-time natural language processing.
- A successful GLUE evaluation would position SpikingBERT as the standard testbed for spiking LLM compression.
Reading between the lines
- If the supplied body text is what was actually submitted, the abstract and the body describe two different papers, so the pruning claims should not be treated as supported until the matching manuscript is examined.
- A testable extension of the claimed method would compare per-layer timestep schedules derived from activation statistics against a fixed schedule, measuring GLUE accuracy per unit latency; one would expect the schedules to transfer across similar tasks if they capture true layer convergence.
- The claimed activation-statistic pruning implicitly assumes that masks computed on one task generalize; an editorially intended extension is to check whether masks need re-derivation when the task distribution shifts.
- The framework's practical value depends on whether the saved operations and latencies are measured end-to-end, including the overhead of choosing per-layer timestep schedules, not just the forward pass.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The abstract announces a spatio-temporal pruning framework for SpikingBERT, combining spatial pruning of neurons/attention heads, temporal pruning of per-layer timesteps, extreme quantization, and knowledge distillation, with experimental validation on the GLUE benchmark. The full text supplied, however, contains none of this material. After the abstract, the manuscript is an entirely different empirical study on LLM agents synthesizing microservice-based applications using LangGraph, Docker, and GPT-3.5/4o-mini/o3-mini, with its own sections, tables, and appendices. There are no equations, algorithms, GLUE results, ablations, or even the keywords 'spiking', 'SpikingBERT', 'pruning', 'quantization', 'distillation', or 'timestep' in the body. The claimed framework is not derivable or testable from the submitted document.
Significance. If the abstract's claims were supported, a framework reducing compute and latency for spiking LLMs while preserving GLUE performance would be a meaningful contribution to efficient NLP. However, as submitted, that contribution is absent: no derivation, implementation, or evaluation of SpikingBERT appears anywhere in the manuscript. The body's microservice-agent study may be of some interest to the software-engineering community, but it is a different paper and cannot serve as evidence for the spatio-temporal pruning claims. The manuscript provides no machine-checked proofs, reproducible artifact, or falsifiable predictions for the central claim; it therefore offers no assessable basis for accepting or even seriously evaluating the abstract's promises.
major comments (3)
- [Abstract vs. Full Text] The central claim is entirely absent. The abstract promises a spatio-temporal pruning framework for SpikingBERT with 'extensive experimental evaluation' on GLUE, but the body of the manuscript contains no mention of spiking networks, SpikingBERT, spatial/temporal pruning, quantization, knowledge distillation, timesteps, or GLUE. There are no equations or tables reporting computational operations, latency, or task performance for the proposed method. This is not a missing derivation or an insufficient ablation; the object of study described in the abstract is not present in the submitted text. A referee cannot confirm or refute the claimed efficiency/accuracy trade-off, and no local revision can repair this absence.
- [Sections 3 and 5 (body evaluation methodology)] Even if the body is evaluated on its own terms as a study of LLM agents for microservice-based applications, its quantitative results rest on a self-authored ground truth. Section 3 states that the authors wrote the specifications, wrote the 'gold' implementations, wrote the unit tests, and then iteratively fixed the spec, gold code, and tests until both the gold implementation and preliminary LLM-generated code passed. Tables 1-6 measure pass rates against this closed, self-constructed suite, with no independent benchmark, no external validation of the gold code or tests, and no usable artifact link. This circular construction substantially limits what the numerical results in Tables 1-6 can support about LLM code-generation ability in general.
- [Section 5.3 and Appendix E] The body's reported results omit a substantial part of the data: GPT-4o-mini results for the library MSBA are excluded from the main body 'due to space considerations' and deferred to Appendix E. When they are finally shown in Table 10, each temperature condition has at most five runs per microservice, and no confidence intervals or significance tests are reported. Given that the pass-rate percentages in Tables 1-6 are averages over 15-20 executions, the absence of dispersion measures makes it difficult to judge whether the observed differences between models, prompts, or temperatures are substantive. This is a presentation gap, but in a paper whose main claims are empirical, it is a substantial one.
minor comments (5)
- [Section 5.2 and Section 8] The model name is inconsistently written as 'GPT-o3-mini' and 'GPT-3o-mini'. Please standardize the notation.
- [Section 5.6] Tables 8 and 9 are referred to as 'figures 8 and 9'; the cross-reference text should say 'Table 8' and 'Table 9'.
- [Section 5.5 / Table 7] The text says the Restaurant MSBA description is 'about �36 larger' than the Library MSBA; this appears to be a garbled '36%' or '1.36x'. Please clarify the intended statistic.
- [Footnotes / Reproducibility] Footnote 2 says specifications and unit tests 'can be found online', but no URL or repository identifier is visible in the manuscript text. A working artifact link is needed for the body's experimental claims to be reproducible.
- [References] The bibliography is severely garbled: entries [2] through [38] contain long runs of undecodable characters rather than readable author/title strings, making source verification impossible. The reference list needs to be regenerated.
Circularity Check
No circular derivation found: the submitted full text is an unrelated microservice-agent study, so the abstract's spiking-LLM claim has no derivation chain that can be circular; the body's self-authored benchmark loop is disclosed and is not a fitted-input prediction.
full rationale
The claimed subject (spatio-temporal pruning for SpikingBERT on GLUE) does not appear anywhere in the supplied full text: there are no equations for spatial pruning masks or temporal timestep schedules, no GLUE experiments, and no occurrence of spiking/pruning/quantization/distillation content. Because the claimed derivation chain is absent, there is no circular step to exhibit; absence of content is a completeness/integrity concern, not a circularity reduction. The body is a separate study of LLM agents synthesizing microservice-based applications. Its evaluation loop is openly documented in Section 5.1: 'We wrote the spec of each microservice... We wrote a gold standard (GT) implementation for the spec. We wrote unit tests based upon the spec and used them to test the GT solution. When testing and finding an error... If it was a mistake in the GT implementation, we fixed the GT implementation. If the test case was not faithful to the spec, we corrected the test case. If the spec was ambiguous or incorrect, we fixed the spec... we repeated until we were confident in the correctness of the GT implementation and unit test cases.' This is disclosed benchmark construction with the authors' own specifications and tests as the scoring criterion for LLM-generated code; it is not a parameter fitted to a subset of data and then reported as a prediction, so it does not reduce to pattern 2. The complexity metric's 'LLM-as-a-Judge' validation uses Claude Sonnet 4, a different model from the evaluated GPT-3.5/GPT-4o-mini/GPT-o3-mini, so it is not self-referential in the sense of scoring a model by its own output. No load-bearing self-citation or imported uniqueness theorem appears. Therefore the circularity score is 0, with the strong caveat that the abstract's central claim cannot be assessed at all from the supplied text because the claimed research object is missing.
Assumptions & free parameters
free parameters (3)
- Spatial pruning ratio (fraction of active neurons and attention heads retained) =
not reported in provided text
- Per-layer temporal timestep schedule =
not reported in provided text
- LLM-as-a-Judge complexity score (body paper) =
3/5 (library), 4/5 (restaurant), assigned by Claude Sonnet 4
assumptions (3)
- ad hoc to paper The full text is the body of the claimed study (spatio-temporal pruning for SpikingBERT).
- domain assumption SpikingBERT exists as a valid BERT-to-SNN conversion whose surrogate-gradient training is compatible with aggressive pruning.
- domain assumption Unit-test pass rate on the authors' self-authored specifications is a valid proxy for code-generation correctness.
Cite this review
Pith. "Pith review of Spatio-Temporal Pruning for Compressed Spiking Large Language Models." pith.science (2026). https://pith.science/paper/BTA26G7T
@misc{pith2026250820122,
author = {Pith},
title = {Pith review of: Spatio-Temporal Pruning for Compressed Spiking Large Language Models},
year = {2026},
howpublished = {\url{https://pith.science/paper/BTA26G7T}},
note = {Machine review of arXiv:2508.20122}
}
read the original abstract
Large Language Models (LLMs) present significant challenges for deployment in energy-constrained environments due to their large model sizes and high inference latency. Spiking Neural Networks (SNNs), inspired by the sparse event-driven neural processing and energy-efficient information transmission in the brain, offer a promising alternative for achieving low-power computing. Integrating the event-driven efficiency of spiking neurons with the advanced capabilities of LLMs represents a promising direction for power-efficient LLMs. This work specifically delves into the design of compressed spiking LLMs. Here, we revisit spatial and temporal pruning from the perspective of SNNs and propose a novel spatio-temporal pruning framework for Spiking LLMs to optimize computational efficiency while preserving high performance. Our spatial pruning technique reduces the number of active neurons and attention heads, effectively lowering the computational complexity of the model. Meanwhile, temporal pruning minimizes inference latency by dynamically adjusting the number of timesteps required for different layers. By combining these approaches with other compression techniques, we present the first work in the domain of Spiking LLMs to jointly explore spatial pruning, temporal pruning, extreme quantization and knowledge distillation strategies. Extensive experimental evaluation of our proposed framework for SpikingBERT on the large-scale GLUE benchmark demonstrates the efficacy of our approach in terms of computational operations and inference latency. Our approach offers a compelling solution for real-time, low-power natural language processing applications, making Spiking LLMs more practical for deployment on edge devices and in power-constrained settings.
Reference graph
Works this paper leans on
-
[1]
We wrote the ���� of each microservice as part of a complete MSBA spec- ification, and reviewed it with an LLM for completeness and consistency
-
[2]
We wrote a ������ ����� (�� ) implementation for the spec
-
[3]
We wrote ���� ���� ����� based upon the spec and used them to test the GT solution
-
[4]
If it was a mistake in the GT implementation, we fixed the GT implementation
When testing and finding an error, we checked the cause of the error. If it was a mistake in the GT implementation, we fixed the GT implementation. If the test case was not faithful to the spec, we corrected the test case. If the spec was ambiguous or incorrect, we fixed the spec
-
[5]
We repeated step 4 until the GT implementation passed all tests
-
[6]
We used the spec to generate preliminary code from an LLM and tested that code with the unit tests. We discovered a few more errors this way, and repeated until we were confident in the correctness of the GT imple- mentation and unit test cases. The specifications and list of unit tests for each MSBA can be found online�. ��� ��� ���������� �� �� ���� ���...
-
[7]
����: the number of words in the MSBA specification. Although we gen- erate each MS one at a time, we provide the entire MSBA specification to the LLM because it often needs the entire spec to generate even a single MS correctly
-
[8]
���������: the resource complexity. A resource is either a primitive data type (int, string,...), a structure, where each field is a resource, or a col- lection of resources. If a resource is a single primitive it counts as a single ��������� ��������. If it is a collection, it counts as a single ���������� ��� ������. If it is a structure with �� fields ...
Show all 49 references
-
[9]
� is ������ ���� �� � if � invokes �
������������: Let � be a MS and � be a service endpoint. � is ������ ���� �� � if � invokes � . � may be another MS in the application or it may be an external service. We count the number of dependencies for each MS in the MSBA, and the sum of these is the ���������� ��������...
-
[10]
We count the number of packages that the GT implementation imports
�������� is the number of packages the MS requires. We count the number of packages that the GT implementation imports
-
[11]
moderate complexity
�������������� is the score, between 1 and 5 assigned by the LLM to the difficulty of implementing the spec. The specification size indicates the number of details the LLM must contend with. The number of dependencies and packages indicates the amount of ex- ternal knowledge r...
-
[12]
https://www.langchain.com/langgraph, 07 2025
LangGraph. https://www.langchain.com/langgraph, 07 2025
2025
-
[13]
In ���� �������� ���� ������ �������� ���������� �� �������� ������������ ��������� ����������� ���������������� (2025), pp
��������� �� Revisiting SWE-Bench: On the importance of data quality for LLM-based code models. In ���� �������� ���� ������ �������� ���������� �� �������� ������������ ��������� ����������� ���������������� (2025), pp. 235–236
2025
-
[14]
���� �������������� (2021)
������� ��� ������ ��� ���� �� ��� ������ ��� ������������ ��� ������ ��� ������ ��� ���� �� ��� ������ ��� ��� �� ��� ��� ������� �� Program synthesis with large language models. ���� �������������� (2021)
2021
-
[15]
��������� ��� ����� ��� ��� �� �������� ������ �� Combining TSL and LLM to automate REST API testing: A comparative study, 2025
2025
-
[16]
API-University Series
������ �� ������� ��� ������ . API-University Series. CreateSpace Independent Publishing Platform, 2016
2016
-
[17]
In �������� �� ������ ����������� ���������� �������(2020), H
������ ��� ����� ��� ������ ��� �������� ��� ������� �� ��� ��������� ��� ������������ ��� ������ ��� ������� ��� ������� ��� �������� ��� ������������� ��� �������� ��� ��������� ��� ������ ��� ������� ��� �������� ��� ��� ��� ������� ��� ������ ��� ����� ��� ������� ��� ����...
2020
-
[18]
���� �������������� (2021)
����� ��� ��� ��� ��� Evaluating large language models trained on code. ���� �������������� (2021)
2021
-
[19]
���� �������������� (2024)
������� ��� ��������� ��� ���������� ��� �������� ��� ��� ���������� �� You can REST now: Automated specification inference and black-box testing of RESTful APIs with large language models. ���� �������������� (2024)
2024
-
[20]
������������ ��� ��� ���� �� �� DeepSeek-R1: Incentivizing reasoning capability in LLMs via reinforcement learning. Tech. rep., 2025
2025
-
[21]
���� �������������� (2024)
���� ��� ���� ��� ��� ��� ������ ��� ����� ��� ��� ��� ����� ��� ���� ��� ������ ��� ���� ��� ���� ��� ����� ��� ������ ��� ����� ��� ��� ��� ������ ��� ���� ��� ����� ��� ����� ��� ���� ��� ���� ��� ���� ��� ������ ��� ��� ������ �� What’s wrong with your code generated by la...
2024
-
[22]
https: //blog.promptlayer.com/best-llms-for-coding/, 05 2025
������ �� The best LLMs for coding: An analytical report. https: //blog.promptlayer.com/best-llms-for-coding/, 05 2025
2025
-
[23]
���� �������������� (2024)
������ ��� �������� ��� ������ ��� � ������� �� ��� ����� ��� ����� �� ��� ��� ������� �� GitChameleon: Unmasking the version-switching capabilities of code generation models. ���� �������������� (2024)
2024
-
[24]
�������� �� ��� ����� ��� ������� ��� ���� ��� ���� ��� ������ ��� ��� ����������� �� SWE-bench: Can language models resolve real-world GitHub issues? ���� �������������� (2023)
2023
-
[25]
���� (2025)
������������ ��� ������������� ��� ��� ������� �� How robust are LLM-generated library imports? An empirical study using Stack Overflow. ���� (2025)
2025
-
[26]
In ����������� �� ��� ���� ���������� �� ��������� ������� �� ������� �������� ����������(Miami, Florida, USA, Nov
��� ��� ����� ��� ����� ��� ������ ������ ��� ����� �� Control large language models via divide and conquer. In ����������� �� ��� ���� ���������� �� ��������� ������� �� ������� �������� ����������(Miami, Florida, USA, Nov. 2024), Y. Al-Onaizan, M. Bansal, and Y.-N. Chen, Eds...
2024
-
[27]
��� ��� ��� ��� ������ ��� ����� ��� ��� ���� �� EvoCodeBench: An evolving code generation benchmark aligned with real-world code reposito- ries, 2024
2024
-
[28]
In �������� �� ��� ����������� ��� ������������� ���� ��������� ��� ���� (Bangkok, Thailand, 08 2024), L.-W
��� ��� ��� ��� ����� ��� ��� ��� ���� ��� ���� ��� ����� ��� ���� ��� ����� ��� ����� ��� ����� ��� ������ ��� ���� ��� ����� ��� ���� ��� ��� ��� ������ ��� ��� ��� ��� ��� ��� ����� �� DevEval: A manually-annotated code generation benchmark aligned with real-world code repo...
2024
-
[29]
In ����������� �� ��� ���� ���������� �� ��������� ������� �� ������� �������� ����������� ����� (12 2023), H
��� ��� ����� ��� ��� ��� ����� ��� ��� ��� ��� ��� ��� ��� ������ ��� ��� ��� �� API-Bank: A comprehensive benchmark for tool-augmented LLMs. In ����������� �� ��� ���� ���������� �� ��������� ������� �� ������� �������� ����������� ����� (12 2023), H. Bouamor, J. Pino, and K...
2023
-
[30]
In �������� ���� �� ��� ���� ������ ������� �� ��� ����������� ��� ������������� ���� �������� ������� �� ���� ������� (Vienna, Austria, 07 2025), W
��� ��� ������ ��� ���� ��� ���� ��� ���� ��� ����� ��� ������ ��� ����� ��� ��� ��� �� FEA-Bench: A benchmark for evaluating repository-level code generation for feature implementation. In �������� ���� �� ��� ���� ������ ������� �� ��� ����������� ��� ������������� ���� ����...
2025
-
[31]
���� �������������� (2024)
���� ��� ����� ��� ����� ��� ��� ��� ��� ����� �� Autofeedback: An LLM-based framework for efficient and accurate API request generation. ���� �������������� (2024)
2024
-
[32]
In ��� ������� �������� ������ ���������� �� �������� ���������������� ���� �����(05 2024)
���� ��� ��� ��� ��� �������� �� �� RepoBench: Benchmarking repository-level code auto-completion systems. In ��� ������� �������� ������ ���������� �� �������� ���������������� ���� �����(05 2024)
2024
-
[33]
���� (2025)
�������� ��� ��� ��� ����� ��� ���� ��� ����� ��� ��� ������� �� �� Type-constrained code generation with language models. ���� (2025)
2025
-
[34]
O’Reilly Media, 1005 Gravenstein Highway North, Sebastopol, CA 95472, United States, 09 2021
������� �� �������� �������������� ��������� ������������ �������, 2nd ed. O’Reilly Media, 1005 Gravenstein Highway North, Sebastopol, CA 95472, United States, 09 2021
2021
-
[35]
������� ������������ ������, version 3.1.1 ed., 10 2024
������� ���������� . ������� ������������ ������, version 3.1.1 ed., 10 2024
2024
-
[36]
O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472, United States, 08 2019
������� ��� �������� ��� ��� ��������� �� ����� ������. O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472, United States, 08 2019
2019
-
[37]
In ����������� �� ��� ���� ��� ������ ���������� �� ��������� ��������� ��� ���� ������� ��� ����� ���������� ������ ������ ������ ���� (2024), R
������ ��� ������� ��� �������� ��� �������� ��� ������� ��� ����� ��� ��� ������� �� Measuring an LLM’s proficiency at using APIs: A query generation strategy. In ����������� �� ��� ���� ��� ������ ���������� �� ��������� ��������� ��� ���� ������� ��� ����� ���������� ������...
2024
-
[38]
In �������� �� ������ ����������� ���������� ������� ��� ������ ������� ���� �� ������ ����������� ���������� ������� �������� �����(12 2023), A
������ ��� �������� ��� ��������� ��� ����������� ��� ��� ���� �� Reflexion: language agents with verbal reinforcement learning. In �������� �� ������ ����������� ���������� ������� ��� ������ ������� ���� �� ������ ����������� ���������� ������� �������� �����(12 2023), A. Oh...
2023
-
[39]
���� (2024)
���������� ��� ������������� ��� ������ �� �� �� ��� ������ ��� ��� ���������� �� We have a package for you! A comprehensive analysis of package hallucinations by code generating LLMs. ���� (2024)
2024
-
[40]
���� ��� ���� ��� ��� ����� �� Harnessing LLMs for API interactions: A framework for classification and synthetic data generation.���� (2024)
2024
-
[41]
In ���� ���� ���� ��� ����������� ���������� �� �������� �������� ���������� ��� ����������� ������ (2020), pp
����������� ��� �������� ��� ��� �������� �� RESTTESTGEN: Automated black-box testing of RESTful APIs. In ���� ���� ���� ��� ����������� ���������� �� �������� �������� ���������� ��� ����������� ������ (2020), pp. 142–152. 23
2020
-
[42]
����� ��� ���� ��� ����� ��� ��� ��� ����� ��� ����� ��� ������ ��� ��� ���� �� Do advanced language models eliminate the need for prompt engineering in software engineering? ���� (2024)
2024
-
[43]
In ��� ���������� ������������� ���������� �� �������� ���������������� ���� ����� ���������� ����� ������ ���� (2025)
����� ��� ��� ��� ����� ��� ��� �� ��� ����� ��� ������ ��� ���� ��� ����� ��� ��� ��� ������ ��� ����� �� ��� ��� ��� ��� ��� ������ ��� ����� ��� ����� ��� ������������ ��� ������ ��� ���� ��� ���� ��� ��� �� ��� OpenHands: An open platform for AI software developers as gene...
2025
-
[44]
���� �������������� (2024)
���� �� ��� ����� ��� ����� ��� ��� ������ �� Agentless: Demystify- ing LLM-based software engineering agents. ���� �������������� (2024)
2024
-
[45]
In �������� �� ������ ����������� ���������� �������(2024), A
����� ��� �������� �� ��� ������� ��� ������� ��� ���� ��� ����������� ��� ��� ������ �� SWE-agent: Agent-computer interfaces enable automated software engineering. In �������� �� ������ ����������� ���������� �������(2024), A. Globerson, L. Mackey, D. Belgrave, A. Fan, U. Paq...
2024
-
[46]
����� ��� �������� �� ��� ������ �� ��� ������� ��� ����� ��� ��� ��� ������ ��� ������������ ��� ��������� ��� ����������� �� ��� ����� ��� ����� �� ��� ��� ������ �� SWE-bench multimodal: Do AI systems generalize to visual software domains? ���� (2024)
2024
-
[47]
In ����������� �� ��� ���� �������� ������������� ���������� �� �������� ������������ ���� ���� (04 2024), ACM, pp
��� ��� ����� ��� ���� ��� ������ ��� ������ ��� ��� ��� ������ ��� ��� ��� ����� ��� ��� ���� �� Codereval: A benchmark of prag- matic code generation with generative pre-trained models. In ����������� �� ��� ���� �������� ������������� ���������� �� �������� ������������ ���...
2024
-
[48]
In ��� ���� ���������� �� ��������� ������� �� ������� �������� ���������� (2023)
������ ��� ����� ��� ������ ��� ������ ��� ���� ��� ���� ��� ���� ��� ���� ������ ��� ����� �� RepoCoder: Repository-level code com- pletion through iterative retrieval and generation. In ��� ���� ���������� �� ��������� ������� �� ������� �������� ���������� (2023)
2023
-
[49]
In �������� �� ��� ����������� ��� ������������� ������������ ��� ���� (Vienna, Austria, 07 2025), W
������ ��� ����� ��� ��� ��� ������ ��� ����� ��� ��� ��� ���� ��� ���� ��� ����� ��� ������ ��� ���������� ��� ���� ��� ����� ��� ��������� ��� ������ ��� ��� ������ �� DI-BENCH: Benchmarking large language models on dependency inference with testable repositories at scale. I...
2025
Reviewed August 5, 2026 · model on record in the stance chip above.
Discussion (0). Sign in to comment.