Smaller Teams, Higher Stakes: What CTOs Expect From AI

by Annetta Benzar

Around 1,500 technology professionals gathered in Warsaw on 10 September 2026 for the first Tech Race Summit, organised by SOFTSWISS. The event featured more than 40 speakers across three parallel tracks. Tickets for in-person attendance had sold out three weeks earlier.

TECH RACE SUMMIT 20262 1

The topic of AI ran through much of the programme, whether discussing cloud infrastructure and software development or security and the changing workplace. The discussion took flight during the CTO panel on the Vision Track.

Moderated by SOFTSWISS Chief Technology Officer Sergey Kastukevich, the discussion featured Yaroslav Sakharuta, CTO of Evoplay; Roman Bobreshov, Deputy CTO of Plata; Alexey Tulia, Executive Leader at CoinsPaid Dev; and Artur Bergman, founder and CTO of Fastly.

Together, they examined how AI is altering the structure of engineering teams and the role of the CTO.

One of the panel’s most provocative questions came near the end, when Kastukevich asked whether engineering teams would be much smaller in 2027. The response from all four panellists was an immediate and resounding yes.

TECH RACE SUMMIT 20266

Kastukevich did not stop at smaller teams, however. He next asked whether AI would write 99% of production code by the next Tech Race Summit in September 2027. Three of the four panellists agreed. Alexey Tulia questioned whether the percentage itself mattered.

“Agree, but who cares?” he said.

Yaroslav Sakharuta was the only dissenting voice. “Who will check?” he asked. Kastukevich clarified that he meant code reaching production without human quality gates, but Sakharuta maintained his objection. His concern centred on removing human review before release.

What Changes As Teams Become Smaller

Those answers came during a lightning round at the end of the panel. Nearly 40 minutes earlier, Kastukevich had begun with a question about the people doing the work. Had AI changed how companies managed and motivated engineers?

“I think people didn’t change,” Bobreshov said. “Now they just have a really good and powerful instrument like AI.”

Engineers still want good pay and interesting assignments, including the chance to work on demanding systems.

Bergman agreed that the basic work of leadership remained.“The core fundamentals of leadership and management haven’t changed,” he said.

He did, however, expect companies to employ fewer managers. AI can already handle some of the paperwork that takes up their time, from scheduling on-call teams to processing routine approvals. A manager with fewer administrative tasks could, therefore, oversee a larger group, and so fewer managing personnel would be needed overall.

Tulia described “two streams of expertise” emerging among engineers. Some remain drawn to the “craftsmanship” of writing code by hand. Others are “mostly attached to business outcome” and want to see the effect of their work as quickly as possible. The management challenge, he argued, is to understand which kind of work motivates each person.

As engineering teams become smaller, managers will have less room to misjudge what each engineer values in the work. There may also be fewer colleagues able to compensate for weak management or unclear ownership.

Who Signs Off The Code?

The next question Kastukevich fired was whether engineers might lose their sense of ownership as code becomes easier to generate and replace.

Bobreshov’s answer centred on production incidents. Once a service reaches “real clients” in “real production”, he explained, engineers remain “responsible for this code, for this service”. Whether a person or AI wrote it is of little matter when it fails. Someone still has to fix the bugs.

Tulia called AI a productivity tool for engineers. Its output still needs an owner.

“A human being is accountable at the end,” he said.

Bergman contextualised AI coding tools within a longer history of changes that programmers back then also initially resisted. Engineers once took pride in creating “beautiful punch cards” and later in “the assembly they handcrafted”. When compilers arrived, he added, some programmers argued: “We can’t trust compilers. We should hand-write our code.”

Bergman did not romanticise that resistance. “And then they didn’t have jobs anymore,” he concluded.

Tulia brought the comparison back to the present. AI may change how code is produced, but, ultimately, “a human being is accountable at the end.”

The leaders making those decisions also came under scrutiny. Sakharuta argued that companies were teaching employees how to use AI without giving enough attention to how it worked.

“We don’t know the fundamentals,” he said.

Tulia agreed, describing a similar gap he witnessed among executives. Engineers were being asked to build agents and internal AI platforms while some senior managers struggled to use even the simpler tools. He argued that executive and middle-management training deserved its own programme.

Sakharuta then turned the same criticism on CTOs.

Many CTOs began as engineers, Sakharuta said, but for some that hands-on experience dates back “five years ago, six years ago”, while the industry has continued to change. “A lot of CTOs now should be more hands-on,” he argued. Leaders need to practise using AI-assisted coding themselves if they want to judge its effect on productivity and staffing.

Bobreshov acknowledged that he faced the problem himself. A CTO must determine “if my team is performing or not, or if they are productive”, he said, drawing on metrics as well as personal experience. But he admitted to struggling “a little bit” because he lacked recent hands-on experience. “I need to gain it now,” he said.

The Hidden Cost Of Moving Faster

When Kastukevich asked where CTOs should invest, Tulia chose adaptability.

“Personally, I would invest in company adaptability,” he said.

That includes preparing the company to work with new technologies as they appear. Tulia also pointed to data quality, security and privacy, particularly where companies handle financial or customer information.

Bobreshov focused on bringing automation into the work of employees outside engineering. He named “lawyers, recruiters” and other staff who should be able to automate parts of their own work without knowing a programming language or relying on IT teams.

Bergman argued that CTOs should remove the processes slowing their companies down.

“I would invest in getting rid of bottlenecks, process and technology debt that are not conducive to a fast-moving, changing environment,” he said.

Automation, he warned, can make a poor process more damaging.

“If you’re doing the wrong thing or a bad thing, doing the wrong thing more efficiently just creates even more of the wrong thing,” Bergman said.

Kastukevich then asked whether AI-assisted coding would encourage companies to replace purchased HR or finance software with applications built internally.

To illustrate the risk, Sakharuta asked the audience to imagine an HR system built in two days. The speed looks impressive until it goes down on day three, is hacked on day four, and faces questions from a regulator on day five about a breach of personal data, backups, and certification.

“You cannot replicate so fast the process behind the system,” he said. Sakharuta argued that companies would still need vendors to maintain systems, handle incidents and meet security requirements.

Companies will still need vendors to maintain systems, handle incidents and meet security requirements. Sakharuta expected more businesses to experiment with their own utility software, although many would eventually decide that building it was a poor use of their time.

Bergman predicted that “a whole class of SaaS services” would probably not survive, partly because “the complexity for our employees is real”. He described staff having to choose among “50 or 80 different SaaS services” before they could even begin their work.

He distinguished those applications from the “systems of record” behind them. Customer databases and invoicing systems would remain “extremely important”, but employees could reach them through an AI agent instead of learning to navigate each platform. Companies could then change providers without having to “retrain your thousands of employees”, weakening the hold individual SaaS vendors have over their customers.

A company could redirect the agent to a replacement system while employees continued using the same interface.

The cost of AI divided the panel.

Sakharuta expected prices to rise as usage increased. He also pointed to the energy consumed by AI and the possibility of heavier regulation. Companies may eventually restrict their most expensive tools to trained or certified employees.

Bergman disagreed emphatically.

“I don’t think it’s expensive. I think it’s cheap,” he said.

He compared the cost of AI to that of experienced engineers. AI could justify its price by helping the latter complete more work, provided companies controlled which models they used and how much they spent.

Bobreshov questioned how companies were measuring efficiency. Too often, he said, people measured it by telling themselves, “I am really powerful.” However, “the biggest shift” appeared in smaller teams. In companies with “10,000 engineers,” the overall effect could still be “really small.”

What Smaller Teams Need

Sakharuta warned that AI could worsen an already serious burnout problem. Employees would face “more problems in a day than usual”, he said, placing a heavier cognitive load on people across the company.

“We already have enough burnout in engineering and business,” Sakharuta said, warning that “we will have even more.”

Bergman raised another problem facing smaller teams: access to company knowledge. Information is often scattered across documents and databases, with some of it known or only accessible by long-serving employees. AI agents struggle to work independently when they cannot locate that information. New employees face the same difficulty.

At Fastly, Bergman said, one team “onboarded agents as they would onboard coworkers.” A few months later, a new employee went through the same onboarding process. Previously, the process could take five months for someone to be “on call on their own” for the system. After the team collected its knowledge and made it easier to find, that period decreased to “less than four weeks.”

“It turns out it really helped the human as well,” Bergman said.

Kastukevich’s final question returned to the CTO. Would the position become less technical and more focused on business?

The panellists resisted the idea that greater business responsibility would make the CTO less technical. Bergman said CTOs needed stronger business knowledge, then added that they “cannot let go of the technical foundation.”

Kastukevich summarised the role of the CTO as increasingly connected to the business while remaining “still with a technical heart.”

Back

Become a Speaker

Become a Speaker

Become a Partner

Subscribe for our weekly newsletter