Applying AI in Software Engineering: Bugs, Tests, SDN
Last updated: 13 September 2026
Where is AI actually applied in software engineering?
AI is already applied in four jobs teams recognize: finding defects, steering software-defined networks, testing, and maintenance. Models rank bugs, balance load, generate tests, and predict failures. The hard part is still data, explanations, and fitting the tools into the stack you already run.
Petar Georgiev Todorov, writing from the Plovdiv branch of Sofia Technical University in Bulgaria, makes those four jobs the spine of a 2022 review in the International Journal of Advanced of Multidisciplinary Research and Studies (volume 2, issue 5, pages 835-842). The research article is a survey, not a new detector. That is useful. A lot of “AI for software” writing stays at the slogan layer. Todorov names methods: grammar analysis, Naïve-Bayes, backpropagation nets, ant colony routing, self-healing tests, SonarQube, DeepCode. He also names the stall points: data quality, explainable models, integration complexity, technical debt.
If you already run a pipeline, read the paper as a checklist of places a model might sit. A static checker before merge. A dynamic watcher in staging. A routing policy in an SDN controller. A test generator in CI. A refactor bot on a stale module. Each of those is a product with a failure mode. The review is at its best when it keeps those failure modes in the same paragraph as the win.
"A detector that cannot explain a flag will not last in a team that has to ship on Friday."
This piece walks through Todorov’s map in ordinary language. You will see how static and dynamic detection differ, why SDN is a software problem, what “self-healing tests” are supposed to do, and why explainability is listed next to GDPR-style compliance instead of as a research hobby.
How do AI methods find software defects?
They find defects by learning patterns from code and from runs, then scoring new work against those patterns. Static methods never execute the program. Dynamic methods watch it while it runs. Learned models sit on both and try to predict the next fault. Manual review should not be the only net.
Static detection, in Todorov’s telling, uses grammar analysis, rule learning, and type derivation. Grammar analysis checks syntax against a language’s rules and is a good early filter. Rule learning trains on old bug reports and code changes, then writes rules you can apply to new files. That is how you focus review on the risky corners. Type derivation looks for mismatches: a value used as the wrong type, a constraint that was promised and then ignored. The win is cost. You catch structure problems before a long test run. The limit is honesty. Static tools cannot see a race that only appears at runtime.
Dynamic detection is the other half. Todorov describes non-execution stack and heap monitors (the names in the paper are a bit awkward; the idea is watching stack and heap behavior for anomalies), plus memory mapping. Stack traces can hint at overflows or illegal access. Heap patterns can hint at leaks and wild allocation. Memory maps show how a process uses RAM so you can compare a run against known bad shapes. The win is coverage of faults that never appear in the text of the file. The cost is that you have to run the software, which takes time and still cannot hit every path.
Learned Detectors Named in the Review
- → Backpropagation neural nets trained on code and defect reports for non-obvious bugs
- → Naïve-Bayes classifiers that score defect likelihood from attributes and history
- → Fingerprints of code segments matched against known bad signatures
- → Li and Zhang’s 2018 layered method using software-behavior decision trees
Those models share a weakness Todorov does not hide. They need large, decent training sets. They can be hard to interpret. Accuracy depends on the data more than on the brand of algorithm. If you take one rule from this section, take the pairing: use static methods early, dynamic methods when you can run the system, and treat a learned score as a ranking, not as a verdict.
Why does software-defined networking belong in this review?
Software-defined networking belongs here because the control plane is software. SDN splits decisions (where traffic should go) from forwarding (sending the packets). That split lets you program the network instead of waiting on proprietary boxes. Load balancing, routing, security, and adaptive apps are then ordinary software jobs, which is why AI methods show up in the controller.
Todorov lists the usual SDN selling points: flexibility, scale, programmability, automation. The controller talks to devices with protocols such as OpenFlow. Once that program exists, you can put a model in it. Neural nets look at traffic and pick routes or load splits. A backpropagation net can do dynamic load balancing to cut latency. Genetic algorithms search routing options. The paper’s concrete number is an ant colony method for quality-of-experience-aware flow routing that raised maximal QoE by 24.1 percent against a shortest-path baseline.
Security is the second SDN chapter. Neural intrusion systems watch traffic and try to block bad activity, including DDoS, with high reported accuracy in the cited work. Fuzzy logic systems mix techniques so the policy can bend as conditions change. One example pairs a fuzzy inference system with rate-limiting. Intelligent applications sit on top: reinforcement learning for adaptive video streaming that picks paths and quality to cut frame loss, and QoE controllers that watch latency and packet loss.
If you do not run networks, still read this section. It is a clean picture of AI sitting inside a control loop. The model is not writing a blog post. It is choosing an action under a time budget. That is closer to production software than a notebook that classifies GitHub issues.
How is AI changing software testing?
AI is changing testing by generating cases, ranking where to look, healing tests that went stale, and even comparing screens. Static tests still inspect code. Dynamic tests still run it. The new work is choosing those tests with a model so people spend less time on the obvious paths and more time on the ones that usually break.
Intelligent test case generation is the headline. Models read requirements and code structure, then propose cases. Genetic algorithms are the example Todorov gives for building a diverse set. Self-healing test systems watch for a case that no longer matches the software and then rewrite or regenerate it. That is a direct answer to brittle UI tests. Visual testing compares what the user would see against an expected picture, which matters for graphical interfaces where a passing unit test can still show a broken layout.
The tool list is familiar on purpose. Selenium and Appium automate execution and reporting and can simulate user actions. SonarQube-style analyzers look for smells, security holes, and maintainability issues. Todorov treats those as AI-powered enough to count. The engineering reading is: they encode heuristics and learned rules, and they only help if someone still owns the threshold. A thousand “code smell” tickets is not a quality program.
| Job | What the model does | What still needs a person |
|---|---|---|
| Case generation | Invent inputs from structure and history | Decide which failures are real requirements |
| Self-healing tests | Rewrite a stale case after a UI or API change | Confirm the new case still means the same thing |
| Visual checks | Diff screens against an expected image | Judge whether a pixel change is a bug |
| Static analysis | Flag smells, holes, and complexity | Triage noise so the board stays usable |
The maintenance half of the same chapter is the delayed twin of testing. Automated refactoring suggests simpler structure or less duplication. Predictive models try to catch defects before production. Reinforcement learning is named as a way for software to adapt to new user behavior. DeepCode-style tools suggest fixes from a large codebase of past patches. Adaptive maintenance systems watch performance and change resource use, for example on a cloud app under shifting load. That is attractive. It is also how a system can “heal” itself into a state nobody understands unless the actions are logged and reversible.
Why do data quality and explainable AI keep blocking adoption?
They block adoption because the models are hungry and opaque. Many tasks lack a clean labeled history. Noisy tickets teach the wrong lesson. The wrong feature shape makes a good algorithm look dumb. Cleaning that mess is slow, so teams skip it and then blame the model.
Explainable AI is the second wall. As models get deeper, “why this flag?” gets harder. Todorov gives three reasons to care. Interpretability is how developers and users decide whether to trust the output. Debugging is how you fix a wrong call. Compliance is how you survive a regulator who wants a reason, not a probability. If you cannot reconstruct the decision, you do not have a tool. You have a lottery with a dashboard.
Integration is the third wall, and it is the most operational. Compatibility with legacy systems can mean a rewrite. Process integration means training people and changing the workflow so the model’s output has a home. Technical debt is the hangover: rushed AI features that nobody can maintain. Todorov is not anti-adoption. He is anti-magical-adoption. A detector that cannot sit in the pipeline will rot in a slide deck.
If the data is the problem
Stop training. Fix labels, coverage, and the way events are stored. A better net on the same garbage will still be garbage, only faster.
If the explanation is the problem
Do not ship the score alone. Pair it with the features that moved, a similar past case, or a rule the team already accepts.
Those three blockers (data, explanation, integration) are why Todorov’s “opportunities” chapter can sound like a second paper. Design assistants, generated models from specs, self-managing systems, and intelligent maintenance are real directions. Collaboration tools that read project chatter, language models that summarize status for non-engineers, and even subscription services around review and security scans are business models sitting on the same stack. None of them escape the blockers. They inherit them.
What should a team try first from Todorov’s map?
Try the job you already measure. If review is the pain, start with a static detector. If production failures are the pain, start with a watcher. If the network is the product, start with one policy you can roll back. Do not start with a self-managing system. Earn the right to automate the loop.
A Practical Reading List From the Paper
• Pair static and dynamic: structure bugs and runtime bugs are different animals
• Put the model in a loop you can undo: SDN routing and auto-healing tests both need a kill switch
• Treat explanations as a feature: trust, debugging, and compliance all buy the same artifact
• Count integration as work: a detector that is not in the pipeline is a demo
Todorov’s last pages ask future work to fix data, raise explainability, smooth integration, and look at new applications such as design assistants and adaptive maintenance. That is a research agenda that also works as a team agenda. Quality goes up when defects are caught earlier. Productivity goes up when routine tests and refactors are not typed by hand. Innovation goes up only if the insights are visible enough that a person can argue with them. Invisible automation is just a new kind of outage.
Keep the 2022 survey nearby when someone says “we should add AI to engineering.” Ask which of the four jobs they mean. Ask what labeled history they have. Ask who will read the explanation when the model is wrong. If those answers are empty, you do not have an application of AI in software engineering. You have a wish.
FAQ
These answers restate Todorov’s four-job map so you can quote them without opening the PDF. They cover static versus dynamic detection, why SDN belongs in software engineering, and what usually blocks a rollout. If you are choosing a first project, start with the job you already measure.
Where is AI actually applied in software engineering?
Todorov’s 2022 review focuses on four places: finding defects, running software-defined networks, testing, and maintenance. Static and dynamic detectors, load-balancing models, generated tests, and refactoring tools are the concrete examples. The claim is not that AI replaces the lifecycle. It is that those four jobs already have working methods, plus a shared set of blockers. If your plan does not name one of those jobs, it is not yet a plan.
What is the difference between static and dynamic AI defect detection?
Static methods inspect code without running it: grammar checks, learned rules, type derivation. They catch structure problems early and miss runtime faults. Dynamic methods watch execution: stack and heap anomalies, memory maps. They see leaks and crashes and cost more to run. Hybrid and learned models try to get both kinds of signal from history. Most teams need both, because a clean compile does not prove a clean night in production.
Why does a software-engineering paper spend so much time on SDN?
Because a software-defined network is software. The control plane is a program that steers the data plane. Load balancing, routing, intrusion detection, and adaptive streaming are network jobs implemented as software. Neural nets, genetic algorithms, and fuzzy controllers are the AI layer on that program. If you maintain SDN controllers, you are already in software engineering. The 24.1 percent QoE gain cited for ant colony routing is the kind of number that only matters if you can roll the policy back.
What usually blocks AI integration on a real team?
Bad or missing data, models nobody can explain, and tools that do not fit the current stack. Todorov also names technical debt from rushing the adoption. Explainable AI matters for trust, debugging, and compliance. Compatibility and process change matter because a detector that cannot sit in the pipeline will not be used. Training the people who have to live with the output is part of integration, not a soft extra.
What does Todorov see as the next useful applications?
Design assistants, generated models from specifications, self-managing systems, and maintenance that acts before the outage. He also points at collaboration tools and language models that translate technical status for non-engineers. Those are opportunities only if the data and explanation problems are treated as product work, not as research leftovers. A self-managing system without a log is a future incident report.
Related articles
Defect and network work sits next to broader writing on AI opportunities, other surveys of AI in engineering practice, and modeling technique guides. The links below are the closest neighbors on this site. Use them when you need workforce context or a wider technique menu than this four-job map.