THE CHAINSAW HAS ARRIVED. ARE YOU STILL USING AN AXE?

What’s happening in software development in the United States and what to expect in Brazil

By Marcos Bozza, CEO of Axoma

A few weeks ago, I watched the film Train Dreams, which follows the life of a logger in the early 20th century United States, a man who makes a living through heavy labor building railroads and harvesting timber. One scene stayed with me: the moment when the character, now older, after a lifetime working with an axe, comes across a group of young workers cutting trees with chainsaws. Everything happens at a pace he has never seen before. The logger picks up one of the chainsaws. He tries to start it and can’t. He doesn’t react, doesn’t express open frustration. He goes silent amid the noise of the machines, visibly uncomfortable, almost displaced, as if he himself had become obsolete along with the tools he used.

That was on a Friday night. The following week, I was in meetings with development teams in the United States hearing essentially the same story, only with code instead of trees.

What I’m seeing in practice

One of the most direct conversations I’ve had recently was with a client’s CTO. He opened a meeting with his team by demonstrating something simple: he asked Google Gemini to generate an API gateway. Total time: 263 seconds.

In the same meeting, he showed something else. He took a real backlog task that one of the team’s engineers had spent about three hours implementing. He redid the same task using AI in roughly 30 minutes. He closed the meeting with a statement no one in the room forgot: “After next week, nothing will be coded the old way ever again.”

Similar situations have been recurring and, somewhere between the excitement and the technical debates teams are immersed in, there’s a question hanging in the air that no one quite dares to ask out loud: where do I fit into all of this?

It’s a legitimate question and, in many cases, an urgent one. Experienced developers, highly competent within the traditional model, are starting to realize that part of what once differentiated them is losing relevance. What used to be highly valued — implementation speed, command of syntax and the ability to quickly translate specifications into code — is now partially absorbed by these tools. This does not eliminate the need for professionals, but it changes the nature of the contribution expected from them.

A concrete example helps illustrate this shift.

The backend team lead at one of our clients has almost stopped writing code directly. With the support of GitHub Copilot, he structures what needs to be done, generates pull requests, reviews the output, adjusts and approves it.

He hasn’t been replaced, but the focus of his work is no longer coding itself.

Those who fail to adapt to this new model are, in fact, at risk. A new professional profile is emerging, less centered on execution and more on the ability to interpret, structure and validate. This requires a different skill set: clarity of thinking to define requirements precisely, the ability to break down complex problems into parts that can be delegated to AI, a systemic view to understand how different components interact and, most importantly, critical judgment to assess whether what has been generated is correct, not just syntactically, but functionally.

At the same time this more structured model is taking shape, I’ve also seen movements toward development with minimal human oversight, an approach often referred to as vibe coding. Code is generated by AI, superficially validated and pushed to production under the assumption that “if it works, it’s good enough.”

In practice, this model tends to accumulate risks that are not immediately visible. The first is the loss of traceability and the ability to answer questions such as: Which requirement did this code originate from? Who decided on this implementation? Why was this approach chosen? What changes were made over time?

In traditional engineering, this comes from artifacts such as tickets, pull requests, code reviews and decision logs. With unsupervised AI, gaps emerge: decisions are not documented, the model generates code without a clear record of rationale. In the event of a failure, incident or legal challenge, there is no clear accountability trail.

Another critical issue is the risk of systemic inconsistency. AI can generate solutions that are locally correct but misaligned with the architecture, internal standards or business rules that were not explicit in the prompt. This leads to systems that work in isolation but fail to hold together as a cohesive whole.

For this reason, the idea of fully automated development without qualified supervision still seems premature.

What we’re experiencing at Axoma

At Axoma, we are going through this transition ourselves. As in many companies, what exists today is an ongoing process — one that involves experimentation, adjustments and, in some cases, revisiting assumptions that seemed solid until very recently.

We started, like most of the market, with autocomplete tools. The initial gains were clear: faster code writing, fewer repetitive tasks and smoother day-to-day workflows for developers.

It quickly became evident that this was only the first stage. The next step, more complex, has been the adoption of agentic coding models. Not as an abrupt shift, but as a gradual build. We have been testing different approaches and tools, including more integrated development interfaces as well as command-line tools such as Cursor CLI and Claude Code, evaluating where they truly add value.

At the same time, we began integrating AI into less obvious parts of the process, beyond direct code generation. For example, in support workflows, we are using AI to pre-analyze tickets before they even reach developers. This reduces triage time and helps prioritize what truly requires human attention.

In task management, we have started testing scenarios where AI performs an initial triage of new tickets, suggesting classifications and even early breakdowns. This does not eliminate the team’s role, but it reduces the initial organizational effort.

In production, we have been exploring more advanced automations. When an error is detected, agents can trigger workflows that range from problem analysis to opening a pull request with a potential fix. Naturally, this still goes through human review, but it significantly changes response times.

We are also experimenting with agents for test generation. In some cases, they can quickly cover basic scenarios and increase coverage, freeing the team to focus on more critical validations.

There are also situations where AI is beginning to fill operational gaps. In mobile projects, for instance, we have been able to move forward on specific tasks using developers with only web experience, something that previously would have required deeper expertise in native development. Parts of the stack that once demanded highly specialized knowledge are becoming much more manageable.

None of this is linear. And that may be the most important point: adopting AI is not just a tooling decision. It requires adjustments in processes, in professional roles and in how work itself is structured. We are learning this in practice.

It is precisely this learning — along with its uncertainties, testing and refinements — that has been guiding how we support our clients through the same transition.

And in Brazil?

In Brazil, this movement is likely to arrive quickly and, in some cases, has already begun with direct implications.

The first is increasing pressure for productivity. Engineering teams are expected not only to deliver, but to deliver more with less operational effort.

The second is a reevaluation of team structures. Not necessarily smaller teams, but teams with different roles and a higher concentration of responsibility among more experienced professionals.

The third is the accelerated adoption of tools, often before a deeper reflection on how they fit into existing workflows.

And perhaps the most important: the need to evolve processes, not just technology. Companies that anticipate this shift and address it in a structured way are likely to gain a real advantage. Those that see AI merely as an isolated productivity tool face a different risk: increased complexity, more rework and, ultimately, loss of control over their own systems.

The chainsaw has arrived

In the end, the logger’s problem was not the chainsaw. It was not knowing what to do with it. The technology was there and clearly more efficient, but it required a different way of working.

In software development, we are entering that exact moment. The ability to produce code has increased, but that does not solve the core problem: understanding what needs to be built, why and how it generates value. More than tools, this becomes a question of direction.

What I have seen in the US market is that companies making consistent progress are not necessarily those that have adopted the most tools, but those that have been able to combine technology with well-grounded structural decisions: architecture, process and governance.

This is where Axoma has been operating, closely following this transformation, supporting companies through the transition and connecting technical decisions to business objectives.

The chainsaw has arrived. Are you prepared to work with it, or are you still trying to use it like an axe?