The Next Wave of AI in the Software Development Lifecycle

Even a few months ago, the developer conversation focused on how many people had adopted coding copilots and how often they accepted their suggestions. Today, the options have expanded. Teams can evaluate AI by the percentage of the codebase that agents produce and by how quickly they can ship features. The line has moved from code completion to usage across the full software development lifecycle (SDLC).

In an arena like software for asset management, that shift to agentic capabilities has very high stakes. We see it on our own engineering teams as well as those of the clients we support.

Moving the line

The first wave of AI in software development was about individual developers. Copilot tools could sit inside the Integrated Development Environment (IDE) and offer inline suggestions to help complete long lines or finish their thought. They let developers either accept the suggestion or keep typing with one keystroke. As early as November 2024, 84% of developers reported regular use of AI assistants for generating and summarizing code across a broad sample.ⁱ

That interaction has become increasingly agentic. A coding agent can take a feature request from the developer and return a well-scaffolded module. Google’s Agent Smith, for example, can plan and execute workflows autonomously, a meaningful step beyond suggesting code for a developer to accept or reject.ⁱⁱ Inside our own engineering, a significant percentage of the code we ship now originates from agents. Agents can also run the tests they wrote against the developer’s own machine and fix bugs in corners of the codebase the developer has never read.

With coding compressed into a fraction of the lifecycle, other elements of the SDLC become more visible. Before writing code, product and engineering go through multiple rounds of revision of the requirements document, and the developer can’t start writing until the spec settles. After writing code, a completed module can sit idle in the queue while the adjacent team finishes the API contract it depends on.

Once teams move beyond coding efficiency improvements, what they measure shifts. Adoption counts only tell you how many people have a coding agent turned on. What matters is how much code agents contribute to what a company actually ships.

Contribution Metrics

• Commits to production
• Code review passes
• Defect reduction
• Volume of merge requests

The trust gaps that emerge

The first gap emerges because code that satisfies the spec can still produce the wrong answer in production.

Imagine you want to enhance a feature that updates a portfolio’s cash balance when a trade settles. The coding agent can write both code and tests that reflect the patterns it has seen most often. But if a multicurrency trade arrives and the FX timing convention isn’t in the spec or the test set, the code might apply the trade-date rate instead of the settlement-date rate. The cash balance ends up off by the FX move between the two days. It’s doing what it was written to do, and the issue is elsewhere in the SDLC.

A second gap opens at code review. In a traditional SDLC, someone reviewing code usually had hands-on experience with changes before the merge request, either as the developer who wrote it or as a colleague who discussed the approach. That engagement gave them enough context to assess the diff with intent in mind. When an agent writes the code instead, the change reaches the reviewer as an opaque diff. The reviewer has to reconstruct why the code looks the way it does, often guided by inline comments the agent left in the file. Using the agent’s narration of code that the agent itself wrote becomes circular.

The same dynamic plays out across every SDLC handoff with AI agents in the mix. At every step, the person passing the artifact along didn’t produce it themselves. The product team might use an agent to write a spec. Then an engineer codes with an agent and passes it to QA without fully understanding it line by line. The PRD itself may have gone through several agent-mediated iterations between product and engineering before the engineer ever touched the code. If a defect appears in production, no single human in the chain authored the layer where it originated, which dilutes responsibility.

The reviewer’s scaling problem

Our team at Arcesium sees ~300 merge requests pass through automated review every day, and each one lands on a human reviewer’s queue.

Agents also create review comments on each merge request, multiplying the volume for humans further. A single change might carry five to ten agent-generated comments, which the reviewer has to evaluate to decide whether they are real issues or false alarms. Rather than reading every comment carefully, reviewers scan for those that catch something they wouldn’t have noticed on their own. Volume itself has become a real problem because past a certain threshold, the agents’ comments turn into noise.

As agentic features become more embedded, senior reviewers are now deploying agents of their own. Each code reviewer’s personal agent reads each incoming agent comment, checks it against the actual code change, and tags it as worth the reviewer’s attention or not. Those agents learn from the reviewer by capturing review actions in the background. When the reviewer dismisses a comment, the agent that originally posted it adjusts and flags fewer issues like it next time.

Closing the documentation loop

Automation paired with feedback from human judgment shows up in code documentation, too. Documentation used to help the next engineer who touches the code. It now helps agents as well, since agents reading a codebase rely on the documentation to orient themselves. AI writing documentation alongside the code it generates keeps the two in sync at the moment of shipping. That alignment matters because when documentation drifts from the code, the next reader, whether a human or another agent, gets pointed in the wrong direction.

But AI can produce far more documentation than human teams used to. The agent’s comments capture what the code does, but don’t always reflect human discretion on which decisions deserve explanation and why. At the same time, humans don’t have time to keep up with documentation the way they did when they were writing all the code themselves. Some people would argue that it’s always been a weakness in software development. Automation hooks can update documentation automatically whenever any change lands in the code, AI-written or human. A second feedback loop can be integrated into the automation that improves what gets documented as reviewers act on it.

Where domain knowledge sits

Investment management has a high bar for domain awareness. Data models need to represent how trades actually flow and settle, and how asset classes behave under specific business events. The reality can differ from textbook accounting. Coding agents need to internalize that data model. Engineers reviewing what the agents produce need that same depth, because the platform’s domain awareness only translates into reliable behavior when humans can verify it.

Verifying that the agent has actually absorbed the domain is harder than installing it. A new release has to demonstrate behavior on the kinds of inputs the business actually encounters, not just textbook cases. Through test data and regression suites generated from the same proprietary data model, teams close that verification gap. Without them, a team can install all the skills marketplaces it wants and still ship code that behaves incorrectly the first time it meets a real edge case.

Every gap described here — from spec to handoff to review to documentation to domain depth — is a trust gap. Closing them is a matter of making explicit what the old workflow provided automatically. As AI’s role in software development expands, each new capability will affect the trust boundary. Engineering past those boundaries comes down to specific practices across the lifecycle:

• Build platforms that absorb new agent capabilities as they arrive, through skills marketplaces and integration layers that don’t require rebuilding the stack each time a new capability lands.
• Treat every handoff as a place where the implicit trust the old workflow provided has to be engineered back in deliberately, not assumed.
• Deploy reviewer-side agents to triage the comment volume upstream agents produce, so the human reviewer’s queue stays manageable, and attention goes to what only humans can catch.
• Pair documentation hooks that keep artifacts in sync as code changes with feedback loops that route reviewer judgments back into the system.
• Embed semantic understanding of the data model into the agent at the foundation level, so its reasoning operates on operational reality rather than on generic patterns from a public codebase.

The teams that build these practices in parallel ship code that behaves the way the business needs. The ones that don’t have to explain why later.