For decades, a significant portion of the tech industry has been obsessed with accelerating development. Companies wanted to launch products sooner, reduce the time between idea and production, and enable engineering teams to deliver more features in increasingly shorter cycles. First came agile methodologies, then DevOps, continuous integration, infrastructure as code, and cloud platforms. Now, artificial intelligence promises to accelerate the entire process once again.
AI-assisted development tools can generate features, write tests, explain repositories, suggest refactorings, and produce complete blocks of software in a matter of seconds. Code generation is no longer an exclusively manual activity and is beginning to become a collaborative process between developers and language models.
The change is already visible. A Sonar survey published in January 2026 found that 721% of developers who have tried AI tools use them daily, and that, according to the surveyed professionals themselves, around 421% of the code they contribute is already generated or significantly assisted by AI.
But this acceleration is creating a contradiction that the industry is only beginning to understand: We can produce code faster than our organizations can review, understand, and maintain it..
The new crisis in software engineering may not be a shortage of code. It may be exactly the opposite.
We are entering an era of code overproduction.
There's an idea that Artificial Intelligence is forcing us to reconsider: writing code and software engineering aren't exactly the same thing. Code is a representation of decisions about architecture, business, security, performance, and maintenance. It can compile correctly and still be a poor solution for the system it will be implemented in.
An AI model can receive an instruction and generate a technically valid function. However, that function exists within a much broader context. It must respect internal conventions, domain models, architectural decisions, security policies, and behaviors that are likely not fully expressed within the prompt.
That is precisely why the DORA 2025 report on AI-assisted development describes Artificial Intelligence primarily as a amplifier. The research, based on responses from nearly 5,000 technology professionals and more than 100 hours of qualitative data, concludes that AI tends to magnify an organization's existing strengths and weaknesses.
A team with good practices can accelerate. A disorganized system can also accelerate, but in the wrong direction.
AI generates code. Engineering still has to decide whether that code should exist.
For a long time, software development had a natural limitation: producing code took time. A developer would analyze the problem, design a solution, and write the implementation. Human speed itself limited the number of changes that could be simultaneously added to a repository.
AI is partially eliminating that restriction.
Now a developer can produce several alternatives in minutes. An agent can modify dozens of files. One tool can generate tests and documentation while another system proposes a refactoring. The potential volume of changes increases dramatically, but the human capacity to evaluate those changes doesn't grow at the same rate.
A recent GitLab study uncovered precisely this paradox. While 781% of the developers surveyed reported writing faster code with AI, and 731% perceived improvements in quality, 851% identified review, validation, and governance as greater constraints than code creation itself. Furthermore, 731% expressed concern about the long-term maintainability of AI-generated code.
The factory produces faster. Quality control doesn't.
And when that happens, inventory starts to accumulate.
One of the most seductive experiences of AI-assisted development occurs when a tool generates exactly what we seemingly needed. The code appears clean, the solution seems reasonable, and the initial tests work. At that moment, a dangerous temptation arises: to accept the change before fully understanding it.
The problem is cognitive. Generating a solution might take seconds, but building an accurate mental model of how that solution interacts with a complex system still requires human attention. The developer needs to understand dependencies, side effects, exceptions, and implicit decisions.
The greater the volume of code generated, the greater the effort required to maintain that mental model.
The risk isn't just about introducing errors. It also involves a new kind of distance between the team and its own software. Developers begin working on components they technically manage, but never designed or deeply understand.
Over time, the repository may become a system that anyone can modify using AI, but that fewer and fewer people understand end-to-end.
That problem isn't solved by generating more automated documentation. It's solved by preserving technical understanding.
One of the most interesting studies on AI-assisted development was conducted by METR with experienced developers working on mature open-source projects they knew intimately. Participants expected AI tools to reduce their work time by approximately 24%. After using them, they estimated they were actually about 20% faster.
The measured results showed something different.
In that specific experimental environment, allowing the use of AI tools increased task completion time by 19%.
The study doesn't prove that AI always slows down developers. Its authors explain the specific characteristics of the analyzed scenario: experienced professionals, mature repositories, and complex tasks. But the result reveals something much more important for engineering leaders: The feeling of speed does not always equate to real productivity.
Writing a function quickly can feel productive. But if we then need twenty minutes to review, correct, and adapt the result, the perception changes.
Engineering needs to start measuring the entire lifecycle. Not how much code AI generates, but how much reliable software actually makes it to production.
The industry learned years ago that lines of code are a poor productivity metric. One engineer might solve a problem by removing 2,000 lines while another introduces 5,000 new lines and more complexity. Measuring volume rewards activity, not necessarily value.
AI threatens to revive that mistake under new metrics.
Number of pull requests.
Percentage of code generated.
Number of tasks completed.
Prompts executed.
Generation speed.
All of these can become vanity metrics if they aren't connected to engineering outcomes. A team can double the number of changes made while simultaneously increasing review time, production defects, and system complexity.
The true indicator should consider the entire flow: from problem definition to the stable and maintainable delivery of the solution. DORA has spent years studying capabilities and conditions related to the performance of technology teams; its report on assisted AI reinforces precisely the idea of analyzing adoption within the entire organizational system, not as an isolated coding improvement.
AI can increase output. Engineering needs to guarantee outcomes.
Another common misconception in this debate is assuming that AI-generated code will simply be better or worse than human-generated code. The reality appears to be more complex. Both can have problems, but the patterns of those problems are not necessarily the same.
A large-scale study published in 2025 compared over 500,000 samples of human-generated and AI-generated code in Python and Java. Researchers found that AI-generated code tended to be simpler and more repetitive, but more frequently contained unused constructs and directly hardcoded debugging elements. Human-generated code exhibited greater structural complexity and more maintainability issues. However, the analysis also found a higher prevalence of high-risk vulnerabilities in the AI-generated code.
This has an important implication: traditional review processes may need to evolve.
If the way defects are introduced changes, the way they are detected must also change. Teams need to learn what the common patterns are in model-generated code and design specific controls for them.
We are not replacing a human author with an artificial one. We are incorporating a new type of code producer into the development system.
Security is probably one of the areas where this transformation demands the most attention. Veracode's GenAI 2025 code security report analyzed over one hundred language models in Java, JavaScript, Python, and C#. According to its findings, 45% of the generated samples failed security tests.
The figure doesn't mean that all AI-written software is automatically vulnerable. The study uses tasks and tests designed to evaluate specific secure coding behaviors. But it does reveal an uncomfortable truth: just because a model generates seemingly functional code doesn't mean it's correctly implementing security controls.
The Cloud Security Alliance has also warned that programming assistants are changing the way untrusted code enters development environments and that security and engineering teams need to collaborate to detect risks at earlier stages.
The architectural consequence is clear. If generation speed increases, automated controls must be implemented closer to the point of creation. Waiting until a final audit means allowing too much potentially problematic code to advance through the pipeline.
Security needs to move at the speed of AI.
Imagine a team of ten developers where each professional can produce two or three times as many changes thanks to generative tools. If the number of reviewers remains the same and the code review process continues to function exactly as before, the math is simple: a queue will appear.
Pull requests will be larger.
The reviews will be quicker and more superficial.
Important comments will compete with automatically generated changes.
And eventually the team will begin to trust that "if the AI wrote it and it passes the tests, it's probably okay.".
That moment represents a dangerous shift in engineering culture.
Code review isn't just about detecting syntax errors. It also transmits knowledge, protects architectural decisions, and allows different team members to understand how the system evolves.
If code review becomes a mechanical approval of rapidly generated changes, the company loses one of its main mechanisms for collective learning.
The solution isn't to ask engineers to read faster. The solution is to redesign the development workflow so that AI doesn't generate unmanageable volumes of change.
Before artificial intelligence, writing a change of thousands of lines required a considerable amount of work. Now an agent can modify multiple components within a single session. Technically, this seems like an extraordinary improvement in productivity.
From a review point of view, it can be a disaster.
Large changes are difficult to understand because they increase the amount of context the reviewer must maintain simultaneously. Furthermore, if a significant part of the implementation was model-driven, even the pull request author may not have a thorough understanding of every decision involved.
AI-assisted engineering needs to reclaim a fundamental discipline: small changes, clear objectives, and explicit boundaries. The ability to generate 5,000 lines of code doesn't mean we should cram them all into a single revision.
AI should help us reduce the cognitive size of changes, not increase it.
A good development agent shouldn't be evaluated by how much code they can write. They should be evaluated by their ability to produce understandable, verifiable modifications that are aligned with the existing architecture.
Maintainability begins before the merge.
Technical debt arises when an organization makes decisions that facilitate current delivery but create future costs for maintenance, upgrades, or corrections. Not all technical debt is negative. In certain scenarios, consciously assuming it can be a reasonable business decision.
The problem arises when nobody knows that the debt is accumulating.
Mass code generation with AI can accelerate precisely this type of invisible debt. Duplicate functions, inconsistent abstractions, unnecessary libraries, and locally correct workarounds can be introduced gradually without causing immediate bugs.
Every change seems small.
The system continues to function.
The tests passed.
Months later, a new feature requires modifying five similar implementations created by different AI sessions. No one remembers why so many variations exist, and each change starts requiring more context.
The technical debt didn't arise from one big bad decision. It came in line by line, suggestion by suggestion, and pull request by pull request.
AI can generate code at machine speed. Without architectural controls, it can also generate technical debt at machine speed.
For some years, some of the discourse surrounding AI suggested that deep technical knowledge would become less important because models would be able to write code. The actual evolution of AI development seems to be showing something different.
The easier it is to produce an implementation, the more important it becomes to decide which implementation should be produced.
Architecture defines limits.
Establish responsibilities.
Control dependencies.
Determine how the components evolve.
A model can generate ten technically valid ways to solve a problem. The engineer needs to identify which one fits the company's technology strategy.
This is one of the reasons why skills such as systems design, debugging, evaluation, and governance continue to gain relevance in technology teams. Routine work can be progressively automated, but responsibility for the system remains.
AI is reducing the cost of writing code. That increases the value of the criterion.
The engineer of the future will probably write fewer lines manually, but will be responsible for many more decisions about code generated by intelligent systems.
Continuous integration and continuous delivery pipelines already incorporate automated testing, static analysis, and security controls. However, the era of AI-assisted development will require strengthening these safeguards.
The generated code should initially be treated as untrusted code. Not because AI is inherently dangerous, but because the production cost is so low that validation must be systematic.
Organizations will need to combine static analysis, automated testing, dependency scanning, architectural validation, and security policies before allowing changes to proceed. For critical systems, it will also be necessary to document which tools were involved in the build process and what human reviews were performed.
An investigation of 7,703 files publicly attributed to AI tools found 4,241 instances of critical web exploits (CWEs) distributed across 77 types of vulnerabilities. The same study observed significant differences depending on the programming language and tool, reinforcing the need for controls tailored to the technical context.
There is no single magic filter for AI code.
Quality must be built as a system of successive barriers.
In many current repositories, it's difficult to determine which parts were written manually, which were suggested by a copilot, and which were generated almost entirely by an agent. According to recent research from GitLab, 43% of the developers surveyed struggle to distinguish AI-generated code from human-written code.
Does it really matter who wrote the code?
From a purely functional perspective, it might seem irrelevant. If it works and meets the requirements, the author shouldn't change the result.
But traceability becomes important when security, licensing, auditing, or maintenance issues arise. An organization may need to know which tools were involved in a change, what context they received, and who validated the implementation.
This doesn't mean obsessively labeling every line. It means building a process where there is clear accountability for every change.
AI cannot assume corporate responsibility for a vulnerability introduced into production.
The tool can generate.
The team remains responsible for delivery.
That difference must remain visible within the engineering culture.
There is another, less discussed consequence. Many of the tasks that historically helped train junior developers are precisely those that AI can automate most easily.
Create simple functions.
Write repetitive code.
Correct basic errors.
Generate initial tests.
These activities weren't just low-value work. They also served as training. They allowed a developer to understand the repository, make small mistakes, and gradually build technical judgment.
If AI automatically performs all these tasks, an important question arises: how will we train future senior engineers?
The industry needs to avoid a scenario where junior developers primarily learn to accept generated code without developing the ability to evaluate it.
Using AI shouldn't eliminate technical learning. It should modify it.
New training programs will need to teach architecture, debugging, code reading, and evaluation much earlier. The critical skill will no longer be memorizing syntax, but understanding why a solution is correct and recognizing when a seemingly convincing answer is not.
The debate between proponents and critics of AI-generated code typically presents two extreme positions. On one side are those who believe that the models will replace much of traditional engineering. On the other are those who consider the generated code too risky to be used seriously.
Both approaches probably miss some of the point of reality.
AI is already part of modern development. The 2025 survey of Stack Overflow It received more than 49,000 responses from 177 countries and dedicated a specific focus to AI tools, agents, and language models, a clear sign of the extent to which these technologies have entered the developer's daily work.
The challenge is not to stop code generation. It's to professionalize it.
Teams will need better specifications, clearer architectures, stricter pipelines, and review processes adapted to the new volume of changes.
The paradox is interesting: the more code AI writes, the more important software engineering becomes.
Because someone still needs to protect the system.
In The Cloud Group We understand Artificial Intelligence as an accelerator within the engineering process, not as a replacement for architecture, quality, or technical expertise. The ability to generate code faster can provide enormous value when it is part of a development system designed to control quality, security, and maintainability.
Our approach combines software engineering, technology architecture, application modernization, artificial intelligence, and technical debt management to build systems capable of sustainable evolution. It's not just about delivering features faster. It's about ensuring that current speed doesn't become the technological challenge of the coming years.
AI is changing how software is developed. Therefore, code review, observability, security, and governance processes also need to evolve.
Because a company shouldn't measure the success of its team by the amount of code it can generate.
You should measure it by the quality of the software it can maintain.
It cannot be assumed to be automatically secure. Veracode's GenAI Code Security 2025 report found security vulnerabilities in the 45% sample tested. This reinforces the need for static analysis, security testing, and review before deploying generated code to production.
It depends on the context, the type of task, and the team's maturity. Research shows improvements in certain tasks, while others, such as the METR study with experienced developers in mature repositories, where the analyzed tools increased completion time by 19%. Productivity should be measured across the entire cycle, not just in terms of write speed.
It is the accumulation of future maintenance costs caused by AI-assisted or AI-generated code that is incorporated without sufficient understanding, review, or architectural consistency. It can manifest as duplication, unnecessary dependencies, inconsistent abstractions, or solutions that are difficult to evolve.
It shouldn't be done entirely in enterprise systems. AI can help detect patterns and analyze changes, but human review remains important for validating business context, architectural decisions, and risks that depend on the organization's specific knowledge.
It should go through the same controls as any other code and, depending on the risk, additional validations. Automated testing, static analysis, security scanning, dependency review, and architectural assessment are important components of a modern pipeline.
Systems design, architecture, debugging, security, domain understanding, and the ability to evaluate AI-generated solutions will become even more valuable. Syntax can be partially automated; technical judgment remains difficult to delegate.
Instead of solely measuring code volume or the number of pull requests, organizations should analyze delivery time, stability, defects, rework, review time, maintainability, and business outcomes. The goal is to measure reliably delivered software, not generated text.
Artificial intelligence is eliminating one of the historical constraints of software development: the time required to produce an implementation. An idea can be transformed into hundreds of lines of code in minutes, and an agent can modify multiple components before a person finishes reviewing the first file.
This capability represents an extraordinary opportunity. Teams can experiment faster, automate repetitive work, and focus some of their time on higher-value problems. But speed also introduces a new responsibility.
If generating code becomes almost free, Understanding it becomes the scarce resource.
The next crisis in software engineering will not necessarily be caused by models that are unable to program. It could arise precisely because models program well enough for us to accept enormous volumes of code without developing systems capable of reviewing them at the same speed.
That's why architecture, code review, testing, security, and technical debt management aren't losing importance. They're entering a much more critical stage.
Companies that use AI solely to produce more code will likely gain speed for a while. Those that redesign their engineering around quality, traceability, and understanding will build a much more sustainable advantage.
The question is no longer how much code can your team write with Artificial Intelligence.
The real question is:
Can your organization understand, review, and maintain everything that AI is creating?
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
