Technical Judgment, Clear Ownership and Room to Be Wrong: Alexey Tulia’s View of Engineering Leadership in the AI Era

As published by The AI Journal, Tulia outlined his thinking at Tech Race Summit 2026 in Warsaw during the AI Impact in Engineering panel. The session looked at how the work of engineers and CTOs is evolving as AI progresses from drafting text and supporting analysis to systems capable of acting through a company’s infrastructure.

Tulia’s long-range forecast sets the tone for the rest of his argument. By 2029, he expects engineering teams to be smaller while each one covers a wider scope, and he anticipates that AI will generate most of the code running in production. When machines write the majority of software, the scarce skill becomes checking it: deciding whether generated code is correct, whether a system is well designed and whether a new tool deserves a place in the stack. That challenge will grow as building technology becomes easier, since companies will bring in more vendors and more AI-built systems that all need evaluating. For this reason, Tulia said, the CTO of the coming years will still need deep technical knowledge combined with a real understanding of the business. “I think technical judgment becomes even more important,” he said.

The same logic shapes his view of individual engineers. Faster coding and prototyping, in Tulia’s opinion, should give engineers space to engage with the business problem behind their tasks and to follow their work through to production, where its real impact becomes visible. Managers play a direct part in making that happen. When teams know the business context and understand what outcome a project is expected to achieve, their performance can be judged on whether the software works correctly, can be maintained over time, keeps systems secure and runs reliably. Measuring output by the quantity of code tells leaders little once much of that code is produced automatically.

Ownership becomes even more critical when AI moves from writing software to acting on it. Companies are preparing to connect agents to live environments, where they can reach sensitive data and use deployment pipelines. “The more authority we give machines, the more important accountability becomes,” Tulia said. He asked the audience to picture an agent that can prepare a change and deploy it to production: should it be able to release without a human approving it, and who answers for the consequences if the release fails? His answer points to preparation. An organization should grant that level of access only after it has put the necessary protections in place:

• permission controls that restrict what the agent is allowed to do;
• audit logs that keep a record of its actions;
• a way to stop the agent if something goes wrong;
• the ability to recover from a failed deployment.

In Tulia’s framework, any increase in an agent’s autonomy has to be matched by clearly defined authority and a human who remains responsible for the outcome.

Tulia applies a similar principle to technology spending. He urged CTOs to connect AI investment to a concrete need within the organization and to strengthen the foundations that make change safe, including solid APIs, dependable data, automated testing, observability, security and flexible architecture. He also warned against roadmaps that allocate every available resource, because a team with no spare capacity cannot experiment with emerging tools or adjust when priorities shift. Work on architecture and on limiting vendor lock-in may bring little revenue in the short run, but it makes replacing a provider or redesigning a system far less painful when earlier assumptions no longer apply. “I don’t need to predict the future perfectly. I need to make being wrong cheap,” Tulia said. His practical conclusion for engineering leaders is to settle safeguards and ownership now, before AI agents are given access to critical production systems. Tulia draws on his experience at Coinspaid Dev, an independently owned and operated software engineering company specializing in blockchain infrastructure development, which employs more than 120 engineers, has over 11 years of industry experience and runs software engineering, infrastructure, security and R&D teams building distributed systems and blockchain infrastructure across more than 20 blockchain networks.