Brian Houck:
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 GenAI 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.
Robert Lucero:
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. 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 plug into the product offering and solution that we are 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.
Brian Houck:
Awesome. To kick us off, I feel like I’ve had so many conversations lately that all end up with 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. 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. Are the fundamentals actually changing? And so as I think about it’s like all of our identity systems are built around this notion of human identity. But as enterprises are managing hundreds or thousands, maybe even millions of agents, what about the fundamentals of identity might be changing?
Robert Lucero:
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 I’m operating as 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 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 ideal offering 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.
Brian Houck:
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, based on your answers, our identity platforms are sort of like the layer that will manage that context that agents are able to access. And it’s like, I’m curious, are these sort of new problems with agents or are these solving the age-old problems that we’ve had for documentation with humans forever?
Robert Lucero:
Oh, that’s an interesting question. I think 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 the world of automation, having overscope 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 grain access or cross-app access with, again, fine grain controls, means that I can govern what access these agents have in order to be successful.
Brian Houck:
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? It’s creativity, so to speak. It 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. So that makes me think of scale. It’s like we have service accounts that we have to manage their identities. We have certainly humans. And do you think that it sure seems like in the foreseeable future, there will be more agent or non-human identities than human identities? Do you agree with that? And if so, when might we expect to have that happen?
Robert Lucero:
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 user agents or 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.
Brian Houck:
As you say it, I’m like, “Well, of course.” 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 break down. And even this notion of when do we spawn up the sort of armies of agents versus it’s one agent, is almost a technical detail, it’s not really like a new security detail. That’s interesting. I think that a question I have often come back to, ever since my first days working in Windows CardSpace, my first job at Microsoft, is this idea that there’s a separation of concept between identification and authorization. And I’m curious, as it relates to agents, how you think about that distinction, and are we sort of like changing based on what you just said, are we changing the very definition of what identity means? As now we look at grouping things together, not as unique entities, but as sort of shared responsibility?
Robert Lucero:
Interesting. Yeah. In all of our conversations internally at various external 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 how we think about this within 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 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 of 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 a user record that’s a service account at food.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 this is really good for the identity space because 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.
Brian Houck:
I mean, that makes sense, but where it sort of breaks down for me a little bit is this notion of autonomy. Where agents, we are expecting to act a lot more autonomously than we have historically wanted our service account-driven automation to run.
And so I’m curious, at what point as an organization should we be trusting AI to act autonomously for us? And are there helpful signals that organizations should look for on when they’ve reached that level of trust?
Robert Lucero:
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? 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? It’s pretty ephemeral. MCP specs 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 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 version 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 human-in-the-loop, but it really is boiling down to, 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 fine-grained authorization and the control point in order to access the resources that you need. Not, here’s an AI agent that exists on a box and then it goes crazy trying to download things on the internet.
Brian Houck:
I mean, the sandboxing point is particularly timely right now since the OpenAI, Hugging Face issue just came out, where it’s like, the agent jail-broke itself and was like, “Oh, how can I find the answer to these things? I will go in and hack my creators in order to find it.” Well, yeah, having those guardrails in place. And you know what? I think your analogy of new hires is really interesting where it’s like, you want to contain the blast radius of what they can do. But with humans, we have this notion of different levels of authorization. And as an organization trusts you more, we grant you higher levels of privilege.
Do you see that analogy playing out then with agents? If you started it 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?
Robert Lucero:
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 and identity company. So we need to be very smart about how we roll these things out. That’s 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 mpm package? Why did you feel a need to connect to our production system?”
And so I think it’s tackling it from two layers, which is again, technical control, sandboxing, guardrails, and then building into enterprise level 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.
Brian Houck:
I mean, just-in-time access is something that, for most of our system, like touching production systems, we probably always should have had for humans as well.
As I think about what you’re saying here, Bob, I’m struck by this idea that so much 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’re 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 future being painted of everyone is going to be a manager of agents. And I will say that I’m actually a little skeptical that that is the paradigm that lands. 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 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 makes me think, do our identity systems, our identity platforms, do those become the orchestration layer for our agents?
Robert Lucero:
Yeah. Brian, that’s an interesting question. I think my personal view on it is that the identity layer, 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 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 where it’s running.
Brian Houck:
It’s part of the system, but it is not the fundamental orchestration layer in and of itself. I think that makes sense.
Robert Lucero:
But along those lines, I do think that there is interesting visibility into it. I want to see what that relational graph may end up being, especially as we start looking at agent to agent relationships or agent to resource relationships. Eventually there’s going to be a problem, whether it’s a security incident or a liability issue, I want to know why this agent was able to access this resource, even though on paper it shouldn’t have been able to do that.
Brian Houck:
Traceability. Absolutely. So as I think about all of this, 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 customer’s 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 GenAI.
And I have a couple of sort of questions around how you internally are using AI, but I think to kick us off along this thread, in general, developers can be skeptical as a group. We like to see the data before we jump in. Developers working in security are another level of skeptical. Did you find that it was particularly challenging to drive adoption of new AI tools internally more than you might’ve expected when you look across the industry?
Robert Lucero:
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 a company standpoint? And 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 and 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 weren’t being successful with the outcomes. So you ask it a question and it’s 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 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’s a pocket of engineers who were cutting edge, trying to get the evangelist 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 supports, but their tasks aren’t really transforming. I’m actually curious, could you actually detect the differences between those cohorts in some of your internal productivity data?
Robert Lucero:
Most of this was survey-based data and it was doing a handful of what we’re calling like AI assessments. And 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.
Brian Houck:
Prompt engineering, to context engineering, loop engineering. We keep on inventing the new, what it is that we actually do here.
Robert Lucero:
And so what we saw was from the surveys is that the feedback we got on one of these surveys was that engineering was not adopting AI as successfully because they were more skeptical of the outcomes. And again, if you think about that, that kind of makes sense, which is we’re writing a security product, the outcome needs to be successful. If I get weird garbage out of a tool, I’m less likely to use it day to day because it’s not going to make me more successful and it’s not helping me in my job. Fortunately, this tooling has evolved so rapidly that again, now this is kind of ingrained into every engineer’s lives in some capacity, whether it’s code review, or code generation, or supporting some other task. But that was our learning curve and I think in the evolution of the industry.
Brian Houck:
Yeah. One of my research papers, Space of AI, had a key finding that was like the hype around AI was one of the things that was holding it back. And just 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?
Robert Lucero:
So 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 that 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, but 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.
But to kind of get to that next level, we’re not a greenfield new service company. We’re a legacy company. And so we’re having to invest in AI readiness of our products, of our repos. And it’s actually caused us to sort of re-envision and re-imagine a lot of our processes. What does it mean to have AI generated code go through a code review? How do I test it? How do I know it’s successful? Because if it’s just another human-like contributor to the system, now I just have more changes going into a system. Is it providing the outcome and the goal? And we’re learning. And I think we’re instrumenting it effectively and we should have better outcomes soon.
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 10% writing new code. So there’s 60% of an engineer’s time that is non-coding task, 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 all of our work goes beyond just the feature work.
Brian Houck:
Yes, I in fact have multiple papers on this very topic on software engineering is about so much more than writing code. And some of my own research shows 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’re debugging, you are sort of like analyzing telemetry, you’re managing deployments, you’re learning new skills, all of these other critical things, we often don’t talk about and focus on how AI is improving.
Brian Houck:
So you said something in your previous answer, Bob, that really got me thinking around this notion of the AI readiness of a repo. And I’ve thought about things like, well, what are the languages being used in that repo? What are the dependencies that it pulls in? How old is the code base? And I’m curious in your work, as you were looking at sort of evaluating how ready a repo was for new AI workflows, what were some of the factors that you looked at?
Robert Lucero:
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 abiding 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 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 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. And in our super mature repos, that’s a heavy lift for these agents. So there’s some challenges on that front.
But in our more smaller repos, our microservices and places like that, it’s a little harder to onboard an agent because it has sort of these unbounded rules. So it applies its rules that it thinks is right and it doesn’t quite fit in and then it fails in CI and then you have these long feedback loops. And so we have to invest in the repo itself to be not only AI agent ready, but even more developer ready. And these are good findings for us because again, investing in that engineering excellence is important for anybody contributing to that space.
Brian Houck:
The fundamentals of good software engineering still matter. And so I’d love as someone who has, like yourself, a background in software testing. 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, does AI create more bugs than it catches? And do those curves sort of cross at some point? What are your thoughts?
Robert Lucero:
I don’t know. It’s a hard question.
Brian Houck:
To be clear, I also don’t know.
Robert Lucero:
In our test and 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? And you could call manual testers, you could call it user acceptance testing. But at the end of the day, 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-
Brian Houck:
And do those agents have access to that context to help them understand the business requirements?
Robert Lucero:
Exactly. And I think we had a conversation with Adriana, our head of design, and there’s an interesting thing around just how can we get agents to fix simple layout things? And in conversations with our design team and our UI engineers, it’s like, “Well, how do we make sure that there’s a maturity in the tooling 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 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 you have to build beyond that. So somebody has to be opinionated and 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?
Brian Houck:
All of this 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 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 move so much quicker than they ever could before. And I’m curious, from your perspective, which side is winning and how scared about it should I be?
Robert Lucero:
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 altogether. This is something that I think is just starting to take hold and take fold. We’re living in this world today and I think we have to be building systems in a secure and 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 think we’re going to be moving very much towards a hardened space and a responsive space and it’s going to evolve. I’m scared, but at the same time, I’m hopeful that the investments that we make across the board and the product that we build secures and produces the outcomes that we need. Otherwise, we’ll react and we’ll make it successful.
Brian Houck:
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?
Robert Lucero:
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.
Brian Houck:
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 and is like the green chilies. The green chili, that’s all you need to know. Well, Bob, thank you so much for joining us. This was a ton of fun. And yeah, I wish you all of the success and best wishes and making sure that we all stay secure.
Robert Lucero:
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.
Brian Houck:
Cheers, everyone.