Integrating AI Into the Software Development Life Cycle

Why teams still struggle to put AI into the SDLC

Most software teams already touch AI somewhere. A planner tries a better estimate. A developer accepts a suggested function. A tester runs a generated suite. That scatter of tools is not the same as integrating AI into the software development life cycle. Integration means the work is planned, reviewed, and owned across phases, not dropped in as a demo.

Marcela Paladino and Claudia Pons, writing from Lifia at the Universidad Nacional de La Plata, with Pons also tied to Centro CAETI and CIC-PBA, treat that gap as the subject of a 2025 narrative review in the Memorias de las 54 JAIIO Argentine Symposium on Software Engineering. Their research article does not sell a new assistant. It sorts recent studies from 2022 to 2025, names the tools that actually appear in each phase, and groups the reasons those tools stall: technical limits, organizational friction, and ethical risk.

That sorting is useful because the public conversation still jumps from “AI writes code” to “AI replaces engineers.” Neither slogan matches how software gets shipped. Planning still needs history. Requirements still arrive as messy language. Tests still miss cases. Production still runs on systems that were never designed for a model. Paladino and Pons keep returning to those ordinary constraints, which is why the review is worth reading even if you already use Copilot.

"Deep learning, NLP, and agents can speed planning, coding, and tests. They do not erase bad data, old systems, or a team that was never trained."

This piece walks through that review in plain language. You will see which tools show up in planning, requirements, design, development, testing, and maintenance. You will also see why planning, testing, and post-release work remain the hardest stages, and why training plus ethics sit next to architecture instead of in an appendix. If you lead a product, run a delivery team, or just want a clearer map than a vendor slide, start here. The same map is also available as a research article on Academia.edu.

What is AI integration in the software development life cycle?

AI integration in the SDLC is the planned use of machine learning, natural language processing, and intelligent agents inside the phases you already run: planning, requirements, analysis, design, development, testing, deployment, and maintenance. It is not a new life cycle. People still own decisions the tools cannot explain.

Paladino and Pons are careful with words, and that care helps. They split three layers that people usually mash together. Tools are concrete products, such as GitHub Copilot for code or Selenium for test automation. Techniques are methods, such as supervised learning for effort estimates or NLP for turning a user story into a spec. Technologies are the broader families, such as NLP as a field that includes tokenization, embeddings, spaCy, and NLTK. If you confuse a product with a method, you will buy the wrong thing and then blame “AI” when the estimate is still wrong.

The review also treats machine learning as a technique when the paper means the method, and as a tool only when a framework is named, such as TensorFlow. That sounds fussy. It is the difference between “we use ML” and “we trained a model on last year’s tickets and now we can see why the forecast moved.” Integration, in this sense, is traceable. Someone can point to a phase, a tool, a dataset, and a person who still signs off.

The authors keep the scope on traditional development settings. They do not try to cover every adjacent topic in AI product design. Planning through maintenance is already a large map. Staying inside it lets them compare like with like: what the tool does in that phase, what usually breaks, and what strategy the literature actually proposes. That is a better starting point than a catalog of every chatbot.

How did Paladino and Pons study the problem?

They ran a narrative review, not a locked systematic protocol. Studies from 2022 to 2025 came from IEEE Xplore, Scopus, and Google Scholar using AI, software lifecycle, and integration terms. Each paper needed a clear method and a direct link to putting AI into the SDLC. The result is a structured map, not a census.

The practical instrument is an extraction matrix. For each source they recorded the SDLC phase, the challenge, the factor that made it better or worse, the suggested strategy, the expected effect on efficiency or quality, and the citation. That spreadsheet is how a narrative review stays honest. Without it, you get a pile of anecdotes. With it, you can see that planning, testing, and maintenance keep showing up as the painful stages, and that data quality, legacy fit, resistance, and opacity keep showing up as the reasons.

They then used three analysis moves: a narrative synthesis of the qualitative findings, a comparative matrix across phases, and thematic coding to catch repeated patterns. The method is not flashy. It is the right one for a field where papers mix experiments, case write-ups, and tool reports. The authors also flag the limit themselves. A narrative review can miss studies, and the selection criteria belong to the reviewers. That does not make the map useless. It means you should treat it as a well-organized reading of recent work, not as a census.

One more timing note matters. Around 2023, large language models stopped being a niche and started showing up in code generation, semantic analysis of requirements, and test automation. Paladino and Pons do not run a before-and-after trial. They do notice the shift: from tools that automate a narrow task toward generative and adaptive systems that try to sit across several phases. That is the background for why Copilot and ChatGPT appear in the results without becoming the whole story.

Which AI tools show up in each SDLC phase?

The review lists tools by phase. Planning uses agents and deep learning for estimates and schedules. Requirements use NLP and large language models. Analysis adds OCR and vulnerability prediction. Design uses neural nets for diagrams. Development is Copilot-style assistance. Testing generates cases. Deployment and maintenance add predictive monitoring and explainable models in CI/CD.

Start with planning, because that is where many AI programs quietly fail. If the historical data is thin or biased, a fancy estimator just produces a confident wrong date. The literature Paladino and Pons collect still likes specialized training sets and more consistent planning platforms. That is a data problem dressed as a calendar problem. Agents that draft a schedule are only as good as the completed projects you are willing to show them.

Requirements are a better news story. NLP can take a messy description and push it toward a structured specification, which helps traceability later. Domain-specific models reduce ambiguity. That does not mean a product manager can skip writing. It means the conversion from “the user wants this” to “the system shall do that” can be assisted, checked, and linked. Analysis then sits on top: OCR for documents, NLP for sorting, ML for guessing where the weak spots are. Combined pipelines with cross-checks show up as the practical advice, because a single classifier on a PDF is not an analysis process.

Design is the quiet middle. Models can sketch flows, suggest architecture patterns, and turn a drawing into more structured code. The promise is fewer structural mistakes and a faster pass from idea to artifact. The risk is a pretty diagram that nobody can defend. Development is louder. Generative assistants write code and can flag problems early if they are trained for that job. Paladino and Pons, drawing on work they collect, still want human review. Over-dependence plus huge training sets can insert defects and security holes. An assistant is not a compiler, and it is not a security review.

Testing is where deep learning and NLP earn their keep by generating and classifying cases. Coverage can rise. Manual load can fall. Traditional test bias can shrink if the generator is not just cloning the old suite. Deployment and maintenance close the loop: CI/CD automation, predictive monitoring, and repair suggestions, with explainable methods so operators can see why a fix was proposed. That last piece is easy to skip and expensive to skip. A self-healing pipeline that nobody understands is a new kind of outage.

Why are planning, testing, and maintenance the hard stages?

AI shows up in every phase, but three stages keep lighting up. Planning lacks clean history, so estimates stay guesswork. Testing still leans on old methods and thin coverage. Deployment and maintenance hit legacy systems and weak defect prediction. Those stages decide whether the rest of the AI stack is a toy or a process.

Planning is hard because it asks a model to do the thing software history is worst at: tell the truth about how long work took. If completed work is logged poorly, if scope changes are not recorded, if teams hide overtime, the model learns fiction. Suggested strategies include deeper learning models for estimates and interoperable platforms that can talk to older systems. Neither is a shortcut around better project records. If you want AI planning, you are volunteering to clean the archive.

Testing is hard for a different reason. Teams already have a ritual. Adding a generator that invents cases sounds like relief until someone has to judge whether those cases are real. The review notes a shortage of tools that can create and classify cases as the product changes. Deep learning and NLP are the proposed lift. The honest caveat is that generated tests can look abundant while still missing the one path a customer will hit. Coverage numbers are not the same as confidence.

Deployment and maintenance are hard because production is where legacy lives. New models do not like old interfaces. Environments change. Defects do not announce themselves in a training set. Predictive systems, reinforcement-style methods, and proactive monitoring are the suggested answers. The operational truth is simpler: if the model cannot sit next to the systems you already run, it will stay in a pilot. Integration with inherited architecture is not a later phase. It is the job.

What technical obstacles still block AI in software teams?

The technical bucket has three stubborn items. Dirty data wrecks planning and later analysis. Modern AI tools fit poorly with inherited architectures. Code generators need huge datasets and can still inject errors unless a person reviews the output. Fix the data and the interfaces, or the rest of the stack will look smarter than it is.

Data quality is not a slogan here. Paladino and Pons keep pointing at fragmented records and black-box algorithms that make results hard to trust. In planning, that shows up as bad effort numbers. In analysis and validation, it shows up as predictions nobody can defend. The controversy they surface is the right one: can you trust these models blindly, or do you need ongoing human review next to the automation? Their answer is the second option. Current models are not yet as sturdy as critical environments demand.

Legacy integration is the other technical wall. Modular platforms sound attractive in papers. In companies, people still buy a point solution that never quite joins the systems that have grown for years without AI in mind. Paladino and Pons treat that theory-practice gap as real, not as a failure of will. If your architecture has no standard way to share data, an agent that “plans resources” is a slide. Interoperable tools and staged modules are the boring path that works.

Code assistants sit in a third trap. They are useful. They are also hungry for data and easy to over-trust. The review’s stance is mixed on purpose: keep the generator, keep the human pass, train models that look for early errors, and do not treat autocomplete as architecture. A team that measures accepted suggestions without measuring escaped defects will congratulate itself on speed while shipping a slower incident later.

How do organizations resist, and what training actually helps?

Organizational resistance is not a personality flaw. People fear lost roles and stale skills. Training is thin. Leaders often fail to fund the work or to say why it matters. Paladino and Pons treat that mix as a first-class barrier, equal to data quality. A tool nobody is trained to challenge will be ignored or trusted too much.

The literature they gather is split in a way that matches real offices. Some technology leaders treat AI as a necessary ally. Others look at the cost and the learning curve and stall. That split is not solved by a lunch-and-learn. The review’s proposed response is continuous training that covers both the methods and the tools, plus mixed teams that put AI specialists next to developers and project managers. The point of the mix is not harmony. It is so a generated estimate or a generated test has someone in the room who can say it is wrong.

Management support is the quieter half. If executives do not treat AI as a strategy, the budget for data cleanup, platform work, and training will lose to the next feature. Paladino and Pons argue for making the case at the top and for a culture that allows controlled experiments. That last part is easy to fake. A controlled experiment has a rollback, a metric, and a person accountable for harm. A sandbox that never touches a real pipeline is not adoption. It is delay with better branding.

Related studies they cite, including work that uses a technology-organization-environment frame, land in the same place: culture and resistance sit beside the model. If you only hire for prompt skill, you will miss the harder work of changing how estimates, reviews, and incidents are discussed. Training that helps is training that teaches people to read a model’s output the way they already read a pull request: with suspicion, context, and a path to override.

Why do ethics and opacity keep coming back?

Ethics here is privacy, security, and black-box models. Sensitive data in planning or production can leak. Automated decisions that nobody can explain erode trust. Paladino and Pons treat those as adoption blockers. A team that cannot defend a model will not put it on the critical path, or will take a regulatory bet if it does.

Privacy shows up whenever large volumes of sensitive information feed a model. The review notes weak rules and weak audits as a live argument: how far can you automate without breaking confidentiality? That question is not theoretical for a bank, a hospital, or any product with user logs. Data used to train an estimator or a defect classifier can still be personal or commercially secret. If your pipeline cannot say what was retained, you do not have an AI process. You have a leak with a dashboard.

Explainability is the twin problem. If developers and stakeholders cannot see why a schedule, a generated test, or a repair was chosen, they will not trust the tool, or they will trust it blindly. Both are failure modes. The authors want explainable methods in the stack, not as a research extra. They also admit that those methods are still young and may not yet meet regulatory or ethical standards. That honesty is useful. “We added a heatmap” is not the same as “a reviewer can challenge this.”

The ethical strategies they list are concrete: privacy and security policy, periodic audits for risk and bias, and mechanisms that make outputs inspectable. None of that is glamorous. All of it is what turns a Copilot trial into something you can leave running. If you only remember one ethics line from the paper, remember this. Opacity is not a style issue. It is why a good model still fails to enter planning, testing, or production repair.

How do technical, organizational, and ethical strategies compare?

Paladino and Pons do not pick a winner among the three dimensions. Technical work without training leaves a tool unused. Training without data quality leaves a confident mess. Ethics without either becomes a policy PDF. You need all three if the goal is a durable process rather than a pilot that dies after the demo.

Read that table as a sequencing hint, not as three separate projects. Data curation without an owner becomes a graveyard of CSV files. Explainable models without training become screenshots in a slide deck. Audits without executive cover become a compliance theater. The review’s contribution is the insistence that these moves travel together. That is also why planning, testing, and maintenance stay hard. Those stages touch dirty history, real users, and live systems at once.

The authors compare their grouping with other recent work on project-planning barriers, organizational adoption of AI tools, and generative AI’s pressure on SDLC methods. The overlap is reassuring. When independent papers keep naming culture, resistance, and the need to rewrite ethical frames, you can stop treating those as soft extras. They are part of the engineering work.

What should a team try first?

Start where the review says the pain is, and start smaller than a platform rewrite. Pick one planning estimate you can check, or one test-generation pass with a human gate, or one monitoring signal in a system you already understand. Pair it with a named reviewer and a rule for when the model is wrong.

The future Paladino and Pons sketch is not mysterious. Large language models will keep spreading across code, requirements, and tests. That spread will not automatically fix data quality, legacy fit, or trust. If anything, it will hide those problems behind fluent text. The review’s value is the refusal to treat fluency as adoption. You can read it as a 2025 snapshot and still use it as a checklist: where is the data, who is trained, what is inspectable, and which phase is actually in scope.

That is the real lesson. Integrating AI into the software development life cycle is less about finding a smarter assistant and more about making the existing cycle honest enough for a model to help. Bad estimates, untested paths, and unexplained production fixes were already expensive. AI makes them faster. The strategies in this review (cleaner data, modular platforms, mixed teams, audits) are how you make them better instead.

Frequently Asked Questions

What does integrating AI into the SDLC actually mean?

It means placing AI tools and techniques inside ordinary software work, not treating AI as a side experiment. Paladino and Pons map that work across planning, requirements, analysis, design, coding, testing, deployment, and maintenance. The goal is better estimates, clearer specs, faster code, wider tests, and earlier failure detection, without pretending the old process disappears.

Which SDLC phases are hardest for AI adoption?

The review flags planning, testing and quality assurance, and deployment plus maintenance as the most stubborn stages. Planning lacks clean historical data. Testing still depends on old methods and incomplete case coverage. Deployment and maintenance collide with legacy systems and weak prediction of defects after release. Those three stages decide whether the rest of the AI stack is a toy or a working process.

What technical problems stop AI from working in real teams?

Poor data quality is first. Models cannot estimate effort or find bugs if the records are messy. Second is compatibility with systems that were never designed for AI. Third is over-trust in code generators that can insert errors or security holes. Paladino and Pons argue for data curation, human review, and modular platforms rather than a single big-bang swap.

Why do organizations resist AI in software development?

People worry about losing roles and about skills going stale. Training is uneven. Managers often fail to fund the work or to state why it matters. The review treats that mix as a cultural problem, not only a tooling problem. Interdisciplinary teams, ongoing training, and visible executive support are the proposed countermeasures.

How should teams handle ethics and model opacity?

Treat privacy, security, and explainability as product requirements. The authors call for audits, privacy policy, and explainable methods such as attention maps and rule-based accounts so developers can inspect automated decisions. A model that cannot be explained is hard to trust in planning, testing, or production repair. Opacity is not a style issue. It is why a good model still fails to enter the critical path.

Related articles

• Integracion de IA en el ciclo de vida del software
• Harnessing AI for advanced software engineering
• Advancements in software engineering through artificial intelligence