Recently, at zenital, we carried out a proof of concept for a client on the use of GitHub Copilot in Power BI development. Beyond evaluating the specific capabilities of the tool, the experience led us to a question that repeatedly arises in corporate environments: when should a new technology be incorporated, and when is it better to wait for it to mature?

Adopting it early can bring clear advantages: gaining access to new capabilities sooner, increasing productivity, improving certain processes and, above all, starting to build experience while other organisations are still evaluating its potential. However, it also means accepting a higher level of uncertainty: less stable products, incomplete documentation, features subject to change, and a limited base of real-world experiences to learn from.

Therefore, the decision is not simply about choosing between adopting a technology as soon as possible or waiting. It is about determining whether the value of starting earlier outweighs the risk and additional cost of working with a technology that is still immature.

The value of getting there first

In our PoC, we found that some Power BI development tasks could particularly benefit from the use of GitHub Copilot. AI can accelerate certain tasks and reduce the time spent on repetitive activities. For example, documenting a Power BI model may involve writing descriptions for dozens of tables, columns and measures. GitHub Copilot can generate this type of content in seconds and with a high degree of reliability. It can also speed up DAX code writing and assist in identifying and resolving issues in reports.

These improvements reduce development times and free up time for tasks where professional judgement provides greater value: understanding requirements, designing the model, analysing results or deciding how to present information.

However, the most significant benefit of experimenting early may not be immediate productivity, but the knowledge that is generated. Testing a technology before its use becomes fully established makes it possible to identify what it does well, where its limits lie and in which situations it truly adds value. In consulting, knowing a technology is not enough; we need the judgement to advise when it is sufficiently mature for a use case, what risks are involved in introducing it and what level of dependency is reasonable to assume.

‍

The cost of working with an immature technology

Early adoption also shifts part of the vendor's maturation effort onto users.

During our PoC, we encountered several examples of this. One was a bug that blocked Desktop Bridge, a component required to connect Power BI to the AI agent. We also observed less visible but relevant limitations for real-world adoption: in some tasks, Copilot was slower than desirable, and credit consumption could increase rapidly. This does not prevent the tool from being used, but it does affect its viability when scaling its use.

The PoC also highlighted that using a general-purpose tool is not always sufficient. To truly integrate it into our way of developing with Power BI, it is necessary to customise its behaviour through a dedicated agent or skills that incorporate our development guidelines and criteria. Discovering these requirements before scaling is, in fact, one of the main benefits of experimenting early.

On top of all this, there is another challenge: when something goes wrong, there is often nobody to ask. With a well-established technology, when a difficulty arises, the solution can usually be found in the official documentation, a forum or a technical article. With a very new technology, that support network is still being built.

Early users, therefore, do not only assume greater technical risk. They must also solve and document problems that those who arrive later will probably find already explained in the documentation or by the community.

‍

A dilemma that is not unique to AI

Power BI provides a very close example: Microsoft regularly releases new capabilities in Preview status, allowing them to be used before they reach their final version, but also requiring users to accept possible changes, limitations or unstable behaviour.

In our work, we are already exploring some of these capabilities, such as the PBIP and PBIR formats and the new Modern Visual theme.

Using them early allows us to become familiar sooner with a way of working that will become increasingly important. However, there is an important difference between testing them and building critical processes on top of them.

‍

‍

Not all technologies should be adopted at the same time

The right time to adopt a technology depends on several questions, which help us decide how much risk is worth taking:

• How mature is the technology? If significant changes are still expected, uncertainty increases.
• What benefit do we expect to obtain, and at what cost? Performance, financial cost and how these factors change when scaling should all be considered.
• Does it fit our way of working? A tool may be technically valid and still require customisation to comply with guidelines, standards or internal processes.
• What happens if it fails? Accelerating an internal task is not the same as affecting a critical process, just as using a capability that can easily be abandoned is not the same as building a dependency that is difficult to reverse.
• Do we have the capacity to experiment? Time, knowledge and room for mistakes are required.

These questions help avoid two equally unrigorous extremes: adopting a technology simply because it is new, or dismissing it solely because it is not yet fully mature.

The cost of waiting must also be considered. While one organisation is not experimenting, others may be accumulating experience and training their teams. When the technology becomes established, everyone can access the same product; what cannot be acquired immediately is the knowledge accumulated during that period.

‍