AI isn't a horizon event for engineering teams. It's already here. Rewriting how software gets built, how teams are structured and what it means to be a great engineer. The question isn't whether to adapt. It's how fast and how well.
During our most recent event, hosted in partnership with Schroders Investment Management, we brought together five of the most senior women in technology for an honest, unscripted conversation about exactly what they're seeing in their organisations now.
The voices in the room included:
- Kalpana Chari - Head of Public Markets Technology, Schroders (panel host)
- Selina Pavan - Ex-Global Markets Technology
- Lucia Pino-Garcia - Chief Technology Officer, Ninety One
- Lisa Heneghan - Global Chief Digital Officer, KPMG
The room was full, the conversation was frank and the audience didn't hold back. What follows are the questions asked live on the night and what the panel had to say in response.
What leadership skills matter most as engineering becomes AI-driven?
This was the top-voted question of the evening, and the panel's answer was consistent, even if they each arrived at it differently.
Empathy, collaboration, and the willingness to bring people with you came through as the defining leadership traits for this moment. Not because the technical stakes have lowered (they haven't) but because the pace and scale of structural change inside organisations means the human side of leadership has never mattered more.
The panel was clear that the gap most organisations need to close isn't a technology gap. It's a people one. Business and technology teams that have historically operated in separate worlds are now being asked to work in fundamentally different ways, and that shift doesn't happen without leaders who model it first.
"If we don't display, from a leadership perspective, the openness to do that, it will never happen within our teams."
What came through just as strongly was empathy for the people living through that change, engineers whose roles are shifting, team structures that are being redesigned and a broader workforce being asked to adapt faster than most organisations have ever moved before.
"Change is really difficult. Technology change, we know, is difficult, but people changing their roles, the team structure changing; that's quite scary for folks. As a leader, bring them with you, give them a little bit of patience for things to sink in, and give them the reason why."
And underneath both, a consistent insistence that human connection remains what people trust above everything else. As AI takes on more of the work, the leaders who stay visible, available and genuinely curious about their people will be the ones who bring teams through it.
What does a high-performing engineer look like now, and in two to three years?
The panel pushed back hard on a definition of engineering excellence that the industry has clung to for too long: the idea that the best engineers are the ones who ship the most code, the fastest.
That model, the panel argued, has always been too narrow. And in the age of AI, it becomes actively misleading.
What separates a great engineer now is the ability to think at system level, to hold domain knowledge, architectural context, and business understanding simultaneously, and to apply judgment at the point where it matters most. The panel named this the expert generalist: someone who can go deep, but who also understands the end-to-end.
"The stereotype of a high-performing engineer is someone who cranks out clean code very fast. But that's kind of undermining what a great engineer is overall; how they think in terms of system design, architecture, having the context, the domain experience."
Five skills surfaced as genuinely business-critical for the engineers who will thrive in this environment: judgment and decision-making; problem framing and decomposition; architecture and systems thinking; context engineering; and learning velocity. The last two generated the most discussion.
On context engineering, the panel drew a direct parallel with the early days of Agile, when teams mistakenly believed that moving fast meant abandoning documentation and standards. The same mistake, they warned, is being made now. As AI generates more of the code, the need for a strong underlying constitution - clear standards, methods, and design principles - becomes more important, not less.
"More so than ever, we absolutely do need to have what I'd call almost a strong constitution - the standards and the design, standards and methods and all of those things."
On learning velocity, the point wasn't about keeping up with every release or reading every article. It was about breadth, understanding the adjacent domains of product, platform, and operations well enough to see how they interplay and being genuinely curious about the business context beyond the codebase.
"The importance of engineering is absolutely still there. However, what we're seeing is a shift towards the real value that comes from judgment."
Are engineers still builders, or are they becoming orchestrators?
One of the liveliest exchanges of the evening came when the panel was asked whether the engineer's identity is shifting from builder to orchestrator as AI takes on more of the actual coding.
The panel's answer was a firm, collective no, but with important nuance.
Engineers are still builders. That identity hasn't changed. What has changed is what building looks like. The analogy that landed hardest in the room came from Selina Pavan: we built houses differently in the Middle Ages than we do today, but we're still builders. The tools change. The fundamental act doesn't.
What is shifting is the scale and complexity of what engineers are directing. As agentic development becomes the norm, with multiple AI instances running in parallel, generating code across different threads simultaneously, the engineering role takes on a dimension that looks less like individual coding and more like leading a team of AI workers.
"The role is not an orchestrator, but an engineer leading AI workers that are building the code."
Lucia described watching this play out in real time through something as simple as what's on an engineer's screen; the gradual shift from an IDE dominating the workspace to an AI agent taking up more and more of it, from asking for approval on every change to running in what she called "YOLO mode," to eventually spinning up multiple instances in parallel.
"At some point you're going fully agentic, you're realising you can spin lots of different instances and be coding lots of things in parallel. And that is when it gets tricky, because one day you realise you cannot keep the context of all these threads."
And that loss of context at scale is where architecture and judgment become the engineer's most important tools.
How is AI changing the SDLC and is Agile dead?
An audience member pushed directly on something many engineering teams are quietly asking: if AI is already accelerating code velocity, what happens to the delivery frameworks built around human-paced development?
The panel's view was that the bottleneck has visibly shifted. It's no longer in the coding. It's in everything that comes after: deployment, safety, quality assurance, stakeholder adoption and the increasingly important question of whether what's being built is actually the right thing to build.
"Code velocity does not equal your organisational velocity. You can have all these tools and change the code, but if your organisation is not ready to accept or modify the way they're working, that's going to be the challenge."
The conversations about Agile's future - whether its ceremonies, its cadences, and its assumptions about team size and iteration speed still hold - were already happening inside their organisations. The panel didn't declare it dead, but they were clear that a shift is coming.
"We've moved from curiosity and productivity to real structural changes across all industries, and software engineering and technology are at the leading front of that."
What the panel were equally clear on was the adoption gap. Even in organisations where people use AI tools daily, measurable business benefit remains elusive because the tools aren't yet embedded in the actual flow of work. The implication was pointed: AI adoption isn't a technology programme. It has to be a business one, owned at every level of the organisation, or the value will keep slipping through the cracks.
When should teams automate and when should they use AI?
A sharp question from the floor asked how engineering teams should decide between automation and AI, and how to avoid defaulting to the wrong one.
The answer was grounded in something more fundamental than tool selection: commercial judgment. Not every problem needs AI. In fact, reaching for AI where simple, deterministic automation would do introduces unnecessary cost and unpredictability into systems that should be reliable.
The example that crystallised it came directly from that week; a team that had proposed using generative AI to solve a problem that was, at its core, a straightforward automation task. The better question, the panel suggested, was why not use AI to build the automation instead; removing the stochastic nature of the model from a process that needs consistent, repeatable outputs.
"Agentic development allows you to do a lot of the automation that we've never got to because we just didn't have enough people, or the complexity or the prioritisation got in the way. Now you can reach more places and add more value."
But the cost dimension matters too, and it's one most organisations haven't fully confronted yet. As token costs accumulate across large teams with multiple tools running, the business case can quietly erode.
The engineers who will add the most value are the ones who can make that call well, who understand both the commercial implications of AI at scale and the technical landscape well enough to know when not to use it.
"Not every use case is a good use of AI. That puts a lot of pressure on software engineers; they're the ones who can identify where you can remove the need for GenAI entirely."
What does AI mean for junior engineers?
The structural reality the panel acknowledged is this: as AI raises the productivity ceiling for experienced engineers, organisations may find themselves needing fewer people overall, and specifically fewer at the junior end of the spectrum. The demand for depth, domain knowledge and architectural judgment is increasing. The demand for volume is not.
But the panel was equally insistent that abandoning junior pathways is not the answer. The depth that senior engineers carry has to come from somewhere. Without investing in the next generation, organisations will eventually hollow out the very expertise they're depending on.
The simplest way to explain this was done through an aviation analogy: you still need people who know how to fly the planes, even when technology does most of the flying. AI could provide the equivalent of a flight simulator, a way of building real depth and experience in a lower-stakes environment, accelerating the development of junior engineers in ways that weren't possible before.
The panel also made it clear that this isn't a problem corporations can solve alone. Smaller organisations won't have the resources to build those pathways. The responsibility is shared between businesses, governments, and educational institutions, and needs to be treated as a societal challenge, not just an HR one.
"Smaller companies will be poaching depth from other companies because they won't be able to afford to be building those pathways. This is a societal problem. Governments and other institutions also need to take a role."
For the junior engineers in the room, the closing message was direct: the rules aren't set yet. This moment of uncertainty is also a genuine opportunity for anyone willing to back themselves, find their niche and bring others with them.
"This is a moment in time. We don't get these moments very often. Believe in yourself. You can design the future, so why don't you go and do it?"
How are team structures really changing?
The two-pizza team rule (the idea that no team should be too large to feed with two pizzas) has long been the default benchmark for engineering team size. The panel was clear that it's now under pressure. But the implications go further than just headcount.
What's emerging is a fundamentally different model: smaller, more empowered teams with higher individual accountability; engineering managers potentially becoming individual contributors again; and the old separation between engineering, product and platform teams giving way to a more integrated, persistent capability.
The cultural difficulty of that integration was named directly. Teams that have operated in different worlds - one close to the business, one managing the infrastructure and guardrails - are being asked to work together in ways that require real cultural adjustment, not just a reorganisation chart.
"Culturally, that's hard. One team has felt very much in control and at the front of the business, and now, they're suddenly having to engage with the people who've been managing the guardrails."
Architecture is changing its role too. For years it has often sat at the side of delivery, a stage gate, a validation function. The panel argued it needs to be embedded into how teams build, not bolted on at the end. One structural capability flagged as increasingly important: forward-deployed engineering - an elite capability that creates a genuine bridge between business and platform, building into core products rather than at the edge.
How do you balance C-suite enthusiasm for AI with the reality on the ground?
The real gap isn't between senior leadership and end users; it's between the technology teams shaping solutions and the business functions that need to own their adoption.
Too many business leaders still treat AI as someone else's responsibility, the technology team's problem to embed. But technology teams can't drive adoption into parts of the business they don't understand. The people who run those functions have to own it.
The practical implication is a governance model that brings business and technology together at the point of decision, joint ownership of where AI goes and what value it's expected to deliver, rather than technology pushing solutions out to a business that hasn't been part of the conversation.
How does AI represent an opportunity for women in tech?
The traits that have sometimes been positioned as liabilities for women in professional environments - the willingness to say "I don't know", the openness to learning, the readiness to ask for help - are precisely the traits that an AI-driven world rewards.
"Openness to learning is a really positive trait that women generally have. And also the openness to actually share where you're uncomfortable or what you don't know. Those softer skills are things which I think are real opportunities for women."
In a landscape where no one can know everything, where learning velocity matters more than the appearance of certainty, and where intellectual honesty is a competitive advantage, the panel's view was clear. This moment is one women in tech should be moving toward, not waiting out.
The bottom line
What came through most clearly across the entire evening wasn't a single prediction or a neat framework. It was something more durable: a consistent, collective insistence from some of the most senior women in technology that the fundamentals of great engineering and great leadership haven't changed. They've become more important.
Judgment. Empathy. Collaboration. The ability to frame a problem before you build a solution. The willingness to keep learning when the ground keeps moving.
AI changes the speed. It doesn't change what good engineering or good leadership actually looks like.
This article draws exclusively from the live panel discussion at Engineering in the Age of AI, hosted by SGI and Schroders. Speaker quotes have been lightly edited for readability but reflect what was said on the night.
Want to watch the coding session? The recording is available here: Live Coding
