BetBoom: AI agents are changing development and forcing engineers to relearn

An author from BetBoom described a moment familiar to many developers: just as you manage to master the current tech stack, the market already demands work with AI-agents. Their main conclusion — AI doesn't cancel the profession, but rapidly changes the role of an engineer, security requirements, and companies' dependence on cloud infrastructure.

How the profession is changing

The text begins with personal experience of returning to development after a long break. During that time, the familiar world of CMS and universal web-masters disappeared: frontend and backend diverged completely, frameworks became the mandatory foundation, and entry into the profession became more complex. When the basic level was regained, generative AI entered the scene.

At first, ChatGPT was perceived as a crutch for those who didn't want to figure things out themselves, but over two years it transformed into an everyday tool that replaces search, forums, and part of routine analysis. Against this background, the author developed a new sense of falling behind: simply writing code is no longer enough; now you need to understand how agents work with code.

Agents enter the process

The next stage is familiarization with implementation practices through conferences and professional communities. After a Yandex event, it became clear that business is no longer discussing the fact of using AI itself, but rather metrics of its effectiveness, arguments for management, and ways to integrate new tools into team processes. At the MTS "Russian Techno" conference, this gap felt even sharper: cases with AI-agents for pull request reviews, routine automation, and acceleration of typical tasks already sound like a normal part of an engineering workflow, not an experiment for enthusiasts.

The author was particularly impressed by Sber's approach, where agents are proposed to be evaluated almost like employees: through KPIs, human-hours, task costs, and actual usefulness. This model helps explain the value of automation to the business, but simultaneously feeds developers' fear that an agent will begin to be perceived as a direct replacement for a junior or mid-level developer. The article, however, also contains a more grounded conclusion: even if an agent knows how to write tests, find errors, and suggest changes, responsibility for task definition, result verification, and business logic still remains with the human.

Security and dependence

The practical usefulness of agents in the article is not disputed, but the main emphasis shifts to risks. If such a tool can execute commands, work with a repository, and access internal services, then the cost of a mistake rises sharply. The author recounts recommendations from the stage: start not with maximum rights, but with maximum restrictions, run agents in isolated environments, and consider security as a basic condition, not an optional feature.

"Use at least rootless

Docker, but ideally move toward completely isolated infrastructure"

• Spin up a separate environment for a specific task
• Run the agent only inside this boundary
• Save artifacts to external storage
• Destroy the environment after work is complete
• Limit the lifetime of tokens and keys

A separate thought in the article concerns the economics of the entire race around agent systems. The author suggests that cloud platform and per-second billing service owners benefit most from the current boom. For companies, it's convenient: they can automate processes faster, reduce routine work, and scale experiments. But the deeper business ties development to such providers, the higher the risk of vendor lock-in: teams get used to agents, processes are restructured around them, and then the supplier gets room to raise prices.

What this means

The conversation about AI-agents in development has already moved from the hype level to operational practice. For engineers, this means not the end of the profession, but a shift in focus — from pure code writing to managing agents, verifying results, designing secure environments, and understanding the real cost of such automation.