# Securing AI Agents: Identity and Autonomy

**Podcast:** Engineering Enablement by DX
**Published:** 2026-09-11

## Transcript

What's interesting about how we think about an AI agent versus onboarding somebody new to the organization is that we put a lot of implicit trust into a person, that they are vetted and governed and that they have some levels of controls.
So we needed to apply some of this implicit sandboxing capability and apply it to our agent as we were designing and developing it.
Welcome to the Engineering Enablement Podcast.
I'm your host this week, Brian Hook.
Before we dive into the episode, I want to tell you about our Q2 State of AI and Engineering Report.
It looks at data from over 500 engineering organizations and examines where AI is generating measurable gains in throughput and time savings, where those gains are not translating into shipped software or improved developer experience, and what the data suggests about sustainable AI investment.
To read the full report, head over to getdx.com forward slash reports.
Welcome to the Engineering Enablement Podcast.
I'm your host, Brian Houck.
And today we have an incredibly special guest.
We are joined by Robert Lucero.
Robert is Chief Architect at Okta.
He has spent more than 15 years helping large engineering organizations build faster, more resilient, more secure software.
His work spans everything from developer productivity and engineering metrics, obviously a topic near and dear to my heart, to cloud resiliency, AI adoption, and very importantly, enterprise identity.
At Okta, he led the company's Gen AI strategy, looking at everything from driving adoption to modernizing their internal workflows and helping to prepare the world's leading identity platform provider for a future where AI agents are first-class citizens in all of our internal engineering systems.
On a personal note, Bob and I, 20 years ago, almost to the day, joined Microsoft.
at the exact same time.
We went through all of our internal training together initially and have known each other ever since.
And so I am thrilled to have him join us today.
Bob, welcome to the show.
Hi, Brian.
Thank you so much for inviting me.
Hello, everyone.
As Brian mentioned, I am Robert Lucero.
I'm a chief architect here at Okta.
I won't rehash the intro pieces, but yeah, for the last 18 months, I've been heavily involved and focused on our internal AI adoption strategy for our engineering organizations and supporting our product organizations and then aligning with our corporate team in terms of how do we enable our workforce?
And then separately, how do we plan?
plug into the product offering and solution that we're building and offering to our customers.
That way we can state what we use is what we secure.
And that's what you all can take advantage of.
Awesome.
To kick us off, I feel like I've had so many conversations lately that all end up with the sort of the idea that AI is an amplifier, but it isn't necessarily changing the fundamentals of our work.
And so, for example, it's like code review is a bottleneck.
But we've always had code review problems and AI is amplifying that.
Like testing is incredibly important and problematic.
It's always been incredibly challenging and it's just AI is amplifying that.
I am curious if identity is different though.
Like are the fundamentals actually changing?
And so as I think about it, it's like all of our identity systems are built around this notion of human identity.
But is...
enterprises are managing hundreds or thousands, maybe even millions of agents.
What about the fundamentals of identity might be changing?
So I think what's interesting about this space in terms of AI agents doing work and amplifying things, and I think this initial wave, especially when it comes to coding tasks, it can generate code.
And then when you generate code, you want to get feedback on that code.
I think this next wave and iteration of it is, how do I start getting access to additional tools and resources and information and knowledge?
And that's where identity really becomes critical.
So if you're operating as like a service account or a single AI agent, that has access to files on a disk and generates code, and maybe it can execute some local commands, that's great.
But if I need to then get access to a Google Doc with the spec information, now all of a sudden my agent identity matters, and the scope and controls and what it has access to really matters, because then it's acting beyond the kind of confines of just content generation.
It's acting in a space that's like it.
executing and reading and operating in various systems.
When we were rolling out AI agents, that was the interesting thing, which is like, that was the horizon that we saw, which is like, oh, it's cool that it can generate content, but it's immediately going to want to get information from other places and other systems that needs to be gated and controlled.
And so when I think about how AI agents are then working in this space and getting to this kind of like ideal operating that we sort of expect.
That's where identity really, really matters.
I want to govern what my agent has access to, what it can see, what it can do, and the important resources that it needs to be able to be successful.
And I don't want to grant it in the same context as like a service account, where I flip at a token, hope I vault it correctly and I have tracking on it, but it's acting with an immense set of permissions.
I want that.
policy control plane to be dynamic.
I want it to be scoped.
I want it to be notifying me if it tries to go beyond.
And I want it to start from a very safe place.
So that's super interesting to me.
And one of the things that I've been sort of diving into a lot lately is this idea that our agents are only able to do their best work if they are in an environment that provides them high quality, healthy.
context.
And I'm curious, like, you know, based on your answers, like, you know, like our identity platform is sort of like the layer that will manage what did like that context that agents are able to access.
And it's like, I'm curious, like, are these sort of new problems with agents?
Or are these like solving the age old problems that we've had for documentation with humans forever?
That's an interesting question.
I think it solves.
It solves an age-old problem around what does it mean to have an automated system be able to access something.
And again, looking at it from the lens of what Okta continues to call the identity fabric and how we think about service accounts, we've been operating in a world of automation, having overscoped tokens and getting direct API access for years.
Now, because we don't trust the automation, to work in that space successfully, that's where we're starting to get more granular and fine grained.
And it comes back to what you're trying to get to, which is, I trust my automation to only operate in a very controlled way.
AI doesn't do that.
It's very non-deterministic.
And if it gets access to things, it can discover additional information that it needs.
So that control plane that the identity layer provides via MCP and scoped roles and fine grained access or cross-app access with...
again, find great controls, means that I can govern what access these agents have in order to be successful.
Oh, totally.
So it's not even just the scale, but it's like, I mean, the non-determinism, which is what makes AI powerful, right?
Like it's creativity, so to speak.
It's like adds a layer of unpredictability, which adds a layer of risk.
And so it is sort of like a net new problem.
That's interesting.
Which also like, so that makes me like think of scale, right?
It's like we have...
You know, we have service accounts that like we have to manage their identities.
We have certainly humans.
And do you think that like it sure seems like in the foreseeable future, there will be more agent or non-human identities than human identities?
Like, do you agree with that?
And if so, like when might we expect to have that happen?
I think we're starting to see this.
play out.
And in my conversations with our go-to-market teams, with our product strategy teams, with our internal product teams and our engineers, I think we're seeing a gambit of the entire industry sort of wrestling with this.
Is every single one of my ephemeral AI workloads an independent?
identity that gets stood up and tracked?
Or are we looking at it from a system orchestrator that is a defined identity that can spawn tasks and kind of do on behalf of?
Or am I tying agent activities to either a service account level AI identity or a human-based owner?
Let's say, for example, right now, I have four coding harnesses that you could qualify as agents.
Will I register them as independent agents or are they agents that are related to me and backed by my core identity, but have an AI governance policy based on its sort of like user agents or other, some other identifier.
And I think we're trying to really reason through that.
We have customers who think that every AI.
activity, ephemeral or not, is an identity.
And we have other ones who look at it from workloads and other ones who are still taking the more service accounts approach.
And I think that this is evolving, but the product space is really trying to account for all of this as it's coming online is being imagined.
Like, as you say it, I'm like, well, of course.
I just sort of like my mental model was always like, well, of course, every agent is its own unique identity, much like every human is its own unique identity.
But those parallels act.
break down and even this notion of you know when do we spawn up sort of like armies of agents versus it's one agent it's like it's almost a technical detail it's not really like a new security detail that's that's interesting you know i think that a question i have often come back to ever since my first days working in windows card space my first job at microsoft is this this idea that There's a separation of concept between identification and authorization.
And I'm curious, like, as it relates to agents, like how you think about that distinction and are we sort of like changing, you know, sort of based on what you just said, like are we changing the very definition of what identity means?
As now we look at like grouping things together, not as unique entities, but as sort of shared responsibility.
Interesting.
Yeah, in all of our conversations that I've had, the fundamentals of identity aren't really changing.
Authentication and who you are or what you are and authorization still are the core concepts.
We're lucky to have Aaron Parecki here at Okta who helps guide us in terms of like how we think about this within the...
the industry space and has helped us with the oauth spec and with mcps and i think that that conversation continues to come up and now when you have what i sort of see is agents are continuing to be similar to service accounts there there still needs to be a seeded idea that you give something, an entity, some level of authorization, and whether that's minted externally or it's part of a registration flow, at some point you're going to have an authentication piece of the puzzle.
And once it's registered to a system of record, like an identity system, that's where you can start to apply your authorization, your governance policies, your fine-grained access, and your controls.
And I think it's really taking this age-old problem.
We've lived in a world where we've written automation.
RESTful APIs are super powerful.
You have a token.
You trust what it can do.
But we never really truly did a good job of tracking that as a...
full-fledged identity.
Sometimes there would be like a user record that's a service account at foo.bar, and that would exist in your identity system or in Windows, and then you would assign a role to it, and then you would eventually get a token that you would then use.
And that's kind of being upended on its head because we want these things to be short-lived, dynamic.
scoped and auditable.
And that's, this is really good for, for the identity space, because these are the, these are the hard questions we've been trying to explain to people over the last three to five years.
And AI is just making it apparent.
I mean, that makes sense, but where it sort of breaks down for me a little bit is this like notion of autonomy and where like agents.
we are expecting to act a lot more autonomously than sort of we, we want our, like we have historically wanted our like service account driven automation to run.
And so I'm curious, like at what point as an organization should we be trusting AI to act autonomously for us?
And like, and are there sort of helpful signals that organizations should look for on like when they've reached that level of trust?
So this is something we've had a number of conversations about.
Just for context, back at the end of February, our CEO pulled the Auth0 organization and the Okta research and development team to the side and said, can you write a coding agent?
Like, how fast can you do that?
And so when we were tackling that problem, one of the biggest questions we had is, how?
autonomous do we want this thing to be, right?
Like it's pretty ephemeral.
MCP specs are being, are coming online.
What resources does this agent need for us?
It needed access to our ticket tracking system.
It needed access to our CI system.
It needed access to our source code, all of which have tokens and actions and identities associated with them.
So we had to wrestle with this very quickly.
And what we realized really early on is it was almost like onboarding a new hire.
And what's interesting about how we think about an AI agent versus onboarding somebody new to the organization is that we put a lot of implicit trust into a person, that they are vetted and governed and that they have some levels of controls.
So we needed to apply some of this like implicit sandboxing capability and apply it to our agent as we were designing and developing it.
One of the scariest things I think we all saw when we were trying to figure this whole thing out was we gave our agent a task, but the environment wasn't set up correctly.
And it didn't know about our CI system in terms of how to get the right versions of Java and Maven and some other things.
But because it's a non-deterministic system and very similar to what we see new hires do, okay, I don't have Java.
What am I going to do?
Oh, I'm going to go look on the internet to go get a version of Java.
Okay, well, I can't download that version of Java.
Well, let me go find another thing.
I'm going to build a curl command to go find a different version that I know about based on my LLM training.
And when we saw this play out, we're like, absolutely not.
We have to sandbox this.
We have to give it directed controls.
And similar to a new hire, who we have also seen go off to the Internet and download the resources that they think that they need because our onboarding tools and processes didn't really account for an issue that they ran into.
That's how we're trying to scope it.
So when it comes to agent autonomy, we're really diving deep and thinking about sandboxing.
I don't want it to leave its space.
I want to have all the relevant guardrails to control it.
I want to know that it can only do certain things.
And this could go to the extreme of like human in the loop, but it really is boiling down to it.
Do tasks that we specifically define, make sure that it can operate successfully in that environment, and then leverage our technology and product offerings in terms of the flying grain authorization and the control plane in order to access the resources that you need.
Here's an AI agent that exists on the box and then it goes crazy trying to download things on the internet.
I mean, like the sandboxing point is, is particularly timely right now since like the open AI hugging face issue just came out, you know, where it's like the agent jail broke itself.
Uh, like, and it was like, Oh, how can I find the answer to this things?
I will like.
go in and hack my creators in order to find it.
Well, yeah, like having those guardrails in place.
And it's, you know, I think your analogy of new hires is really interesting where it's like, you know, like you want to contain the blast radius of what they can do.
But with humans, we have this notion of different like levels of authorization, right?
And as an organization trusts you more, like we sort of like grant, you know, higher levels of privilege.
Do you see that sort of analogy playing out then with agents?
If you started it sort of with a level of trust of a new hire, do you eventually expand that level of trust for that agent as you see it behaving appropriately?
Observationally, I think we're still new to this space.
And again, we're taking a little bit of a slower tact in terms of adopting these things because we're a security in hand.
identity companies.
So we need to be very smart about how we roll these things out.
That's kind of why we've taken the more opinionated sandbox approach.
And we've been a little bit more, I would say, diligent in terms of how we're trying to launch capabilities within the organization.
So as an agent becomes more efficient and effective, I think we're going to lean more on technical controls as a mechanism to gate versus a subjective human assessment of what it can do.
Because again, the non-determinism, it's really hard to go back to an agent and ask, why did you go delete all these files?
Why did you try to download this random gem you found online or this NPM package?
Why did you fill a need to connect to our production system?
Right.
And so I think it's.
It's tackling it from two layers, which is, again, technical controls, sandboxing, guardrails, and then building into enterprise level sort of like networking and security practices.
And on the reverse, evaluating and thinking about dynamic restrictions and controls and just-in-time access for things, not only for agents, but then we can apply that back to humans and people.
I mean, just-in-time access is something that for most of our systems, you know, like touching.
production systems like we probably always should have had for humans as well.
It's, you know, as I think about, you know, what you're saying here, Bob, it's like, I'm struck by this idea that so much of sort of the capabilities of our agents are going to be dictated by how autonomously they're allowed to operate, which is driven by what they are allowed to do, as well as what do they have access to in order to help inform their decision making.
And so we have this like future being painted of everyone is going to be a manager of agents.
And I will say that like, I'm actually a little skeptical that that is the paradigm that lands.
Like I think that most people probably wouldn't make effective human managers.
So what makes us think that we'd be effective agent managers?
But again, if that is the future where we're all sort of orchestrating lots of agents and our identity systems are really what are dictating how effective those agents can be beyond the capabilities of the models themselves, of course, it's like, it makes me think, do our identity systems, our identity platforms, do those become the orchestration layer for our agents?
Yeah, that's, Brian, that's an interesting question.
I think my personal view on it is that the identity layer is, it's more of a control plane.
It's less of an orchestration layer.
And again, it's about getting visibility and insights into the policies of what.
an entity can do and it's almost like a graph it's like i have this identity it has access to these resources and i can it can call this other agent i don't see it as an orchestration builder of saying my coding agent can call a review agent they can call a test agent they can call a deploy agent i think that will exist outside of the identity system but what i would expect to see is if that relationship is being developed, it's similar to does it have permissions to trigger that environment, not I am making that literal connection in the system of where it's running.
It's like part of the system, but it is not sort of the fundamental orchestration layer in and of itself.
I think that makes that makes sense.
But along those lines, I do think that there is interesting visibility into it.
Like I want to see sort of what that relational graph may end up being, especially as we start looking at agent to agent relationships or agent to resource relationships.
Eventually, we're going to there's going to be a problem, whether it's a security incident or a liability issue.
I want to know why this.
was able to access this resource, even though on paper it shouldn't have been able to do that.
Traceability.
Absolutely.
So, you know, as I think about all of this, like what I'm struck by is how quickly the world is changing.
for a company like Okta.
It's just like everything about your systems and how you have to operate in order to meet your customers' needs are changing.
And so in order to more quickly respond to that change so you can ship innovation faster, I know that you have been leveraging AI and you have been in charge of sort of driving Gen AI.
I have a couple of sort of questions around how you internally are using AI, but I think like to kick us off along this thread, in general, developers can be skeptical as a group.
You know, we like to see the data before we jump in.
Developers working in security are another level of skeptical.
Just like, did you find that it was...
particularly challenging to drive adoption of new AI tools internally, like more than you might have expected when you look across the industry?
It was interesting.
So around this time last year, the organization was looking at how do we jumpstart and really embrace AI, not only from an engineering standpoint, but from like a company standpoint.
And we went through the, this is in the midst of us launching our kind of first agentic.
AI tooling.
We were launching GitHub Copilot at the time, and it was something that was available.
And people were starting to use it in experiment.
And at that point, it was pretty tied to like the IDE, you could kind of ask it questions, or you get the kind of IntelliSense thing.
But people were pretty skeptical, mostly because they were being successful with the outcomes.
So you ask it a question, it was like, I don't know what you're talking about.
And then fast forward to, I think, around October, November of last year, that's kind of the cloud code windows.
The Anthropic models are launching the newer, more coding specific models.
That's where this like light switch started to flip in a lot of people.
And we started to see this sort of like stretching effect in the organization.
There was a lot of there's a pocket of engineers who were, you know.
cutting edge, trying to get the advantage of the latest tools and really trying to push the envelope and seeing this sort of future vision.
We have a big chunk in the middle who are getting value out of asking questions and getting support, but their tasks aren't really transforming.
I'm actually curious, could you actually like detect the differences between those cohorts in some of your like internal productivity data?
Most of this was survey based data and it was doing a handful of what we're calling like AI assessments.
And you have to, What's funny about this is the industry at that time was so focused on prompt engineering.
And could you write a good prompt?
Almost all of that has gone out the window since.
Prompt engineering and context engineering, loop engineering.
Like we keep on inventing the new, like what it is that we actually do here.
One of my research papers, Space of AI, had a key finding that was like the hype around AI was like one of the things that was holding it back.
And I just like.
Interesting to hear that that gets amplified even further in a security organization.
Now that you've sort of conquered that hurdle, I know your adoption, like most tech companies, is over 90% now of AI workflows.
What have you seen sort of transformationally or iteratively improved in your own engineering experiences and workflows?
The usage of the tool has been really interesting.
And I think that we've been working to find better ways to capture and measure ROI on the tasks at hand.
And again, for engineers, we tend to focus specifically on coding tasks.
And so we're still learning about what are good ROI cases.
We have our internal autonomous coding agent that we've just launched.
targets very specific scoped task we see a lot of success on those and we see a lot of value but going back to your earlier statements and what is a bottleneck we're not fixing the problem of the bottlenecks we're getting good outcomes we're seeing value in Fixing non-deterministic tests, tackling phones, targeted bug fixes, support in developing and generation of new features with local orchestration.
I think one of the big takeaways that we got is when we were launching our AI enablement programs and we had this all hands meeting a little over a year and a half ago.
And then we had a follow up last August, so about a year ago.
And we started getting Gartner research studies and doing some external research.
And one of the funniest.
things about this is, and you're aware of this for sure, an engineer's time is only like 40% writing code and only like 10% writing new code.
So there's 60% of an engineer's time that is non-coding tasks, non-coding work.
And that's something that we've seen.
ai enablement tackle on all sorts of things can they summarize docs better can they give feedback on pm specs can they analyze an issue in production faster can they give feedback to a customer request more efficiently and there's a whole host of things that i don't think we effectively capture within the engineering space that are tasks we assign to them but we focus so heavily on the can i write code faster can i build a feature can i ship it faster when it all of our work goes beyond just the feature work.
Yes.
I, in fact, have multiple papers on this very topic on like software engineering is about so much more than writing code.
And some of my own research shows like writing code might only be about 14% of what a developer does.
And it's like everything else, which may be incredibly important tasks like.
You know, you're debugging, you are sort of like analyzing telemetry, you're managing deployments, you're learning new skills, all of these other like critical things we often don't talk about and focus on how AI is improving.
So you said something in your previous answer, Bob, that like really got me thinking around this notion of like the AI readiness of a repo.
And I've thought about things like, well, what are the languages being used in that repo?
What, you know?
are the dependencies that it pulls in?
How old is the code base?
And I'm curious in like in your work, as you were looking at sort of evaluating how ready a repo was for new AI workflows, like what were some of the factors that you looked at?
Yeah, that's a good question.
So our AI enablement team, our core team that launched our autonomous coding agent.
took a good lens at this and applied these requirements as we were onboarding the initial repos.
And it kind of falls into two to three categories.
So category one is, can an agent work with the code directly?
So does it have an agent's MD?
Is it the biting by best harnesses specs?
Are there good prompts available in the repo to tell what it does, what it is, how it works?
Are your dependencies discoverable?
Is the language clear?
Right.
And so those are kind of just like, can a coding agent work on it?
So that's one.
The second part of it is, is we have requirements to work in our system, right?
I don't want an agent to go try to figure out what resources it needs and go download a random thing from the internet to try to get it to work.
So we have some, some harness requirement pieces that we've sort of defined.
And then the last piece is really sort of around, readiness.
I think what we've looked at and seen is if a repo is more mature, if it has a strong CI system and a good review process, there's other safety nets that makes those changes more successful.
So if there's not as good tests or as good sort of linting or standards in that repo, we're...
trying to get people to onboard more of those things in to make an agent more successful.
The fundamentals of good software engineering still matter.
And so I love, as someone who has, like yourself, a background in software testing, like I love this notion that testability and actually having tests is sort of like one of the fundamental requirements of being AI ready.
And I'm curious your thoughts as someone with a testing background.
What role does AI play in software testing and validation?
And I'm curious, like, does AI create more bugs than it catches?
And like, do those curves sort of cross at some point?
What are your thoughts?
I don't know.
It's a hard question.
To be clear, I also don't.
In our testing quality organization, they're tackling some of these questions head on, which is exciting to see.
And they're thinking about how to automate some of the more traditional manual testing things.
But that goes back to, I think there's one angle to all of this, which is like, who certifies that something did what it intended to do, right?
And you could call manual testers, you could call it user acceptance testing.
But at the end of the day, that the...
Did the task complete in the way that we expected?
And did somebody sort of say yes to that?
Is it correct?
And I think that that's really where I think things are moving towards.
So when we talk about bugs, I see these automated tools and these automated systems.
And I've seen examples of prompts being start with TDD.
Okay, if an agent doesn't know what the business outcome is of the task that you're trying to apply, it can write tests.
it can write code to meet that those tests pass does that achieve your end outcome i don't know and so bugs remain really really important and i think that this is where people who are providing the context for what is built whether it's a dev a designer a test engineer a product owner they have to give feedback they have to give requirements back to the system.
And so I think it's varied.
I don't know if it's this magic curve of good code.
And do those agents have access to that context to help them understand the business requirements?
Exactly.
And I think we had a conversation with our, our, Adriana, our head of design.
And there's an interesting thing around just how can we get agents to fix simple layout things and conversations with our, with our design team and our, and our UI engineers.
It's like, well, there's, how do we make sure that there's a maturity in the tooling to, to get to those outcomes?
And so at the end of the day, it's going to be a screenshot and it's going to go in front of somebody who has an opinion.
on that outcome to say yes or no.
And I think to extend this to the...
to one additional thing, which is when all these conversations of the death of SaaS and anybody can generate any code and you can vibe code something.
And I think what's important in all of that is it's usually one person to a small group of people who see the demo, see the outcome, it launches, it solves their need.
And I think what's important from an engineering standpoint and enterprise software and software in general is like, You have to build beyond that.
So somebody has to be opinionated to be thinking about not just my needs for the task I gave it, but how does it fit into a system?
And how is it solving a business problem that we can actually go to market with that people will want to buy?
All of this sort of makes me makes me think like on one hand, you have AI helping companies like Okta deliver innovation faster, which in turn.
allows you to better protect your customers' data and systems.
And so like AI is helping you do a better job securing your customers.
But on the flip side, AI is also allowing bad actors to have much more sophisticated attacks and to, you know, move so much quicker than they ever could before.
And I'm curious, like, from your perspective, which side is winning and how scared about it should I be?
So I get to hang out with our security team a lot, and I think we do a lot of security design reviews together.
And in some cases, we're on the security incidents all together.
This is something that I think is just starting to take hold and take full.
We're living in this world today, and I think...
We have to be building systems in a secure, reliable way.
We have to be able to respond as efficiently and effectively as we can.
And the good news is we're able to build a product and leverage the product as it's being built and give opinionated guidance into what we think is the right solution that our customers can take advantage of.
However, we know the industry is moving at lightning speed.
You see all the frontier models saying that they can jailbreak or they can hack your system in seconds.
I love it.
I love it.
All right.
Well, then I am buoyed by confidence.
Bob, I got one last question for you.
As we look across the entire country, which state has the best food and why is it New Mexico?
Oh, great question.
Because number one, it's got sopapillas.
Number two, it's got red and green chili.
It's the breakfast burritos in the entire country.
And I will challenge anybody who says otherwise.
It is my home state, and I am proud to represent it.
Although I live in California, my heart will always be in New Mexico.
For those listening in, I always knew that Bob was incredibly proud to be from New Mexico.
And I have now had the opportunity to go and visit New Mexico multiple times.
And I will tell anyone who listens that it is easily the best food in the country.
The green chilies.
The green chili.
Like that's all you need to know.
But well, Bob, thank you so much for joining us.
This was a ton of fun.
And yeah, I wish you all the success and best wishes and making sure that we all stay secure.
I appreciate it, Brian.
Thank you for inviting me.
I love talking about engineering productivity.
I love being able to try to tackle this challenge of embracing a new technology.
So thank you for inviting me.
Cheers, everyone.