Discover how AI transforms agile engineering practices like TDD, pair programming, and CI/CD in 2025. Learn which practices still matter and how developers adapt to AI-assisted development.
In 2001, seventeen software industry leaders gathered at a ski resort in Utah to address their frustrations with software development. This was before smartphones, before cloud computing, and long before ChatGPT. They created the Manifesto for Agile Software Development and published 12 principles that fundamentally changed how teams build software.
Among those principles, the ninth stands out: “Continuous attention to technical excellence and good design enhances agility.” That principle was absolutely true in 2001.
But in 2025, with AI writing increasing amounts of production code, software teams face a critical question: does this principle still hold?
The Questions Keeping Developers Awake
If AI generates the code, what role do developers actually play?
For engineering coaches, there’s an equally pressing concern: are the technical practices we’ve evangelized for years still relevant when AI handles implementation?
We’ve coached engineering teams for years and watched them transform by applying agile engineering practices. Recently, we’ve had to completely rethink everything we assumed we knew. AI isn’t just changing how teams write code. It’s challenging the fundamental assumptions behind why these practices were adopted in the first place.
Where Agile Engineering Practices Stand Today
The 6 main agile engineering practices are: Test Driven Development (TDD), Pair Programming, Collective Code Ownership, Automated Testing, Continuous Integration, and Continuous Deployment.
Most companies have adopted continuous integration and created “DevOps” teams to attempt continuous deployment. These areas have seen the most progress, even if they’re not truly doing continuous integration as originally intended (coding off trunk with no branching), and even if the term DevOps strays far from its original intent.
With test automation, there’s progress, yet it’s mostly with dedicated test automation teams doing automation from the UI. Not exactly ideal, but better than an army of manual testers.
Very few companies actually practice or even encourage test-driven development, pair programming, or collective code ownership. Adoption of these practices remains minimal.
Given the current state of things, do teams still need these agile engineering practices? And how will AI impact them?
How AI Transforms Six Core Agile Engineering Practices
Continuous Integration and Continuous Deployment: Increased Intelligence and Automation
CI/CD focuses on always integrating the code base and having it deployed or ready to be deployed. AI will accelerate this evolution through increased automation and predictive analysis, optimized resource allocation, and faster or even automated response to incident resolution, whether that’s rerouting traffic, restarting a service, or applying a security patch.
All the practices for AI-generated application code will apply to infrastructure as code as well.
When DevOps was first introduced, it was intended to bring development and operations closer together by merging the two skills on the same team and have developers do and automate operations work. However, in practice, DevOps became just a new name for the old operations team that now also does automation. The silos in work and the hand-off from Development to Ops (now called DevOps) remained.
The advances in CI/CD automation with AI might actually make the true meaning of DevOps a reality. A development team with AI assistance will now be able to own and automate the build pipelines.
Pair Programming: From Human Collaboration to AI Pairing
Pair programming is the practice of having two programmers work side by side solving the same problem together. Despite its benefits, pairing has had low adoption because of management pushback. The common objection: “What do you mean two developers are going to work on the same thing? That is so inefficient, costly, slow.”
These concerns become irrelevant with AI pairing, and teams start realizing several benefits:
Immediate feedback. With AI pairing, you get immediate feedback from AI or provide the AI with feedback before going too far off track.
Early discovery of bugs. The AI can point to possible bugs immediately, spotting silly mistakes that might otherwise cost hours of debugging time.
More elegant solutions. AI can suggest or you can prompt for different possible solutions to consider.
Just-in-time peer reviews. This eliminates the traditional pull request cycle of providing feedback, making changes, and submitting again. With AI pairing, you’re reviewing the AI code constantly and the AI is reviewing your code.
Knowledge sharing limitation. This is the one benefit teams lose with AI pairing. There is no knowledge sharing across the team in terms of technical knowledge or domain knowledge since team members are not working together and are just working with the AI.
AI pairing will become more common, delivering most of the benefits of traditional pairing except for knowledge sharing across team members.
Collective Code Ownership: AI Owns the Code
The key benefit of collective code ownership is that everyone is familiar with the code and can make changes instead of how we traditionally work by always relying on one person, creating knowledge silos and bottlenecks. However, without active pairing , collective code ownership is close to impossible because there’s no knowledge sharing amongst developers.
With AI code ownership, there is no more waiting on the one person who knows how to change the code. Now AI owns the code. Whenever you want to make a change, you ask AI to explain the code or to make the change directly.
The benefits of collective code ownership become a reality with AI code ownership.
Test-Driven Development: Prompt-Test Driven Development
The key benefit of TDD is moving quality checks to the left, having the solution emerge while building it iteratively and incrementally. However, test-driven development has low adoption for many reasons. There are many reasons for the pushback against TDD and these include:
- TDD is hard
- TDD is counter-intuitive
- Testing after the fact is easier
- My manager does not let me do TDD
- I do not have time to write tests
- More code means more maintenance
- I’m a senior developer, I don’t need TDD
- Teeny tiny steps are stupid
- TDD ignores the big picture
- I make one change and a gazillion tests break
One of the biggest misunderstandings is that TDD is not about testing, but a design and development technique.
Traditionally, developers cycle through red-green-refactor 30 to 40 times, taking baby steps.
With AI, the loop will be much faster, probably x2. You think and prompt, and the AI completes the loop. The steps will likely be larger, just like an experienced developer who can see ahead for obvious things and take larger steps, backtracking to small steps for less obvious work.
AI-assisted TDD will gain adoption because thinking about the client and what the client wants to do becomes a natural way of prompting the AI and providing it with context.
Automated Testing: Acceptance Specification Driven Development
Today, most teams do test automation from the UI because they’re used to manually testing from the UI. However, this is not the best test automation strategy. UI tests tend to be fragile. A minor change will break them, they take a long time to run, and when they fail, teams don’t really know why and still have to debug.
A solid test automation strategy balances out the tests based on the testing pyramid, where most of the automated tests are unit tests, with less integration tests, less system tests, and even less UI tests. AI can now write automated tests at any level, and this balanced test automation strategy can become a reality.
Teams however, still need to make sure they can accept the code. Meaning these automated tests prove that the code works as the AI intended it to work. It does not prove that the code works as the client expects it to work. This is where acceptance testing come into play. AI can still help here by using AI-ATDD or AI-BDD, AI with acceptance test driven development or Behavior Driven Development. Teams can write prompts based on client end-to-end expectations, using specification-by-examples in gherkin syntax: given, when, then.
The Evolution of Agile Engineering Practices
Here is how these six agile engineering practices change:
- Test-Driven Development becomes Prompt-Test Driven Development
- Pair Programming becomes AI Pairing
- Collective Code Ownership becomes AI Code Ownership
- Automated Testing becomes Acceptance Spec Driven Development
- Continuous Integration becomes AI Generated Test Suite
- Continuous Deployment becomes Infrastructure as Spec
The Human Role in AI-Assisted Development
What becomes of the human role in each practice?
CI/CD: AI self-optimizes the pipeline while the human supervises and designs the policy
Pairing: AI and human collaborate where the human is the context setter and just-in-time reviewer
Collective Code Ownership: AI owns the code while humans ask AI for explanations and request changes
TDD/ATDD: AI cycles through red-green-refactor while humans prompt and review
Test Automation: AI automates tests at all levels while humans write expectations as specifications
The Risk of Returning to Big Up-Front Requirements
There is a movement now focused on taking massive step by writing up front detailed specification and asking the AI to write the code. Converting detailed user stories into code. This is taking teams back to the days of big up-front requirements.
The reason the industry moved away from that was the wants versus needs problem and the long cycle before the client found out that what they though they wanted. asked for, and was built, does not work, does not meet their needs, and does not deliver value. That cycle was too costly and time consuming. Maybe it won’t be as costly with AI?
The primary questions remain the same:
- Does the customer know what they want?
- Did they properly describe what they want?
- Did I understand what they want?
- Did I properly prompt what they want?
- Did the AI properly understand my prompt?
- Did the AI properly write the code?
- Does it work?
- Does it do what the customer expects it to do?
- Does it deliver value to the customer?
We are ultimately still trying to address:
- Are we building the right thing?
- Are we building it the right way?
- If the AI agents are doing it, how do we know?
Why Agile Engineering Practices Still Matter
AI combined with agile engineering practices enables teams to rapidly create, steer, verify, reflect, and refine at each step. This is otherwise known as iterative and incremental development.
Principle 9 states: “Continuous attention to technical excellence and good design enhances agility.”
Principle 1 states: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
AI enhances Principle 9, which in urn makes Principle 1 a reality. AI amplifies the ability to maintain technical excellence while accelerating the capacity to satisfy the customer.
The practices change. The human role evolves. But the principles remain true. Perhaps more true than ever.
Frequently Asked Questions
Do agile engineering practices still matter with AI coding assistants?
Yes. Agile engineering practices matter more than ever because they provide the discipline needed to maintain quality while using AI. Without practices like test-driven development and continuous integration, teams generate code faster but accumulate technical debt that eventually slows delivery. AI amplifies both good and bad practices, making disciplined engineering essential.
How does AI change test-driven development?
AI transforms TDD into prompt-test driven development. Instead of manually cycling through red-green-refactor 30 to 40 times, developers prompt AI to complete the loop. The steps become larger because AI can implement obvious functionality quickly, while developers focus on writing tests that define the desired behavior. The discipline of thinking through client needs before implementation remains critical.
Can AI replace pair programming?
AI pairing delivers most benefits of traditional pair programming including immediate feedback, early bug detection, and just-in-time code reviews. However, it loses one critical advantage: knowledge sharing across the team. Teams should use AI pairing for individual productivity while maintaining some human pairing sessions specifically for spreading domain and technical knowledge.
What is the biggest risk when using AI for development?
The biggest risk is returning to big up-front requirements and design. Some teams write massive specifications and have AI generate entire features at once. This repeats the waterfall mistakes the industry moved away from. The long cycle before discovering whether the solution works or delivers value becomes painful, even if AI makes implementation faster. Iterative development with frequent verification remains essential.
What role do developers play when AI writes the code?
Developers become context setters, reviewers, and decision makers. They define what needs to be built through prompts and acceptance criteria, review AI-generated code for correctness and maintainability, make architectural decisions, and verify that solutions deliver customer value. The focus shifts from typing code to ensuring the right thing gets built the right way.
How does collective code ownership work with AI?
AI code ownership replaces traditional collective code ownership. Instead of every developer needing familiarity with all code, developers ask AI to explain unfamiliar code or make changes directly. This eliminates bottlenecks from waiting on the one person who knows a particular module, while removing the challenge of spreading knowledge across the entire team.
Resources and Further Reading
- Top 5 Agile Engineering Practices covers the core practices (TDD, pair programming, collective code ownership, CI/CD) that form the foundation discussed in this article.
- 8 Steps to Technical Excellence provides a practical implementation roadmap for teams adopting these practices, including training, coding dojos, and building CI/CD pipelines.
- What is Test-Driven Development (TDD)? provides a clear explanation of the red-green-refactor cycle and why TDD creates better code design.
- TDD: That Was Easy addresses common objections and misconceptions about TDD, many of which still apply when working with AI assistants.
- What is the Testing Pyramid? explains the proper balance of automated tests across different levels, which becomes more achievable with AI-generated test suites.
Ready to improve your team’s agile engineering practices? Sign up for our AI Test-Driven Development Workshop to learn how to maintain quality while maximizing AI acceleration. You’ll learn to prompt AI to follow test-driven development practices, creating code that’s both fast to write and reliable in production.