--- title: "AI Is Writing More Code Than Humans Can Review - [Dev]olution Podcast - Coder" description: "Listen to the [Dev]olution Podcast from the team at Coder." image: "https://i.ytimg.com/vi/Hp3xpmDarHM/hqdefault.jpg" canonical: "https://coder.com/podcasts/devolution/ai-is-writing-more-code-than-humans-can-review" --- [Back to podcast list](https://coder.com/podcasts/devolution) # AI Is Writing More Code Than Humans Can Review ![AI Developer Relations Lead, Qodo](https://coder.com/_next/image?url=https%3A%2F%2Fwww.datocms-assets.com%2F19109%2F1788308475-nnenna-ndukwe.png%3Ffit%3Dcrop%26fm%3Dwebp%26h%3D400%26w%3D400&w=2048&q=75)Nnenna NdukweJul 29 2026 [YouTube](https://youtu.be/Hp3xpmDarHM)[Spotify](https://open.spotify.com/episode/5TwIOQCLP6UqVT6A7dAWAs?si=WpRNHl0eTOqhgITzrYH0Mw)[Apple Podcasts](https://podcasts.apple.com/us/podcast/ai-is-writing-more-code-than-humans-can-review/id1839475248?i=1000778867585) ![](https://coder.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fdevolution-masthead-bg.af392453.jpg&w=2048&q=75&dpl=dpl_6wsypvurgW3Wca4tyrJ6aVYnLrcb) ![](https://i.ytimg.com/vi/Hp3xpmDarHM/maxresdefault.jpg) ## Transcript _This has been generated by AI and optimized by a human._ **Nnenna Ndukwe (00:00):** I think that no matter what, with all the trends that are coming out, all of the marketing and the fear-mongering or the hype, that's never going to change. Just take AI out and replace it with another tool or a technological innovation. Make sure you know how to play the short game, but to play the long game as well. **Nicky Pike (00:20):** This is \[Dev\]olution, bringing development back to speed, back to focus, back to freedom. I'm Nicky Pike. Okay, everyone's talking about AI making developers faster. Write the code, ship the code, 10X the team before lunch. The inner loop has never gotten more love, but here's the question almost nobody's asking. Was the inner loop ever the bottleneck? We taught the machines to write code at a thousand miles an hour, but did anybody ever think to build the brakes? Is the real fight moving to the outer loop? To review, verification, governance, the unsexy layer where your AI code either gets controlled or it doesn't. Because here's what I keep seeing. Enterprise is shipping AI code faster than ever and they're breaking production more than ever, all at the exact same time. Everyone fell in love with the part that writes the code, so who's minding the part that decides whether this is any good? With me today is Nnenna Ndukwe, AI developer relations lead at Kudo. She's a software engineer with eight plus years in the trenches who now spends her days in the room with engineering leaders, separating what actually works with AI from what's just loud. Code quality, code review, governance. The stuff that decides whether all this AI velocity is real or just expensive. Nnenna, welcome to The \[Dev\]olution. **Nnenna Ndukwe (01:34):** Thank you so much. Super glad to be here. **Nicky Pike (01:37):** Oh, I'm super excited. So we're just going to jump into this. You had eight years as an engineer and now you sit at this scene between engineering and developer experience and what leaders actually decide to do. That's not a job title. You've actually got a really good vantage point here. So take me back. How did you get from writing code to advising people on who decided how AI gets to be used on that code? **Nnenna Ndukwe (01:58):** It all started honestly with first teaching myself how to code. It was really exciting to, I guess it was mentally stimulating, but like a really exciting challenge to learn. And then I took that further by getting into software development officially and studying computer science. But working for years as an engineer on the side, I was always building content and involving myself in the community and really that's a way of just listening and learning from other developers how they're experiencing developer tools themselves. And so getting involved in that conversation externally combined with the collaborative experience on an engineering team, collaborating with product managers and project managers, I got to ask the question why a lot. And I just became very curious in that particular direction. I don't just want to code to code. I'm not one of those types of engineers. That doesn't satisfy me. What I want more is to understand why I'm even writing this piece of code. What is the value behind it? What kind of value am I delivering to customers or the business? What is the impact? And if I can find some depth there or strong reasoning, that's the motivation to actually execute on the code side. And so I think that the way my career has unfolded is really diving even deeper, leaning more into the why. And that's how I've ended up in developer relations and formalizing what it means to really create technical content for developers and also for customer enablement workshops internally for engineering teams at enterprises. **Nicky Pike (03:29):** I see that as a common thread, especially with developer relations. Almost everybody kind of tells a story. We started coding. There were things that I felt were missing or I really enjoyed explaining why I did things and that's how I got into developer relations. But now you're taking that into more of the enterprise leadership way and you're starting to bring the why, which I love that by the way. The why are we doing this up to more strategic thinking with the enterprise. Is that the way you saw your career going? And I got to assume this is making you pretty happy. **Nnenna Ndukwe (03:55):** Just hearing you say it back to me. Yeah, it is super exciting to me. I couldn't have imagined that this is the route that I would take, but I knew that staying long-term maybe as an IC in engineering, that I wasn't really sure how that would pan out. So it might have been some kind of hybrid product engineering role to some degree anyway. But with AI in particular, I think that's one of the things that makes my career direction even more exciting. I realized how much I love emerging tech or how exciting that space is. I love that we have to, every single day we have to keep up to date with the latest research that's coming out or any of the latest tools and what different organizations are experiencing in the adoption process. There's so much to keep up to date on no matter what levels of education like academic career that you've reached. And I love how it levels out the playing field and it's that kind of, I don't know, stimulation that makes me want to continue being a student, a student in my professional work. **Nicky Pike (04:54):** I see how you're smiling. And that was one of the things that you're noted as saying is the thing that lights you up is really becoming more of a strategist, becoming that trusted advisor instead of a person that just ships code. So when did that kind of click for you? I mean, was it AI? Was it the new technology coming out that's got everybody's attention or was it before that? What changed how you see the work? **Nnenna Ndukwe (05:12):** Yeah, I think with AI, I wasn't just looking at it as, okay, I want to learn how to build AI systems and I want to learn how to use AI efficiently. It was watching the swarm of people and being able to listen to how everyone else was experiencing it, how leaders and organizations were talking about it and the way in which the conversation around engineering seemed to completely change. This influx of AI made me really pause, although I'm still in the bubble, it also made me pause heavily and think we need to go back to those principles that allowed us to be really great at the work that we do and we need to hold ourselves to a certain standard. And I'm sure that if individuals, if I feel like I need to say this or communicate this in the industry because I'm not seeing enough of it, that individuals I want to share that with, and there's probably information that needs to go beyond just like the individual developer or a person using or adopting AI. This is something a problem or a gap that's going to expand for entire organizations and like communities. And so I think that kind of advisory angle, that's when it really started to kick in. And the exposure as well internally with my work at Qodo, the cross-functional nature of developer relations, I guess with my role, getting my hands into sales, customer success, engineering, product, just really understanding the whole full pipeline of the business go to market and customers with the customer experience, that exposure was what led me to feel like, okay, I have opinions here and I've been sharing them consistently externally and I'm getting that exposure to share that and internally to empower people and who wouldn't want to empower people and especially with the times that we're in where there's some fearmongering as well in this space. **Nicky Pike (07:02):** And I think you and I, we got connected, I want to say it was a commit your code in Dallas and one of the things, there were a couple things that really struck me as one is just the energy and the enthusiasm that you bring when you're talking about technology. You were one of the founding members of Women Apping AI. Yo came up through Google Women Tech Makers and that was something that impressed me and I think that helps there. Question for you before we jump into the meat of this is what does women in tech mean to you and what are you actually doing about it? Not the LinkedIn version, but how are you actually promoting that forward? Because I see this as a great movement and you are a shining star of that movement in my opinion. **Nnenna Ndukwe (07:40):** It all comes down to community and community in general is something that I value, but as a woman and as a black woman, I'm in different multiple communities. I just see in my investment in women in tech, my involvement. I know that there are so many women in the past who have helped me, practitioners who are just super experienced and skilled, who have extended a hand to me to train and teach me, to encourage me to provide pathways forward and put resources or connections or network in front of me when I didn't have that in tech. So many women have helped me along the way and it's like, why not turn around and participate in helping others move forward, whether that is my peers or people coming up with who are newer to the industry and anyone who is curious, maybe they're AI curious or they're tech curious, provide a space where they get to be curious and provide them with the resources and the knowledge to really explore different pathways. Why not do that? And since I've been lucky to have encountered so many incredible women in tech and so I'd like to find ways to host workshops and any type of enablement sessions or programs, I'm able to do that through women applying AI and a few other orgs. And I hope to see more of that to bring women into the conversation to find their passion or interest within the domain of AI and push that forward. **Nicky Pike (09:10):** It's pay it forward, right? You've taken all the things that have helped you get to where you're at, which is incredible paying that forward. It's absolutely amazing. And I, for one, yes, please reach out to Nnenna. 100% she's going to help you out. And I think with that, we're going to go ahead and jump in here and I want to lay out the challenge. And the challenge on the table is that CloudBees in their 2026 report, they found that about 81% of enterprise tech leaders were seeing more production failures tied to AI generated code. And that's a litle bit different than what we're hearing about. Everybody's talking about how this is helping developers, now it's increasing productivity, but they're seeing more failures in code when it comes to production, not less. And so everybody's pointed at AI as being part of the pipeline that was already fast at writing code, but we ignored the part that was already slow. The output went up, the gates that didn't and now production is paying for it. So how does this end any differently than any other adopt now governed later technology hangover that we've lived through already, right? And that's what we're going to be digging into. So the first question for you, for years, the whole industry chased the same thing. They chased developer productivity, but you've made the point that the inner loop was never really where things got stuck. So where was the jam actually happening in your eyes this whole time and why did anybody just aim AI at the wrong end of the pipe here? **Nnenna Ndukwe (10:30):** I would say with the inner loop, outer loop conversation with AI, there was been so much excitement about what it could produce because that's the generative side. But what I think is a harder problem has always been the overall software delivery process, really how to optimize and govern and observe that and make really intelligent decisions about what are the patterns here, where are the patterns where we're slower or what are the type of incidents that we keep coming across and how can we prevent that in the future? I think that the process of planning and implementing and reviewing and then merging and deploying code, that's been functioning well to a degree and there's different variations of how to go about that underneath the hood of all that is the SDLC. But there are certain processes related to people I think like the overall system that seems to have been broken that they're not things that can be easily solved with AI. I think that's the human aspect of it and being able to analyze the full delivery cycle and whether that's really truly efficient or not. But AI has been exciting for on small slice of being able to generate code. **Nicky Pike (11:41):** We've got the idea now of citizen development, the idea that anybody can be a builder at this point and it's been a top use case along a lot of enterprises that are looking to bring AI in. And I think that's kind of what leads to that people aspect that you're talking about. Now that we've got anybody can use AI to build code, we're seeing this output explode, but we're also seeing it pile up at review time. We still got companies that built these huge pipelines to basically look at, approve, make sure the code's secure and then release it and that is starting to back up. Now one of the things that we look at is you've been watching a metric that I think most teams haven't been and it's something that I want to talk about here, which is the rework rate. How often are developers having to go back and fix that AI assisted code? Or in the case of citizens and developers, how much does somebody technical have to go back and review a code that somebody non-technical wrote? What is it that the number tells the truth right now? Why is that number the one that makes the most sense to you? **Nnenna Ndukwe (12:39):** So first of all, it is adjacent in some way to like the change failure rate. And I think it's important because that is a signal for whether or not GenAI assisted changes are improving or helping the software delivery velocity without sacrificing software quality. I think that is what it could point us to. If we want to really reap the rewards that we were promised about AI for developer productivity and shipping software, then we need to consider is AI on the other end potentially contributing to more incidents or more issues with having to do rollbacks because of issues with the deployment due to the quality of the code. And we've seen certain large orgs actually put out articles about that and I won't say the name because I don't think I can, but they did make that public that they had proof that GenAI assisted changes were resulting in incidents and outages that lasted far longer than they should have and that they need to go back to the drawing board on training and enablement for more structured, more secure practices around a shipping code with AI. **Nicky Pike (13:53):** So let's dig into that right there. Do you think that's because AI is producing bad code? Do you think that's because maybe people are just rubber stamping the code going through and they're not really paying any attention to it? Or is it a combination of both? Because I think there's a couple different thoughts that could be pulled from that. **Nnenna Ndukwe (14:09):** I think it's a combination of both. I think that the way in which you wield agent harnesses is an education aspect. First of all, you need to have experimented with and sought out the information or be trained to follow best practices. Then you actually have to decide to implement those best practices. So there's knowing it and then there's actually doing it. And then there's the part of the code review and the verification checking for the level of quality. When you've got a lot of pull requests coming in, when you've got a lot of code changes moving into the pipeline, I think that there's a bit of a cognitive load issue there with being able to review all of that code as a human with the same level of scrutiny that you would in the most consistent way possible. So there's some issues there and I think that it's much easier to just rubber stamp and kind of like hope for the best, right? **Nicky Pike (15:05):** And I think you framed the problem right there is we've got generative AIs coming out, we're producing all of this code now. We know it's causing bad problems, so we need to review it more, but you kind of got a chicken and egg there. Our output of code has went so high that it's almost unreasonable at this standpoint to think that we can go in and look at all that code and make sure that it's valid. So now we're kind of getting into the area that you play in. Do we need to start looking at how AIs review the code for us because everything's happening at machine speed. We're hitting a bottleneck here where humans can't keep up with the output. What are your thoughts on that? **Nnenna Ndukwe (15:40):** I think in general, what we will see is we started with AI code gen as this obsession and actually building out solutions to do more of this through different harnesses that are available now. And now we've approached this code review bottleneck, which we just spoke about now. We're going to see even more solutions and that's what we're building at Codo. For example, it's an AI code and governance platform, AI code review and governance platform. So we're going to see this focus on, okay, we need to get better at being able to not only review the code but to provide fixes for the highest signal issues that are found because not every issue is valued or the same or of the same level of significance or severity. And so AI code review solutions that are able to analyze the code from different angles, security and code correctness and maintainability of your architecture and your team standards and different aspects of that and produce the highest signal findings that can help I think a human dynamically review code and determine which PRs actually need my attention the most that need me to have that deep work time that I dedicate to it and which ones are actually like lower risk and I can move that through the pipeline. I'm hoping to see that we have statistics around it that's showing that it's helping teams, but I want to see a lot more of that. And so there's more aspects to code review and code quality gates that I would like to see get implemented not just at that PR stage, but post merge and even earlier at the code en phase too. Well, **Nicky Pike (17:19):** And there's a secret that I think you said right there, which is you got to be thinking about this stuff before you even bring in AI because you had said something about teams that whatever's good or bad about a team today, AI is going to amplify that. If they've got a clean proces, AI is going to put your team into orbit. If they've got a messy process for review and the pipeline and the golden path, then they probably just strapped a rocket onto the chaos and we're going to see them blow up on the launchpad. So before anybody buys a tool, what's the work that you think that has to happen first? And I think you were starting to get into that a little bit. **Nnenna Ndukwe (17:53):** Yeah. So I truly believe, and I said this months and months ago, I truly felt that AI will amplify and exacerbate your current processes now. So if you've got some great efficient SDLC processes, then AI is going to be your best friend and it's only going to take that to another level. If it's broken, then that's where you're going to see more brokenness. **Nicky Pike (18:20):** Let's take that back one step. So again, what do they got to do first? If you're seeing a rework of human code that's 20%, then you can expect that if you add AI to that same kind of broken process, we may see that go up to 40, 60% because you're amplifying the process you already have. So am I hearing you right and the first step that you think should be happening with AI is evaluate what you've got, right? Evaluate where you sit because there's this old platform engineering adage, you can't automate what you don't understand. The same thing, you can't amplify or you can't increase the output of something that you're not doing well already. Is that a fair statement for you? **Nnenna Ndukwe (18:57):** I think that's the right framing. You need visibility into the systems if you want to know how to improve it. And I think in this case that visibility is understanding and being honest about the current state of your processes, your SDLC and once you're honest and you can look at the pros and cons across each of the stages, then you have opportunity. Now you have the opportunity to tackle certain slices or stages and say, okay, without AI, if we can improve or get back to how can we refine this, then we'll be in a better condition to actually add AI to make it even better. That's the approach that I would take at least to start. **Nicky Pike (19:39):** Okay. So here's where this gets really interesting. Nnenna just told us something that should stop every engineering leader cold. Whatever your team is today, good or bad, AI doesn't fix it. It amplifies it. Clean process, you go to orbit. Messy one, you just draped a rocket onto the chaos and you're going to blow up on the launchpad. So after the break, we get to the part that nobody wants to talk about out loud. We already watched developers rubber stamp the code that AI wrote. Now we're handing AI the code to review as well. So what stops the whole thing from being one big slot machine where a robot flags it, a human clicks approve and nobody actually reads a single line. Nnenna's got a sharp answer on where she thinks the real gate lives, the one number that she trusts over every other vendor benchmark and why she went anthropic in public with six words. More tokens is not engineering doctrine. Stay with us. That leads into the next, right? Is the one thing that really everybody's kind of talking about right now is the AI slop when it comes to code, but nobody's really talking about the place where you play, which is the AI slop in code review, right? We've watched developers rubber stamp AI generated code. We talked about that and now we're talking about because of the speed, we're having to hand AI the review itself. So what do you think stops that from becoming the exact same slot machine? AI is going to flag it, the human's going to click approve and nobody actually reads any of it. It just goes through and it contributes to that rework metric that you're talking about. **Nnenna Ndukwe (21:08):** That is such a good question. I just recently hosted a code quality in the age of AI workshop with lead dev and our field CTO and I specifically dedicated a slide to code review versus verification because I think like a code review AI tool is just going to give you suggestions. And also if you don't think the results are relevant, a developer might get into that groove of just rubber stamping or ignoring the results completely and doing their own thing and just moving code through the pipeline. So I think that we've got to take that a step further with verification and I think verification has some elements of deterministic equality gates in it. I think that being able to stop code from being merged or blocking emerge for issues that seem high severity based on all the proper context that an AI code review or AI code quality system or tool has. Now that catches the attention. Now that's something that is recorded as a part of the Git provider or tool or experience that you have. And so I think deterministic quality gates is one thing. Lindters. I have never had a problem with linters when I was using it when GenAI for code wasn't a thing. There was a system and a structured way that I needed to have for the shape of my code. There's conventional commits. So that was something that I also had. There was a structured way of pushing code and making commits and moving it onto the next stage. I think it's okay to be leveraging the best of the non-deterministic traits that AI has as well as some deterministic tooling and enforcement as well that is baked into our existing developer tooling interfaces. I **Nicky Pike (22:55):** Think a lot of vendors out there are waving around a benchmark, "Hey, we're great at this. " But you said the number that you actually trust the most when you're seeing it from your product or others is the acceptance rate. The percentage of what AI's comments a developer reads and goes, "Yeah, that's right. I'm going to take it. " Why do you think that's the signal that cuts through the marketing noise that we're hearing with other vendors? **Nnenna Ndukwe (23:17):** I don't like to use benchmarks as an exact example of how a tool would function in reality in production with different developer teams working on different software. A lot of variability there in the real world. So what some of that can come down to around the quality of a tool is the developer experience. And if developers are actually trusting the AI suggestions that they see and if they're like, "Okay, this makes sense. Oh, this was a subtle change or this is a subtle issue that I wouldn't have caught while reviewing the code." And you're actually accepting that new code suggestion or accepting that, okay, I'm going to take an agent prompt and copy paste it in my coding agent and solve it in the way that this AI code review tool is telling me to solve it. Now we are onto something. I think that that would be a signal that there's a trust layer that is actually being built between the developer as a practitioner, as a person with that final judgment and say, and the technology that is supposed to help and augment that process. **Nicky Pike (24:19):** How do you differentiate between, yeah, trust, I believe that the AI did what I wanted it to do versus rubber stamping. How do you make that determination? **Nnenna Ndukwe (24:29):** That's a difficult one. So there are ways to actually find out from your developer or developer teams their sentiment about a tool. And I think that gauging from them, you can do that through surveys when you're actually evaluating all of these different tools and because if the developers don't like it, they're not signing off on it. So gauging this sentiment I think could help peel back the layer of what their experiences are with that tool, especially versus or comparison to another. And that can help to separate the difference between I'm just going to accept the suggestions or asking the right questions to the developers who are using this tool to uncover, have these suggestions actually been useful to me Because if anything, we know that developers are opinionated, right? I know that I'm incredibly opinionated just a little bit. And we know that we get complaints. In the AI code review tool space, one of the biggest complaints is noise, right? Too much noise, too many comments are being added, flooding my PRs and too many comments that are not very relevant or as super high severity things that I should pay attention to. And I think that's another side of what would get the attention of a developer to then be able to give an opinion on whether a tool is useful to them or **Nicky Pike (25:50):** Not. One of the things that I've heard through is some companies are going in and they're writing instructions for their AI that no big PRs, right? They're limiting it that to maybe 100 or 300 lines at most. That's what the size of a PR has to do because they believe that it helps the human be able to review that. Plus it also prevents or hopefully prevents that rubber stamping because now I've got something that I can actually get through in a short amount of time. What do you think of that methodology? Do you think they're going down the right path? Do you think that's something that we could build into tools themselves rather than just an AI prompt? **Nnenna Ndukwe (26:24):** That's an awesome way to approach. I see that some of the development or software development methodologies that we've had in the past can still and should be considered to apply now like trunk-based development, for example. If you look at all of the different methodologies, like that includes test-driven development or test first development, that can and should be encoded to the best of our abilities, whether those are actual independent solutions or there are different mechanisms or tools that come out like agent skills, for example, that can allow this to not be as much of an agent-centric experience and more of a human agent experience where we need to be able to work together in tandem. I need to be the person who is the final judgment layer and I need to encode my values and my methodologies into how agents work. **Nicky Pike (27:16):** I really like that sentiment, more of a partnership centric with your agent. And that brings me up to kind of one of the other follow-up questions when you were talking about trust. But here's a question and you may not be able to answer this, it kind of just popped in my head. Everybody's using a model. You guys are using a model that goes through and helps with these reviews. Those models are changing at a rapid pace. Does the model change? It seems like that could have impact on trust because there's very big differences between Opus and Haiku and things of that nature when we're talking about Cloud. Maybe I did trust it and then we moved to a new model. Do I have to go through that whole trust exercise again with the new model? How do you guys kind of approach that when you're looking at bringing in a new model to the tool? **Nnenna Ndukwe (27:56):** For myself, I will say I think that everybody's experiencing that. When a new model comes out and then when you choose to use it, there is a bit of a learning curve or there are some differences that you experience and so kind of having to go through that process over and over again every time there's a new model. But with how we do things at Qodo, there are multiple models that we're using for different tasks and sub-tasks within the overall AI architecture and the different agents and all the things that they need to do in parallel. So we're constantly evaluating different models as they come out. That also includes some open weight models too. And so to determine which model would be good for which of these agents are tasks and do we want to officially bring that in when we compare it to any of the past iterations to then power the newer latest version of Codo. A lot of evaluating that goes on and luckily we've got an R&D team that is totally, completely dedicated to that because that's a ton of work. **Nicky Pike (28:59):** This is something I've been saying for a long time that I do think that this one model to rule them all is very quickly going away. OpenWeight models are coming into Vogue now using different models for their capabilities rather than I'm just going to commit to one model, the ability to swap. I love to hear that you guys are doing that same thing over on the tooling side as well. Speaking of using models, now one of the things that I saw on LinkedIn, you wrote this piece where you pushed back on Anthropic's Boris journey, right? And it was the idea that if you throw enough computed agents that they'll do the work well and your line was more tokens is not engineering discipline. I loved reading your take on this. Tell the audience, where did you think that he was technically wrong and why did you think that framing was dangerous for an engineer who might want to hear this and run with it? **Nnenna Ndukwe (29:45):** I think that more tokens is not technically wrong. He's right in the fact that an agent can probably eventually complete a task the way that you want it to if you just throw more cont Cute at it. But I think it's really dangerous because it's a tactic for maybe some in the moment or ad hoc things. This can't be the mentality about tokens and agents and how we use them in general for software engineering. That's when it starts to get dangerous because the incentives, I think it just changes the incentives around what it means to build things with quality. I think it changes the shape of the software development lifecycle experience. And also when I think about tokens and the cost and how we went from token maxing to, I think it was the pragmatic engineer who said there are now some engineers at certain firms that are getting rewarded or they're getting bonuses for using tokens efficiently now instead of token maxing. So yeah, that is not the practice of what it needs to be a good engineer. And I don't want tactics like that to be used as an actual principle for how we try to ship code with AI. **Nicky Pike (31:07):** We're going to link to your tweet and what you wrote on that because it was really nice and I do agree with you. You're getting away from engineering when you start looking at things like, I guess you could say it's kind of engineering to say, how can we best use tokens? But just throwing compute at the problem, letting more tokens go through, you are losing that. How do we architect? How do we build something new? And you're giving more authority over to AI rather than the human that needs to go in and actually build something of business value. And I do think that that is a very bad approach. And on your whole token maxing thing, this is something that I laugh at when I hear about it because it's like, "Hey, we're incentivizing people to use the most money that we possibly can. " And we know developers, right? If you give developers free reign, they're going to reach for the biggest, most expensive thing that they can use. Do we want them using Fable F to go in and write a couple comments on their line or to document their code? It's the same problem that we saw. I need a hundred CPUs to run a web app problem. So from your perspective, and this is something that looks like you don't necessarily agree with either, how does a platform team control those costs without neutering the developers or becoming a villain and being accused of stopping their work? **Nnenna Ndukwe (32:18):** I just had this visceral reaction because I was like, "Don't take my models away from me." **Nicky Pike (32:23):** Right. **Nnenna Ndukwe (32:25):** I think we just need to have more efficient model usage. That's how CODO itself, like the actual system is leveraging models. It's about balancing the cost optimization with performance and of the quality of the system itself. I think we can apply that same concept to the different models that we use for different tasks. There are tasks that are far more intensive and maybe like deep work that would be a good, strong use face, more complex, that would be good use cases for more intelligent, more capable models. And then other lower risk tasks and less complex tasks that could be used that you can use probably one of the less capable models for. **Nicky Pike (33:10):** I have that same reaction because everybody's got their favorite model 100%. Everybody's got their favorite model. Don't take that away from me or you break my workflow. But it feels like this almost needs to become a part of that pre-engineering thought before you adopt AI is again, you don't want to use Opus 4.7 for documentation. You want to save that for where you really need the token work. And it feels like that might be a recommendation out to companies. I know it's one that I make is you need to think through how you're going to use AI and where it makes sense because it doesn't make sense to go in and use AI if you're going to quadruple your cost because you're using the most expensive model to do something mundane. And there's an engineering principle there on the platform, which models and how you're going to route. And it's awesome to hear that Kudos doing that yourselves and how y'all are using models. Are you trying to build this into any of your workflows today when you're not just using the tools? Are you trying to build in that model routing yourself? **Nnenna Ndukwe (34:05):** I wish you didn't ask me that because I love GPT 5.5 extra high and fast and I'm willing to pay for it. It's so easy to kind of get attached. It's like a dopamine hit. When you get attached to the speed and the quality, then it's like, well, why not have this speed and quality be applied to literally anything that I do or touch? So right now I would say I don't have enough incentive to switch my models for the work that I'm doing, but maybe if I were to go all in on this open source tool I'm building called PolicyNim and it's about encoding engineering standards into coding agents so they're forced to consider them when you're trying to complete a specific coding task. Now, if I were to go all in on that to become like a real open source maintainer, then I think that my AI native dev workflow would need to be far more efficient and I'd have to take that route we were just talking about. **Nicky Pike (35:03):** Well, and it feels like there's a division line there because I mean, I imagine that we're definitely seeing it here in coder where there's almost been fist fights, ChatGPT versus Cloud versus Gemini, which one's the better one to use? And I think it's subjective to everybody's point, but there's a division line there and I think this is what enterprises and developers are going to have to think about is from an enterprise perspective, from a cost control and observability perspective, we have to build this engineering in. I can't just let my developers go free reign. Developers go and use the model of their choice because they built workflows around it, but I'm not sure how that's going to mesh within the enterprise world because you can't really have both of those at the same time. You can't allow with the coding work for it to go and be routed by allowing your developers for all their other work, use something where you're just going to see your token cost go up there as well. **Nnenna Ndukwe (35:49):** Yeah. I think we're going to see a bigger focus on the efficiency and optimization in general. And I think that there'll become something more standardized or more prevalent across organizations for incentivizing this shift to be more efficient with the different models that you're using for different tasks in order to save, yet still produce high quality work. Whatever that balance is that we find, I think we're going to build some type of incentive models around that in the industry for organizations. **Nicky Pike (36:23):** It's a repeat of the same pattern. How do we get the most value for the least amount of money? And everybody's going to be looking through that. I don't know where this is going to go, so I'm going to ask you one more practical type question from your experience. VP of engineer is watching this. He comes to you and he's, "I need to do AI. I need to keep up with the rest of the industry, but I have no idea where to start." Give that VP your Monday morning version of what the actual first move should be that they should take this week. So the one place that they need to start on and the one place that they absolutely should not point AI to. **Nnenna Ndukwe (36:56):** I think the first place I would start is having a really strong or deeper understanding of your code base, your systems, and being able to divide then between which projects, initiatives, products are business critical paths, which ones are more experimental prototype playgrounds and essentially do this like risk model assessment of where is it safer to introduce AI if we do want to go through this phased rollout That will help with being able to understand the blast radius of your changes and feel more confident about that exploration process. If you haven't mapped that out, that's the very first place that I would start is then you can begin the experimentation for different teams and different repos and for the SDLC for those teams safely. **Nicky Pike (37:49):** You just gave an answer that nobody else has ever really given before. Most people are start talking about, well, look at how you're going to control the agent. You actually approach this from a business case, which is risk profile your code. Don't put agents into the code that makes you the most money right now where you have the greatest risk. Start it out on something small like citizen developer work cases or here's some code that we're using internally that we can try this on. If it goes bad, yeah, it might hurt, but at least it's not going to cost us money. I hope you take that with more and more as you're starting to talk to more and more enterprises because I think people will listen to that. **Nnenna Ndukwe (38:23):** Glad that you think that because that was months ago. I created a whole AI code adoption governance framework and I posted it on Kudo's resources and it was just kind of an idea that came to mind from after having a few enough conversations. I was like, "I think there's something here." **Nicky Pike (38:40):** All right, here we go. Rapid fire questions. I'm going to hit you with some really quick questions. I don't want you to think about them too hard. Just kind of give a, "Hey, here's what comes to mind and here's my quick thoughts on it. " You ready? Yep. All right. AIDLC, this is a real shift or it's just a rebranded buzzword? **Nnenna Ndukwe (38:57):** Rebranded buzzword. **Nicky Pike (38:59):** AI coding metric that needs to die tomorrow. **Nnenna Ndukwe (39:01):** Lines of code. **Nicky Pike (39:03):** I don't think that should have ever existed in the first place. Do review bottleneck gets solved by better tools or better humans? **Nnenna Ndukwe (39:12):** Right now, better tools. **Nicky Pike (39:14):** Better tools. All right. More compute or just better prompts? **Nnenna Ndukwe (39:19):** More compute. **Nicky Pike (39:20):** More compute. AI, you'd actually call a good coworker right now and the one that you would kick out the door tomorrow. **Nnenna Ndukwe (39:27):** Good coworker. Best coworker right now is Codex. I think the one that I've kicked out, I'm not using it at all, so I don't have one. Don't have **Nicky Pike (39:36):** One because I only use things that help me. **Nnenna Ndukwe (39:38):** I'm very picky. **Nicky Pike (39:39):** All right. Tell me why Codex. **Nnenna Ndukwe (39:41):** I love that I was able to just easily integrate so many different tools that I'm using plus using my favorite model, GPT 5.5. And so I get to be a full-fledged coder and developer advocate and I don't know, thought leader and all in this one place that I don't know, it just feels very intuitive. It doesn't feel like an IDE. It's just like a true workspace and it's just very effective, very fast and understands exactly the mission that I have every time that I prompt. **Nicky Pike (40:15):** So we're getting a litle bit outside the rapid fire, but I'm interested. Do you think that that has to do with because you love ChatGPT that influenced your case or do you think it's really because Codex gives you something that you can't see with some of the other tools? **Nnenna Ndukwe (40:28):** I was never the biggest fan of ChatGPT. I do use it for some creative strategy work and that's literally it. I was always using Claude Code and Cloud for everything, but Codex provided a different personality, a different interface that I found to be quite useful for the wide array of developer work that I wanted to do, like in open source or different tools. I felt like I could actually manage that experience easier in Codex and get all the benefits of how many cool new features that they're shipping out, like the automations. Now I've got automations running for my projects always cleaning them up, so it's exciting. **Nicky Pike (41:08):** Excellent. So it's the tool that fits your method of work the best? **Nnenna Ndukwe (41:11):** Yes, it is. And that's also why I became a Codex ambassador. **Nicky Pike (41:15):** There you go. All right. Well, and now we're coming up to the end of the show. So now we're going to put you in the hot seat a little bit. We always end the show with some predictions and one final question, so I'm going to start with some predictions. It's 2030 AI isn't a toggle anymore. It's just how people are getting work done. Walk me through what you think a developer's actual Tuesday morning looks like. What are they spending the day doing and how much of it is actually writing versus deciding what's good enough to keep? **Nnenna Ndukwe (41:42):** I think that probably in 2030 we're going to see 95% decisions, maybe 5% of writing. I think there's just going to be more of a managing systems and processes and knowing dynamically when to actually get into the wees. And I think that is going to be one of the biggest metrics of what a good developer is and who knows if the word developer will even be the title. But yeah, that's where I think that they're headed. **Nicky Pike (42:11):** Well, and one of my favorite responses to this was when I asked a question like that, somebody said, 2030, man, we're talking about AI. Ask me what's going to happen in December of 2026. That's still a prediction because nobody knows with how fast we're moving. **Nnenna Ndukwe (42:24):** Yeah, I agree. I try to think of there's people at the forefront and organizations who are moving super, super fast. And then there's a majority, that's why they call it an AI bubble. There's the majority of societies nowhere near that. So I'm trying to account for the full spectrum **Nicky Pike (42:42):** Here. Everybody, not just our little portion of it. That makes sense. All right. So what's your spiciest take on this one? With domain experts now vibe coding real tools, we've got AI doing all the hefty lifting for them. What percentage of what we currently call a developer's job do you think gets absorbed by non-developers with good AI and with the good ideas? **Nnenna Ndukwe (43:03):** Ooh, oh my goodness. This is a fascinating one because we're seeing product-minded people who are curious enough to learn whatever it is they need to in front of them to get a job done, but they have the product instinct. We're seeing them surpass I think the everyday developer's ability to adjust to this AI forward shift. I think that is a signal for what we're going to see be the most valuable and it's those agile creative folks with product instinct who will learn what they need to in order to get to the next stage and accomplish the next thing and get better, 1% better. **Nicky Pike (43:45):** A lot of the enterprises I'm talking to, the citizen developer is becoming one of their top priorities because they've got all of these really smart people out there that have great ideas and we are seeing this explosion of software. Now they're able to actually put fingers on it and do things to it with AI, but we're still talking about AI slot. They don't have the decision making to go in and say, "Did AI give me something good or did it just give me something that works?" What do you think that the IT's role and the software development team's role comes into just polishing up and securing a lot of these domain experts code that comes out as we see this rise? **Nnenna Ndukwe (44:20):** Yeah, there will definitely be a major opportunity or I guess a bigger opening for those with a deeper technical expertise to come in and kind of be a professional janitors maybe in a way and probably get paid a lot to do it, but they will probably also need to be very skilled with AI to figure out how to do it with AI, to do it at a speed that can meet the needs of the market and the industry. So I think that'll be pretty interesting. **Nicky Pike (44:49):** Microservices come out. The whole point of that was to be able to improve code faster. This has taken microservices to the nth degree because now we're able to do the same thing with whole application sets, hold code bases rather than just a part of a code base. And so it's going to be curious to me to watch how enterprises they're going to have tools that different domain experts come up that are competing. How do you pick the best one? How do you pick which one's going to go through and which one that you're going to dedicate some of that software IT's time into perfecting and securing up. It's going to be interesting to see some of the royal rumbles that are going to be coming up in enterprises between domain experts when they create like tools. **Nnenna Ndukwe (45:26):** I can't wait and I'm going to be right there to help them and educate them. **Nicky Pike (45:30):** Just being referee, just jumping in there and seeing what you can make them do. All right, here's the final question. This is the same one that we ask every guest. So after all that you've done, eight years in the trenches, you're trading the keyboard for the strategy room, you're building the case for governance while everyone else is chasing speed. What does it mean to you to be a coder? **Nnenna Ndukwe (45:52):** Ooh, to be a coder. What it means to me is to be honestly a problem solver. No matter what, it's having the skillset to turn a solution into multiple languages or one or more languages that can push you or a thing, a tool, a product, business forward. **Nicky Pike (46:17):** I do agree with you. Problem solver is a huge part of it, at least for me, but this is all about you. What does it mean when you come to work every day? What is it about being a coder? What does it mean to you? What makes you proud to be able to put that label on yourself? **Nnenna Ndukwe (46:30):** Yeah, I think it is being a problem solver. I think it's being a person that has the mental stamina to rise to a challenge no matter how long it's taken or it takes to solve a very subtle obscure bug. You can get into the weeds in order to do it. And that is a very distinct trait that not everyone has, but it shows up and everyone who is a coder and a good one. **Nicky Pike (47:01):** You like to be challenged. Yo like to be stumped and then be able to beat the crap out of whatever's trying to stump you. **Nnenna Ndukwe (47:07):** Absolutely. **Nicky Pike (47:08):** Well, we are at time now. Is there anything else that you want to say to the audience before we go out? Is there any last thoughts, any pearls of wisdom that you want to impart before we leave? **Nnenna Ndukwe (47:17):** I think that no matter what, with all the trends that are coming out, all of the marketing and the fear-mongering or the hype, that's never going to change. Just take AI out and replace it with another tool or a technological innovation. I think it's important to make sure you can cut out the noise, follow practitioners that you really trust who are truly experts in the space and stay grounded in being able to develop and sharpen the skills that are going to really matter in the long term. Make sure you know how to play the short game, but to play the long game as well in your career and to transcend the trends. **Nicky Pike (47:54):** Could not agree more. We've seen all these patterns before. The difference is the speed at which we're seeing it take off and I couldn't think of better advice. We're in a technology where we're always learning and the only way to learn is through community, through the people that you trust. Find those whose word means something to you and absolutely stick with it. I think that is wonderful, great advice, and I think people will really appreciate that. **Nnenna Ndukwe (48:15):** It's great being here. Loved, loved talking to you. Made me a little bit nervous. I was sweating. I don't know if you can tell, but that means my brain was working, which is good. **Nicky Pike (48:26):** Well, that's what I try to do. I want to bring you in. I want to get the real answers from you, not the polished answers. And that's what people come here for. All right. Well, with that, we're going to go ahead and end it and thank you very much for coming on. **Nnenna Ndukwe (48:38):** Thank you so much. **Nicky Pike (48:40):** Thank you for listening to \[Dev\]olution. If you've got something for us to decode, let me know. You can message me, Nicky Pike on LinkedIn or join our Discord community and drop it there. And seriously, don't forget to subscribe. You do not want to miss what's next. Show more ## Featured speakers ![AI Developer Relations Lead, Qodo](https://coder.com/_next/image?url=https%3A%2F%2Fwww.datocms-assets.com%2F19109%2F1788308475-nnenna-ndukwe.png%3Ffit%3Dcrop%26fm%3Dwebp%26h%3D400%26w%3D400&w=2048&q=75) Nnenna Ndukwe AI Developer Relations Lead, Qodo ![Field CTO, Coder](https://coder.com/_next/image?url=https%3A%2F%2Fwww.datocms-assets.com%2F19109%2F1746230577-nicky-pike.jpg%3Ffit%3Dcrop%26fm%3Dwebp%26h%3D400%26w%3D400&w=2048&q=75) Nicky Pike Field CTO, Coder ## Watch more [![ 96% of Companies Run AI Agents. Only 21% Can Control Them](https://coder.com/_next/image?url=https%3A%2F%2Fi.ytimg.com%2Fvi%2FqTRwwcx4QQI%2Fhqdefault.jpg&w=2048&q=75)](https://coder.com/podcasts/devolution/96percent-of-companies-run-ai-agents-only-21percent-can-control-them)[![ Open Weight AI Isn't the Risk You Think It Is](https://coder.com/_next/image?url=https%3A%2F%2Fi.ytimg.com%2Fvi%2FrFFbzoKGMtc%2Fhqdefault.jpg&w=2048&q=75)](https://coder.com/podcasts/devolution/open-weight-ai-isnt-the-risk-you-think-it-is)[![Why Developers Are Ditching AI and Talking to Humans Again](https://coder.com/_next/image?url=https%3A%2F%2Fi.ytimg.com%2Fvi%2F-DYZyPLovjc%2Fhqdefault.jpg&w=2048&q=75)](https://coder.com/podcasts/devolution/why-developers-are-ditching-ai-and-talking-to-humans-again) ## Additional content Read more in these blog posts. ## Additional content Read more in these blog posts. [![A blog post thumbnail image with the title and small purple icon](https://coder.com/_next/image?url=https%3A%2F%2Fwww.datocms-assets.com%2F19109%2F1784830943-blog_when-anyone-can-build.png%3Ffit%3Dcrop%26fm%3Dwebp%26h%3D324%26w%3D604&w=2048&q=75) AI • Jul 23 2026 • 3 min read ### When Anyone Can Build: Gene Kim on What Vibe Coding Breaks First ![Nicky Pike](https://coder.com/_next/image?url=https%3A%2F%2Fwww.datocms-assets.com%2F19109%2F1748473544-nicky-pike-linkedin-image.jpeg%3Ffit%3Dcrop%26fm%3Djpg%26h%3D100%26w%3D100&w=2048&q=75)Nicky Pike Read more](https://coder.com/blog/when-anyone-can-build-gene-kim-on-what-vibe-coding-breaks-first)[![A blog post thumbnail with the title over a light background](https://coder.com/_next/image?url=https%3A%2F%2Fwww.datocms-assets.com%2F19109%2F1782244428-blog_five-months-to-patch-one-day-to-weaponize.png%3Ffit%3Dcrop%26fm%3Dwebp%26h%3D324%26w%3D604&w=2048&q=75) Jun 23 2026 • 3 min read ### Five Months to Patch, One Day to Weaponize: CVE Remediation Has a Math Problem ![Nicky Pike](https://coder.com/_next/image?url=https%3A%2F%2Fwww.datocms-assets.com%2F19109%2F1748473544-nicky-pike-linkedin-image.jpeg%3Ffit%3Dcrop%26fm%3Djpg%26h%3D100%26w%3D100&w=2048&q=75)Nicky Pike Read more](https://coder.com/blog/cve-remediation-dashaun-carter)[![Blog thumbnail image with the title over a dark background with a purple icon.](https://coder.com/_next/image?url=https%3A%2F%2Fwww.datocms-assets.com%2F19109%2F1781801403-blog_everyone-said-ai-would-kill-developer-community.png%3Ffit%3Dcrop%26fm%3Dwebp%26h%3D324%26w%3D604&w=2048&q=75) AI • Jun 18 2026 • 4 min read ### Everyone Said AI Would Kill Developer Community. The Opposite is Happening. ![Nicky Pike](https://coder.com/_next/image?url=https%3A%2F%2Fwww.datocms-assets.com%2F19109%2F1748473544-nicky-pike-linkedin-image.jpeg%3Ffit%3Dcrop%26fm%3Djpg%26h%3D100%26w%3D100&w=2048&q=75)Nicky Pike Read more](https://coder.com/blog/ai-and-developer-community-pauline-narvas) ## Subscribe [YouTube](https://youtu.be/Hp3xpmDarHM)[Spotify](https://open.spotify.com/episode/5TwIOQCLP6UqVT6A7dAWAs?si=WpRNHl0eTOqhgITzrYH0Mw)[Apple Podcasts](https://podcasts.apple.com/us/podcast/ai-is-writing-more-code-than-humans-can-review/id1839475248?i=1000778867585)