What AI changes about software development and QA - and what it doesn’t

This is the second part of the conversation between Lukasz Lazewski, CEO and co-founder of LLInformatics, and Krzysztof Kempinski, host of the “Porozmawiajmy o IT” podcast. Before reading this one, we suggest reading part one of the conversation.

Note: The original conversation is in Polish. Some quotes have been lightly edited for clarity and readability in English, while keeping their original meaning intact.

If you want to listen to the full podcast episode in Polish, click here.

Speed doesn’t make a PoC production-ready

Rapid prototyping is one of the clearest benefits Lukasz sees in AI-assisted development. He recalls Balsamiq, a tool deliberately designed to make early product concepts look like sketches. Its visual simplicity helped people understand that they were looking at an idea rather than a finished application.

But AI creates almost the opposite risk. Even a few hours of work can produce something that can look surprisingly polished, making it seem more complete than it is. Lukasz underlines the risk: “That overinterpretation creates cognitive biases and leads to business decisions that reach much further into the future than they should.”

Krzysztof also agreed to this: “I think this has always been a perception problem on the business side. When you showed somebody a PoC, they often interpreted it as, Great, we already have the first version of something that we can deploy tomorrow.”

The main purpose of a PoC should still be learning: collecting feedback from end users, validating whether a problem is worth solving, or finding out whether the intended product has market potential.

Production introduces different questions. If, for example, 50,000 existing customers are expected to use the system from day 1, that information may affect architecture, infrastructure, scalability, and technology choices before the real product is built. “What the AI generated the PoC with is secondary. The important thing is that we collected knowledge from the market and checked whether it makes sense to build it.”

There are, of course, exceptions: building a small application for one person to manage a household budget has very different requirements from a platform processing millions of operations. “For things like that, I think an AI-generated, production PoC is fantastic.”, says Lukasz. The level of engineering should reflect what the software is expected to do.

AI may change how tribal knowledge is captured

One of the less obvious effects of AI-assisted development is what happens to the knowledge that used to live mainly inside the team. “Previously, it was often the developer’s decision whether or not to document something. They would share knowledge with colleagues in meetings, stand-ups, or some other dedicated setting.” That created a familiar risk. When those people leave, change roles, or simply forget why a decision was made, part of the project context leaves with them. Lukasz sees AI as a way to reduce that dependency because conversations about development can be part of the project record.

What used to stay with people can now be preserved outside them. “Today, after every sprint, you can ask the system, What did you learn? What changed in the context? Great. Give me a PDF, produce the Markdown file, or add it to our wiki. And we have it.”

This does not mean teams suddenly need to produce more documentation. In fact, part of the value comes from reducing the effort required to maintain it. Instead of relying on someone to update a document, teams can ask AI to summarise decisions, update shared context, or record the reasoning behind changes as part of the normal development workflow.

Knowledge no longer has to depend so heavily on who happened to be in the room when a decision was made. AI does not remove the need for experienced people to make those decisions. But it can make their reasoning easier to preserve, retrieve, and reuse later.

QA is moving earlier into the development process

Faster code generation does not make quality assurance redundant either. While some traditional QA work can become easier to automate, there’s still a need to do that intelligently. AI can increase test coverage and help execute repetitive checks, but QA engineers still need to oversee that.

QA specialists can become involved earlier: “They need to oversee how quality itself is contextualised, how tickets are written, and increasingly they move somewhat into the product owner’s territory.”

One interesting case for using AI in software testing is trying to break the product. As Lukasz explains it: “I like the idea of having QA ask the model, Okay, what if I had malicious intentions and wanted to break this? Because when we normally work around happy paths, we still don’t necessarily think like that. We don’t necessarily give the AI the context that says, Be resilient to somebody entering a sequence of numbers into the name field.”

There’s one more area where QA adds value: “If every developer handles this independently, and nobody manages and maintains those contexts centrally, including the knowledge inside those Markdown files, you end up with multiple different worlds.” They ensure consistency across quality standards and that everyone adheres to and improves them.

Spec-Driven Development gives AI clearer boundaries

Vibe coding showed how quickly AI can produce something that looks convincing and what happens when generation starts before the team has clearly defined the constraints, dependencies, and expected behaviour.

For Lukasz, the important part is not simply writing a longer technical specification. But getting input from developers, product owners, and QA. Some parts define the technical environment, such as the framework version, backwards compatibility requirements, or coding conventions. Others describe how a feature should behave, what business requirement it supports, and which dependencies need to be considered.

Much of the technical context only needs to be defined once. Teams can keep it in shared Markdown files or repository-level instructions and reuse it across subsequent interactions with AI.

“The spec still has to be written by someone who understands what they are specifying.” Because a generated solution can look polished even when the assumptions behind it are incomplete.

Lukasz compares it with a building blueprint: “A random person might create a beautiful design for a beautiful-looking building, but it could be structurally unsound or fail to comply with building regulations. That is where the specialised knowledge of developers, QA engineers, and product owners remains essential.” Software has the same problem. AI can execute a specification very quickly, but it still depends on the quality of the decisions and constraints behind it.

AI can lower the cost of technical debt, but technical judgement still matters

Technical debt has always competed with feature development for engineering time. Features usually win because they are easier to connect with revenue, customer requests, or growth. But now, agents can analyse codebases regularly, identify potential issues, create tickets, suggest refactoring, and in some situations prepare the pull request before the team has finished discussing the problem. Work that once required several days may take far less engineering time.

That does not mean every proposed refactor should automatically go into production. Teams still need to understand its effect on existing users and business processes, supported by tests and environments where changes can be verified safely.

Lukasz described a Fortran project with a UK insurance company and how AI models struggle when access to training data is limited. The model produced nonsense and mixed different languages. Even though they are not Fortran developers, they could see this.

“It’s an interesting example of the probabilistic nature of these models. The more data you have, the more accuracy increases. With a less popular language, that probability falls.”

As development accelerates, Lukasz expects infrastructure and DevOps to become an increasingly important part of the equation. Teams need to create test environments quickly, run different versions in parallel where appropriate, and roll changes back when something behaves unexpectedly.

What’s the future for AI in software development

Looking ahead, Lukasz sees two interesting trends: hardware-based solutions and locally deployed models. “I mean specialised models that are contextualised and trained for specific tasks for a specific type of user or employee. I think there’s an enormous revolution coming in that area.”

The other thing is adoption. In the EU, new legislation might restrict adoption of some American or Western tools. But what happens when we reach the point where most jobs are automated and only a fraction remains?

“I’m an optimist, so I think we will find a way through it," says Lukasz. “Somehow we will reach a world where most people are essentially managers of agents, and the important skill will be the ability to describe a task.”

“Think of Tony Stark talking to JARVIS in Marvel, or John Travolta in Battlefield Earth talking to that model, that AI hologram in the Library of Congress. You have an AI companion that guides you through many different subjects and problems and even handles bureaucratic matters for you, which I personally hate. It deals with them or resolves them on your behalf. That’s an incredibly interesting concept.”

Krzysztof also sees it similarly: “Like you, I’m optimistic. I’m not afraid of these changes. I think they’ll probably bring more benefits than harm. Obviously, the transition period that accompanies every revolution and every major change is difficult. It requires a change in mindset and a change in the skill set developers need to have in their toolbox.”

The fundamentals still matter

One crucial thing kept recurring during the conversation: AI changes how software gets built, but that doesn’t mean engineers or QA specialists will be replaced. There’s still a need for technical knowledge and experience. Fundamental knowledge and understanding, such as the problem we’re solving and the business needs, still matter. Someone still needs to own the system throughout its life cycle. Testing, security, traceability, and business continuity remain important even when much of the implementation can be generated.

What changes is where people spend their time. Less effort may go into typing individual functions. More will go into defining the right context, reviewing decisions, connecting product requirements with technical consequences, and recognising risks that a model does not know to look for. Code may become easier to produce. Knowing what should be built, how far it needs to go, and who takes responsibility for it remains a human decision.