AI Agents in Production: Why Engineering Teams Need Clear Ownership Before Automation

AI tools that previously only suggested code are now beginning to carry out tasks within real infrastructure. This situation raises a practical question for all engineering teams regarding who will be responsible when an agent makes a change.

According to The Tech Portal, Alexey Tulia, Executive Leader at Coinspaid Dev, took up this question at Tech Race Summit 2026 in Warsaw, where he spoke on the AI Impact in Engineering panel. His main point was that the benefit companies get from AI in engineering will depend on how clearly they define authority, safeguards, and human responsibility around it. The capability of the models themselves is only part of the picture.

From assistant to actor

In order to understand why this is important, we can consider the way most teams currently use AI. A developer will ask the model to write a function, to summarise a document, or to analyze a log file. The model then provides an answer and a person reads it, checks it, and decides on their next step. Human review thus comes between the AI’s output and any actual consequences.

The next stage removes much of that buffer. AI agents are now being linked to live systems such as databases which contain sensitive records, cloud accounts, ticketing tools and deployment pipelines. Since it has access to these systems, the agent can do more than suggest a change; it can apply a configuration update, merge code, or push a release by itself. When software is capable of acting in a production environment, concerns regarding permissions and responsibility for each decision cease to be purely theoretical, and the teams need to have answers before the first agent is given its credentials.

How the engineer’s job is changing

Tulia thinks that the change will transform engineering teams within a few years; he believes that by 2029 smaller teams will be in charge of larger areas of responsibility and that AI will produce most of the production code. In such a situation, when a machine writes most of the code, checking that code will become the more difficult and therefore more valuable aspect of the job.

He views the improvements in coding and prototyping as an opportunity. Instead of spending so much time typing, engineers can spend more time understanding the business problem involved in a given task and seeing their work through right up to production, where it will either achieve the desired result or it won’t. In order for this to take place, managers must provide teams with genuine business context and a clear expected outcome, rather than just a list of tickets.

The method used to measure productivity also changes. It doesn’t make much sense to count lines of code or commits when an agent is able to produce thousands of lines in a matter of minutes. Tulia referred to more sensible criteria: whether the code is correct, whether it can be maintained, whether it is secure and how it performs in real operating conditions.

In his view, the CTO role will always require deep technical expertise alongside business understanding. Since building technology is becoming easier, companies will employ more vendors and more systems produced by AI, and somebody will have to assess all of them. “Technical judgment therefore becomes all the more important,” Tulia stated.

Building a foundation that can adapt

Tulia was clear about budgets: AI spending should be linked to a specific organizational need, and it’s a weak justification to adopt a tool simply because the competitors have it. The kinds of investments he gave priority to are those that allow a company to introduce new technology safely, and each of them also has an effect on how well an AI agent can work.

Good APIs give agents a controlled, predictable way to interact with various systems. Since the decisions of an agent are only as good as the data it reads, reliable data is important. Automated testing catches faulty changes before they reach users, whether a human or a machine made them. Observability reveals what actually took place in a system, something that is essential in the case where the actor is software. Finally, security and a flexible architecture finish off the foundation.

Certain aspects of this work generate only modest immediate income. For instance, the aim of reducing vendor lock-in seldom appears in a quarterly report; its benefits only become evident later, when it is necessary to change providers or when a system has to be redesigned since the original assumptions are no longer valid. Tulia described this strategy by saying, “I don’t need to predict the future perfectly. I need to make it cheap to be wrong.”

He also maintained that it is necessary for teams to have some spare capacity; if a roadmap uses up all the available time, then the engineers will not have the opportunity to test a new tool,l and the organization will find it difficult to react when priorities change. It is this amount of slack in the plan that enables experimentation to take place.

The production test

To illustrate the accountability issue, Tulia presented a specific example. Suppose there is an AI agent which is able to prepare a change and deploy it to production—should it be permitted to do so without a person first approving the release? And if the deployment causes something to break, then who should be held responsible?

He answered that the organization has to put certain controls in place before granting that level of access:

• permission controls that limit what the agent can touch
• audit logs that record every action it takes
• a reliable way to stop the agent at any moment
• the ability to recover quickly from a failed deployment

These requirements form part of his wider argument: the more autonomy an AI system is given in the course of production, the more clearly the company has to define both the authority it holds and the human responsibility connected to it. “The more authority we grant to machines, the more important accountability becomes,” Tulia stated.

What this means for engineering leaders

For organizations that are already working with AI agents, the lesson is one that can be put into practice. The right time to determine who is responsible for an agent’s actions, what it is permitted to do and how its errors are to be detected and corrected is before it is given access to important systems. It is too late to deal with this once the first incident has occurred. Companies that establish these safeguards from the start will be in a position to assign greater responsibilities to the agents with confidence. In contrast, those that omit this step will have to learn the lesson in a live environment.