Dev & EngARTICLE

AI finished the job. Now the work begins.

AI finished the job. Now the work begins.
Image: Cezar Taurion

At theGarage IA we have been conducting some informal research and complementing these observations with several conversations with executives and technology leaders. We cannot consider this a statistical sample of the market, but the data show a recurring pattern.

What do we see? There is a significant gap between the expectations created around AI in software development and the impact that many organizations are actually observing across the full engineering workflow.

The first generation of copilots made it much easier to write, explain and modify code. Now agentic tools have advanced several steps further. They can already explore repositories, change multiple files, run commands, run tests, interpret results, debug problems and fix their own code in successive cycles.

Therefore, the discussion can no longer be reduced to the idea that AI accelerates code generation and simply shifts the bottleneck to review and testing. Agents are also advancing into these stages.

The more interesting question has become a different one. The capacity to produce, test and modify software is growing rapidly. Can the engineering system absorb this new capacity while maintaining quality, security, maintainability and reliability?

That is where the main challenge appears. Producing more changes does not necessarily mean putting more useful features into production. Pull requests can grow in number and complexity. Reviews can become more difficult. Automated tests may not adequately cover the changes. Dependencies and business rules are not always explicit in the code or available in the agent's context.

The agent can run existing tests and fix what they identify. But that does not mean the existing tests are sufficient.

Passing tests demonstrates conformance with what was tested. It does not demonstrate the absence of problems that no one thought to test.

This point is especially important in large, legacy systems. An agent may understand one part of the repository very well and still not have access to all the knowledge needed about integrations, architectural decisions, production behavior and external dependencies.

For this reason, it is not correct to claim that code produced by AI is inherently worse. Nor is it defensible to conclude that, since agents are getting better, the engineering problem is disappearing. What is happening is that the bottleneck is shifting to a different level.

As agents take on generation, testing, debugging and part of integration, the importance of an organization's ability to verify and govern changes produced at growing speed increases.

This explains why development agents make practices we have known for decades even more relevant. Comprehensive and fast automated tests, reproducible environments, reliable CI/CD, clear APIs and contracts, access control, environment isolation, rollback, dependency management, accessible documentation and objective criteria for promoting code to production, all of these remain essential.

The quality of the environment for an agent is directly related to the quality of the engineering platform itself. A codebase that is poorly documented, with fragile tests, inconsistent pipelines and poorly understood dependencies was already problematic for human developers. Agents do not automatically eliminate these fragilities. In some cases, their speed simply makes them surface more quickly.

For this reason, measuring development productivity solely by lines of code, commits, accepted suggestions or volume produced has lost even more of its meaning. We need to look at the full workflow.

We also need to look at a less obvious effect. If producing changes becomes very cheap, we can simply produce more changes. In this scenario, the developer's local productivity increases, but the total complexity of the system can also grow.

Code that is cheap to produce is not necessarily software that is cheap to own. That is why the arrival of programming agents should be seen less as the end of software engineering and more as a shift in what becomes scarce.

Writing code is ceasing to be one of the main constraints. Testing, verifying, integrating, understanding consequences, controlling changes and operating reliable software gain relative importance.

Agents will keep improving and will probably take on growing parts of these activities. This does not eliminate the need for engineering. It raises the level at which it must be practiced.

In the end, the organizations that extract the most value from these tools will not necessarily be those that produce more code or use more agents. They will be the ones capable of turning generation capacity into delivery speed, speed into reliable software, and software into business results.

Translated from the Brazilian Portuguese original · Read the original

More from Cezar Taurion
View profile →