Making sure that what you’re building is what users want is a big deal. “It’s not the final version, and we may need a bit more time to adjust and to reiterate,” shared Irina Kamalova, an engineer with over 10 years of professional experience. Irina and I had an interesting conversation in December 2025 at the apidays conference in Paris. We discussed the wide availability of AI coding tools and what the implications are for software quality. One of those implications, according to Irina, is that it’s easier than ever to create prototypes. I’ll stop here and let you watch the full recorded interview.
This article is brought to you with the help of our supporter, Scalar.
Scalar is the modern OpenAPI platform for the entire API lifecycle. Govern APIs with Scalar Registry, test offline with their built-in Client, generate beautiful documentation, and ship SDKs instantly - all from your single source of truth.
The “Behind the APIs” interview series is a collaboration between Scalar and the API Changelog newsletter.
Here’s the transcript of the “Behind the APIs” session with Irina Kamalova. Parts of the transcript have been edited for improved readability.
Bruno Pedro: Hello, my name is Bruno Pedro, and I’m here today to do one of the “Behind the APIs” interviews. So, this is a collaboration between Scalar and the API Changelog newsletter. We’re here at the apidays conference, at the venue, and I’m here with Irina Kamalova. Hi Irina. Irina is the co-founder and director of the Women in Coding community. This is a large community with around 4,000 members, I’ve been told. The community helps women get into technology and coding APIs as well. So, it’s a great initiative. She’s also the VP of Lead Software Engineering at JPMorgan Chase, and she has a lot of interesting ideas around API prototyping and AI-related software development. So, hi Irina. Thank you so much for being with me today. I hope you’re having a good time at the conference.
Irina Kamalova: Thank you. Thank you so much for the introduction. It is very nice to be here. Thank you so much for hosting. Yeah, so a little bit more about myself. Overall, I have 10 years of experience as a backend software engineer, and I’ve worked for different companies. I worked for Revolut for three years. So, I built very diverse experience around different platforms and how we build APIs and the actual software in backend side of things. So, today I’m sharing my career experience, and I’m really glad to do this. And yeah, thank you for mentioning the Women in Coding community. With this initiative that I’m running for a few years and indeed helped a lot of women to grow up and switch careers to IT, and do not give up and do not quit these careers because we are here to support women.
BP: Nice, nice. That’s a great initiative, and thanks for leading it. I have here a few topics that I know you’re interested in, just to get us started. I know this is a topic that many people are interested in as well: AI-related development. So, what do you think are the interesting approaches nowadays? We see a lot of people using different tools and doing things in different ways. What’s your take on this?
IK: Yeah, so it’s an amazing time, and I’m really lucky to be here at the apidays conference in the era of AI. So, tools that I see on the market are emerging as generative AI, generative agents, and it’s amazing when I try them for my personal projects. I see that by just using trial, I would encourage everyone to try things like Junie, which is JetBrains new like copilot but from JetBrains. I’m Java world, so I love IntelliJ IDEA. So I started to try a Junie for a personal project, and I was impressed by how many things it could optimize, bring, like, okay, build an application in a much faster way. Of course, you need to still have a foundation. That’s what I tell all students, like they’re asking me what to do with GenAI errors, etc. And I tell them that you still need to be able to validate the input that all these generative AI tools are doing for you. So, at this moment right now, I believe that the fundamentals of how we build software, how language works, what issues you may meet in production if you use even generative AI, like what’s under the hood. So, you need to be able to correct those tools, to correct and to guide them on how to do it right. They made mistakes; you need to be able to validate those mistakes. So, for me, tools like Cursor, I think you’ve heard about it again, Copilot, and even with Copilot, it’s possible to use different models, Claude is very good as one. So, there are many that are coming, and they compete with each other. So, it’s also interesting to compare models with each other. You try one model, you see one result. You try another model, you see another result, and you can say, “Oh, that’s actually a bit better. That’s working in the context that you give them. They gas better.” There is still a problem of hallucination. That’s how we call it. That’s models hallucinated. So, they’re basically trying to give you some result, and you can see that actually it’s not what it meant to be. And sometimes, it’s also disappointing when a model just gives you something like, “Yes, I can read it, and I can’t understand it, and I can do over communication around it.” Like I can say many more things, but you can read these things as well. It’s good to learn how to communicate from these tools as well. Like how to describe even some processes by myself, I may not have all the time all these words. But that’s somehow these tools could be useful today.
BP: Are these tools, in your opinion, more like generic programming tools, for example, like an IDE, or a code editor? Or, do you think you can adapt them to the reality of how you code inside your company? So, for example, I’m sure that inside your company, you follow certain standards or certain rules for coding.
IK: I would say, in any company, you build a team and the best way to do it is with a very good lifestyle that you can adopt as a team, any company anywhere I worked. For example, I worked once for Yandex, and I’ve been in a team, and another team had another style, and another team had another style. They used different libraries, and it was like a zoo of different technologies, and it’s always in Scala. Scala was so new it was this moment, like it was seven or eight years ago, and they just adopted libraries whenever anyone wanted. To be honest, it was so hard to develop in this culture because just do small adjustment in the service that another team handling instead of waiting for them like in their changelog when they do this. It was so hard. You had to learn the whole framework that they adopted because they couldn’t even read what they wrote. After all, it was so hard. So, in my opinion, teams and companies should do very cool, clean style what they want. And then we come to generative tools. It’s becoming very hard to adapt them indeed because they need to learn first from your context. You need to explain them like, “Oh, I want to do this in this way, that in that way.” And at some point, so that was a little bit more in my talk, tracing bullet development, prototyping, and something I didn’t put in the title, but we can think about traditional development when they didn’t use any generative tools, because sometimes it’s actually easier and faster just to write by yourself in the code style that was adopted. So, this is what I see right now.
BP: Yeah, thank you. You mentioned something interesting. I didn’t know that terminology before reading about your talk. Tracing bullet developments. So, this is quite an interesting concept. Can you share a little bit, you know, your view on that and what the benefits of this style are?
IK: Yeah, so unfortunately, it’s not me who invented this term. I found it in the book “The Pragmatic Programmer.” And I won’t recommend this book because it has references to very old technologies like Smalltalk language, something like that. But I found what I liked. For example, another concept is “cat ate my code.” Like, there was something funny about coding at this time, 30 years ago, that you actually put a lot of responsibility for your code base. So, you can’t say, you know, like “my homework was eaten by a cat.” Like, you can’t say give the same idea about code, right? So, now it’s very interesting in generative AI. What should we say right now? “Oh, I didn’t generate my code.” You can’t say this; you should still be responsible for this. So tracing bullet development is the idea that brought by this book and the idea is that when we try and to build new product it’s actually very hard to get all requirements at the same time in front of us and the mistakes that we can make dig too deep to these requirements before even start to build anything because and we live right now in very changing and fast-paced world which is kind trying to forever do specification. So, tracing bullet development suggests that before you even reach the goal, you actually, instead of “ready, aim, fire,” you do “ready, fire,” and then aim. So, the idea is that you fire the first tracing bullet, you see where it goes, and you see how close you are to the goal, like to the end user to the end product. It’s different to prototyping because you would use prototyping when you have no idea how market will react on this product and prototyping is good for startups, especially on pre-seed, seed rounds, series even A maybe we still would prototype a lot of products because we may launch it and say like actually it’s really not needed for clients right now, but now it’s coming another idea what exactly the gap that clients has and what we can cover. So, that’s how we can survive through the first few first over rounds. We need to be able to change our strategy. So, that’s why we can use prototyping and just throw away our coding base. But when we talk about tracing bullet development, we’re saying that we already have some products, we already have some style, we already have some tools. We already know what clients want. We already know some critical flows that we have to implement. So, in this case, we can try tracing the bullet because we may not know all the things that we need to implement. We may not need all specifications, all details, and we may still have to remodel our models, which is the hardest thing to do with models when you build software. So, we are ready to take this risk and rebuild it. We communicate very well about all this business, as it’s not the final version, and we may need a bit more time to adjust and to reiterate. However, we start to deliver MVP to our business, and they see how first they were well, a kind of prototype. Still, it should be clean code. The idea is that it’s still clean code. It’s very responsive coding because these parts we may be throwing away some parts, but we still have another part. So we still build it in a very object-oriented programming, for example. We use all our frame like what design patterns, etc. So we use it carefully, we cover it with tests because we still build scalable, reliable software, but we do not build the final version right now.
BP: Interesting. Interesting. Interesting. So the difference with prototyping, you were saying, is more like prototyping is when you’re on that stage where you’re still exploring what you want to build. You don’t know exactly what you want to build.
IK: And you communicate with the business that we build such a prototype that we are ready to trash if we think that it’s not scalable at all, because otherwise we may come to risk where we build a prototype. It’s become an actual product, but we didn’t do a lot of design on the first stage. We didn’t think about, oh, what if now it will be a million clients who use it. So, the reason is that the team can end up maintaining this product all the time, and they won’t be able to do other features for other clients. So that’s the risk. So we should communicate very well, like what style of development we’re using right now to build our product.
BP: Right, right, right. And how do you see prototyping and following that same software development strategy, about prototyping, but now applied to the world of APIs? Do you see this as an activity that many people are following, or do you see it as something that people are starting to explore? You know, API prototyping in general.
IK: Yeah, so I see that right now in the era of AI, we have so much more opportunity to build faster. For prototyping, we can leverage generative AI because, in this case, we don’t have a style yet. In this case, we don’t yet have strict rules for how we build software, right? And that is something that generative AI will do for you. It may do a lot of styles from different parts, like where it’s learned, like it may learn how to do one thing from one code base and then another part from another code base, and that could be absolutely different code styles and teams who wrote it. So at the end, you have like a zoo again in your system. However, we can say that during prototyping, we can leverage this because we are fine. We can live like this. And, because of it, I expect it will be super popular right now because it’s so much faster prototype solutions.
BP: There’s no reason not to do it, right? It’s not about the time it takes anymore. It’s easy now.
IK: Yeah much more ideas that you could validate because a lot of things are now reduced by generative AI, also a lot of operations are reduced, so, for me, when I do something as a pet project, I want to try something. Before, I wouldn’t even touch it because it would take me a lot of days to type in coding and writing functions. But now I feel like, okay, now I can ask an agent to create it for me, and while it’s creating, I think what the next step is, and then I see the result, and I try to see if I need to amend this one, or I can proceed and try the next thing. So, for me, it’s very good personally because they don’t have to break now too much time as much of little one. But for me, it’s kind of me take it to try now explore all the backlogs that I had before.
BP: Nice, nice, nice. Yeah, that’s a great approach, and I think I’m also on your side. I think that now with AI, it’s getting easier and easier to be able to experiment while you are coding and while you are trying to understand what exactly, you know, you should be coding. Thank you so much for sharing these thoughts with us and with the audience. And we’ll see each other again soon. Thank you.
IK: Thank you so much for having me. Have a great day.
