Make Being Wrong Cheap”: Alexey Tulia’s Practical Playbook for Leading Engineering Teams in the Age of AI Agents
Most conversations about AI in software focus on speed. Alexey Tulia, Executive Leader at Coinspaid Dev, prefers to talk about preparation: what companies should put in place before AI agents are trusted with real authority inside their systems.
According to Coinpedia, Tulia laid out his thinking at Tech Race Summit 2026 in Warsaw, where he spoke on the AI Impact in Engineering panel. His remarks covered the changing responsibilities of engineers and chief technology officers at a moment when AI is moving from a helpful assistant to a system that can act on its own. For anyone running a technology business, or planning to, the points he raised work almost like a checklist for the next few years.
Why “being wrong cheap” is the smartest strategy
One line from Tulia’s talk sums up his approach better than any other. “I don’t need to predict the future perfectly. I need to make being wrong cheap,” he said. It sounds simple, yet it runs against the way many companies plan their technology investments. The usual instinct is to study the market, bet on the winning tool and commit. The trouble is that in AI the winning tool can change within months. A model that leads today may be overtaken next quarter, and a pricing change can suddenly make a favourite vendor too expensive.
A company that has built its whole stack around one provider pays heavily for that kind of surprise. A company that designed its systems to be flexible can switch with far less pain. That is the core of Tulia’s advice: instead of trying to guess correctly, reduce the cost of guessing badly.
Where the money should go first
Tulia encouraged CTOs to tie every AI budget to a specific organisational need. Buying tools because competitors are buying them rarely produces lasting results. When there is a clear problem to solve, such as slow customer support, manual reporting or long release cycles, it becomes much easier to judge whether an AI investment is paying off.
His list of priorities is notable because most of it is not about AI at all. At the top he placed strong APIs and reliable data. APIs are the connections that let different systems talk to each other, and an AI agent can only be as useful as the systems it is able to reach. Reliable data matters for a similar reason: an agent working from incomplete or messy information will make confident mistakes.
Alongside these, he pointed to automated testing, observability, security and flexible architecture. Each one gives a business room to introduce new technology without breaking what already works. Automated testing catches errors before they reach customers. Observability means being able to see what is happening inside a system in real time, through metrics, logs and traces, so problems can be spotted and explained quickly. Security protects the data and infrastructure that AI will increasingly touch. Flexible architecture allows parts of a system to be replaced without rebuilding everything around them.
Tulia acknowledged that architecture work and efforts to reduce vendor lock-in may bring little immediate revenue. Vendor lock-in describes the situation where a company becomes so dependent on one supplier that leaving is expensive or technically difficult. Spending money to avoid it can look like a cost with no return. Its value appears later, when a provider needs to be replaced or a system has to be redesigned because the original assumptions no longer hold.
Leave room to experiment
Another practical point concerned capacity. If a roadmap consumes every available engineer and every available hour, the team has no space left to test an emerging tool or respond when priorities shift. In a fast-moving field, that rigidity can be costly. A competitor that keeps a small share of its capacity free for experiments can evaluate a new model or workflow in weeks, while a fully booked team may not get to it for months.
For smaller companies and startups, this advice may feel difficult to follow, since every hour seems already spoken for. Even so, setting aside a modest, protected slice of time for trials tends to pay back, because it keeps the organisation able to learn and adjust. A simple way to do this is to agree in advance how much time goes to planned work and how much stays open, then review that balance every quarter.
When AI agents get access to production
The most serious part of Tulia’s talk dealt with what happens when AI stops only suggesting and starts acting. Today, many companies use AI to draft text, analyse documents or propose code. The next stage, as he described it, links agents directly to live infrastructure, from sensitive data to the deployment pipelines that push software updates to real users. At that point, the agent can change things that customers depend on.
“The more authority we give machines, the more important accountability becomes,” Tulia said. His comments came as the wider technology industry debates whether AI capabilities are advancing faster than safety practices. Anthropic CEO Dario Amodei has called for slowing capability development so that safety work can catch up. Tulia brought that global question down to the level of an individual company, asking what limits a business should set once agents can reach its production systems.
He used a concrete example. Imagine an agent capable of preparing a code change and deploying it to production. Before letting it run, a company should be able to answer a few direct questions:
- Is the agent allowed to deploy without a person approving the change?
- Who is responsible if the deployment fails?
- Which systems and data can the agent reach, and which are off limits?
- Is every action it takes recorded in an audit log?
- Can the team stop the agent immediately if something goes wrong?
- How quickly can the business recover from a failed release?
In Tulia’s view, permission controls, audit logs, the ability to halt the agent and a reliable recovery process all need to exist before access is granted. Adding them after an incident usually costs more. Taken together, these requirements express his broader view that more autonomy in production has to come with clearly defined authority and a human who remains responsible for the outcome. One common way to apply this is a staged approach. The agent prepares changes and a person approves them, and only after a track record builds up does the agent get permission for low-risk tasks on its own.
What changes for engineers
AI is already speeding up coding and prototyping. Tulia argued that this should give engineers more room to understand the business problem behind a task and to follow the result all the way into production. In other words, the job shifts toward ownership of outcomes.
That shift depends heavily on how managers lead. Tulia said leaders can help by giving teams the business context and a clear expected outcome. An engineer who knows why a feature matters to customers and what success looks like can make better decisions, especially when AI is producing large amounts of code that still needs to be checked.
Measurement changes too. Counting lines of code or the number of tickets closed tells little when a machine can generate thousands of lines in minutes. Tulia suggested assessing productivity through correctness, maintainability, security and operational performance. Correct code does what it is supposed to do. Maintainable code can be understood and changed by the next person. Secure code does not open new risks, and code with good operational performance runs reliably under real conditions.
The outlook for 2029
Looking a few years ahead, Tulia expects smaller engineering teams to manage larger areas of responsibility by 2029. He also expects AI to generate most production code. If that happens, the bottleneck moves from writing software to verifying it. Someone has to confirm that the generated code is correct, safe and suited to the business, and that work calls for experience and judgment.
For people building a career in tech, this points to a clear set of skills worth developing. Careful code review and a solid understanding of how systems behave in production will likely matter more than raw typing speed. Engineers who can explain the business impact of a technical decision will be easier to trust with the larger areas of responsibility Tulia expects teams to carry.
The role of the CTO will keep requiring deep technical expertise combined with a real understanding of the business. As technology becomes easier to create, organisations will bring in more vendors and more AI-generated systems. Each one has to be evaluated before it goes live and watched afterwards. “I think technical judgment becomes even more important,” Tulia said.
Key takeaways for business and technology leaders
For companies planning their next steps with AI, Tulia’s message comes down to sequence. Safeguards and ownership should be defined before agents receive access to critical production systems. Investment should follow real organisational needs and strengthen the foundations that make change affordable, from APIs and data quality to testing and architecture. Teams need some free capacity to experiment, and engineers need enough business context to take responsibility for results.
Tulia’s approach accepts that nobody can say exactly how AI will develop, so the goal is an organisation that adapts quickly when forecasts miss.
About Coinspaid Dev
Coinspaid Dev is an independently owned and operated software engineering company specialising in blockchain infrastructure development. It has more than 120 engineers and over 11 years of industry experience. The company brings together software engineering, infrastructure, security and R&D teams with experience building distributed systems and blockchain infrastructure that operates across more than 20 blockchain networks.
