# Scaling AI-First Engineering in Regulated Enterprises

**Podcast:** Engineering Enablement by DX
**Published:** 2026-06-22

## Transcript

Welcome back to the Engineering Enablement Podcast.
I'm your host, Justin Riok.
This episode was recorded live at DX Annual, featuring a panel of engineering and product leaders from some of the largest regulated enterprises in the world.
We were joined by Nidhi Alpiram from Nationwide, Jay Schniep from Comcast, Brent Foster from TD Bank, and Praveena Pachipilusu from Hewlett Packard Enterprises, with the conversation moderated by Rebecca Fitzhugh, who is a lead principal engineer at Atlassian.
In this session, they talk what it takes to drive AI-first work inside large, complex, regulated organizations, where moving fast can't come at the cost of compliance, security, or trust.
They discuss how Nationwide is scaling an AI-assisted development lifecycle across more than 400 agile teams, why reinventing the SDLC matters more than just bolting AI onto existing processes, and how the role of the engineer is fundamentally broadening into what the panel calls compound engineering.
Let's get into it.
Our next session is going to be a panel featuring leaders from Nationwide, Comcast, TD Bank, and Hewlett Packard Enterprises.
They're all going to be speaking about what it means to drive AI-first work in large enterprises and regulated industries.
Moderating the conversation is Rebecca Fitzhugh, Lead Principal Engineer at Atlassian.
And I know they all have a lot to share, so let's go ahead and welcome them up.
Please welcome Rebecca Nidhi Alapuram, Jay Schneip, Brent Foster, and Praveena Pachapalusu.
Hello, everybody.
We are so excited to be joining you.
We are what is holding you between lunch.
So you're welcome.
But as you've been hearing today, AI is not just this future thing anymore.
It's something that we're applying every single day to our daily work.
But that's even harder in very large, complex organizations.
So the question doesn't become how do we adopt AI and how do we go faster?
But also how do we do that without breaking everything and potentially losing things like our...
compliance certifications in the process.
So I'm extremely excited to be joined by leaders from across a number of very complex organizations.
So today we have on the far left, well, to you, right?
Okay.
We have Brent from TD Bank.
We have Jay from Comcast.
We have Praveena from HPE, and we have Nidhi from Nationwide.
So to get started, each of you...
leads a pretty large, complex engineering organization.
How far along are you on that journey?
Can we start with you, Brent?
Sure.
Can we do maybe a slight tangent first?
Or why not?
What day is it?
Is it Thursday?
Thursday.
It might be thankful Thursday.
I just wanted to take a quick moment.
So Danny and Jake over there, they made DX happen for us.
So let's give them a round.
Yeah, made it happen.
And I saw Nick and Molly.
I see Nick over there and the DX crew.
Great partners.
Thank you.
So, sorry, what was the question again?
This will be the only question that Brent gets.
You lead a large engineering organization, complex.
How far along are you in the AI journey?
Oh, well, I think you've heard it from every speaker here.
We're all figuring it out as we go, right?
What's that analogy?
Like building the airplane while you're falling out of the sky or whatever?
That's what's happening.
So I think every day, and I think Tim said it best from Microsoft, like it's the learning and experimentation.
So the quicker you can learn, the quicker you can adapt, and you can feed that right back into what you're doing.
the better off we are.
So we're really trying to figure out how can we tighten that feedback loop and learn and grow as quickly as possible.
But we've rolled out some agents.
We've got like some mortgage adjudication happening, which is pretty neat.
But scaling something like that in that sort of a space, like, you know, it's a little bit easier.
How do you do it everywhere?
What, you know, where do the deterministic like decisions you have to make?
Where can you let them loose?
Figuring that out as we go.
Excellent.
Jay, what about you?
Well, I don't run an engineering organization.
I run a product organization within DevEx.
So it's a little bit different, but a lot of the same.
You have to be talking to your users.
You have to understand what they're looking for and where we are in the journey.
I don't know where we end.
You know, I think Jen made some great points today earlier in her session around this is an inflection point.
I don't see this as a major change yet.
We've been through this already as technologists.
And so how do we make sure that our users are there with us and we're continuing to ask them, what do they need?
How do we help?
And that's whether or not you're talking to your subscribers at Comcast or you're talking to your engineers as a DevEx organization.
We have to be in the front of our users and saying, what do you need?
How do we help?
Excellent.
I do want to kind of shift the question a little bit.
So we keep hearing today about this being this massive shift, this massive change in how we're doing software engineering, how we're running our organizations and so on.
So I'm curious, how are you talking about it?
with your peers, with your company, with your teams.
Praveen, I would love to start with you.
Yeah, I think, you know, Jay and he went before me, but then basically there is no other topic nowadays.
I think that's the only topic at top of everybody's mind.
Doesn't matter.
It's your team members.
It's your peers, peers at other companies within the company, right?
So...
Everybody is using AI.
It just depends on what the use cases are.
I think most of the companies have like 20 to 40% around using AI, but a lot of it is code generation for sure, but then maybe in a smaller areas.
And then as you see, maybe it's more production level or, you know, fully blown modules or functions, you know, it's a little bit less.
And then as you go to the production level, customer facing, you know, that will be even less, right?
So I think we are just figuring it out how much and which type of application you're starting to use AI and then fail fast, right?
And then also validation of those AI outputs and then relearning into the agents is very critical.
So I think...
As we go along, we'll figure out, but I think that's where industry is kind of moving.
Most of the companies have adopted.
It just depends on the team size, the functions, and then, you know, what are the applications, the workloads, and where you are starting to use them.
Nidhi, I completely skipped you.
That's okay.
So I did that on purpose a little bit, right?
Because one of the things as we were talking, you gave us a little bit of information about this AI-assisted development lifecycle that is being rolled out across nationwide, right?
And my understanding, this is across hundreds of teams at this point.
So I'm very curious, like, walk me through that.
Where did you decide to start first?
And where are you now?
Okay, sure.
Before I start, first of all, it's a pleasure and an honor to be part of this amazing panel.
Looking forward to learn from this panel, too.
So before we dive in, a quick fun fact I want to share with the group.
For those who don't know, Nationwide is headquartered in Columbus, Ohio.
And the fun fact is we are celebrating our 100-year anniversary this week.
So pretty excited about it.
So with that, first of all, I'll answer our journey a little bit.
At Nationwide, AI is just not a tool on top of SDLC.
We are reimagining how we do SDLC mode to be more AI first.
So from the very first line of the requirement to the last line of code.
So again, from a mental model, it's very simple.
We want AI to be the trusted team made for our engineers.
So our engineers are not thinking about AI when they are stuck, but they're starting off with AI.
So back to the journey of how we started.
Early in 2024, we started with some AI tools, just doing prototyping, or sorry, piloting, testing, more in building code, more in the code assist space.
And we saw great efficiency and productivity.
In 2025, what we did is we did a focused 10-week experiment across a handful of teams.
And what we, as the teams, as we provided first, we provided a handful of AI tools that they should be leveraging across SDLC.
When we say across SDLC, from elaborating requirements to design, to develop, to do code reviews, to do testing.
So through that experiment, in that 10 weeks, what we have learned is it was less about the tools.
They said that the tool that we...
brought in in 2024 and scaled across, that was good enough to do what we are asking them to do across SDLC.
But what they said, which was very profound, was giving them the training, the time to upskill, and getting that air cover to go slow before they speed up was key.
So they said...
give us that and we are actually seeing productivity instead of just saying go use AI.
So that was what gave the insights for us to start off a AI flagship effort across the, so we have about 400 plus agile lines.
So we said we are going to scale it across and we started this early January.
in different phases.
The goal is to get all 400 lines on AIDLC by end of August.
It's definitely an aggressive timeline, but we are seeing...
good feedback.
We are hearing from teams good feedback because we are giving them the training material, the training, the playbooks.
We are providing them embedded coaches.
We are giving them accelerators.
So that itself is helping them to take time, upscale, and use AI.
And the big thing is we are providing guidelines, guardrails, and putting some governance around it.
I love that.
That really resonates with me.
I think...
we're going through a similar journey where we are reinventing the SDLC and that's how we're talking about it, right?
Because for us, we've already made it AI powered, but that's more of a bolt on.
It's not really changing the way we fundamentally think or work.
And a lot of this transformation I think requires a pretty strong product sense.
So I'm curious, Jay, from your point of view, how are you approaching this reinvention of the SDLC?
Yeah, for us, it's really looking at the entire journey end to end.
And it's also looking at the DevEx platforms themselves.
Can you reliably consume AI if you're not in a consistent journey with your development process?
And so still making sure that our teams are in the tools that we're investing in, are running on the platforms that we want them to use.
and then adding AI to that.
And you can't just add AI or agentic at the coding standpoint.
You have to be thinking about product.
You have to be thinking about your usability perspective.
You know, we've talked about code reviews and the second part before you deploy.
It's that end-to-end journey or else you're just going to create more bottlenecks.
So we're really looking at how do we make our product managers more efficient and effective in the early discovery time?
Because historically, that discovery phase of the SDLC is 50% of the time it takes.
get something into production.
So it was never about the code.
It's about everything that exists on either side of it.
And so we're really leaning into what do our product managers need in the business?
What do our usability teams need?
How do our developers want to interact and work with those teams to gather those requirements and bring them in?
And then making sure at the end that we're actually delivering outcomes.
Because if we're not delivering what we expected, we're just creating more inventory.
And that's not something we want to continue to manage going forward.
Very interesting.
Were you about to add something?
No, that is here.
I just want to make sure I align with that.
Yeah.
So whenever you are introducing AI into some sort of an established delivery process, how do you decide what you keep and what you redesign?
I'm going to start with you, Jay, because I feel like that's a natural place where you left off.
Sure.
Praveen, I'd love for you to jump in.
Yeah, I think it's really important to think about the fact that as humans, we're still responsible for the risk and everything we deliver.
regardless of who wrote the code, we are still responsible.
So at what point throughout that journey do you need a person to look at something, approve something, move it forward?
I don't want to use actually, I don't want to use the word approve because it's not really about approve.
It's about validating what's out there and making sure that it's meeting the right expectations.
So for me, it's about understanding the role that product now plays further into the journey, the role developers play.
further to the left?
How do we get security further to the left?
And really start to talk about it as that code function, that middle gooeyness, we're all right there now.
You know, there isn't, you know, those definitive lines that we've had before.
And so how do we bring us all together at that point to move things forward?
Yeah.
That's a professional gooeyness in the middle.
That's like the- I like that.
Like a cookie.
The cookie, yeah.
The gooey middle, yeah.
Yeah, I want to just- actually convey the same.
I think shifting left, right?
I think we all are doing even security left, like quality left, shift left, right?
But then now with AI intermixed, we want to like double down on it, right?
Like policy driven, maybe templates, which are more secure because now not just the code, but even infrastructure, AI is writing the infrastructure, like Terraform, YAML, right?
But then...
it may be more permissive IAM roles, right?
That can maybe expose your infrastructure.
So how can you have policy-driven secure guardrails?
Then the AI-generated infrastructure needs to be validated against these policy-driven guardrails before it's deployed, right?
So like not just the code, but also infrastructure.
And then what developers are doing is like, you know, inadvertently, like asking something.
the other agents which are not approved by the enterprise.
So you're like, you know, opening up, right?
So how can you put some edge, like security at the edge so that not inadvertently our code base is exposed, right?
So that's the other thing.
And then even for some security questions, they ask like, oh, how can I?
secure, you know, how can I remediate?
For those questions also, it has to be really a boundary, right?
One is your internal boundary, one is at your company level edge boundary, right?
So those are like different levels of security and vulnerability, right?
But it is definitely helping, I think, because it used to take for debugging for, you know, how do I fix this?
There is a vulnerability, how do I fix it, right?
But now...
Agents are actually telling you how to fix it.
You can make a judgment call if you want to accept or deny, right?
So it's definitely improving, but then you still need to make certain guardrails.
And that judgment is super important because none of us want to be the first company litigated because of AI.
Literally no one in this room wants that.
No one in the world.
So, yeah.
I'll touch on two points here.
Again, great points you both made.
For my harness engineering, back to what you were saying, you have to build the harness in such a way.
that again, AI is very non-deterministic.
It's building the code based on the code that's already out there with vulnerabilities.
So how do we make sure that we are not building new code with more vulnerabilities, right?
So the big thing that we are focused on, how are we building that strong harness?
And the other thing which you mentioned about human in the loop or being accountable, I like to say human at the helm is what I like.
And no matter who is typing the code, the human is always the accountable person for the outcome.
So that's the two big things that we are focusing on.
Interesting.
So I think we're starting to kind of touch on security a little bit, compliance.
Brent, you lead architecture at a bank.
I can't help but ask this question of like, how are you even deciding where you apply AI and what should still be human-led today?
Yeah, that's a good one.
Well, first off, because I was thinking about your 100 years.
I found out on my flight over here, United Airlines been around for 100 years, too.
Oh, wow.
American, too.
Oh, wow.
Yeah, yeah.
We're all getting old.
We've been around for 170-something years.
So we've seen a few things.
So I guess there's a few things there.
So a couple things to keep in mind.
One, and I heard accountability from each of you, you cannot delegate accountability.
And that doesn't change with AI agents, doesn't change in your life.
you're accountable.
So there's kind of two different realms you could kind of divide this into.
First is, what are those deterministic decisions?
And if you look at the SDLC, those are kind of good little break points like, oh, am I planning, building, testing?
If I released it, am I maintaining it?
Those are kind of natural decision points, and those are very deterministic.
And as a bank and as a G-Sib, you heard Jason mention this.
And by the way, Jason, I'm on board.
We're doing a yes day.
We're saying yes.
But you can say yes if you actually bake in security into the fabric of everything you do.
You build in those guardrails, you do it right.
And so from an agent perspective, I'm a big fan of GitHub's spec kit.
Has anyone played with it?
Okay, so you define a constitution, you get a spec, and all of a sudden you can start to consistently drive execution.
But you need to wrap it in some sort of deterministic situation.
That's a strange word to say.
So basically, if you look at it from that lens, anything deterministic, anything where there's a decision, the human should be a part of that.
The human should drive it.
If it's execution, it's kind of the mundane, like, hey, go write this unit test for me.
Go run that test harness, that regression test suite.
Let it run, but do it in some sort of context where...
Maybe you've got a PR, you've got a merge request you're reviewing, and that's your gate.
But I think that's kind of how I look at it.
Makes perfect sense.
We've been talking a bit about regulated industries and some of the guardrails that we need to put in place to ultimately ensure safety.
But I'd like us to actually maybe shift for a second away from delivery dynamics and discuss maybe what's changing for the engineer on the day-to-day.
how are you keeping pace with the needs of the developers, right?
Because their needs are changing right now, but also we're fundamentally shifting from the developer being the construction worker to being more of the foreman, right?
Which also means that we as tool builders have to build our tools a little bit differently to suit that.
So maybe Nidhi, let's start with you.
So...
I feel like the AI is taking over the boilerplate, right?
So with that from engineers, what is expected or what...
what we want.
I think, I don't know who mentioned this.
I think maybe it was Jen who was mentioning that as roles are changing, we need to give them what is expected of their role, right?
So with AI taking the boilerplate, engineers are more expected to be that design thinking, should have that design thinking, system thinking capabilities.
The go forward or where I see this engineer's expectations would be that they are orchestrating humans.
agents and platforms with just using AI, this is where the skills are what we see for the engineers.
I can add a little bit.
Basically, it's not just one job anymore.
We used to hire for, hey, do this job, QA, test, development, or design, and UX.
I think those lines are getting a little bit blurry.
You want somebody, now we see fewer teams doing most of the jobs because you know the mundane repetitive task like you know he was mentioning is done automatically so now you can actually expand right so you can do UX, little bit of UI product, and then tell what to do to the agents, right?
So that part has become easier, but then you have kind of expanded and then you're the decision maker who is validating, who is making that judgment call.
At the end of the day, the team is still responsible and accountable for what the outcome is going to be.
But to tell this is the intent and is the outcome exactly the same as the intent, that's the job of that engineer or that skill set, right?
So it's a little bit of...
taking a broader role, right, for each of those engineers.
That's kind of, along with the system design architecture, all that has to be done by the humans.
It's compound engineering.
Compound engineering.
There we go.
You found the right place.
That's it.
That's it.
As you can tell, we made a lot of bets with each other.
Get certain keywords in.
So that was our first one.
We're very excited.
That's probably on poly markets or somewhere.
You know, if anyone bet on that.
If I can just also the decision making piece, I think that's something that's going to be measurable for us going forward.
How quickly are we making decisions and moving things forward?
I feel like especially in large enterprises, we get really hung up on whose decision is this?
And rather than worrying about the right person is making the decision, are the right people in the room?
Are we empowered to make the decision on behalf of this piece of code, this outcome that we're looking for?
And then how do we learn if the decision wasn't right?
You know, if we have the right guardrails in place.
and we've shifted left from security, what's the biggest risk?
We've created something that no one wants to use.
Okay, then how do we take it back out of the environment and build something better?
But getting it out there and getting that empowerment for our teams to be able to move stuff forward is going to be critical because we've got to cut the red tape that we've created around ourselves in the last 30 years.
That's it.
173 years, right?
You heard Abhi and Brian.
So that 14%, who wants to just live in that 14%?
That is my favorite 14%.
But guess what?
We want to go, like, fix those bottlenecks.
We want to move upstream.
We want to move downstream.
We can do it.
I think we can do it.
Yeah.
But you're hitting on, I think, a very important point, right?
So we just mentioned this idea that the role of the engineer is broadening and also generalizing to some extent.
And then we heard this morning in the panel that Avi led around, you know, with our CTOs, they were talking about, like, designers are landing code and PMs.
So this definition of who is a developer doesn't matter.
It's who is the builder who has that maker mindset, right, was one of my big takeaways this morning.
So then that begs this question in my head of, what is a good developer experience in this era?
Because the one thing I'll share with you is I had my worst nightmare meeting on Monday.
I was explaining linting rules to a designer.
Nice.
And then I had to explain CI.
And then I went, what am I doing?
Right?
I had this moment where I was like, do they need to know that?
So I'm curious, what is a good developer experience now?
Maybe Brent, I'll start with you.
And I would love to actually just kind of go down the row on this one.
Well, that, and guess what?
we also care about the agent experience now too, right?
Well, I think one, it's a breaking people out of their silos.
So where before maybe, maybe the designers lived in Figma and engineers are in GitHub or VS code and, and then the project and program or the product that they're in JIRA, like break on all those barriers down, bring people together.
But I think part of it is like, and you heard it, I think Nancy was talking about it.
Like, Spend that energy building those harnesses in such a way that you remove those barriers.
You remove that friction.
You can basically say, yeah, come on in.
You know, go take your Figma mock up and go put it in the prod.
Just run it through this first.
Run it through that pipeline.
Compose it together in the appropriate way.
You're going to be fine.
But I think what a great time to have everyone, like, experience that.
You know, you get in that state of flow.
You're working on something.
You're enjoying it.
Now everyone can see that and you can actually get the outcome.
You can actually see your work reach the end.
You don't have to stop wherever your barriers were before.
You can go all the way, which is super cool.
Yeah.
I think about it a little bit differently from the standpoint of not everyone's going to make it.
And I'll say that as a challenge to all of us.
And, you know, again, I think, Jen, you are the.
Great session this morning.
Really thinking about that change management piece.
And some folks are just not there.
They're operators.
They've been operators their entire career.
That's what they want to do.
That's what they want to be good at.
Good.
How do we make sure that they have a place still?
Because we still need operators out there checking that work of the AI that's, you know, on that, if you want to shift left, shift down, you know, that kind of underlying KTLO effort and things like that.
So for me, it's about getting the right team of people together who want to work in the same way.
and moving them through the journey.
So where do the operators want to sit?
Where do those smaller, and I agree with the panel earlier this week or earlier this morning, you know, smaller teams delivering an outcome together collaboratively all the way through.
That's where we are because we can't continue to say that like, oh, PMs are going to prototype.
We've been prototyping with paper.
Like this is not new to us.
Now you just gave us a tool like Replit and Figma to do it with.
So I think also it's about, A lot of this isn't change as much as enablement of better tooling, better systems in a way for us to collaborate together.
Yeah.
I'll quickly add, I know you probably want to, it's basically enabling.
I feel like, you know, we are, because of the agents and AI, it's enabling to learn more quicker, but also to, I think Jennifer mentioned, psychological safety, right?
If you provide psychological safety, then every individual will be like, it's okay, let me learn.
And I have...
you know, the air cover and let me fail at it or maybe move forward, right?
If you create the operators can create the agents to make your life easy, but also somebody else to learn that area, right?
So I think it's kind of coming closer with the agents and also providing that air cover so that I can fail fast and move forward.
Just to add to what is developer experience now in this world, in this era, right?
In the past, we were trying to remove friction.
I think now it's more creating a trusted workflow to our engineers.
So how do you go from ideate to a prototype to go to market?
Again, before it was months.
Now can we go from months to weeks to days?
I think that...
is going to be the experience that they're going to have.
Again, when we are providing them to tools or refraining them from not using something, giving them the clear understanding back to helping them understand why they're expected to use a certain tool versus another one is what we have to be explicit for their experience.
Makes sense.
I know this morning they said...
They're not planning to, by they I mean our CTOs that were on stage this morning, they were talking about not planning too far in the future.
They were saying a quarter at a time, a quarter at a time.
I'm not going to heed their advice, okay?
I want us to fast forward to 2030, okay?
So the year 2030, by the way, I want to consider this our spicy hot take round.
Let's open it up.
You're making me hungry.
I know.
Oh, that was the second reference, perfect.
Are we going to need...
fewer engineers or just different engineers?
Praveena, start with you.
Yeah, kind of sort of little bit answered, right?
So I think it will be fewer, but then also it will be different, right?
Because the skill sets like we just talked about, if you are pure coder or, you know, purely like one skill set, that probably won't fly that much, right?
So you probably want to have a...
broader skill set, right?
That you gain over period or learn.
So, you know, who is designing?
Designing is very important.
And intent-based outcome.
How do you tell the agent that this is what I want and this is my intent, right?
So that definition of it and designing specifications and architecture is very crucial because the easy tasks the agent is going to do for you, right?
But then telling it exactly, you know, this is and how...
Quickly, we can reach there, but with the guardrails, right?
So the guardrails are also equally important.
You cannot open up yourself to vulnerabilities.
So putting that quality, security, mindset, and guardrails compliance, but also having varied skill set will definitely, like 2030, I think that's where it will probably land.
Yeah, I know you've been doing a lot of thinking about 2030 engineer.
I can't wait for your take.
Well, I have thought about the engineer and thinking about the entire persona and the journey of DevEx.
I agree, skills are changing and we need to be ready to train and help folks adapt to that.
You know, the people who are going to be strongest in this.
as we move forward are those that can have critical thinking skills, the folks that can bring others along with them.
That idea of getting work done through others as leaders, we now need to train our engineers on how to do that with agents and the rest of the teams that they work with.
My hot take on this one, and this is a great debate on LinkedIn, is we're going to need more product managers and UXers who are working with our users.
regardless if you're managing a DevEx organization, you're, you know, a B2C, B2B company, being able to engage with your users is super important.
And I do not believe that that's something we should give up to AI.
We need to have those conversations.
We need to make it qualitative and quantitative, but we really need to lean into those.
that listening and closing that loop on the things that we build.
So everything we build is not going to be successful and we need to be ruthless about taking things out of our environment that just cause waste.
because AI is giving us this opportunity to build so much more so much faster.
But that doesn't necessarily mean it's good.
And it doesn't necessarily mean it's giving value back to the business.
And so that finalizing that loop around, did this work the way that we expected?
Did people adopt it?
And if they didn't, what are we missing from a functionality standpoint?
Or did we just miss the boat completely?
And what's great about AI is that we can move more quickly through that phase, but we can't overlook the idea that just because something went into production means that it's valuable because it absolutely doesn't.
I'm curious, Nathie, what percentage of code do you think will be written by AI?
Again, it's hard to tell how it's going to be a year from now, but 2030, I would say probably still 70 to 80 percent is going to be AI and we would still need humans to, especially when you're a regulated organization and have a lot of compliance needs with banking and all of that.
I think you need that.
Regardless of, again, who is typing the code, the human is owning the outcome of it and is accountable for it.
All right.
I was just taking a look.
But I think code becomes more ephemeral.
It's kind of like you're talking about YAML and infrastructure as code.
This is, you know, cloud native software becomes more ephemeral.
I think you're doing the same thing for code.
It's actually fun, fun side tangent here.
I was thinking about context.
So my father-in-law recently retired.
I've noticed on his bookshelf, he's got all these engineering notebooks from like decades of work.
How much knowledge is trapped in those notebooks that will never be useful context to anyone else because it's just in a notebook?
That's a problem like everywhere.
And it doesn't even have to be a notebook.
It's like maybe it's in a Confluence wiki.
You got a diagram in Visio.
Like we got to break all this loose.
Like that's what I'm thinking about for 2030.
Like we've got to like free up all this knowledge that is sitting all around us.
We've got to make it useful.
How are we going to do that in the next few years?
Well, the context becomes super powerful, but also super dangerous.
Because all of a sudden you're putting context to things and now the machines are deciding how that's all coming together.
And you're like, oh, we never thought about it like that, right?
And not to double down on the mythos scenario from earlier this week, but was it a PR stunt?
Is it real?
Whatever it is, stuff is going to get out.
And so as very regulated organizations.
Like that security, that threat modeling that we need to do is critical now because we need to put context around it, but we also need to protect it so it doesn't get out.
Indeed.
I wouldn't dare keep our lovely audience from lunch, and I see that we have five minutes left, so I'm going to give us the final question, and I would love all of you to answer.
Large.
complex organizations, right?
I think those are the key words for all of us on stage.
So for the leaders and the engineers that are in the audience today with a similar type of complexity and road ahead of them, what advice would you give them to help prepare for the year 2030?
My advice would be go understand what you have and how to codify it into specs that then agents can actually do something useful with.
Like that's, you know, you got all this brownfield after 170 years, you got a lot of brownfield.
How do I turn that into something useful today?
And the greenfield stuff is easy, but it's that brownfield stuff.
Focus on that.
I'd say lean into the creativity of it all.
Stop thinking about the tooling.
Stop thinking about the process.
How do you think differently?
How do you think creatively?
Because your AI isn't.
It's going to tell you that you're super smart and you ask all the right questions, but creatively.
It's deterministic.
I know.
Anyway, it's our creativity that's going to keep us on this stage in our roles, thinking about things differently.
So if you're not a naturally creative person, I would lean into training for critical thinking and how we think about problem solving, solving problems differently.
I need to eat.
Yeah.
Big thing is get on the board, right?
Like you have to get on the board no matter what.
And then doesn't matter what type of, you know, organization it is, what type of skill sets you have.
You have to get on the AI train.
And then, you know, it could be sooner than later, but everyone will be talking about AI, right?
So you have to get on the board.
And the fundamentals still stay though, right?
The human being is accountable and the fundamentals don't change.
Be it SDLC, be it...
AI DLC or whatever, the fundamentals don't change, right?
So just use the knowledge that you have and start using AI in your day-to-day life and it will start helping you.
For organizations that are large, I would advise is don't just say go use AI.
Build a system or a framework that will stick.
So again, things that we are doing.
along with providing the training, playbooks, all of that, we have created something called an AI champion initiative or a team where, again...
Organically, we have asked people who are interested or passionate to be part of that program.
And we continuously provide them training material.
We bring them together and get some learnings, more feedback to say how are things going, how are they using, what are the things that we can help provide more as an accelerator.
So I think having a system or a program built in will allow you to scale while sustaining the new tools, technologies that are coming in.
To wrap it up, it sounds like humans are still very much in the loop, still very much accountable for all of the code that's being generated, but guardrails and safety are becoming more and more important.
We have to find that right level of abstraction with the definition of who our makers are expanding.
Fantastic.
Are you ready for 2030?
Yeah, let's do it.
How about lunch?
We'll start with lunch.
Thank you all very much.
Ready for lunch.
Thank you.