Alex Antonuk:
– AI is starting to write code faster than teams can review it. Features pop up quicker. Prototypes take hours now, not weeks.
And yet, delivery doesn’t always feel any easier.
Something is shifting, but it’s not only speed.
So, what’s really going on inside product teams right now?
Are developers turning into AI supervisors?
Are we actually building better products – or just building faster?
And how much of this is real… versus just early hype?
Today, we will be looking for the answer to these questions with Igor Ponikarchik. I invited him as he has spent the last year deeply embedded in project work with AI. Igor is a product manager, former Senior Product Manager at Cubic Telecom, and someone I had the good fortune to work with across different setups for over five years.
I’ll put it this way – Igor has always been the type to get his hands dirty with project delivery.
And I’m curious how that carries over into this new AI-powered world.
Igor, great to have you here!
Igor Ponikarchik:
– Thanks for having me.
Alex Antonuk:
– Honestly, it’s good to catch up like this. We’ve been in the trenches together before, so I’m curious how your perception of the software development industry has changed with all this AI boost. So, we will be talking about one of the AI coding tools, Claude Code, and what it really does to product teams.
No hype – just experience and real workflows.
This is Agile Redemption.
I am Alex Antonuk.
Let’s go.
[Musical intro]
Alex Antonuk:
– Igor, let’s start from the top. AI coding assistants are everywhere right now. Every week, there is a new tool, a new demo, a new promise. From your perspective, how are these tools changing the way teams ship products in terms of speed, quality, and collaboration?
Igor Ponikarchik:
– Yeah, that’s actually a good question. I’ll be speaking today from the point of view of product management, right? And again, just a couple of things out of the way.
I’m not technical. I’m tech fluent, but I’m not technical. I will not be able to cover deep technical aspects of AI, generic AI coding, but I’ll be talking on the level of a product manager.
So, yeah, we’re in a very weird situation right now where AI is not new-new, but it’s still kind of a new thing to a lot of people. When we’re talking about AI, we’re not talking about generative AI chatbots like just using your ChatGPT, or Perplexity, or Claude, or Copilot.
Back to your question, I guess there are a couple of things happening currently in software product delivery and product management, in general. Number one is the changing of workflows. We’re used to a process where you get the insights, then you do discovery, then you write tickets, and then you refine those tickets. Then you get technical feedback from your teams, and then you plan them. So, this is how it used to be.
Now, everything is going, basically, we’re flipping the coin a bit. This is number one. The flows are changing.
And we hear more and more about AI native flows. They don’t necessarily mirror the previous story, but we are redesigning them as we speak.
Number two is the speed. This is crazy, and we’ll talk about it later, but the speed of development is crazy. I’m sure all of you have heard things that before, software development was very expensive. Teams and companies used business analysts, designers, project managers, and product managers to compensate and, basically, remove risks from software development, to make sure we’re doing the right thing.
Right now, it turns out that the designers and product managers are more expensive in terms of process than the software development.
And then, the third one is the role of all of us, particularly software engineers, because I’m sure you will talk about this, but the trend is that they are now less writing the code, more directing the code.
I think these are the three major shifts currently.
Alex Antonuk:
– Yeah, that’s interesting, and I like how you frame it as a change in how work is done, not just speed. Makes me think of something I came across lately. There was a piece in TechCrunch, and the idea was that developers are slowly turning into managers for AI agents instead of writing every line themselves.
When you look at actual teams working, does it match what you see now?
Igor Ponikarchik:
– Absolutely, and this is a good observation. And there’s a reason TechCrunch shared this story. It’s very important right now.
It’s not only about the role of a software engineer. We also should look at it because, as I said, the workflows are changing. If you look at the role of a software engineer, yes, before they used to write the code, they had to think a lot about the architecture and the structure of the data, and everything.
Currently, the roles are a bit mixed, and the line is getting thinner between the roles of a product manager, a designer, or an engineer. Currently, with the new setup and new flows, I think the code will be written by product managers and designers in terms of the initial kind of ticket writing, and the engineers will be looking into reviewing those pull requests, making sure everything is there, making sure all the checks are done, and the tests are done. I think that’s the shift we’re currently in.
Yes, the engineers are becoming less the writers of code and more the reviewers of the code.
Alex Antonuk:
– Okay, right. So, not a full replacement, but the role itself definitely changes.
Igor Ponikarchik:
– Yeah, yeah.
Alex Antonuk:
– And now I’m curious about something more practical. When teams pick up these tools, do they actually trust them with production work, or do they mostly keep AI for prototyping and experiments?
Igor Ponikarchik:
– Again, a very important thing, I’m talking based on what I see and what I’m currently doing. I cannot speak for all of the industry, but what my experience currently is, it’s actually used for production work.
So, the engineers and product managers are actually using Claude Code to write the code. And now, we’re at the level where these tools allow us to do production code. As I said before, you still need people, but enough people in the loop to look through the code, to make sure it’s doing the thing.
You still have to be an engineer, understanding all the basics, but we’re writing the code currently with AI. The prototyping and experimentation, as you mentioned in your question… There are a bunch of ways to do prototyping. And in a sense, a lot of people are saying, ‘Oh, go use Lovable to prototype.’
But currently, with the speed of development, I know some instances where people just use Claude Code to prototype. It’s funny enough, because it’s almost already a production-level version, but because of the speed – it takes a couple of minutes – you can actually use it for prototyping. But instead of just in the classical sense of a prototype, like a Figma prototype, where it just moves between screens, but they’re dummy, they don’t have any data.
In this sense, when you prototype with Claude, it actually comes up with a production-level prototype with the data. Again, if you use it like a demo with the data and everything. It’s amazing how you can actually use it for both worlds, for prototyping and experimentation, and also as the production code.
Alex Antonuk:
– Well, makes sense. And there is always that moment when experimentation turns into responsibility. And now I know you’ve been trying out Claude Code.
And if you are willing to share, what kind of tasks do you already trust AI with?
Igor Ponikarchik:
– Let’s separate. I’m currently working for a very AI-native company.
And also, I’m doing a bit of my pet project. Let’s separate those two. And in both cases, I use Claude Code.
For my day job, I use Claude Code. And again, as a product manager, there are a couple of use cases.
Let’s go a level above, Claude.
When you install Claude, you have your app as a chat – one part of it – Cowork as a second part of it, and then Claude Code, which is the third one.
There’s a use case for each of those products. For chatting, and we know how to use chat. So let’s give that a pass.
Actually, no, can we go back to chatting for a second? And back to your question about prototyping and experimentation. The chat in Claude is actually a good tool to quickly prototype.
Not a lot of people know about it, but if you give it enough context and provide a reference and, say, ‘This is what I’m trying to do, this is what the customer journey I want to come up with’, it actually creates a prototype, a clickable prototype, similar to something that you can get with Figma, which is enough to present your idea or, I don’t know, define a basic user experience for your ticket.
I was surprised recently by the level of prototypes that you can get from just a simple chat.
But moving then to Cowork. Cowork is something that product managers should do for research. It’s an amazing tool.
It’s similar to Perplexity Deep Research or ChatGPT Research. It goes deep into a lot of topics and comes up with very structured information. And then it can also generate documents – Google Docs, or PowerPoints, or Numbers – whatever you want it to come up with.
But also, if you use Notion, for example, or Figma for your design files or research files, then connecting to Figma MCP or Notion MCP would allow Cowork to actually upload the pieces of research or prototype right into your documents directory, which is amazing. It saves tons of time for research. And it does really good research.
So, this is number two, Cowork. And then, Claude Code, which is a bit of a trickier thing. It’s not just like you open it out of the box, and go ahead and start doing code.
Again, just for the context, you still need to install the infrastructure. Most of the time, you use the terminal to code.
But the use case for Claude Code, there’s a bunch of it, one of which is writing the code. But as a product manager, before writing something, it’s not like you’re just saying, ‘I want this and this.’ I mean, you can still do this, and it does a brilliant job.
But on a production level, you need to create the ticket. So Claude Code does a brilliant job creating tickets. Again, especially when you have the right setup, and it has access to your codebase and also Figma, it creates amazing products, amazing documents for tickets, for refinement with your team.
And then also, of course, if the story is simple enough or small enough, you can just go ahead as a product manager and create the code and submit a PR.
Alex Antonuk:
– Mm-hmm. Okay. That’s a good way to put it.
But what about surprises? When you first started using AI agents in development workflows, did anything catch you off guard?
Igor Ponikarchik:
– Let’s look at it from two lenses.
I see a lot of people online saying, ‘I’ve done this product in three hours, and I don’t need an entire team.’ There are tons of these stories out there.
And the surprise number one is, especially for Claude Code, it’s not an out-of-the-box tool that you open and start ‘Create me an app for running’, for example, and that’s it. You still need to set up the infrastructure level. You still need to set up your Claude Code. You still need to set up all your testing tools in order to see what’s going on, what you’re actually building.
Also, I think there’s a new challenge coming up.
A lot of companies are starting to offer services such as vibe-coded project cleanups. A lot of customers use Lovable or other products to come up with a product to show to investors or something, but then, as they need to grow, then they hit the wall of, ‘Okay, this is not scalable.’
Surprise number two, you still need a good senior architect to actually help you define the architecture, scalable architecture, secure architecture, and maybe even the setup. Don’t get me wrong, as a product manager, non-technical, you can still set up everything yourself.
I’m not saying that you need extra people, but if you’re thinking seriously about scaling your product, then maybe it does make sense to consult an architect to help you with this. So, this is number two.
Number three, you don’t have to trust it completely.
You still need to review it. So first of all, surprise number three for me, it is a brilliant tool. It saves so much time, especially when you are writing your ticket.
It does ask brilliant questions. It’s almost like you’re sitting in a design thinking workshop and you have your architect, and maybe even head of engineering, and your design director, and then they’re looking at the feature and saying, ‘Okay, what is this use case? Let’s think about corner cases.’
Normally, the things that you would come up in a meeting, in a big refinement session, this happens in seconds. If Claude Code is connected to your code base, it’s an amazing tool to look into what you have right now, especially if you give enough context and say, ‘Okay, what about this?’ It asks really good questions.
Surprise number four, sometimes it asks not the right question. Sometimes it comes up with a huge ticket that needs a lot of refinement. It’s a minor thing, but the surprise is that it’s so good at refinement that it shocked me – because that’s the real value. It saves tons of time for going back and forth, refining, and spending a lot of time with people, and actually refining.
Alex Antonuk:
– Okay. So I think the gap between expectation and reality – that’s where things usually get interesting. Let’s talk about one of the biggest promises out there.
People put it like that. You describe a feature in plain language, and the AI builds most of it. With tools like Claude Code, how close are we to that today?
You already mentioned a bit, but maybe you can just add something.
Igor Ponikarchik:
– We are there. We’re there. And again, without naming people, I see people just talking to explain what they need to do.
Again, the prerequisite for it is that you have to have infrastructure and your architecture there. Once you have everything, and then once you have the first kind of iteration of the product, maybe, or a process site, then you can definitely talk to it. Again, it’s not about the plain language.
This is what I’m doing as well, as a part of my job. You just go ahead and describe it in the Claude Code. You can use standard writing skills or custom writing skills.
But yeah, you describe, this is what we need to do. Honestly, the best way for that is how I use it. You can actually fit in the PRD file, maybe saying this is what we’re trying to achieve, this is the context. These are the product areas that we want to update. You still need a bit of context.
And if the infrastructure is set up correctly, it just goes into the code base, reviews what’s out there already, and what are the best ways to integrate. And then, basically, it asks clarification questions. So you kind of, again, explain it in plain language, in a human language, ‘These are the use cases’. And then you, as a human, need to define the limits. This is in scope, this is out of scope.
That’s it. It just goes there and creates a ticket. Normally, my process is: you create a ticket first, because this is where you define what you want to do, what the limits are, and what the use cases are, what the corner cases are.
And you refine it together with Claude Code. Then once you’re happy with this, you can just go ahead and refine or take it to tech review with your tech leads. But if you’re fine, if it’s just a small feature, you literally say, ‘Now let’s code it.’
That’s it.
Alex Antonuk:
– Okay, fair enough. So, you mean AI still needs guidance, not just instructions. An important distinction, in my opinion.
And then from a product perspective, if someone starts working with tools like this, where does the impact show up first? In planning, development, testing, or maybe all at once – where do you see it in the first place?
Igor Ponikarchik:
– From the product management perspective, there’s a couple of steps we need to ensure. Delivering features is just a part of the job, a small part of the job.
And this is definitely where Claude and AI agentic coding tools help a lot, specifically around writing tickets. What took you a couple of days, maybe a week to go ahead: be a business analyst, write those tickets, define all the corner cases and acceptance criteria – and you did it with your hands – currently, it does it in minutes and seconds. I did not measure, but it’s super quick. This is the biggest benefit, I guess.
Then, if you go back a couple of more steps, the focus, the real role of a product manager is to look at the product in a couple of different ways and see, ‘Okay, what can we change or update? What metrics can we fine-tune to deliver better results?’, based on your North Star metric. This is where, again, Claude and other AI tools can help, using their research feature to understand what the opportunities are in your product.
It’s an amazing tool for brainstorming. If you give enough context to this tool – specifically around your business area, your goals, your markets – and provide all those details, along with enough context about your product (or maybe access to a product), it could be an amazing tool to come up with a roadmap and say, ‘You can do this and that.’ Then, as a product manager, your job is to prioritize and say, ‘This is brilliant. But our North Star is, for example, this, and we can do this and this to move it.’
So, again, it’s an amazing tool to understand your product, and understand the trends and market shifts, and actually suggest to you what can be done.
Use it cautiously, I guess.
Alex Antonuk:
– Okay, it sounds to me like the bottlenecks move, but don’t actually go away. And you know what, we’ve already seen cases where AI tools made costly mistakes when people gave them too much freedom.
So my next question is, when teams bring AI into production workflow, what safety measures do they actually need?
Igor Ponikarchik:
– First of all, as we mentioned in the beginning, you still need people in charge of approving things. This is where the engineer comes in, in the current workflow, to review.
So you see, when you push your PR to Git, depending on your process, depending on the complexity of each, you still need one or two or three engineers to review it and approve it, make sure the sense checks there. But on top of that, depending on your product complexity and your workflows, you still need your security checks, your compliance checks, and your testing in place. Is it automated? Is it manual? It’s based on your approach. This is the last part before going live.
Also, I think the safe bet would be a small feature set, yes, after all the reviews and tests are done. And get most of those tests automated, or you can hire external people to do that for you: security, testing, and usability testing.
What I’m saying is that usability testing should be done before. But if you’ve done it, then you’re safe to upload your code to production. But again, as a final level of protection is to do soft launches, or maybe small task groups where you launch first, see if it works well, and then go into production for your entire user base.
But this is for sure, you still need people to review what’s going on. Because there are still hallucinations in those tools. And so you still need people to review it, and preferably a couple of them, and then you still need all your tests. And again, you can actually soft launch it and test to make sure everything is 100% okay.
Alex Antonuk:
– Right. So you still need strong engineering discipline, and maybe even more than before.
There is something else that caught a lot of people off guard.
A 2025 study from METR showed developers actually got slower with AI, mostly because of the back and forth prompting, reviewing, and fixing outputs. Have you seen that play out yourself? Does it still hold true now in 2026?
Igor Ponikarchik:
– Again, I’m talking for myself. I don’t see this. And honestly, teams are crazy fast.
The speed of delivery is amazing. And this is a good sign. The only thing I see right now is that, because of the speed of development, the new kind of challenge that product teams will have, or already have, maybe some of them, is deciding what to deliver and actually supply work for the engineers.
Right now, because of the speed, you can actually do anything. You are in a position where the engineering speed and cost became so quick and so low that basically you can do everything you wanted to. You can cover all your technical data.
You can take into account all the insights. You can fix all your bugs. You can do all your improvements in terms of performance, speed of your systems, and security. So now you can do everything. The biggest challenge is: what do we do next? Mostly, what’s next for our product?
And now the challenge is you don’t have that much time to actually sit down, strategize, test, and everything. Before, it took ages to go through the development lifecycle. Business people and product people had a lot of time to sit down with the presentations and consultants and go, ‘This is what we were planning to do.’
Right now, it’s becoming more reactive. Engineers need to work. We need to supply. But at the same time, the biggest risk is that you need to make the right decision quickly. You don’t have so much time. This is where the risk is, you are now starting to have almost the entire thing becoming like a casino – you need to make bets very quickly and react very quickly. This is the change that I see. But from the speed of the development, no, they are now becoming super quick, super efficient.
This is crazy.
Alex Antonuk:
– That’s a good reality check. Thanks, Igor, for these insights. Now you’ve worked as a product manager and as a consultant with different clients.
When the teams or stakeholders see AI written code, how do they usually react? Do they trust it? Or do they still push back?
Igor Ponikarchik:
– I don’t think that clients are looking into AI-written code. I think there’s a general trend that most of the companies, boards of directors, and senior leadership teams are actually promoting heavily going all in on AI. Now it’s not about do I trust the AI or, can I use it on a production level?
I think there’s another question: how do I actually do it? This is not a question, shall we do it? Shall we not? Now the question is, how do we do it safely? I was recently talking to a head of engineering of Transport for Greater Manchester, and they are now starting to go into AI, embarking on the AI journey.
For most companies, it’s not as straightforward as just setting up this or that tool and letting the code happen. It’s about: how do we adopt this on a company level? How do we make people use it? How do we make sure it’s secure? How to make sure the code is safe?
There are a lot of bigger questions that companies are looking into right now. Again, the level of AI-generated code or products is not the question. It’s the adoption and the frameworks. What’s the next step for me to actually do this? Because now, a lot of companies are pushed to do that – if you’re not a part of this journey, then you’re losing.
Alex Antonuk:
– Yeah. Okay. Yeah, I noticed that dynamic too – curiosity on one side, hesitation on the other.
But let’s step back for a second, or maybe even get a bit philosophical. If AI starts writing a large percentage of code, how does it change the role of engineers, product managers, and tech leads? We already have touched on this topic before, but maybe in a nutshell, on these roles.
Igor Ponikarchik:
– The only way for me here is just to kind of fantasize, become a little bit of a science fiction writer, and share my thoughts. It’s just my thoughts.
It’s a funny thing. So there’s a lot of moving parts at the moment.
There’s no clear direction, I guess. From one side, now you don’t need that many engineers, product managers, designers, and tech leads to deliver a software product.
The biggest thing that I see right now is the traditional squad – it could be a bunch of software engineers, normally three, four, five, six people, depending on the squad. And then you have a design and then a product manager. Sometimes you have a QA on board in the early days.
Right now, you don’t need this huge team. You can just have a product manager, a designer – maybe a shared designer, maybe a shared product, even – and one or two engineers. One of them should be an architect to make sure everything’s working fine. Product managers and designers can write code right now with Claude Code.
And then they also have an advantage of understanding the business layer of the product and the product metrics, and what needs to be done to move it. This kind of business/commercial perspective allows them to make the decisions of what needs to be done. On the other hand, the engineers can do the same thing, because I’m sure you’ve heard of the term vibe PMing.
Now you can say the same thing – you can vibe code, you can do vibe product management, and you can create ideas, user stories, and roadmaps. Again, a tech lead or engineer can be this Swiss Army knife man. It’s kind of difficult to say what the future will be.
The industry at the moment is playing with different models, different ways of working, and different frameworks and workflows. It’s so difficult to say, but it feels like there will be a balance. I think the engineering teams will shrink to smaller teams – almost like in military terms, those special operations squads, A-teams – and they will be responsible for small streams of product. Not just responsible for delivering and shipping features, but also responsible for the actual outcomes of the product.
And this is the dream of a product manager: being responsible for the outcome. They will be owning a certain metric, certain features, and just on the top level, there will be people kind of aligning all the small squads, making sure that the product in general is moving toward the bigger value. But right now, it looks like engineers could be the group that can do everything.
Product managers, if they manage to learn how to set up everything and how to use Claude Code, and a couple of terminal tricks, they could be the group that can do everything, from writing things to coding. The funny thing is, designers can do the same, because designers understand the customer journey, they understand how to impact or influence behaviour. If you can set up the Claude code and everything, happy days.
The only caveat here is that the engineers and product managers, to do a really good job, have to be a bit of an architect, or a really good engineer, to understand the architecture, data infrastructure, and everything. This could be a challenge. Right now, it’s not clear what the future will look like for us.
But it’s interesting to be a part of this journey.
Alex Antonuk:
– Sure. Well, it’s definitely something to think about. All right.
But let’s get practical and wrap it up. Say a product team listening to us wants to start trying Claude Code tomorrow.
What’s the smart first move?
Igor Ponikarchik:
– Let’s say this product team is still doing things the old way.
And they want to go, ‘We need to use Claude Code.’ At this stage, depending on their journey, but if they already have a product, I would say just have your small group that will have a senior engineer to help with the setup and everything, have your product and designer, and maybe a couple of engineers. You don’t have to go with the entire team from day one, because there’s still a learning journey.
You still need to figure out your skills. You still need to figure out the entire workflow and test it a couple of times. So I would say, just define a small part of the product that is not mission critical. And try to do the entire journey. End to end, that’s it.
Learn from it. Adjust them, because I’m sure you’ll have some blockers, and you will hit the wall. This small team will spend a couple of weeks or a month to build this cycle, development loop, test it, make sure it works.
And then after that, when you’re happy, just go ahead and actually make it like an official on the company level, saying ‘Now we’re doing this thing.’ The thing is, and this is amazing currently what I see: if you just say, ‘Okay, this is the new way of working,’ yes, there will be a couple of people saying, ‘This is not right.’
But just go ahead. Yes, things can be messy at the beginning. That’s absolutely fine. And to be honest, I currently speak to a lot of people, a lot of product teams, and engineering teams about this.
We are all in this massive middle. Nobody knows what the right thing is. And that’s the beauty of it.
My advice for a product team: just go, start doing it, create the entire life cycle, the full loop. Even if it’s ugly, my best kind of learning is – growth is all about feeling stupid at the beginning.
This is the signal that you’re doing the right thing. Go out there, set up Claude Code. Make sure your product managers are using it.
And designers, because it involves using the terminal, which is uncomfortable for a lot of people, do this entire journey, test it, see it, and then just roll it out for the entire company.
Alex Antonuk:
– Okay, so just give it a try. Yeah.
Igor Ponikarchik:
– No, Alex, no, not give it a try. There should not be a wave, like a fallback plan. The idea is, we’re going there, guys. There’s no other option. We’re going there. But instead of going all in from day one, we have this small team doing this, right? They will test it, they will share all the information, we will align it, and then we’ll roll it out. Not try, but do a first step, put it this way, do a first step.
Alex Antonuk:
– Okay. Okay, Igor, thanks for joining me today. That was a really grounded conversation.
And as for me, I will definitely have something to think about later. And honestly, it was great to catch up like this.
Igor Ponikarchik:
– Thank you, Alex. It was great. Thank you very much for having me.
Always a pleasure speaking to you. And I do hope that your listeners learned something today.
Alex Antonuk:
– Thanks.
