Future Visions Panel: The AI-Enabled SDLC Opportunity Report

On the panel: David Low (Chief AI Officer), Ewan Nicolson (Director of Engineering & Data), Brian Graham (Data Consulting Director), Lynsey Brownlow (Head of Design) and Morgan Kainth (Director of Strategy & Innovation).

Thank you to everyone who came. The drinks ran long, the canapés ran out, and the questions kept coming well past the allotted time, which is usually a good sign. If you were in the room, this is a chance to sit with the arguments again. If you weren’t, here’s the shape of the conversation.

The thread running through nearly every answer, from bottlenecks to boardrooms to graduate hiring, was: AI is not the variable that determines whether your software delivery improves. Your organisation is. AI just makes that fact very hard to keep ignoring.

The theory of constraints, not the tech stack

The panel’s clearest warning came early. Feed an unoptimised legacy process into an AI tool and it won’t fix the process, it will accelerate it, tickets and all. The fix isn’t more AI at the point of friction, it’s the theory of constraints, applied properly: treat the SDLC as a chain, find the weakest link, break it, then move to the next one. AI amplifies whatever behaviour is already there, good or bad. If your handovers were sloppy before, they will not become less sloppy because a model is now involved.

Make friends with governance

“I’d love to do more AI, but I’m blocked by governance” was, by the panel’s account, the single most common complaint they hear across regulated sectors. Governance teams aren’t blocking AI projects for the sake of it, they carry legitimate regulatory concerns, and the way through is to sit down with them and co-create the solution, not route around them.

Practically, that means building governance into the platform layer rather than bolting it onto the application layer. Underlying pipelines change rarely, while the software running on top of them changes constantly, so that’s where acceleration checkpoints belong: embedded early rather than inspected late.

Mindset, accountability and the end user

Governance is as much a cultural problem as a structural one. Lynsey Brownlow, our Head of Design, explained that pushing AI initiatives forward means leadership has to build an environment where teams feel a real sense of accountability and psychological safety. AI rules can be blurry by nature, and people need to feel safe making decisions inside that blurriness rather than freezing or quietly working around it.

Her point was that it’s right to step into the mindset of a governance body, but teams must never lose sight of their primary stakeholder: the end user. Whether you’re designing for internal staff or external clients, the goal is user enablement and affordability, and every step of the AI journey has to stay anchored to what that user is actually trying to achieve, not to what the technology happens to make possible.

Data realists, not data romantics

The C-suite, as our Director of Strategy & Innovation, Morgan Kainth highlighted, is not short of enthusiasm for AI. It’s short of realism. Executives are fielding a constant stream of inflated claims, and the leaders caught between that vision and the actual delivery work carry the tension of it daily.

Our Data Consulting Director, Brian Graham’s advice split two ways. First, be a data realist: define exactly what’s achievable given your current budget, timeline and skills, and treat a modest, honest payback period as a feature, not a failure. Second, win what he calls “facts and minds”: get the people who use the tools every day advocating for them because the tools genuinely make their work easier, not because a leadership deck told them to. A hundred engineers who want a tool is a far easier case to make upward than any slide.

When it comes to tech strategy execution, our Director of Engineering & Data, Ewan Nicolson has a great methodology. It goes like this:

• Get them excited: paint a clear picture of the technology’s ultimate potential.
• Get them grounded: be transparent about the difficulties, acknowledging that the real challenge isn’t the technology itself, but the organisational change management around it.
• Get them going: define the immediate, practical steps required to start extracting tangible value.

The sceptics convert faster than the optimists

Perhaps the most counterintuitive finding concerned who resists AI hardest. It isn’t the sceptics. It’s senior and lead engineers, precisely because they’re already excellent at the work being automated. Junior developers, by contrast, adopt almost immediately, because AI gives them a leg up on things they couldn’t previously do.

The panel’s read was that sceptics are actually the easier group to work with: once they realise AI removes a specific task they already dislike, they find sharp, targeted use cases fast. Enthusiasts dreaming big are harder to ground. And once senior engineers see AI stripping out the administrative grunt work, dense documentation, retrospective summaries, they convert quickly too. Both groups meet in the middle.

Hiring junior people into the toolkit

That has real implications for graduate hiring. MIT Sloan’s research into generative AI and software developers found that access to an AI coding assistant lifted junior and recently-hired developers’ output by 27 to 39%, against 8 to 13% for their more senior colleagues. IBM has drawn the same conclusion from the other direction: it’s tripling entry-level hiring in the US in 2026, on the basis that cutting junior headcount now creates a mid-level talent shortage later. 

Our Head of Design, Lynsey Brownlow and Data Consulting Director, Brian Graham emphasised that juniors act as a great organisational leveler; they lack legacy enterprise conditioning, bring fresh energy, and are highly adept at adopting new tools, experimenting, and talking about ideas and expertise publicly on social media. 

The real question is how you replace the grunt work that used to build foundational knowledge, three years of slide decks, three years of basic code modules, with structured mentorship and pair programming instead.

The path to realising gains

Some organisations successfully align their AI initiatives with long-term strategic roadmaps, while others make the mistake of simply running their legacy processes with a bit of AI tacked on, an approach that rarely yields results. 

Three moves came up again and again as the practical difference between organisations that see the 10-20% gain and those that don’t:

Measure value, not just cost. Framing AI purely as a cost-cutting exercise triggers job-security fears and resistance. Frame it as offloading humdrum work so people can spend more time on judgement and creativity, and the same initiative lands very differently.

Watch for human-in-the-loop fatigue. A human placed in the loop purely to rubber-stamp AI outputs tends to get worse at the job over time, often by quietly feeding the results into a second AI to check the first. David described an alternative used on a recent greenfield build: individual QA sub-agents check the work continuously, but a single oversight agent compiles a daily summary of every change made in the previous 24 hours. The team reviews and accepts that summary at stand-up, once, rather than reviewing code line by line. Shared context, without the fatigue.

Let the subject-matter experts write the rules. Architecture-as-code and automated guardrails can carry compliance forward automatically from one project to the next, provided it’s your subject matter experts programming those rules in the first place, not a generic policy pack.

What’s next for AI?

The panel closed by looking at what they’d add to the Report today, if they were writing a supplementary chapter to it right now. Four ideas came up.

Embracing the unlock. Organisations have to get comfortable with not knowing what’s next. A year ago the industry was fixated on code-generation hype, and today the conversation has moved to governance and cost management, and neither was as visible in the story being told eighteen months ago. David Low argued that token spend is simply the new cloud spend, and the governance frameworks that adapted to cloud will adapt again.

AI team topologies. How do organisational structures, and the “team topologies” that describe them, change once autonomous AI agents sit inside teams alongside human workers, rather than as tools those workers pick up and put down?

Agentic SDLC compliance. The focus needs to shift from rigid, one-and-done delivery pipelines toward continuous, automated compliance and testing, carried out by specialised agents throughout the lifecycle rather than checked once at the gate.

Fluidity of roles. Organisations should experiment with cross-skilled teams built entirely around problem-solving rather than rigid job titles. Intercom’s designers shipping production code is one early example of the shift, moving away from siloed development cycles towards a holistic product operating model that gives individuals end-to-end visibility, and that tends to produce better, faster decisions.

Where this leaves us in 2026

Pull the threads of the evening together and a clear message emerges. AI doesn’t introduce new problems into an organisation, it removes the option of ignoring the ones already there. Fix the real constraint rather than the visible one, bring governance in as a partner rather than a blocker, keep the end user as the anchor for every decision, and be honest with the C-suite about what a business case can and can’t promise. 

The practical moves the panel kept returning to are what turn that principle into the 10-20% compounding gain our Report sets out. 

—

If you’d like to talk through any of this against your own organisation’s SDLC, get in touch. We’re always happy to compare notes.

Download the AI-Enabled SDLC Future Visions Opportunity Report below to see the research and statistics for yourself: