AI coding assistants have made writing software faster, but the next generation of tools goes further: agents that can deploy code, change configurations and work with live data. Alexey Tulia, Executive Leader at Coinspaid Dev, believes this changes both the developer's job and the way engineering organisations should prepare.
As covered by The Next Web, Tulia discussed these changes on the AI Impact in Engineering panel at Tech Race Summit 2026 in Warsaw. He described a transition already under way in many companies: AI is moving from drafting and analysis toward systems that can act directly through company infrastructure, with access that reaches from sensitive data to deployment pipelines. That access, he noted, forces teams to think carefully about permissions and about who is responsible for every decision an agent makes.
Writing code is becoming the easy part
For most developers, the first visible effect of AI has been speed. Boilerplate, prototypes and routine functions take minutes instead of hours. Tulia sees this as an opening to shift attention toward work that AI does not handle well on its own. Engineers can spend more time understanding the business problem behind a feature and following that feature into production, where its real value, or lack of it, becomes clear.
This has a direct effect on how developer productivity is judged. When an agent can generate thousands of lines in one session, measuring output by volume stops telling managers anything useful. Tulia suggested looking at whether code is correct, whether other people can maintain it, whether it is secure and how it behaves under real operating conditions. For leaders, the practical step is to give teams the business context of a task and a clear expected outcome, so engineers know what "done" actually means.
His forecast for the coming years sharpens the point. By 2029, Tulia expects smaller engineering teams to be responsible for larger areas, and AI to generate the majority of production code. In that environment, reviewing and verifying machine-written code becomes one of the core skills of the profession. "I think technical judgment becomes even more important," he said.
The foundation agents depend on
Tulia's advice to CTOs on spending was to connect AI investment to a specific need inside the organisation. The priorities he listed are familiar to any developer, and each one also shapes how safely an AI agent can operate.
Strong APIs define the actions an agent can take and the way it takes them, which makes its behaviour more predictable. Reliable data matters because an agent acting on stale or inconsistent records will make bad decisions quickly and at scale. Automated testing acts as a gate that catches faulty changes regardless of who, or what, wrote them. Observability gives teams a clear record of what happened inside a system, which becomes essential when some of the actors are software. Security and flexible architecture round out the base that lets a company introduce new technology without breaking existing operations.
Some of these investments pay off slowly. Reworking architecture or reducing dependence on a single vendor rarely brings immediate revenue. Their value shows up when a team needs to swap a provider or redesign a component because an earlier assumption failed. Tulia described his philosophy this way: "I don't need to predict the future perfectly. I need to make being wrong cheap."
He also warned against roadmaps that consume every available resource. A team with no spare capacity cannot try an emerging tool or react when priorities change, so some room for experimentation should be planned from the start.
The deployment question
The most practical part of Tulia's talk dealt with a scenario many teams will soon face. Picture an AI agent that can prepare a change and deploy it to production by itself. Should it be allowed to release without human approval? If the deployment fails, who is accountable?
Tulia's position is that an organisation should answer these questions before it gives an agent that level of access. In his view, the minimum requirements are:
- permission controls that restrict what the agent is allowed to do
- audit logs that record each of its actions
- a reliable way to stop the agent immediately
- a recovery process for failed deployments
For developers, these map onto well-known practices: scoped credentials and role-based access, structured logging, kill switches or feature flags, and tested rollback procedures. What changes is how critical they become once the entity pushing changes is autonomous. Tulia summarised the principle behind them: "The more authority we give machines, the more important accountability becomes." Greater autonomy in production, he argued, requires clearly defined authority and a human who remains responsible.
Part of a wider debate
Tulia's comments fit into a larger industry conversation about whether AI capabilities are advancing faster than safety practices. In September, Anthropic CEO Dario Amodei called for slowing capability development so that safety work could catch up. Tulia addressed a related but more local question: the limits an individual company should set once its AI agents can reach production systems.
That company-level view is where most engineering teams will feel the change. Global policy debates take years to settle, while decisions about agent permissions, review steps and rollback plans are being made inside organisations right now.
A changing CTO role
Tulia expects the CTO role to keep demanding deep technical expertise together with business understanding. As building technology gets easier, more vendors and more AI-generated systems will enter each organisation, and someone with strong technical judgment has to evaluate them, decide what to trust and define where human review stays mandatory.
For engineering leaders, the immediate task is clear: define safeguards and ownership before AI agents receive access to critical production systems. Coinspaid Dev, where Tulia leads, is an independent software engineering company focused on blockchain infrastructure, with more than 120 engineers, over 11 years of industry experience and teams building distributed systems across more than 20 blockchain networks.
