Agentic SDLC Discussion

[karlmoll]

Raising this issue for the maintainers & Contributors ahead of the upcoming Standards Project Proposal. We have heard a lot of interest in the community around Agentic SDLC, and we want to get ahead of any pushback on this standard formation.

We are also presenting SDLC Common Controls to the FINOS AI Fund Board meeting the day before as a "related project" - to be clear, we're not positioning this as a "Agentic SDLC" initiative, per se, but we are saying that if FINOS wants to get involved in Agentic SDLC, we believe it makes sense to build on top of the foundation of SDLC Common Controls (and that SDLC is a missing piece from the existing Governance-as-Code pipeline articulated at OSFF/ ai.finos.org ).

We are getting ahead of the fact that we've heard a lot of interest in Agentic SDLC from FINOS members, and we want to make sure we're not creating competing or "re-inventing the wheel" initiatives - so any thoughts on positioning, differentiating, or framing the conversation are much appreciated!

[meekrosoft]

For me, it's pretty simple. Many of the controls we've defined are equally applicable regardless of whether a human or agent is the author. What is interesting with AI is how that can change the risk landscape (e.g. insider threat ) and what controls should be added to cover these risks.

[aaronsearle]

While I agree with the sentiment that there needs to be increased oversight or even the desire for there to be increased oversight of AI driven software development and it's deliverables, this is something we have been discussing at these meeting as well as some of the associated meet-ups around it. However; we always come back to the fact these are just guardrails, we already aim to provide a set of guardrails to steer a community towards not just improved quality but being able to evidence those requirements....developers.

So I don't see a huge difference, controls apply to the artefacts not the person typically and they still will apply to agentic or ai assisted development, just like it would to any other code generation.

Where I do see the shift is:

• Automation - It is now a volume game, we could not keep pace by using manual oversight alone yesterday, we certainly cannot today.
• Breadth - AI allows us to expand the scope of the traditional SDLC guard rail/control toolset. Areas such as architectural drift, legal compliance and quality assessment become something that can be partially or fully automated as a form of supervision give confidence that what is being delivered remains on track.
• Scope - SDLC Controls are often expressed in a way that defers accountability down the chain for qualitative checks; there is a potential shift taking place where the platform itself takes responsibility. We have seen this with the shift to automation already where the controls platform takes responsibility for a degree of the underlying quality. This I can see growing.

[AlexKantor87]

I agree with the comments so far and also don't see any distinction, BUT, I believe there does need to be work to bring a layer of clarity and specificity to companies existing SDLC controls.

for instance - right now - most companies do not specify in their code review controls that the reviewer "must review every single line of code that has changed" instead they will say "review the code change" or something similar. Whilst these two sentences to Humans are pretty much the same thing one has a greater clarity in instruction compared to the other. Without this - AI has been known to skip over reviewing files whilst completing a review.

There's definitely a conversation to be had, but it should be around the same controls but with a step change in granularity of requirements.

[robmoffat]

@karlmoll and I were discussing this last week and I just wanted to chip in with the points I made to Karl then:

• While I completely agree with @meekrosoft, there's significant marketing value in positioning what you're doing as being relevant in the agentic space. You might attract more collaborators / users if you at least address this relationship
• I also agree with @aaronsearle - sometimes, although the threats don't change, as the volume or size of them changes, that totally changes the kind of response. I think the reason an SDLC standard is relevant now is that we are seeing just this kind of volume change. So for me this is about "future proofing" SDLC as much as trying to standardise what's come before.