The Current Challenges of Software Engineering in the Era of Large Language Models
A qualitative study of 24 experts maps 26 LLM4SE challenges across seven software-engineering dimensions.
Key Findings
Methodology
The paper conducts a qualitative study based on six thematic discussions at the 9th CCF Beautiful Lake Seminars. The 24 participants included 17 academic researchers and 7 industry practitioners. Discussions were transcribed and open-coded in NVivo into opinion cards; two authors independently grouped codes using Open Card Sorting, resolved disagreements, and obtained confirmation from additional authors. The process yielded 26 challenges across seven LLM4SE dimensions.
Key Results
- The framework identifies 26 challenges spanning requirements and design, coding assistance, test-code generation, code review, maintenance, vulnerability management, and data, training, and evaluation. It also reviews CodeX, AlphaCode, CodeT5, CodeLlama, StarCoder, and DeepSeek-Coder as representative systems.
- The paper reports rapid scaling of code models: CodeX used about 159 GB of public GitHub code; AlphaCode was trained across 12 languages and outperformed 54.3% of 5,000 Codeforces participants; DeepSeek-Coder used 2T tokens, with 87% code.
- This is not a controlled benchmark study. It reports no new leaderboard, statistical test, or ablation; its principal result is a research agenda grounded in expert discussion, prior literature, and representative model cases.
Significance
The paper reframes the central question from whether LLMs can generate code to how they can participate reliably in the entire software-development lifecycle. It identifies persistent barriers—natural-language/program semantics gaps, unstable outputs, changing models and data, privacy, licensing, and malicious content—that jointly affect quality, productivity, security, and accountability. For researchers, the framework discourages overreliance on isolated code-generation scores. For practitioners, it argues that model outputs must be embedded in testing, review, supply-chain controls, and explicit human responsibility rather than treated as deployable software.
Technical Contribution
The main contribution is systematic integration rather than a new model or learning algorithm. The paper maps data construction, fine-tuning, prompting, and downstream tasks into one LLM4SE pipeline. It discusses Topological Sort for Dependency Analysis, Adapter Tuning, LoRA, Prefix Tuning, Prompt Tuning, zero-shot, few-shot, and Chain-of-Thought prompting. These mechanisms are connected to requirements, coding, testing, review, maintenance, and vulnerability management, producing an end-to-end technical map from model preparation to engineering deployment.
Novelty
Unlike surveys centered on code generation, this work organizes the problem around the software-development lifecycle and combines a structured discussion among 24 academic and industrial participants with literature synthesis. Its fundamental novelty is alignment: model capability, data governance, evaluation, software quality, and responsibility are analyzed in one framework instead of being reduced to HumanEval-style pass rates.
Limitations
- The sample contains only 24 participants and comes from one seminar, so participant selection, discussion dynamics, and author interpretation may bias the resulting taxonomy. The importance of each challenge has not been independently validated with large-scale surveys or industrial telemetry.
- The paper provides no unified benchmark, statistical significance, ablation, or prioritization among the 26 challenges. Its model-scale figures therefore should not be interpreted as evidence that one LLM4SE approach is superior to another.
Future Work
Future work should build dynamic benchmarks containing real repositories, enterprise code, CI logs, and security incidents. Evaluation should cover functional correctness, maintainability, security, license compliance, provenance, and developer burden. Promising directions include retrieval augmentation, tool use, execution feedback, long-context agents, auditable data lineage, and longitudinal studies of real teams. The field needs evidence that LLMs improve sustained engineering outcomes, not merely one-shot generation success.
AI Executive Summary
Large language models are changing software engineering, but the decisive question is no longer whether a model can produce plausible code. GitHub Copilot X and GitLab Duo demonstrate the appeal of natural-language development, yet ambiguous requirements, hidden dependencies, unstable outputs, privacy and licensing risks, and malicious training data separate generation from dependable delivery.
Gao and colleagues examine LLM4SE through the software-development lifecycle. They analyze six thematic discussions involving 24 participants—17 researchers and 7 practitioners—using NVivo open coding, opinion cards, and Open Card Sorting. The resulting framework identifies 26 challenges across requirements and design, coding assistance, test generation, review, maintenance, vulnerability management, and data, training, and evaluation. The paper also surveys CodeX, AlphaCode, CodeT5, CodeLlama, StarCoder, DeepSeek-Coder, LoRA, Prompt Tuning, and Chain-of-Thought prompting.
The central message is that LLM4SE is a socio-technical system, not an autonomous programmer. Larger datasets increase capability but also increase contamination, leakage, and distribution-shift risks; prompts improve adaptation but do not guarantee truth; generated patches require execution, testing, static analysis, review, and security scanning. The paper’s principal output is therefore not a new performance number but a research agenda: build realistic, dynamic, auditable evaluations in which software quality, security, and accountability matter as much as model efficiency.
Deep Analysis
Background
Software engineering evolved from structured programming and modular design to object-oriented, cloud, and AI-augmented development. Earlier AI4SE systems addressed requirements, repair, testing, and project management; LLMs extend this trajectory toward natural-language-driven, potentially end-to-end development. CodeX, AlphaCode, CodeT5, StarCoder, and DeepSeek-Coder demonstrate rapid progress, but dependable lifecycle integration remains unresolved.
Core Problem
The core problem is embedding probabilistic, sometimes hallucinating, continuously changing models into a lifecycle that demands determinism and accountability. Natural language underspecifies program behavior; dependencies, security constraints, and repository context are incomplete; public code may contain defects, secrets, malicious content, or incompatible licenses. These issues make correctness, safety, provenance, and maintenance difficult to guarantee.
Innovation
- ��Organizes challenges around the full SDLC rather than code generation alone.
- ��Derives 26 challenges from discussions involving 17 academics and 7 practitioners.
- ��Connects data construction, model adaptation, prompting, and downstream tasks.
- ��Covers quality, efficiency, reliability, trustworthiness, and security together.
- ��Places model examples and governance requirements in one engineering research map.
Methodology
- ��Data construction: collect code from GitHub and Software Heritage; StarCoder2 applies long-line, auto-generated-file, alphabetic-content, and encoded-data filters.
- ��Data organization: use Topological Sort for Dependency Analysis to order dependent files and special tokens for commits and other data types.
- ��Model adaptation: Adapter Tuning freezes the base model; LoRA injects low-rank matrices; Prefix Tuning adds trainable layer prefixes; Prompt Tuning modifies task inputs.
- ��Inference: use zero-shot, few-shot, and Chain-of-Thought prompting.
- ��Task mapping: connect LLMs to design, coding, testing, review, maintenance, and vulnerability management.
- ��Qualitative synthesis: apply NVivo coding, opinion cards, Open Card Sorting, disagreement resolution, and multi-author confirmation to derive 26 challenges.
Experiments
The study is qualitative rather than a controlled model experiment. Twenty-four participants held six thematic discussions of roughly four hours each on large-model software engineering, code intelligence, quality assurance, data and evaluation, open-source engineering, and future trends. Authors transcribed and coded the sessions in NVivo and cross-checked the categories. HumanEval is discussed as a standard code-generation dataset, while model-scale examples include AlphaCode’s 967B tokens and DeepSeek-Coder’s 2T tokens. No new common test set or ablation study is introduced.
Results
The main result is a taxonomy of 26 challenges, not a model ranking. AlphaCode reportedly exceeded 54.3% of 5,000 Codeforces competitors; DeepSeek-Coder used data composed of 87% code and 13% English and Chinese natural language; StarCoder trained on more than 1T tokens. These figures demonstrate expanding capacity, but they do not establish corresponding gains in enterprise software quality, maintainability, or security.
Applications
LLMs can support requirements exploration, software modeling, completion, API recommendation, code Q&A, documentation, test generation, fuzzing, smell detection, refactoring, log analysis, root-cause localization, vulnerability scanning, and supply-chain analysis. Deployment should include version control, sandbox execution, static analysis, test gates, human review, data redaction, provenance tracking, and license checking.
Limitations & Outlook
The taxonomy is affected by a single seminar, a small sample, and qualitative interpretation; challenge priority and causal importance remain unmeasured. The model table also mixes data-size conventions, and training volume is not a direct proxy for capability. Future studies should use longitudinal, cross-organization experiments in real repositories and measure regression defects, security incidents, maintenance cost, developer trust, and overall team productivity.
Plain Language Accessible to non-experts
Imagine a large restaurant. Traditionally, a customer describes a meal, a chef designs the recipe, staff collect ingredients, cooks prepare it, inspectors taste and test it, and a manager checks hygiene before serving. An LLM is like an extremely fast trainee chef: give it a request such as “make a meal suitable for someone with allergies,” and it can instantly propose a recipe, instructions, and modifications to an old menu.
The trouble is that the trainee may not know whether ingredients are fresh, may copy a bad recipe, or may forget the allergy constraint. It might also use an ingredient whose origin is unclear or whose use is not legally permitted. That is why the paper says we must inspect not only speed, but also whether the request was understood, whether the materials are safe, whether the result meets standards, and whether the process can be traced.
The authors gathered 24 experts and practitioners and identified 26 trouble spots across the entire kitchen operation. The model can help plan, build, test, inspect, repair, and monitor software, but every step needs checking and a responsible person. Mature practice does not let the machine run the restaurant alone; it makes the machine a fast, supervised, inspectable, and correctable assistant.
ELI14 Explained like you're 14
Imagine you are building a huge video game. You tell a very clever chatbot, “Make me a game with rankings, teams, and anti-cheat protection,” and it may write lots of code in seconds. Sounds like a cheat code, right? CodeX, CodeLlama, and DeepSeek-Coder are models trained especially to work with code.
But code is less forgiving than a normal essay. One missing symbol or misunderstood rule can crash the game, and a hidden security hole might let someone steal accounts. The bot can also produce code that looks impressive but does not run. Its training data may include bugs, secrets, or material that cannot legally be reused.
This paper does not simply announce a winner. Instead, 24 researchers and engineers discussed the whole development journey and identified 26 challenges: requirements, design, coding, testing, review, maintenance, and security. Just as a game must be tested repeatedly for bugs and cheating, AI-written code needs tests, analysis, and human review.
So the best conclusion is not “AI will replace programmers.” It is “programmers get a super-fast teammate who sometimes makes mistakes.” Let it draft code, find clues, and create tests—but do not hand over the final decision. The future is about giving this teammate better memory, evidence, safety checks, and a way to notice and fix its own mistakes!
Glossary
Large Language Model
A model trained on large datasets to predict and generate language or code. Technically, it is typically a neural sequence model whose learned distributions can be adapted to software tasks.
It is the core technology underlying LLM4SE applications.
LLM4SE
The integration of large language models into software engineering activities and the software-development lifecycle. It includes assistance with requirements, coding, testing, review, maintenance, and security.
The paper uses LLM4SE as the organizing paradigm for its 26 challenges.
LoRA
Low-Rank Adaptation freezes pretrained weights and learns low-rank update matrices for a target task. This reduces trainable parameters and adaptation cost.
It is discussed as a principal fine-tuning technique for code models.
Chain-of-Thought
A prompting strategy that asks a model to generate intermediate reasoning steps before an answer. It may improve complex-task performance, but an explanation is not itself a proof of correctness.
The paper describes it as a test-time technique for improving software-engineering tasks.
HumanEval
A benchmark of programming problems evaluated through tests of generated functions. It measures localized code-generation ability and does not fully represent repository-level quality.
The paper identifies it as a standard dataset after CodeX.
Software Development Life Cycle
The connected process of requirements, design, implementation, testing, deployment, and maintenance. It provides the paper’s main structure for analyzing LLM use and risk.
The 26 challenges are mapped to lifecycle stages and supporting infrastructure.
Open Questions Unanswered questions from this research
- 1 The long-term effect of LLMs on real repositories remains uncertain. HumanEval-like tests cannot capture regressions, architectural consistency, maintenance burden, or team collaboration.
- 2 There is no broadly accepted way to trace licensing, privacy, and security responsibility for generated code. The field needs provenance, source attribution, auditable logs, and governance standards.
- 3 Outputs vary with prompts, model versions, and context. Dynamic benchmarks connected to real CI pipelines are needed to measure reliability rather than one-shot success.
Applications
Immediate Applications
Controlled coding assistant
Enterprises can deploy models over private repositories for completion, documentation, test drafts, and code Q&A. Required safeguards include redaction, access isolation, sandbox execution, static analysis, and human merge approval. The expected benefit is less repetitive work, not removal of quality gates.
Security and maintenance copilot
Maintenance teams can use models to summarize logs, analyze reviews, localize root causes, propose fixes, and assist vulnerability scanning. Every patch should pass regression tests, dependency checks, and security review before production deployment.
Long-term Vision
Auditable end-to-end software agent
A long-term vision is an agent that turns requirements into tool calls for retrieval, compilation, testing, static analysis, and deployment while maintaining an evidence trail. Realization requires long-context reliability, dynamic knowledge, robust evaluation, permission controls, and explicit human accountability.
Abstract
With the advent of large language models (LLMs) in the artificial intelligence (AI) area, the field of software engineering (SE) has also witnessed a paradigm shift. These models, by leveraging the power of deep learning and massive amounts of data, have demonstrated an unprecedented capacity to understand, generate, and operate programming languages. They can assist developers in completing a broad spectrum of software development activities, encompassing software design, automated programming, and maintenance, which potentially reduces huge human efforts. Integrating LLMs within the SE landscape (LLM4SE) has become a burgeoning trend, necessitating exploring this emergent landscape's challenges and opportunities. The paper aims at revisiting the software development life cycle (SDLC) under LLMs, and highlighting challenges and opportunities of the new paradigm. The paper first summarizes the overall process of LLM4SE, and then elaborates on the current challenges based on a through discussion. The discussion was held among more than 20 participants from academia and industry, specializing in fields such as software engineering and artificial intelligence. Specifically, we achieve 26 key challenges from seven aspects, including software requirement & design, coding assistance, testing code generation, code review, code maintenance, software vulnerability management, and data, training, and evaluation. We hope the achieved challenges would benefit future research in the LLM4SE field.