Advancements in Software Engineering Through Artificial Intelligence
Last updated: 13 September 2026
What advancements is AI actually bringing to software engineering?
AI is bringing three practical advancements into software engineering: models that write and complete code, test systems that generate and rank cases, and maintenance tools that find and patch defects before they become outages. Michael Müller’s 2024 review treats those as current practice, then uses a healthcare case to show what happens when the same idea sits in a clinic rather than an IDE.
Müller, writing from the University of Basel, published the paper in the International Journal of Scientific Research and Engineering Trends, volume 10, issue 4. The research article is mixed-methods: a comparison of work before and after AI tools, plus a case on pulmonary embolism assessment. That pairing is useful. Coding assistants get the headlines. A drop in time-to-treatment is a different kind of evidence. Both can be oversold. Both are worth reading with the caveats the author himself lists: data quality, explainability, and the friction of putting new tools into old pipelines.
"A model that writes a function and a model that flags a clot are both software. The stakes are not the same, and the engineering standard should not pretend they are."
Traditional development, as Müller frames it, is drowning in complexity, reliability work, and maintenance. Manual effort does not scale with the demand. AI is offered as automated reasoning, learning from data, and decision support across coding, testing, and upkeep. The honest sentence in the abstract is the last one: success means AI that augments human developers, not a fantasy of unmanned engineering. This piece stays in that frame.
How does AI-driven coding change daily development?
AI-driven coding changes daily development by turning natural-language intent and local context into suggested snippets, boilerplate, and sometimes whole functions. Müller points to deep models trained on large repositories, and to tools such as OpenAI Codex, DeepCode, and GitHub Copilot. The speed gain is real for repetitive work. The review burden moves onto the person who still has to say yes.
Codex-style systems translate instructions into executable code. DeepCode-style systems look for issues using learned patterns. Copilot, built on Codex in the account this paper uses, predicts the next lines inside the editor. Intelligent assistants also pull examples and documentation that used to take a search. IBM’s AI-powered assistant is cited as improving productivity by 30 percent in enterprise applications and cutting time on routine tasks. Microsoft’s Visual Studio work is cited for automated refactoring. Those numbers come from the paper’s secondary sources. Treat them as reported, not as a guarantee for your stack.
The useful distinction is between generation and assistance. Generation tries to produce code from a spec. Assistance sits next to a person who is already writing. Generation fails loudly when the spec is thin. Assistance fails quietly when the suggestion looks right and is subtly wrong. Müller’s later sections on explainability exist because of that quiet failure. If you cannot tell why a block appeared, you cannot tell when to throw it away.
What coding assistance is for
- → Boilerplate, glue code, and translations of a clear comment into a function
- → Completions that match local style when the surrounding file is a good teacher
- → Refactor hints that a human then verifies with tests
- → Not architecture, security-critical paths, or anything you cannot review
If your team is measuring this, measure review time and escaped defects, not only lines accepted. A 30 percent speed claim that produces a 30 percent rework rate is not an advancement. It is a transfer of work from typing to auditing.
Why does automated testing look different with AI in the loop?
Automated testing looks different with AI in the loop because cases can be generated from the codebase, ranked by likely fault, and watched for regressions without a person writing every assertion. Müller describes broader coverage, faster cycles, and defect prediction from code metrics and history. The tester’s job shifts toward oracles, edge judgment, and distrust of fluent false confidence.
Test generation from learned models can include paths a person would not think to write. Prioritization from historical defect data puts effort on the modules that have failed before. Spectrum-based fault localization, as the paper describes it, uses execution traces to isolate causes and cut debugging time. Parallel execution of large suites then gives rapid feedback. Continuous monitoring of outputs and logs can catch anomalies and performance regressions while the build is still warm.
Visual testing is the less obvious branch. Computer vision can check that a UI still renders across devices, catch layout breaks, and flag accessibility problems. Simulated user behavior can probe whether a flow still makes sense. That is attractive for products with many skins and locales. It is also a place where a model can bless a screen that looks fine and is legally or clinically wrong. Keep a human oracle for anything that is not a pixel diff.
Gains the paper emphasizes
Coverage of odd paths, ranked execution, faster localization, and less time spent writing the thousandth similar test.
Failure modes to budget for
Weak oracles, unexplained failures, and suites that pass because the generator and the product share the same blind spot.
Self-healing tests sit on the horizon in this paper: a suite that notices a behavior change and updates the expected output instead of staying red forever. That can save maintenance. It can also silently accept a regression. The engineering control is the same as everywhere else in the review. Automation proposes. A person, or a strict contract test, still decides what “correct” means.
What is intelligent maintenance in Müller’s account?
Intelligent maintenance is the use of models to detect bugs, suggest patches, and refactor code so technical debt grows more slowly. Müller describes semantic search against known issues, automated program repair, and tools that spot smells and antipatterns. The aim is a codebase that stays healthy without waiting for a heroic cleanup quarter.
Semantic code search and program repair compare faulty code with a store of past defects and fixes. Suggested patches still go through review. Refactoring tools use static and dynamic analysis to find structure that will hurt the next change, then apply known cleanups. Optimization algorithms can target speed and memory. Google’s bug detection work is cited as a way to watch a huge codebase and slow the pile-up of debt. Facebook’s automated review and refactoring is cited as a way to reduce load on human reviewers. Again, those are the paper’s examples, not a claim that your monorepo will behave the same way.
Proactive defect detection is the forward-looking version. Models trained on code changes, developer activity, and history try to mark risky edits before they fail in production. Automated repair can then propose a fix. Müller argues this cuts the cost of classical debugging. It also creates a new cost: verifying a fix the team did not write. If your tests are thin, you have not removed maintenance. You have relocated it.
What happened in the pulmonary embolism software case?
The pulmonary embolism case is Müller’s concrete test of AI-powered clinical software: an October 2022 tool that detects and triages suspected PE from imaging. The paper reports a collapse in time from scan to alert, faster anticoagulation when a response team was involved, and a drop in in-hospital mortality. Those figures are the reason the case is in a software engineering paper, not only a medical one.
Pulmonary embolism is a clot in a lung artery. Delay is dangerous. The institution in the case added a parallel workflow that reads scans and alerts clinicians. Data, as described, runs from January 2017 to July 2023 and includes time-to-assessment, time-to-anticoagulation, and in-hospital deaths, split into pre-AI and post-AI periods. Sources include electronic health records, workflows, and outcome reports.
| Measure | Before the AI tool | After the AI tool |
|---|---|---|
| Scan to assessment or alert | 318.42 minutes mean scan-to-assessment | 5.47 minutes mean scan-to-alert |
| Time to anticoagulation | 164.96 minutes without PERT activation | 83.17 minutes with PERT after AI |
| In-hospital mortality for PE | 8.8 percent | 2.2 percent, with post-AI deaths in non-PERT cases |
Read those rows as the paper reports them, including the combined effect of the tool and the Pulmonary Embolism Response Team. The AI did not replace the team. It made the team faster to activate. Radiologists spent less time on first-pass image review. Patients got anticoagulants sooner. The author also lists the implementation pain: noisy or incomplete training data, clinicians who will not trust a black box, and the work of wiring a new tool into hospital systems and habits.
For software people, the transferable lesson is not “add a model to imaging.” It is that workflow software can change outcomes when it shortens a critical path and when a specialist team is ready to act on the alert. Scalability, ongoing model refresh, and collaboration among developers, clinicians, and data scientists are the follow-on requirements Müller names. A one-off accuracy number would have been a weaker case. Time and mortality are harder to ignore, and still not a reason to skip explanation and monitoring.
Why do data, trust, and integration still stall these tools?
Data, trust, and integration still stall these tools because software artifacts are messy, deep models are hard to inspect, and real pipelines were not designed for a new intelligence layer. Müller treats those as first-class limits. A coding assistant that cannot see your private repo, or a tester that cannot explain a failure, will not survive contact with a regulated or high-load environment.
On data, repositories, bug reports, and tests are often fragmented, inconsistent, and incomplete. Sensitive code cannot always be shared, which caps training volume. Source code, traces, and logs also need structure. Plain text misses nesting and control flow. Abstract syntax trees and graphs help and add their own processing cost. If you skip that work, you get a model that is fluent in public GitHub style and lost in your COBOL-adjacent service.
On trust, the black-box problem is not academic. Developers need a reason to accept a change. Müller lists distillation, saliency maps, rule-based overlays, simpler models, and attention that highlights which code or docs drove a suggestion. Pink and colleagues, cited on trust among practitioners, sit in the same cluster: people will not hand critical tasks to a system they cannot interrogate. That is rational, not Luddite.
On integration, many AI tools start as standalone prototypes. They do not speak your languages, frameworks, or CI. Change management is the human half: fear of job loss, loss of craft, and unreliable output. Scale is the machine half: deep models are expensive, and large codebases need parallelization, GPUs or TPUs, and a smaller footprint. Legacy debt is the historical half. Incremental refactoring and modularization, including using AI to find the debt, are the path Müller sketches. None of that is a weekend plugin install.
What would self-healing and adaptive systems actually do?
Self-healing and adaptive systems would watch their own behavior, detect a deviation, and start a repair or a resource change without waiting for a ticket. Müller places this in future work, next to intelligent design assistants and proactive defect detection. The idea is continuous operation in settings where downtime is expensive, not a magic runtime that never needs engineers.
Design assistants would analyze requirements, suggest architectural patterns, and give live feedback using past projects. Automated model generation, including neural architecture search and reinforcement learning, would explore design options and keep updating as requirements move. Testing systems would generate new cases, repair broken tests, and check UIs. Maintenance systems would forecast risky changes and apply patches. Adaptive runtime examples in the paper include a cloud allocator that shifts capacity with load, and a cyber-physical system that retunes hardware from sensor data.
A grounded way to try the paper’s ideas
• Start with ranking, not autonomy: defect-prone files, flaky tests, or risky diffs, with a person still merging
• Instrument the PE lesson: measure time-to-alert in your own workflow, not only model accuracy
• Demand an explanation path: which input drove the suggestion, in the IDE or the clinical UI
• Refuse silent test healing: auto-updates need a contract or a reviewer, or they will hide regressions
The long view in the paper is AI-augmented teams, continuous adaptive systems, and practices where automation and expertise complement each other. Ethics and regulation get a late but necessary mention, especially in safety-critical domains. That is the right closing pressure. The PE numbers are striking. They do not cancel the need for data hygiene, interpretability, and a human who can still say the model is wrong. Advancement, in Müller’s sense, is that partnership, not a replacement fantasy.
Frequently Asked Questions
What software engineering areas does Müller focus on?
The 2024 IJSRET paper focuses on AI-driven coding and code generation, automated testing and quality assurance, and intelligent maintenance with bug detection and refactoring. It also reports a healthcare case on pulmonary embolism assessment and sketches future self-healing and adaptive systems.
What did the pulmonary embolism software change?
The paper reports that after an October 2022 AI triage tool, mean scan-to-alert time fell from 318.42 minutes to 5.47 minutes, and in-hospital mortality for PE dropped from 8.8 percent to 2.2 percent. Time to anticoagulation was shorter when a Pulmonary Embolism Response Team was activated.
What is a self-healing software system in this paper?
A self-healing system detects and repairs issues at runtime so the service keeps running. Müller points to reinforcement learning and anomaly detection to watch performance, spot unusual behavior, and start a fix. The same idea appears in adaptive test suites that update themselves when the product changes.
What limits AI adoption in software engineering here?
The limits are messy training data, models that cannot explain their suggestions, hard integration with existing tools, cultural resistance, compute cost at scale, and technical debt in legacy systems. Müller argues that AI should augment developers rather than replace the judgment those problems require.
Which coding tools does the paper name?
The review names OpenAI Codex, DeepCode, and GitHub Copilot for generation and assistance. It also cites reported productivity gains from IBM’s AI-powered code assistant and Microsoft’s Visual Studio work on automated refactoring, while stressing that data quality and trust still constrain those tools.