Only 5% of Companies Succeed. Here's How to Effectively Implement AI in Your Company [INTERVIEW]

This interview was originally published in Polish by Business Insider Polska on 17th June 2026.
‍

AI was supposed to speed up software development – and it often does. But shorter turnaround time alone isn't a measure of success, and poor use of the tools can cause more problems than it solves. Business Insider Poland talked with Michał Pierzchlewicz, our CTO and co-founder of TeaCode, who explains the most common mistakes in AI implementations, why the vast majority of AI initiatives never make it past pilot or fail to deliver business results in production, and how to implement AI solutions that actually generate ROI.

Your client base is broad – from startups, through small and mid-sized companies, to enterprise. What do implementations look like in those companies today?

Michał Pierzchlewicz: When large language models entered the mainstream, companies would often come in with a very generic pitch: "let's do something with AI." Back then, most inquiries came from startups.

Today, far more mature companies with solid business track records are committing to AI implementations. They have working solutions that need a next step – not everything built from scratch.

These conversations are also much more mature now, and the starting point is completely different. A client comes in with a specific problem – for example, a process that's time-consuming, expensive, or hard to scale. It's only during the conversation that it becomes clear that AI could be one of the tools to solve that problem – but not always and not in every case.

Clients increasingly understand that AI is not a goal in itself, but a technology that makes sense when it fits into a specific business process and delivers measurable value.

How do you measure whether such a solution actually works and is effective?

That's harder than it might seem. The mere fact that a feature uses AI isn't proof of its usefulness. The real measure of success is tangible impact on the process – shorter handling time, less manual work, greater effectiveness, cost savings. If you can't see that, AI remains a flashy but expensive add-on. 

The thing is, to properly assess this, you need appropriately defined profitability metrics from the very beginning. Many companies still don't do this. And it's not just about whether the solution works, but whether it works well enough to justify the costs.

When a solution moves from pilot to production, its costs can increase several times over. Take the Uvik report, for example. Their analysis shows that production costs can run three to six times higher than PoC costs. Companies are often unaware of how dramatically API costs can rise with scale. It's no wonder that only 5% of implementations deliver real value – I'm referencing the MIT report here.

However, it turns out that it can be done well. According to a Lenovo report, the projected ROI can be very close to a 1:3 ratio. I'm curious to see the actual effectiveness of those implementations, but it shows that real value is within reach. You just need to approach implementation with a clear head and the right expert backing.

So what is truly needed today for a technology project – with or without AI – to make business sense?

The key is a solid discovery process. Before a single line of code is written, you need to understand what problem you're solving, for whom, and why now. Clients most often come with a specific pain point: a process that's too slow, too expensive, hard to scale, or lacking a particular functionality. That's where we start – not from the technology, but from the problem.

We frequently encounter situations where a client brings a very elaborate specification. Increasingly, you can tell that these documents have been largely generated using AI tools. The issue is that when we start going through them in detail with the client, it turns out that a significant portion of those features aren't needed at all. That's why understanding the root of the problem is key for us – not blindly checking features off a list.

Do you ever advise a client against implementing AI after the analysis?

Yes, it happens. Sometimes after analysis it turns out there's no need for language models or advanced AI – all that's needed is modernization of the existing system, process improvement, or a change in product direction. It's normal for a concept to evolve during project development.

Abandoning AI or isolating a proprietary model can also be a deliberate strategic decision related to security. In mature organizations, this isn't a reflexive fear of technology – it's the result of a cool-headed risk assessment: if we see that an AI-based system can conceal its own violations, manipulate reports, or circumvent control mechanisms, it's more prudent to pause and strengthen or implement appropriate security procedures than to push implementation at all costs.

In practice, there's a growing consensus that a "successful AI implementation" isn't just about the right model and a good use case – it's above all about clear control mechanisms, from security policies and access rules, through audit logs, to technical safeguards. What's critical is that the organization is able to limit the system's scope of action when needed, modify its permissions, or temporarily disconnect it from critical environments.

Can you give an example of an AI implementation that genuinely added value to a project?

One such project was Plannin, a Canadian travel startup that came to us at its founding stage. We built a booking platform for them, and later transferred product knowledge to their own technical team.

That was also the moment when we started experimenting more seriously with solutions based on large language models. Plannin's model relies, among other things, on partnering with influencers who drive traffic to the platform. So we looked for ways technology could make their work easier, speed up content creation, or support them in their day-to-day use of the system.

We built an AI pipeline that automates the work. A creator pastes a video link, and the system analyzes the transcription, extracts mentioned locations, places pins on an interactive map, generates descriptions, and selects photos. What used to be tedious, time-consuming manual work becomes a process that takes just a few minutes.

What lessons did you take away from your first attempts at using LLMs in products?

The first deployments of LLM-based systems taught us a lot, particularly in three areas.

First, hallucinations. Although LLMs have a very broad base of general knowledge, domain-specific knowledge for a particular task is not well modeled. You have to consciously work around this – through grounding in your own data, validating outputs, or narrowing the model's responsibility to what it actually excels at.

Second, controllability and output consistency. In our work, an LLM is very often a component of a larger system, not a standalone product. That means it has to communicate with the rest of the system in a predictable and consistent way. This in turn requires structuring the output and the communication between the model and the application, as well as enforcing fixed output formats.

Third, AI requires a shift in thinking. You're moving from deterministic software, where the same input always produces the same output, to stochastic systems where an element of randomness is introduced. This shift has very tangible consequences. Tests that verify exact outputs stop working, because the output changes. You need to test properties instead – format, range, constraints. The nature of errors also changes: the problem is no longer a system bug, but a response that looks credible yet is factually incorrect. That's why evaluation becomes a critical part of project work.

How do you see the coming year in the context of AI?

In my opinion, it will be more of an evolution than a revolution. Models are obviously improving, but the leaps are no longer the "night and day" differences we saw at the beginning. The differences are now more subtle, more qualitative than spectacular.

I also expect greater specialization. Some models will be better suited for document analysis, others for content generation or working with code. It's starting to look more like selecting the right tool for the job than a race to build the most "magical" model. At the same time, AI spending will continue to grow – not because there will be a revolution, but because these tools are increasingly becoming part of everyday work.

In Poland, the situation is somewhat different from the hottest markets. We didn't have as much of an AI investment bubble here, so the risk of a dramatic burst is also lower. Development will be more gradual and more pragmatic than hype-driven.

We've already seen companies that downsized teams, expecting AI to take over part of the work. Is it clear now that this was overestimating the technology's capabilities?

I think some companies did indeed overestimate AI's ability to replace people. These tools can speed up many tasks, but they don't "handle everything." In practice, knowledge, context, and accountability on the human side are still needed. AI generates, suggests, and accelerates – but someone has to evaluate it, understand it, and ground it in product or business realities.

That's why at TeaCode, alongside deploying tools, we're building a culture of working with AI. The team doesn't use them mindlessly. We share practices and observations about what actually speeds up work and what is merely a curiosity. The natural next step is increasingly precise measurement of effectiveness – not just who uses AI the most, but whether it actually translates into better work quality and faster value delivery.

I do see a change in the nature of work, though. There's less "physical writing" line by line and more assembling elements, designing solutions, and thinking about the big picture. In a sense, it's reminiscent of the moment designers transitioned from drafting tables to CAD software. The tools changed how work is done, but they didn't make competencies unnecessary. Quite the opposite – they raised the bar.

So would you say this could lead to a kind of stratification? People focused solely on a narrow part of technical work might have a harder time?

Yes, that's a real risk. People who look at things more broadly – from a product, business, or systems perspective – will find it easier to navigate this new reality. Those who focused exclusively on a narrow slice of "manual" work may find it harder, because some of those tasks are indeed being taken over by tools. But it's not a verdict – it's a signal to change. I see it in our team: people who treated AI as an opportunity to step up to a higher level are developing faster.

Since a broad perspective is so crucial today, how should an organization choose a technology partner? How can you tell early in the conversation that a software house truly thinks about ROI and business?

The most important test is how a potential vendor responds to a ready-made specification from the client. If they accept it without question, estimate the man-hours, and say "We'll build it in three months" – that should be a red flag. A technology partner, before even thinking about writing code, will ask: "Why do we want to implement this? What business problem are we solving? And is AI really the best and most cost-effective tool for the job?"

The second thing is transparency about risks. If someone promises a seamless AI implementation without a data quality audit, infrastructure review, or even raising security and risk concerns, it means they're focused only on the technology. A partner with business DNA will immediately ask about architecture and technical debt, and will suggest verifying the organization's readiness. When the solution is novel or R&D-driven, they won't make blind promises but will propose a PoC to verify feasibility first.

In today's AI projects, competencies are becoming crucial – not just engineering, but also business analysis, project management, and implementation oversight.

If you were to create a short checklist for a potential client – what to do before deciding on an AI implementation – what would it look like?

The first step is to identify a process that genuinely hurts – where the company is losing money, time, or customers. This needs to be described in one simple sentence, two at most. No elaborate documents gathering dust in drawers. One specific, defined process – not an entire system right off the bat.

The second step is to plan and verify the feasibility of the solution, then estimate its cost – separately for the pilot and separately for production. Reports show that production costs can increase several times over, and you need to be prepared for that. Besides, it may turn out that the same result can be achieved without AI – usually at lower cost, since you eliminate token costs.

In the third step, the projected cost estimate needs to be compared against the company's current costs. Without this calculation, it's impossible to honestly say whether investing in AI even makes sense. Sometimes the cost of implementing and maintaining the system is higher than the cost of the problem it's meant to solve.

The fourth step is checking whether you have the data needed for implementation and what its quality is like. Very often, this is exactly where it's worth pausing to organize the data first – after all, input data quality directly drives the quality of results.

The fifth step is defining the pilot details: who will test the solution, over what time horizon, and what results you want to achieve. KPIs must be specific and measurable, because that's the basis for assessing whether the implementation makes business sense.

The sixth step – sometimes underestimated – is answering the question of whether employees will actually use the solution. You need to plan a production deployment strategy. The easiest scenario involves systems that run in the background and optimize processes invisibly to the user. But if you're building an additional tool, training and proper motivation are essential – otherwise the investment ends up as an expensive gadget that no one uses.