What Engineering Organizations Get Wrong About AI Adoption

[00:00:00] Emilie: Engineering leaders are increasingly going to be under pressure to show the ROI of their spend. And if they don’t have an answer, the other parts of the org are going to come up with answers that are not exciting to them.

[00:00:17] Itamar: Welcome to The Agentic Review, the podcast where we explore what good code really means in the age of AI software development.

[00:00:25] Nnenna: I’m Nnenna Ndukwe, Developer Relations Lead.

[00:00:28] Itamar: And I’m Itamar Friedman, the co-founder and CEO of Qodo.

[00:00:31] Nnenna: So, let’s get into it.

[00:00:37] Nnenna: Every episode, we have candid engineering-first conversations about code quality and building a culture that enables trust and governance in the era of AI software development. Before we jump in, follow or subscribe to The Agentic Review wherever you’re listening – Spotify, Apple Podcasts, or YouTube so you don’t miss the next conversation.

[00:00:56] Itamar: Today, we’re joined by Emilie Schario, VP of Engineering at Anaconda and the co-founder of Kilo. Can you believe that? That’s amazing. Kilo is the open-source agentic engineering platform. Anaconda acquired it in July after it grew from 0 to more than 3 million developers in 16 months.

[00:01:17] Nnenna: Emilie has been arguing that most companies are asking the wrong question about AI, not which tools to buy, but what has to change after the tools show up. Her career has crossed data, product, operations, company building, and now engineering leadership. Emilie, welcome to the show.

[00:01:35] Emilie: Thanks so much for having me. That was such a nice intro.

[00:01:37] Nnenna: So, to kick things off, I wanna just jump right into asking you a question. Are we producing better software today than we were two months ago, or is it worse?

[00:01:48] Emilie: I think the key phrase there you asked, like, are we producing better software? And I’d say, like, we’re definitely producing more software, and I think better depends on the hands of who that software is in. Because if there are people who had problems that were not being addressed and now we’ve shipped software to address those problems, I’d say, yeah, it’s better. If we’re just shipping features that nobody is using and we’re shipping for the sake of shipping, then no. And so, at Kilo, I certainly think we’re shipping better software than ever before because we’re able to do more for our users than we were ever able to before. But at some companies I’m talking to, and I’m working with, I hear just about this: they’re throwing spaghetti at the wall, and that is definitely not the path to better.

[00:02:35] Nnenna: That’s something I wanna dig into with you more because there are decisions that are made from, you know, the top down to some degree that determine what you are building and whether or not that’s gonna end up being useful. So, it’s interesting. The speed there, for sure, has definitely increased the quantity. And then another thing is you have said in the past that distributing AI tools is not the same as driving adoption for AI. So, what would drive adoption? What are some things that come to mind for you?

[00:03:05] Emilie: Yeah. I think when it comes to agentic engineering tools specifically, companies think, you know, it’s, let’s buy everyone a license, and we’ll give it to them, and we’re in shape. And now we’re an AI company. Right? But if you take your existing workflow, I see you smiling, Itamar. Like, you agree?

[00:03:25] Itamar: Sure, it’s true. Whoa. I’m listening.

[00:03:28] Emilie: Yeah. You know, I think too many companies take that model, and then they’re like, how do we pack AI into our existing workflow? You know? It’s not “Let’s rethink our workflows from first principles to see what still does and doesn’t make sense in the agentic engineering era,” and if you’re not willing to come to it from that piece, like, you’re not willing to completely rethink, does this still make sense? That’s the hurdle that actually poses a problem. And so, I’ll give you a really specific example. I was talking to an engineering leader. He oversees about 250 developers in his org, and we were talking about a particular part of the org where he’s seeing a lot of AI resistance. And he said, you know, we were trying to diagnose, like, what is the thing that’s really been a hurdle for him? And he said, “Well, they set up, like, a CLAUDE.md file once a year ago, and the last commit on it is from 12 months ago. I was like, what? Like, if you haven’t tweaked your setup, you wouldn’t think that, like, you buy silverware once and it’s gonna be good forever. Right? You have to wash it every time you use it. You have to take care of it. You have to do the same thing with your AI tools. You have to make sure it has the context it needs, it has the access it needs, and your AGENTS.md file reflects the standard protocol with the current version of the models. Like, all these things have to happen to make sure we have the right tools for the task, for the job. We also have to make sure we have the right skills for the job. People need to know that they need to be updating AGENTS.md files. They need to know how to write a good prompt. What is the information they need? How do they manage contacts? What is the right model to use? Like, all of these things need to be a part of educating our team nowadays. I think a lot of the onus also needs to be on the team member to learn their craft, right? Like, software engineering is fundamentally different from what it was 18 months ago. And if you are gonna call yourself a software engineer, you need to come up. You need to develop your own professional development plan that keeps you on top of the skills. You cannot rely completely on your employer to get it right. So, there’s a version where companies need to make sure they’re giving their teams, the employees, access and guidance. There’s a version where companies need to make sure they’re giving their teams access, guidance, tooling, knowledge – all the things they need to be successful – and then it’s also on the team member to take advantage of those resources that are being provided to them to really uplevel the organization.

[00:06:10] Itamar: Yeah. The speed that you need to learn, the speed that you need to adapt yourself, like, increases. I think, like, it was always important for developers to, you know, get to know new programming languages, new tools, get to know the cloud, you know, and just an example from 15 years ago, etc. But now, it’s more important than ever because things are moving really, really fast.

[00:06:32] Nnenna: Yeah. There are multiple angles here at play. I like how you addressed all of them. There’s the responsibility and the agency of the individual who understands that change is happening in their profession, and they can decide to impact it or avoid it. And then there’s the responsibility of the employer, and then the inspiration, the leading by example of the leaders within the organization, many factors there. It’s a continual thing. And software is something that has always needed maintenance. So, this is just, it’s more of the same thing here that hasn’t changed.

[00:07:05] Itamar: By the way, I take the two points that you took so far and mixed them a little bit. Like, I look at a little bit of a Venn diagram. I think what we said so far is that, on one hand, you’re saying you need to rethink everything completely because you need to adapt to a new type of software, a new type of stack, a new type of thinking. On the other hand, I really love that we also mentioned that you need to think from problem-solving backwards. Like, what’s now on top of your bottleneck? What now are you trying to solve? For example, when you said in the beginning, like, am I shipping, you know, if you look at your customers’ users backwards, like, am I shipping new things because they’re not using anything I’m doing right now, or am I upgrading? And do I have a bottleneck on velocity or a bottleneck on quality on all that? And I think, like, if you can find that Venn diagram of free thinking everything but solving the problem that you have today, I think that’s the holy grail.

[00:08:06] Emilie: And I think this is a muscle that people need to learn to exercise that’s not tied only to work things. Like, one of the realities about working with AI is that people don’t always have a lot of the opportunity to experiment with AI at work. You know, people are focused on AI spend, or, you know, they’re working with a limited set of models or data or whatever it might be. There’s not a lot of room to experiment or explore. And so I think this is a great opportunity for people, especially working parents, if you are one, to bring these skills to the home and use that as a playground for experimentation. And so, you know, we’re two working parents. I’ve got a bunch of little kids. Three of them. Not that many, I guess. But I’m dealing with emails from school, from soccer, from gymnastics. Right? All these things that are constantly coming at me – I can build, you know, what is the problem I’m trying to solve and then work backwards into a workflow around this. So, I’ll give you a really specific example of something that we’ve done. Every Wednesday, my husband and I review our calendar for the next, like, week and a half with the kids to understand: do all of these kids’ events have an adult responsible for it? And so we’ve got a Google Calendar, a shared Google Calendar between the two of us where all the kids’ events land, and the adult who’s responsible for making it happen gets assigned to the event. Like, they literally get invited from the shared calendar. This is the workflow that works for us. I know different people have different things. This works really well for us. And so, I prompted an agent to write a script. I outlined roughly what I just outlined for you. “Hey, here’s the process. I want you to look at the Google Calendar. I want you to look at all the events on the calendar for the next two weeks. I want you to see what doesn’t have an adult assigned to it. I want you to put out a readout every Wednesday morning that’s like, here are all the events that don’t have an adult assigned, and then here are all the other events.” And the reason that’s been really helpful is because, now, I get an email every Wednesday morning before we have that Wednesday afternoon meeting that says, “Here are the events that need your attention. Here are the events that need an adult assigned to them.” Right? This is, like, a very small personal thing, but you can imagine taking the same problem at work. How do we make sure every customer meeting is automated? Or we’ve got an account manager for every problem. There are a thousand work problems that are roughly this shape. And by taking the specifics at home, I got the chance to build a workflow with AI that I could then use to take those same skills and apply them at work. I think if you’re wondering where to get started, there are loads of opportunities around you that look for them to build that muscle, and you’ll be much better applying it at work.

[00:10:59] Nnenna: I love, I think, Itamar, that’s something that, maybe this is not related, but you always talk about that sense of ownership in assigning. Like, it’s just kind of taking hold of a problem, and it’s almost like, wait a minute. So, you can actually automate and apply AI to this very thing to make that process of ownership that much easier. That’s just kind of what it reminded me of when she brought up the calendar. Let’s revisit, or let’s get back to talking about Kilo. I would love to hear more about it. Just from what we know, Anaconda describes Kilo as the agentic engineering layer on top of governing packages, models, environments, and orchestration. So, what does that combined stack let an engineering team do that maybe Anaconda alone or Kilo alone couldn’t do? What is that combined stack helping?

[00:11:52] Emilie: Yeah. As companies roll out and adopt more AI, what we’re hearing is if you look at the trend from, say, January, February of this year, you were hearing companies talk about token maxing. Let’s go all in, spend as much money as we can. And then by, like, May, you were hearing, like, oops, we accidentally spent our whole AI budget for the year. And so, we went from token maxing to token maxing very quickly. As people transitioned to that other non-token-maxing world, what you also saw was a look away from the frontier models. So, companies were no longer looking only to Anthropic and OpenAI for their AI needs, but also recognizing that there is this whole world of high-quality models that are much cheaper. Some are open-weight; some, you know, there’s a whole class of other models that are not the Frontier Labs. And so, when they looked to adopt some of those options, what they found is if you were all in on Codex, or all in on Claude Code, you’re using software that is tying you to a specific model, to a specific lab, and so if you wanted to switch even between those two, you had to switch the software you were using. Kilo, our vision is that models change, but great workflows don’t have to. So, you can use the same software in Kilo and start in Fable and switch to Sol and switch to Grok or Mini Max or Kimmy or DeepSeeker – all of these phenomenal models depending on the task you’re working on – without changing the actual software that you’re using day to day. And if you don’t wanna have to decide which model you want to use, we also have built-in auto-routing so that Kilo can help route your task to the best model for the job based on kind of internal benchmarks. But we’re gonna help you get the best bang for your buck. So, you don’t need to decide what is the right model for me to use here; Kilo can do that for you. So, with Anaconda, we can bring this value of model freedom to the enterprise in a governed environment where companies have the security controls and the environment management that they know and love Anaconda for, and now we also bring the model freedom that developers love Kilo for.

[00:14:27] Nnenna: Yeah. I feel like now it just makes me curious. Has that always been one of the principles around Kilo? Because it’s almost like it was before its time. Like, you just mentioned that token maxing came, and then it transitioned into token optimization and just so much, like, fear and trying to figure out, okay, maybe we went in too deep for one particular Frontier Lab, and maybe we should have had a more agnostic approach from the very beginning so we can test out different things and figure out what we wanna commit to. It just seemed like you all had it figured out a long time ago or could predict the problems that we eventually began to experience.

[00:15:07] Emilie: It was one of our core theses from the very beginning. There’s a blog post from, like, August 2025 where we predict developer AI spend to go to 100k, like, very quickly, and I think companies are seeing that. And so we’ve always been open has been a really kind of central principle to us. Kilo is open source. We’ve always been focused on making sure we have as many of the open models as we can, and model freedom is just a core belief of ours.

[00:15:42] Nnenna: I would love to hear your perspective on that, Itamar. Because I know, like, with that, Qodo specifically, there was definitely a projection or predictions about where we saw AI cogeneration and for software development going, and the exact problems that we wanted to catch before they actually became massive problems across the market.

[00:16:04] Itamar: Yeah. I love the notion that at the beginning, we had some token maxing, which was real excitement about what we can get, how we can harness AI. And then we realize that we care a lot about the outcome. And the question that I appreciate is not how can we reduce cost, but rather how can we route and distribute the resources that we have to have the highest impact? And that’s what I heard, Emilie, you’re saying. I think, like, as with many other technologies, we need to have a budget. We can review the budget very often because we see the ROI is really good. Maybe we can add to it. But we need to have a budget. And then the question is not how we reduce the budget; it’s how we define it and then, like, route it to the right places. So, one example of routing is using the right model for the right task and not spending, like, too much of your budget on a thinking model when you need, like, a simple execution that requires a model, cannot be a code, but can be done with one of the leading open-source models. And I think, take it further: it’s also maybe routing even which task to do. And I take it to our world because it’s very easy for me to think about it like code review. Okay? Like, if I think about it, like, if I’m changing, if a coder is reviewing a PR which is a documentation change, we still want to review that. We want a document to work well, but we can route it to a specific designated agent that is very good and doing only that. We don’t need to now spin up all the types of agents that check the intent and check for security and check for whatever. We know that we don’t need that effort, a review effort. So, it’s like we can even take the LLM routing to agent routing, task routing, and then, like, it’s a distribution challenge, which I think, like, is very strongly correlated to token outcome maxing. And that’s a notion I appreciate.

[00:18:27] Emilie: You know, when I think about AI spend, because companies now and I think this is what you’re getting at as you think about, like, what value are we creating. AI spend is a metric that is only gonna go in one direction: up into the right, right? Because companies are gonna reach for more AI for the things they’re already doing, and they’re gonna reach for AI to do things they’re not yet using AI for. And so when you combine those things, we can expect AI spend to go up into the right, probably exponentially. So, if we just stay focused on AI spend, that’s, like, not a good metric for anything, maybe just for CFOs who wanna experience stress and heartburn at night. What we need is a metric that actually gets closer to how do we measure ROI. And so for Kilo, the way I think about that is, you know, what is the best way to measure customer value created? Revenue. Okay. In enterprise, it’s a long sales cycle. How do we move it closer? Well, for DORA metrics, we use PRs merged. Right? Like, that is the closest thing near the coding work that is a measure of customer value created. And so I think a better metric, rather than just AI spend, is AI spend divided by merged PRs, gives you average AI spend per merged PR. And that is better: it’s what do we spend, what is the value created, that gives us what is the return on our spend. Right? If $25 is a metric per PR and our spend overall doubles, but that $25 stays the same, well, then we’re saying we’re creating a lot more value, and that should translate to additional revenue. And if that’s the case, great. That’s the number that’s gonna give us a better indicator of, like, whether or not our spending is actually creating return. I think that’s important because if you don’t anchor on what value is the spend creating, you’re just gonna have these, like, circular conversations that are based on vibes.

[00:20:29] Itamar: What do you think about adding the spend on AI plus human? And then, like, you’re getting the overall cost per PR. Because, to some extent, like, the human effort to get the PR done should go down, and then you can afford to spend more on AI. Rather, it now brings us to a discussion of, like, jobs, you know, security and things like that. If we’re looking from value creation, it feels like AI plus HI budgets per PR.

[00:21:02] Emilie: That makes sense to me. I think there’s lots of things, like, I’d love to also think about total cost of ownership. Right? Not just what is it for this PR; what is it, you know, how many times do we have to come back and touch this part of the codebase because we missed something? Like, I think there’s a lot of ways you can get more granular about it. But when I think about, like, what is the thing we can roll out to people tomorrow, it’s sum all your AI spend over the last month, look at how many PRs shipped, and do the math. And there is a number that, if you wanna have better conversations this afternoon, you put that math together, and you’re already in better shape.

[00:21:41] Nnenna: So, in general, I think, like, to wrap up some of that conversation, because we kind of mentioned it in the beginning and then returning to it. Can more AI usage, more generated code, or faster PR creation, in general, be making things better for engineering in the business? Or you’re saying that beyond that, there is a value that you must be able to quantify or qualify as a result of the speed to justify AI spend, really.

[00:22:17] Emilie: I think engineering leaders are increasingly going to be under pressure to show the ROI of their spend. And if they don’t have an answer, the other parts of the org are going to come up with answers that are not exciting to them. And so, the more intentional we can think about this – I mean, I look at DORA metrics as, like, the great example here – the more we can be intentional about what is the right metrics to measure engineering teams, recognizing that, like, we’re still at the top of the first inning. There’s a lot of figuring out agentic engineering to go, but this is certainly a better metric than AI spend. So, I’m not saying it’s the best and the holy grail, but it’s, like, something you can get to quickly, and it’s better than what teams are using now.

[00:23:07] Nnenna: And then moving on to the first thing, for an organization, for an engineering organization, they’re looking to adopt AI tools. They’re hungry for buying AI tools. What would you say is the first thing that they should look at for redesigning their org to even prepare for that and to get the best use out of it?

[00:23:30] Emilie: Finding the right champions. I have found that the best opportunities where I grew the most in my AI skills were when I had someone I was learning from, oftentimes through osmosis. And so, like, I did some work with a company called Replicated. Grant, the CEO there, Grant Miller, they had a week where they, like, canceled everything on the calendar, cleared everyone’s calendar, and they had these, like, full-day Zoom meetings that were just, like, all AI experimentation. I think of that as, like, a really good opportunity. Most companies are not gonna clear their whole calendars for the week, but if every week someone shares something they learned or, you know, here’s how I’m working or here’s what’s working and what’s not, that’s a really great path, I think, for people to make sure they’re constantly learning. I think it can be really easy to think you’re, to, like, subscribe to a thousand newsletters and then never actually do anything. So, deciding what those, like, one, two, five projects you wanna experiment with are, and then making sure you’re applying whatever you’re reading or learning about to those projects is just gonna be much more valuable than reading every blog post ever written.

[00:24:57] Nnenna: And that reminds me of my time at O’Reilly Media. I was there for four years as an engineer, and I don’t remember if it was weekly or every other week when all the engineering teams would get on a call, and one person from each team would demo something. And since every team has different specializations, different focuses, different stacks or products. We were all walking away learning something from someone of different levels as well. And I do think that that is a cultural thing that can be embedded into an organization. I think the culture of learning from others is when you make space for that intentionally, kind of like what you just described. People can learn consciously or passively. I think it benefits everyone.

[00:25:51] Emilie: Demo days are the best for so many reasons. Like, demo days are helpful for sharing knowledge. They’re helpful for showing how you’re working. They’re helpful for keeping people in the loop. They’re helpful for helping you write your change logs completely. Demo days have so many values for engineering orgs. And as companies grow, it’s one of the first things that gets dropped, and I am so bummed about it every time. Demo days have so many values, and you just covered, like, the surface. I love it.

[00:26:27] Nnenna: Is that something that you ever ran, Itamar or participated in?

[00:26:33] Itamar: Yeah. Of course. Like, we have demo days, and I think, like, almost any company I’ve been in, including in Alibaba, where there’s, like, 180,000 people or so. Not as many engineers, but to some extent, like, it was done a different way. But I have to say, like, in my mind, like, I almost have, like, no matter what we talk about, I have this idea. We are playing a multiplayer game, and that game was only humans, like juniors, mid-seniors, and, like, principals from different teams. Now the multiplayer game is starting to be that there’s a new type of player. And that player is like an agent. We’re on the brink of, like, getting there. Like, your agent is, like, a team member. To some extent, it’s there. To some extent, it’s very far. And, like, I know it might sound unrelated, but I think how would a demo day look at the age where you have, you know, an agent that can demo stuff?

[00:27:35] Nnenna: Interesting.

[00:27:36] Itamar: And should we, like, think about demo days, like, differently? I mean, I’m not sure we’re there, or there should be any difference. But if we’re talking about, like, rethinking your stack, we have a new player. Maybe we can enhance a demo that actually, like, we have an agent in each one of our teams, and that agent is creating, like, a demo for us every day. And we can pick up, like, we can pick up, like, a demo that we wanna share, and we don’t need to wait for a demo. Just an example of thinking out of the box. Might be exaggerating here.

[00:28:10] Emilie: Yeah. I mean, I would probably say at least in the August 2026 era.

[00:28:17] Itamar: Good to point that out. Right?

[00:28:18] Emilie: Good to point out. Like, let’s lock it in because who knows what’ll happen next month. In the August 2026 era, I would say PRs still have to have a human responsible for them. And so, even though an agent’s probably writing 99% of the code and reviewing 99% of the code and there’s, like, a whole loop there, I think the ownership still comes to a human, and that’s the person that I would push to demo because it’s not just ownership of the code shipped. It’s also, like, the feature and understanding: did we build the right thing to solve the user’s problem? And so, at Kilo, we operate in this product engineering model where we don’t have, like, PMs over here planning things and engineers over here building things. We actually focus on pushing the decision to the engineer who’s doing the work, where we’re aligning on what’s the problem. But engineers are often the right people in our case because they’re both our user and our builder to come up with the best solution. So, they are the people driving it forward.

[00:29:26] Itamar: I agree with you, but at the same time, I’ll push back on the humans are responsible for the PR. Oh, whoa. I’m saying, like, quite a big thing here. I’m claiming maybe there is a very near future where people – human developers are not in charge of the PR itself. I’ll explain. I do want to say, before I explain, that I was surprised to hear what I just claimed also from Fortune 500, even Fortune 100 VP engineers, and here is what they told me. Some of them, not everyone. “Our PR process is crap anyway. Like, and if it’s crap anyway, then maybe we can actually take that specific part of the process, give it to bots, to agents, to take over.” Now, to some extent, it’s back to, I think it might be, like, a similar discussion: the token maxing to token outcome, like outcome maxing, that the outcome is what’s the value of the software and how stable it is, and the PR is the gateway for that. But, similarly, when you think about search, like, we offload to Google the search, but the outcome of the search is on us. But the search is such an incredibly important point. If it doesn’t do it well, like, we should go to a library and search ourselves. But the outcome of the search, we are in charge. So, I actually was, we are thinking like that, at least for the future, and I was surprised to hear even Fortune 100 coming to us and saying, “Show us that you can do it as good as, for example, a principal engineer, and we are agreeing to jump over that process.” Humans are still in charge of the outcome, of the reliability, of the maintainability, of the, like, amount of bugs. But the peer process is not necessarily where we want to have the human control. As a provocative thought, I’m hearing that more and more.

[00:31:34] Emilie: I feel like we need to put this caveat of, like, talk to your compliance folks and understand what your org’s compliance obligations are.

[00:31:44] Itamar: There’s a solution. It’s a trick, quote-unquote, that might need to think about maybe a bit more thoughtful process. But what about accumulating all these PRs into one huge PR, which is maybe not called a PR anymore, like a version? And before that version or subversion or subtag is merged into main, then a human is reviewing that. For example, maybe not line by line, but the reports that were generated or so, but still humans, but then it’s like a different unit. It’s not a PR. Like, I’m in charge of the change in the system to some extent. So, I think we’re heading there, but I didn’t, like, I’m not saying I compiled, like, a good enough answer, but I think, like, we’re going in that direction.

[00:32:39] Emilie: One thing I talk to my team about all the time is, like, a recognition that anyone who has the answers right now is full of another word we probably can’t say here. Right? Like, you know, we are making it up. We are reinventing what development looks like in the world of AI. And so every day, every bit of work, it just it’s different, and we have to recognize that and make the best judgment decisions we can. And so I think part of what we have to be comfortable with is accepting that we have to be willing to be a little bit uncomfortable in this process as we’re going through this transition, but putting in the work is the best thing we can do.

[00:33:26] Nnenna: Yeah. I agree. This is a trial-and-error process in public for so many of us in ways in which many have not had to deal with before, which I think is very revealing. I think it’s exciting, and it’s not meant for everybody. But there is, but as I think, as long as we’re documenting what our decisions and our opinions were along the way, I want that to be documented privately. I want that to be documented and shared publicly by people who are, you know, developer advocates, who are principal engineers, who are managers, because then that’s data that we get to look back on and see how the decisions have changed once we all came across new information or discoveries from new or latest research or the newest or latest model or workflows. And that would be an incredible thing to be able to look back on that journey as a whole. There was one thing that we kind of touched on throughout this whole thing, really, is, like, ownership. We have talked about, like, ownership over tasks that you need to make sure that you complete and having AI help with that. We talked about ownership when it comes to agents and, like, bots and what you own versus what you can have an agent take care of. And then that just immediately made me think about what your perspective is on autonomous agents or the permissions for agents themselves. There’s so much discussion about, you know, relying on some classic principles when it comes to what agents can or can’t do. And who should have ownership when something goes wrong. I would love to hear your perspective on that, Emilie.

[00:35:09] Emilie: I think working with AI is like a journey, a hero’s journey, I guess you could say, and you have to make sure you’re using the tools that match where you are on that journey. So, when it comes to autonomous agents, like, you can’t see it, but there’s a Mac mini over there, and it gets to do its own thing. And it does not have access to my taxes or my Social Security number. But there are agents on it that I’m regularly talking to throughout the day, and it’s kind of chugging along, and that’s exactly what I want. The things that it has access to are the things that I feel good about giving it access to. And the mental model that I lean into is like an intern. You wouldn’t give an intern full control of your inbox on their first day of work, right? Like, you have to build that relationship, make sure they understand what’s important to you, and transition to that over time. And I think of it the same way. When it comes to an autonomous agent, you need to make sure it has access to only the things you’re comfortable with it possibly going wrong. If an intern dropped your production database, it’s not the intern’s fault. It’s your fault for giving them access to drop the production database. And so, thinking about where those boundaries are, I think that’s the work that needs to be done upfront for a wider rollout of autonomous agents. But we are going to see more and more autonomy, and just look at how far we’ve come since January.

[00:36:33] Itamar: But wait. I was sure after this podcast, I’m not only going to do grill my parenthood, but also grill my tax reporting. But if I get you right, you’re like, if I’m understanding, you’re saying, like, please get them to differentiate between, like, autonomy and assisting me to do my work. And, like, maybe, like, an agent has full autonomy. You don’t wanna give your this and that information or this and that, like, right permission.

[00:36:59] Emilie: Mhmm.

[00:37:00] Itamar: But if it’s helping you, then, yeah, give it read permission as much as you want to do the work. So, I think, like, I will still do the grill my tax reporting. Right?

[00:37:10] Emilie: I think the other thing too is, you know, we don’t need to throw agents at things just because we can. Right? So, it comes back to what we were talking about earlier. Like, let’s get really clear on what problem we’re trying to solve and then make sure we’ve got the right tools for the problem, and sometimes that’s an agent. But one thing that, like, a negative trend I’m seeing is companies reaching for AI because, like, why not? Instead of thinking, like, could a script be a solution here instead? Do we need a Zapier or an NAN instead of some LLM carding information back and forth? And so, like, just because we have AI does not mean we need to throw out all the principles of the last 20 years.

[00:37:54] Nnenna: I completely agree. I spend a lot of time thinking about that and trying to champion that too with any of my, like, conference talks or meetups, as we don’t need to chase the latest tool and try to leverage it for every single thing when some of the deterministic tools, for example, of the past worked perfectly fine for certain tasks. And the more that we are focusing on the opposite of token maxing, the more people are going to remember exactly what you said and go back to looking, “Okay, where is AI actually the most useful here, and where can we keep using the tools that have already worked?” And try not to fix what isn’t broken and save money in the process. So, we are gonna be wrapping up soon. I was very curious. I mean, both of us are curious. Do you have any hot takes, Emilie? I don’t know if, I’d love to know if you’re active on Twitter and if you’ve actually, or on a blog or something have shared it or not. But any hot takes for us about agentic engineering?

[00:38:59] Emilie: I feel like we’ve had a whole conversation of hot takes. We are all mostly in agreement, but I think we’re really different from where kind of here’s what I’ll say. Most companies are not this far along in their AI adoption journey. Specifically, you know, when I think about building Kilo, I have to think about the developer who is, like, all in on running eight parallel agents and gung ho. I also have to build for the developer who, like, tab-tab autocomplete is the only AI they’re using. And so, thinking about finding users along that spectrum and making sure we’re serving not just the people who are pushing the boundary, but the much larger audience of people who are somewhere else along their journey, I think that’s really important. And I feel like that is not a part of the AI conversation that’s being served really well to engineers.

[00:39:57] Nnenna: That was so well said. I completely agree. I do not hear enough of that. It reminds me of, like, being a web developer and having to care about, like, accessibility and the way that you design and, like, mobile-first design, and it’s just that it’s an empathetic approach to how you can build a product for your users when you’re considering the maturity level of their agentic engineering experience, the entire spectrum, and serving them?

[00:40:29] Itamar: Plus 10. If you go to Twitter X, you’re seeing my dark factory. I just, like, turned on the red light. I did that. I closed the purple light, and it’s now a disco. And now I can turn it off, and I have it. And, like, in reality, we’ll get to a dark factory, or maybe it’s a different topic for those who are not familiar with the term, but, like, there is a journey that we need to go through as a community and each one of us in an engineering organization. So, plus 10.

[00:41:01] Nnenna: That was incredible. And where can listeners follow your work and, yeah, just see more about what you’re building, the work that you’re doing?

[00:41:09] Emilie: Yeah. So, they can always find Kilo, kilo.ai, or find me on LinkedIn. I’m Emilie, E-m-i-l-i-e, Schario, S-c-h-a-r-i-o. And I post about AI most days.

[00:41:25] Nnenna: Amazing. And thank you so much for joining us and having this really exciting conversation. I loved your perspective, and thank you, everyone, for listening. And if this conversation gave you something useful to take back to your team, please follow or subscribe to The Agentic Review on Spotify, Apple Podcasts, or YouTube, and share the episode with someone responsible for the quality of AI-generated code. Thank you, Emilie Schario.

[00:41:51] Emilie: Thanks.

[00:41:52] Outro: If today’s conversation challenged how you think about AI and code quality, that’s the point. At Qodo, we believe that independent, context-aware code review with rules as guardrails is how engineering teams maintain standards at scale. If you’re leading an enterprise team and want to see how intelligent AI code review can reinforce governance, visibility, and accountability in your workflow, visit qodo.ai to learn how we help teams turn AI productivity into production-ready quality. And if you enjoyed this episode, subscribe, share it with your engineering leadership circle, and leave us a review. Until next time, keep human in the loop. And keep shipping.