PROJECT MANAGEMENT IN THE AI ERA: HOW SQUADS ARE REINVENTING THEMSELVES

Artificial intelligence is driving a structural shift in software development, not only in how code is produced, but across the entire project management lifecycle. This article examines how traditional practices are being challenged, how new approaches are beginning to emerge and how teams such as those at Axoma are adapting their processes to operate with greater clarity, quality and efficiency in this new environment.

The adoption of artificial intelligence in software development is not only transforming how code is written, but redefining how projects are conceived, planned and delivered. Traditional management frameworks, which for years sustained predictability in agile squads, are beginning to show signs of strain in a landscape where productivity is no longer linear.

If previously the effort was mostly concentrated on construction, today it is distributed across specification, assisted generation, validation and critical review. This shift demands a profound revision of management practices.

Estimating Under a New Logic: When Velocity Stops Being Predictable

The traditional relationship between effort and time is being fundamentally disrupted. Tasks that once required days can now be completed in a matter of hours with AI support. At the same time, work that appears relatively straightforward may require extended validation and testing cycles, particularly when it involves sensitive business rules. The result is a less predictable delivery environment.

More than simply recalibrating estimates, squads are now dealing with a new category of uncertainty: not “how long will it take to build,” but rather “how much effort will be required to validate and assure quality.”

The New Role of Product Owners and Product Managers: From Prioritization to Precision

If the quality of AI-generated code depends directly on the quality of the input, then specifications are no longer merely directional, they become foundational.

The role of Product Owners and Product Managers is evolving accordingly, with less emphasis on superficial backlog grooming and greater responsibility for clarity, completeness and consistency in specifications. Ambiguity that might previously have been resolved during implementation now manifests immediately as inconsistent outputs.

This evolution aligns software development more closely with approaches such as Spec-Driven Development (SDD), where specification is no longer a supporting artifact but the core of the process.

Spec-Driven Development (SDD): From Documentation to the Core of Execution

In traditional approaches, specifications guide development. In SDD, they structure and often directly enable execution, particularly when code is generated from those definitions.

In practice, this means software quality becomes directly dependent on three factors: clarity, level of detail and the absence of ambiguity.

As Kauan Costa, Tech Leader at Axoma, explains:

“Today, with AI, there is far less room for interpretation during execution. Gaps that would previously have been resolved during implementation now tend to surface immediately as inconsistent or incorrect outputs. AI’s limitations become highly visible when the specification is weak.”

He adds:

“With SDD, development time shifts toward building and refining specifications.”

At the same time, expectations must be calibrated. SDD is not a mature, standardized methodology like Scrum. It is an evolving approach that still lacks broad formal standardization.

“SDD is still undergoing significant transformation. Here at Axoma, we are in a continuous cycle of learning and adaptation, testing and investigating the most effective ways to apply this approach.”

This model also introduces an important tradeoff: the greater the dependence on highly detailed specifications, the greater the risk of rigidity. Not every context allows for complete upfront clarity and excessive specification can constrain adaptability. More mature teams tend to strike a balance, structuring enough detail to guide AI effectively while preserving flexibility for learning and adjustment throughout the process.

AI Is Also Transforming the Client Side

One less visible but increasingly significant effect is that AI is not only reshaping how software is built , it is also fundamentally changing how clients think about, validate and communicate their needs.

Traditionally, there was a translation gap between business and technology. Clients described intentions in abstract terms while technical teams interpreted, structured and translated them into solutions. This process was inherently iterative and often ambiguous.

With AI, that gap is beginning to narrow. Artificial intelligence is becoming an intermediate layer that enables clients to formalize their ideas before deeper technical involvement. They can explore possibilities, test hypotheses and translate descriptions into more concrete representations.

One of the clearest examples of this shift is prototyping, as explained by Leonardo Lopes da Paz, Tech Leader at Axoma:

“Today our clients can send us a functional mockup. Previously, this required substantially more effort using tools such as Figma. Now, with AI, clients can get remarkably close to what they want with only a fraction of the effort.”

Kauan expands on this:

“AI-powered prototypes are extremely visual. The buttons work, and you can test the navigation. There is no backend integration yet, but it’s a very close representation of what the client expects.”

This directly improves requirements definition. Previously, much of the effort was spent interpreting what the client meant. Now, the starting point is much more concrete, which reduces ambiguity, speeds up decision-making, and improves alignment between stakeholders.

“We used to spend days refining visual details at the end of the process. Now much of that is already resolved from the outset.”

Clients now arrive better prepared, with more structured hypotheses and more tangible expectations. Technical teams, in turn, can work with a higher degree of clarity from the earliest stages.

This progress does, however, introduce an important side effect: the false sense of completeness. AI-generated prototypes may appear “finished” while omitting business rules, integrations and exception scenarios. This requires greater scrutiny from technical teams to avoid decisions based on a superficial sense of definition.

In this context, the consulting role becomes even more critical. It is no longer just about building software, but about helping clients better structure the solution to their underlying problem — interpreting, refining and complementing what AI makes visible, but not fully defined.

Code Review: Less Syntax, More Architecture

As AI takes on a substantial portion of code generation, the purpose of code review is changing as well. Basic syntactic errors tend to decrease, but this does not mean less work. It means different work.

The focus shifts toward architectural decisions, business-domain alignment and system-wide consistency. In this environment, validating whether “the code works” is no longer sufficient. The critical question becomes whether it makes architectural and business sense.

Metrics Under Pressure

The introduction of AI also exposes an existing limitation that had previously been less visible: many traditional engineering metrics never measured value directly. Instead, they measured indirect proxies such as code volume, estimated effort or delivery velocity.

These metrics worked reasonably well in more stable contexts. With AI, however, the relationship between effort, volume and value becomes far less linear. Producing more code, or producing it faster, no longer necessarily means delivering greater value.

In practice, several commonly used indicators are beginning to lose relevance — or even become misleading:

Lines of Code (LOC)

AI can generate large volumes of code in seconds, inflating the metric without reflecting complexity or quality. In some cases, it can even increase the risk of redundant or unnecessary code.

Sprint Velocity 

Apparent acceleration in story delivery may conceal growing bottlenecks in review and validation. Teams may “deliver more points” without actually delivering value faster.

Commit-to-Pull-Request Time

 This interval tends to shrink dramatically as code generation becomes nearly instantaneous. However, the metric no longer captures the real effort, which has shifted toward interpretation and refinement.

Test Coverage (when AI-generated) 

Automated generation may inflate coverage metrics without guaranteeing effectiveness. Tests may validate implementation without validating expected business behavior.

The operational risk is clear: organizations may continue tracking indicators that appear positive while actual quality, risk exposure and rework silently increase.

At the same time, a new measurement framework is beginning to emerge, one centered on quality, real efficiency and impact:

AI-Generated Code Acceptance Rate 

What percentage of AI-suggested code is used with minimal or no modification? This helps assess both prompt quality and team maturity in AI adoption.

Review Time 

As generation accelerates, review becomes the new bottleneck. Measuring review time becomes essential for identifying workflow friction points.

Production Defect Density

As code volume increases, so does the risk of subtle defects. Stability and reliability in production become stronger indicators of quality.

True Time-to-Market

Rather than measuring isolated phases, organizations increasingly need to evaluate total time to delivered value, including rework and additional validation.

Value-Oriented Productivity

Rather than measuring how much code is produced, the more relevant question is the impact generated: problems solved, efficiencies created and business value delivered.

Developer Experience (DevEx)

AI reduces repetitive work but can increase cognitive load during review and validation. Monitoring team experience helps prevent short-term efficiency gains from creating medium-term human costs.

In practice, Axoma is already navigating this reassessment.

“When we first adopted Scrum, we also struggled with metrics. They evolved as the team matured. We are now going through a similar process with AI.” — Kauan Costa

At this stage, there is still more intuition than formal consolidation:

“There is a strong sense that we are delivering faster, but we are still defining the best way to measure our work with AI.”

What is already clear is the redistribution of effort:

“We are spending less time writing code and more time on specification and testing.”

There is also a clear shift in quality focus:

“One of our primary metrics today is what comes back from production — the number of bugs and the severity of issues identified. And in many cases, those issues are tied directly to flaws in the original specification.”

This directly connects operational practice to conceptual change: as effort shifts toward definition, specification quality has a direct impact on final performance indicators.

The Developer as Orchestrator

If previously a developer’s primary skill was building, it has now shifted toward guiding, validating and integrating multiple AI-generated outputs. We are seeing the rise of the developer-orchestrator: someone who understands the problem, defines the path, and uses AI as an instrument, not a replacement.

This demands a different set of competencies, such as abstraction, critical thinking, a solid grasp of architecture, and the ability to craft high-quality instructions. Pure execution is losing ground; strategic responsibility is gaining it.

Kauan reflects on this evolution:

 “One of the things we are working on with the team is the importance of understanding the product. AI helps write code, but it doesn't teach you how to build a functional product. This requires a shift in mindset. We encourage the team to ask: Why are we doing this? Who is going to use it? What is the impact? It’s not just about implementing; it’s about understanding the context.”

AI Does Not Work in Isolation: The Role of Process

"One of the most significant practical lessons observed so far is that AI effectiveness is directly tied to process quality", Leonardo notes.

“All developers use AI today, but those working with more detailed specifications have a far more positive perception of what it can actually achieve.”

He offers a concrete example:

“We had a developer who was not enthusiastic about using AI. He was experiencing constant rework, inconsistency and code that failed to meet standards. Once he began working with more structured specifications and SDD-supporting tools, his perception changed completely.”

The conclusion is straightforward: AI does not replace process, it amplifies both its strengths and its weaknesses.

Conclusion: More Than Speed, Clarity

Project management in the AI era is not simply about accelerating delivery. It represents a structural transformation in how work is organized.

In practice, what we are observing includes:

• a shift of effort toward specification and validation

• increased importance of clarity in definition

• the need for more sophisticated critical review

• a reassessment of traditional metrics

Axoma’s experience shows that this transition is neither immediate nor linear. It requires experimentation, adjustment and continuous learning.

It also points to a clear path: teams that can better structure their processes, especially around problem definition and solution framing, tend to extract more value from AI.

In a scenario of accelerated transformation, competitive advantage lies not just in adopting new tools, but in knowing how to seamlessly integrate them into the workflow.

More than just keeping up with change, it is about learning to operate it with intention and clarity. It is this movement that begins to separate organizations that merely use AI from those that actually succeed in transforming the way they build software.