Technology, innovation, and AISeptember 21, 2026

What happens to software quality and technical debt when AI writes more of the code?

How does AI-generated code affect software quality, technical debt, accountability, and traceability? Explore the risks for development teams and regulated industries.

LLI Team

  • AI-generated code
  • QA
  • Regulated industries
  • Project quality
AI-generated code, software quality, and technical debt

No doubt, AI has opened new doors not only to productivity but also to how quickly teams can generate code and create internal tools or prototypes. Building features that once took days can take hours, and some tasks can be done almost automatically during the meeting. But among all this AI hype and experimentation, we still need to ensure that someone understands what the product is supposed to do, decides whether the architecture can support it, tests what has been built, maintains it, and takes responsibility when something goes wrong. There’s an urgent need for accountability, ownership, and traceability of the models.

LLInformatics’ CEO and co-founder, Lukasz Lazewski, was a guest on a podcast “Porozmawiajmy o IT” by Krzysztof Kempinski. They discussed how AI is changing software development, and why the most important questions are moving beyond the code itself.

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.

What happens to the project quality when code generation moves faster than reviewing

The conversation started with the question: What happens when the amount and speed of code generation don’t leave room for code reviews or proper understanding? While in some cases the products are just one-off projects that will be discarded, others last for years and require maintenance.

This all comes down to accountability. For Lukasz, accountability is one of the most important questions surrounding AI-generated software. “The first is that this entire process, including quality, comes down to responsibility and accountability. Who do we go to when something breaks? That is interesting both at the level of an individual developer who is now directing these models and at the level of the whole business.”

Lukasz compares this to the rise of Linux, an open-source software, in the 1990s. Free alternatives created enormous possibilities, but businesses still valued having a supplier they could hold accountable when something went wrong.

The same question applies to software created through AI. “You can generate something for yourself, but who is responsible for maintaining it and developing it further? What happens when the infrastructure and the code start ageing?”

“We still need to ask the same question about accountability and, in many cases, traceability, meaning the ability to demonstrate how something was generated or created.”

For Lukasz, it all comes down to understanding what quality actually means and how it impacts the business. AI can help find the problem, but it cannot always eliminate the business consequences of fixing it.

Can AI-generated code reduce the predictability of the code in regulated industries?

For regulated industries, such as healthcare or fintech, predictability and traceability are critical. As Krzysztof says: “These are industries where regulations and guidelines mean we need to be able to demonstrate, fairly deterministically, why something behaved in a particular way or why a particular decision was reached, because we are dealing with people’s finances and health.”

Lukasz described his experience with building an application in Claude. After carefully describing what to build, the model suggested building it in Node.js, even though the better option would be to build it natively in Swift for macOS. After Lukasz raised that up, the model agreed and called it the “great decision.”

“If I hadn’t known that or hadn’t asked the follow-up question and obtained that knowledge, it would have led me down a probabilistic path of decisions that might not have been right or optimal for me or my business.” That’s where contextual knowledge and awareness become critical.

That also applies to regulated sectors. “In healthcare, for example, you need medical knowledge and unfortunately legal knowledge too, because there is a great deal of compliance involved, patient-data leakage, anonymisation, and so on.” Any potential vulnerability would be a serious HIPAA or GDPR violation, and leaders need to be aware of those security and safety issues.

The fact that AI can help diagnose a problem later does not remove the consequences of earlier decisions. Lukasz argues this with an example: “If I have a production system with real customers using it, making changes to that system can create a problem that neither AI nor humans can resolve within an acceptable business timeframe. If we make the wrong decisions at the beginning about the database structure, we don’t simply have to propose a new database structure on the fly. We also need a migration process for moving all that data, which introduces risk.”

The senior developer is becoming a manager of context

Lukasz sees another change happening inside engineering teams. Senior developers are spending less time producing every line of code themselves and more time directing, reviewing, and contextualising work generated by AI. He compares AI agents with junior or mid-level developers. Giving them a task is rarely enough. They need context, constraints, feedback, and someone experienced enough to recognise when the proposed direction creates risk. That changes what seniority looks like.

The developer’s work therefore moves towards deciding whether the proposed solution makes sense, identifying risks, refining the context, and connecting technical choices with the intended product outcome. “You still need the knowledge to understand that the model is going in the wrong direction, because there are risks you recognise from experience.”

That experience becomes particularly important when AI presents a plausible answer. It can confidently suggest a technology, architecture, or implementation approach, but someone still needs technical background and business knowledge to ask whether another option would better serve the product.

Connecting the business and technology sides with AI

Most problems in projects aren’t related to programming. As Lukasz highlights, they often arise when requirements are transferred between the product team or end client and the development teams.

AI can eliminate that problem. “In the most advanced workflow I have seen so far, at one of our legal-tech clients in the U.S., the AI model analyses Jira and sees what has been assigned to me today. I can ask it questions about those tasks without taking up the product manager’s or product owner’s time. The AI explains them to me.”

“All project conversations from the product and business side are recorded and transcribed. Photos and hand-drawn diagrams created during product workshops are attached as well. That material is then compared with the tickets created by the product team.”

The whole process is enhanced by AI. Many blockers can be reduced, such as waiting for backend/frontend, API integration, or even for a product owner to clarify things. It becomes a loop, but it still includes humans rather than AI alone.

This is part one of the conversation for “Porozmawiajmy o IT” podcast. Click here for the second part.

Start the conversation

Build the right technology with the right engineering partner.

Tell us what you are planning, and our senior team will help you define the strongest way forward.

Talk to our team