Is AI ready for real software development? Insights from Michał Czmiel

Introduction and first experience with AI

Piotr (Host): Hi, I’m Piotr, co-CEO of Boldare, and you’re watching Agile Product Builders: Tech Edition, a 25-minute series for today’s product builders. In this episode, we explore how AI is changing the way we build software. And to be clear, we mean real systems — not weekend side projects or vibe coding, which might be a different edition.

Today’s guest is Michał Czmiel, our senior software developer and tech lead here at Boldare. Michał, you’ve been with Boldare, I think, seven years now. What I know for sure is that you’ve played a major role in shaping some of our most successful products. We’ve co-created these with our great clients — but not just as a developer and tech lead, right? I remember seeing you wearing many hats over the years. Software architect, event storming facilitator… and I think you also like to be a technical coach for developers and entire teams, I would say. So it’s great to have you. Welcome to the show. Hi Michał.

Michał (Guest): Hello. Yeah, nice to be here. Thank you for the warm introduction. Wearing many hats — I think that’s a good way to put it. In the age of AI, it’s, you know, one less step to being replaced by AI overlords.

Piotr: So do you have any favorite hat?

Michał: I really like being a mentor of the trainees is it. It’s always you know, humbling to share some knowledge and also you know when they ask some, some hard questions and you, you kind of just say don’t ask about it, you’re, you’re too young but you need to figure it out the answer and say them that so it, I think that being the, the mentor of the training is very satisfying job.

Piotr: Yeah. I hope this role won’t vanish in times of AI — which might be an option. Or at least, you know, the yellow duck that we’ve been using for so many years is now a bit more intelligent — and not as silent as it used to be. Right?

Michał: Yeah, exactly. Some industry leaders even call AI tools “ambitious trainees” or “weird trainees” — you can yell at them. But no jokes aside, it’s really tough getting into the industry nowadays. And with all these AI tools, it might be harder to start in entry-level jobs.

Piotr: Okay, so let’s talk about these AI tools, right? Because this is really a great topic. Generating code is cheap. Solving real problems is hard. This we know. And I’m curious about your professional opinion. As a developer who builds complex software systems, what was your “aha” moment that convinced you AI coding tools are more than just hype? And I guess it’s not only code generation, right?

Michał: “Yeah, true. I think I had two of those moments. First was during the initial GitHub Copilot preview. You know, when I typed something like beginning of a function to generate a Fibonacci sequence or a description of a react component and I got the answer right there in my code editor.”

Then I felt like, okay, this is something new. It’s not only about speed but also reducing a specific kind of friction — like going to your browser, looking up documentation, checking Stack Overflow.

And here, it kind of enhances the flow of development. But I think the second moment was when ChatGPT was publicly released — a chat-based system with substantial knowledge. You could converse with it on topics, ask it to challenge you, or give you alternative paths.

The second idea was when the ChatGPT was publicly released. So we had a chat based system that had a substantial knowledge and you could converse with it on topics, ask it to challenge you, ask it to give you alternative paths.

So yeah, that was something like, hey, maybe instead of getting stuck, I can get additional context or new ideas. And maybe now the third step — I think we’ll talk about this too — was the introduction of modern agent editing, like Cursor and the new GitHub Copilot Chat.

Piotr: Okay, so it looks like we already have three major steps in this revolution. I like to look at it as an extension of Stack Overflow to some extent. But for me, the second really important step was the IDE evolution. AI tools in everyday work and their applications. Anyway — so what do you use in your daily work? What do you have on your screens when you build products?

Michał: My primary tool is Cursor. Right now I’ve also tried Visual Studio Code and Z editors. I might switch them depending on the features, the changelog they are releasing. Now every tool has AI built in — even Zoom, which we’re using to record this, has some AI assistant. But in terms of tools I use to build software, my primary tool is Cursor.

I’ve also tried Visual Studio Code and Zed editors. I might switch depending on the features or changelogs they release. The editor landscape is changing really rapidly. So it’s also good to be prepared to switch your favorite editor — maybe take your shortcuts with you. I recommend learning Vim shortcuts and motions. That way, you can easily switch between editors. I also use AI chat.

I’ve been using Google AI Studio recently since we use Google Workspace at our company. It integrates well — you can upload documents there, ask questions. I also use Perplexity for more specific lookups — for example, limits on certain DynamoDB commands. I use Copilot as well, but on the GitHub.com website. I use it for automatic code reviews — you can attach GitHub Copilot to a pull request and it will produce sometimes quite useful review comments. I also use it to ask questions about specific repositories. You can go to any repo on GitHub, open a chat, and ask away.

Piotr: Thanks. Looks like there’s quite a stack of different tools, right? But in terms of usage — which one do you use the most?

Michał: I’d say probably the editor. So currently, it’s Cursor. I mostly use it to edit code but also to ask questions about the codebase. If you’re not familiar with Cursor, it’s a modern AI-assisted editing tool — a code editor. It operates in two modes.

The first mode is tap completion mode, where you type your code and you’re the pilot. It autocompletes code, suggests next steps — even more than just single-line completions, which was a limitation of the original GitHub Copilot. Now it can suggest, for example, “Hey, we should import this module,” and jump to the top of the file. The recently released new version — I think just a few days ago — can now suggest changes in multiple files. It might even say, “Let’s go to this other file and update something.” The second mode is agent mode, where you type something in a box, and — hopefully a few seconds or minutes later — you get your code as an artifact.

Piotr: So there’s an assistant mode — the support the IDE gives you — and then there’s the holy grail: something that does the work for you. But you still have to be the operator in agent mode, right?

Michał: Yes, and we’ll probably go deeper into this. But it’s quite a rabbit hole — making this agent mode work requires substantial knowledge: what context to provide, what rules to set, how to write your prompt, which models to use. Should the model be “thinking” or not? Yeah — we should make a separate webinar just about that.

Practical applications of AI and quality preservation

Piotr: Yeah, I’m sure. It’s exciting — because I know how important the integrated development environment is to a programmer. It’s the main interface for building software. And you switched to what I might describe as a modern-day Vim. I’m old enough to remember vi, and then Vim came in… anyway. Tell us — walk us through a real case where an AI assistant saved you serious time.

Michał: Sure. Let me give you an example of something I’ve been building recently. I mostly work on backend systems that deal with data processing and scheduling. When I implement a feature, I try to think of it as a vertical slice — like a mini module or mini app that does one thing.

Michał: This fits perfectly into LLM logic, because it contains all the context needed. Here’s how I usually start working on a feature: First, I iterate on the solution using chat. In my case, I’ve been using Google AI Studio. Let’s say I need to integrate with an external service — I upload the documentation (Swagger, PDF, etc.) and ask follow-up questions like: “What’s the authentication method?”, “What are the rate limits?”, “Give me all endpoints related to command scheduling.”

This way, I figure out what I need to do. Then, I come up with a general technical solution and architecture — how data will flow, what the database structure is — and I ask the chat to validate that. A good tip is to ask chat for follow-up questions — it can detect what’s missing.

I ask things like: “Do you see any performance issues?”, “What about concurrency or memory?”, “How will this scale?”, “What happens if we add a new rule to the system?”

Once I have the solution, I go back to my editor. Some people prepare a detailed plan and let the agent execute the steps. I’m a bit more traditional — I prefer to scaffold the initial structure and write the tests myself. That way, I ensure structure, coding style, and dependencies are consistent — something AI agents often struggle with. Then I run the agent to fill in the gaps. For example, if I need mapping between a database and an external service — or if I missed a corner case, like a user sending an empty array or limit = -10, I can just ask the agent: “Please fix this and add a test case.”

And at the end, I can ask the chat in the editor for a pre-review. I reference key files and ask, “What about this code? Any issues?” To sum up: The goal of this flow is not only speed. I try to maintain quality too. Often, with this “vibe coding” you mentioned — where you don’t care about code, just results — people paste errors into the AI and ignore the rest. I take a different approach.

Speed is not the only goal. I also keep the mental model of the solution in my head. I don’t push that entirely to the AI. Of course, if you’re building something less complex, or you trust the agent more, you can let AI take over more.

Piotr: Yeah — the “vibe coding” thing is phenomenal. But the real question for us is: Can AI help build complex systems? Thank you for walking us through your process — it’s fantastic. As I listened, I imagined you talking to several specialists… except they aren’t human. Maybe your human-to-human communication has decreased? I’ve always observed that in good teams, people spend a lot of time talking. We often tell customers: “You’re paying for the talking,” because the result of those conversations is great. Code is relatively easy to generate, but you have to maintain it — and understand it. So thanks again for sharing. But I have to ask — how much time do you actually save? Or how much more productive are you?

Michał:

I know you want to hear some like, yes, productive, exactly. It’s hard to quantify because it’s different on any task. Just to clarify, also talk to humans, not only AI models, but yeah, I would say it speeds up a lot of time as you grasp the tools and you don’t fight with the tool.

But yeah — it speeds things up a lot, once you grasp the tools and don’t fight them. When you know their limitations, you can be much faster. It feels like having a trainee — and some recent developments, like Cursor’s preview of background/async agent mode, make it even more powerful. In theory, we’ll soon have multiple concurrent “trainees” working on different parts of the code. And yes — I use the saved time to focus on something else, instead of writing repetitive boilerplate.

Piotr: So, can I assume you’re definitely more productive? Maybe not twice as fast — but 1.5x?

Michał: Yes, definitely. If someone hasn’t tried these tools, I strongly recommend it. I’m definitely more productive with them.

Challenges and safety of using AI

Piotr: Okay, I guess there’s also a flip side of this coin, right? Tell me — where have AI-generated suggestions gone wrong for you, and how did you catch or fix those issues?

Michał: The good thing is that none of my AI-generated or hallucinated wrong code has ever made it to production or broken anything critical. I always try to catch errors early. I would categorize the major issues I found into four groups — and maybe share how we fix them:

First, sometimes the LLM agent gets stuck in a loop trying to find a valid solution. It generates random methods or function calls repeatedly. Usually, this happens because the task is too complex or the context is too small. The fix is to break the problem down or provide more context. Second, sometimes we get invalid code that looks valid. That’s why automated tests, type checking, and rules are essential — to prevent using functions that don’t exist. Third, one gripe I have is that sometimes LLM-generated code is overloaded with comments. This dilutes the purpose of comments — which should explain why something is done, not every single line. The fix is to enforce stricter commenting rules. Fourth, which can be harder to spot if you’re not an expert in the library or framework: The AI models have a data cutoff. So the generated code may use outdated library versions or Docker images. Maybe some library has been added to the standard library, but the AI doesn’t know. So you still need to validate the code carefully.

Piotr: So we still have to think. The operator — the developer — has to think. That’s a little disappointing… or maybe not. We still need that. What kinds of safeguards do you use? I mean, there must be concerns about intellectual property or security. How do you cope with that?

Michał: Alright, let’s break it down: On the security side — application security — it’s all about following industry best practices. Bake security in early, use security scanning tools, do human code reviews, etc. Regarding intellectual property, it’s more nuanced. First, enable privacy mode on the AI tools you use. This means zero or limited data retention — your data won’t be used for training the AI. Also, be careful not to use licensed code. Not all code on GitHub is open source. Many top tools provide options to avoid this. It’s mostly a matter of administrative governance — enabling all the necessary settings to protect your IP. If you want to be really fine-grained, some tools allow you to specify ignore files (like .gitignore) — files that shouldn’t be indexed or used for autocomplete. So if you have critical business or secret sauce code, you can make sure those files aren’t scanned or used by AI completions.

Piotr: Okay, thank you. I like to picture AI as an excavator, but sometimes you still need to use a shovel. So how do you decide what to do manually and what to do with AI — or maybe you don’t decide?

Michał: I would say all concept work — high-level architecture, diagrams, modularization — should be done manually. I know there are tools that generate project scaffolds and bootstraps for long-term projects. But having a mental model and understanding is better, especially since you will maintain it yourself. AI is just a helper. The “shovel” should be used for critical business logic — core domain logic, payments, authentication, tests — anything that could blow up if not written and reviewed carefully.

Piotr: And finally — would you imagine yourself not using AI today?

Michał: That’s a very good question. I would think of three possible answers. First, if there was some sort of, you know, regulated industry or some sort of scenario or a domain or a case when AI couldn’t be used. But I don’t know if that will be the case for how much in the future. As those models are getting better, the tools are getting more advanced. And I would say also when you’re doing some coding challenges like advent of code, just improve yourself, not the model.

And the third one would be, you know, when you are in the train or a plane and you don’t have Internet access because running those models is possible locally. But it’s quite. It’s not that you have to have a really beefy GPU and other to run efficient models. But, yeah, generally I would say that I wouldn’t now code without it. Yeah, I think this is like an integral part of my stack node.

Piotr: Okay. So can you tell me yes or no — is AI ready for real software development?

Michał: I would say yes.

Piotr: We waited 30 minutes to answer that question. But yeah, for me, the answer is yes. Thank you, Michał, it was great to have you here. Thanks for the chance to learn from your experience. And thanks to everyone watching us. That’s 30 minutes — a little over time. Greetings to your cat!

Michał: Thank you. Bye bye.