Life is good. Sit back, chill and let AI do its thing. And probably not in an office setting, but at the pool or on the beach. If this is the state of software engineering and coding, where AI is writing the code and engineers are relaxing, do we care about quality code and agile engineering practices?
The Principles Behind the Manifesto for Agile Software Development
Back in 2001, the authors of the manifesto for software development published 12 principles that highlight focusing on the customer, continuous delivery of value, welcoming changes, frequent delivery of a working product, daily collaboration with the business or customer, working on a motivated and trusted team that talks with each other, measuring progress based on what’s in the customers hands, working at a sustainable pace, keeping things simple, and working on self-organizing teams that continuously reflect, adapt and improve.
We’ve come a long way since then, and today we are going to zoom in and focus on this principle
Continuous attention to technical excellence and good design enhances agility.
This principle was absolutely true in 2001. Is this principle still true in 2026, given all the changes and rapid advances in AI? And are the practices still the same?
Agile Engineering Practices
These are the 6 main Agile Engineering practices that we train teams on and encourage them to adopt. Today almost all companies do continuous integration and have created “DevOps” teams to try to do continuous deployment and delivery. Organizations also have dedicated test automation teams. Very few companies do or even encourage TDD, pairing, or collective code ownership. There is very little adoption across these practices as they are less visible to people outside of the programmers.
CI/CD
CI/CD is about always integrating the code base and having it deployed or ready to be deployed.
This practice will continue to evolve with AI, with an increase in automation and predictive analysis, optimized resource allocation, faster or even automated response to incident resolution, whether it’s rerouting traffic, restarting a service, or applying a security patch.
Today most teams do this with dedicated DevOps teams. Now when DevOps was first introduced, it was intended to bring development and operations closer together by merging the two skills on the same team, share and transfer knowledge, and get the team to own, build, and automated ops 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 AI and easing of CI/CD automation might actually make the true meaning of DevOps a reality. A development team with AI assistance will now be able to own and automate their build pipelines. There will be more adoption and continued improvements in this practice
Automated Testing
Today, most teams do test automation. However, most teams automate from the UI. They are used to manually testing from the UI. So, when they move to automate, they automate from the UI. That however, is not the best test automation strategy because UI tests tend to be very fragile. A minor change will break them, they take a long time to run, and when they fail, they don’t really tell the team why, so the team still has to debug.
Instead of having all tests automated via the UI, teams should pursue a test automation strategy that balances out the tests based on the Testing Pyramid, where most of the automated tests are unit tests, with fewer integration tests, fewer system tests, and even fewer UI tests. This makes the tests more robust and easier to maintain.
AI can help here by having AI write automated tests at any level and this can make a balanced test automation strategy a reality.
Pair Programming
Pair programming is developers working side-by-side, solving the same problem together. Pairing provides many benefits:
- Immediate corrective feedback before going too far off track
- Early discovery of bugs, especially the silly mistakes that developers end up spending hours debugging.
- More elegant or well thought-out solution because 2 people are working on the same problem, one thinking tactically and one thinking strategically.
- Fast just-in-time peer reviews instead of longer back-and-forth pull request cycles at the end.
- Knowledge transfer and knowledge sharing across the team in both domain expertise and technical expertise for a shared design and a shared understanding.
Despite all these benefits, pairing has had low adoption. Pairing can be mentally and physically exhausting.
Mentally, because when you are pairing, you are always on. Someone is right there working with you, so you can’t check your messages, socials, emails, and so on, and everyone needs these mental breaks.
It is also physically exhausting because you have someone sitting with you at your desk, and everyone needs personal space. Teams that do this well are aware of these challenges and put basic guidelines in place in terms of when to pair, with whom, how often, on what, and so on.
But one of the biggest pushbacks to pairing doesn’t come from the team, but from management. “What do you mean 2 developers are going to work on the same thing? That is so inefficient, costly, slow.”
These concerns get completely addressed with AI pairing. The AI can be turned off at any time. The AI is not physically in anyone’s personal space, and it’s just one developer, not two.
So pairing with the AI can give the developer immediate feedback on the work, or the developer can give the AI immediate feedback on its code, same with early discovery of bugs, and just-in-time code reviews. The developer and the pair can work through the solution together, where the developer is the strategic pair focusing on design, while the AI is the tactical one typing and implementing. The AI can also challenge the developer on design decisions, and can think through the approach from different perspectives. Also, AI tends to produce very verbose code, and a human pair can cut that down.
However, 1 key benefit of AI pairing is lost, and that is knowledge sharing across the team, since the developer is only pairing with the AI, and can’t transfer knowledge to other teammates.
So, pairing with AI will become more common, delivering most of the benefits of traditional pairing except for knowledge sharing between team members.
Collective Code Ownership
The key benefit of collective code ownership is that everyone owns the code. That is, everyone is familiar with it and can make changes to it.
Traditionally, there are knowledge silos between teams or within teams. The team always rely on one specific team or person to make a change because that person is the only one who knows that module. This creates dependencies and bottlenecks as the team waits on that person.
And even though collective code ownership minimizes the “hero bottleneck” problem, it has low adoption. Because without active pairing, it is close to impossible, as there’s no “continuous knowledge sharing” among developers. A lot of teams do not invest in or put a conscious effort toward continuous knowledge sharing. That kind of sharing requires a big, upfront investment for an uncertain, long-term gain.
With AI Code Ownership, there is no more waiting for the one person who knows how to change the code. Knowledge stops being held hostage to individual availability. AI can “own the code”. Ownership as in knowledge, accessibility, and ability to change. Not accountability. The benefit is that
- AI can explain intent, structure, and impact of changes, eliminating dependence on “the one person who knows the code.”
- Any developer can safely modify code with AI assistance, reducing bottlenecks and cross‑team friction.
- AI lowers the cost of understanding and changing code. This enables broader participation.
- AI can even make change and explain it back to the developer.
Yet, all the while, developers must still own outcomes and quality gates. So, AI Code Ownership reduces knowledge silos by externalizing understanding into a shared, always‑available system. This makes collective ownership real instead of aspirational.
Test Driven Development
TDD has a lot of key benefits, like having the solution emerge via iterative and incremental development, improving the overall design, and moving quality checks early in development. A major side benefit of doing TDD is that functional testing no longer becomes an activity done at the end, but an ongoing process.
However, test-driven development also has low adoption. There are many reasons for the pushback against TDD and these include:
- TDD is hard.
- TDD is counterintuitive.
- 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.
Many think TDD is about testing. But that is probably one of the biggest misunderstandings. TDD is not about testing. It is a design and development technique. TDD is about solving a problem from the client’s perspective. It is about putting yourself in the client’s shoes and asking: what does the client want to do?
That client can be a user, another system, or a code module that needs something from you or your code. TDD is about solving that problem iteratively and incrementally.
It is about thinking about the client’s problem. Thinking about a single action the client wants to do and representing that with a test. That representation doesn’t have to be via a test, per se, but using a testing framework is a convenient way to emulate that ask or action.
Now that there is a concrete use case, developers write just enough code to solve for it and, in turn, make the test pass. The idea is to produce the simplest thing that can work first, and then improve it or refactor it as the code grows and becomes more complex.
After that, the cycle continues with the next use case. What else does the client want to do? And so on.
TDD Example
The following TDD example is a very simple example to illustrate the approach. No developer will solve this simplistic problem this way. This basic example is to emphasize the technique and discipline required to shift how developers approach problems by thinking about the client or user first. It is difficult to learn or shift our way of thinking with an elaborate or complex problem.It is best to illustrate and practice on basic problems, and once that is clear, and it becomes second nature, developers can tackle more complex problems, and that is where teams start benefiting from TDD.
This example is about building a supermarket checkout scanner that tracks the total of items scanned.
Start by thinking through the problem. If a customer hasn’t scanned anything yet, the customer expects the total to be 0.
Great, describe this user behavior or user expectation via a test.
Notice, this is not about what the product should do or the features of the product. This is about what the client wants to do.
Run the test. It fails because the total implementation does not exist yet.
Implement the total logic. Run the test again. Now it passes.
What else does the customer want to do? Well, the customer wants to scan an apple.
What does the customer expect? The customer expects that the price of the apple should be reflected in the total, so that the customer knows how much to pay.
Represent that client behavior in a test. Run the test. It fails because scan logic does not exist yet, and the total logic is too simplistic.
Implement the scan logic and update the total logic. Run the test again. It passes.
Notice how the code is slowly evolving based on actual use cases and scenarios.
Again, this is a simplistic example to illustrate the approach and thought process. No developer will solve this problem in this way, as that would be very silly for such a simple problem space.
Next, if the customer scans another apple, the customer wants to make sure the running total reflects that.
Add that behavior, run the test, see it fail.
Add the code to implement running totals, and run the test. See it pass.
Next, the customer wants to buy other items besides apples.
Add a case for bananas, run the test. See it fail.
Add the code. Run the test. See it pass.
Note that the implementation started with the simplest possible approach. As the code grows, it gets refactored. Maybe it needs to call a pricing service to figure out the price or a database lookup to get the product description. This code can now change, expand, grow, and improve. The scenarios should keep running, guiding the implementation along the way and providing a safety net that nothing accidentally breaks as the implementation improves.
AI TDD Example
Now, with AI TDD, after the developer describes the behavior, the AI suggests a test that represents that behavior, and the developer accepts it or rejects it. This makes the cycle a lot easier and faster as the AI is taking care of the typing. The thinking stay the same. Think through the customer behavior and actions, instead of thinking about the product or features.
Notice in this example, the behavior is represented via a comment or the method name, and the AI suggests a test that represents that behavior. Developers do not need to write the test, but instead, they have to review the options the AI provides and accept the one they like. The cycle remains the same, except now the AI takes care of writing the test and following the loop once the behavior is explained.
Agentic TDD
AI TDD can go a step further with Agentic TDD and have the AI go through the entire process by pompting the AI to follow the TDD cycle on its own. A human is not involved in every loop, but simply reviews the final result after many cycles.
So traditionally, with TDD, developers tend to take small steps. Experienced developers who can see ahead for obvious things take slightly larger steps, backtracking to small steps for less obvious work. With AI TDD, the cycle goes a lot faster but still forces the LLM to take small steps, keeping the code base easy to maintain and easy to test with clean interfaces and modular design. Without it, code quality deteriorates, code gets messy, and technical debt increases.
What is the Impact of AI on Engineering Practices?
AI will have the following impact on Agile Engineering Practices:
- True DevOps with AI automation that enables developers to own their pipelines
- Balanced test automation across all layers as AI writes the tests
- Always available pair to help with implementation and challenge me on design decisions, and provide a real time code review.
- True collective code ownership as AI owns the code and can provide me with context about areas I am not familiar with.
- Improved TDD cycles as AI writes the Test and Code
AI makes all these practices easier and increases their adoption for developers actively engaged in the development and using AI as an assistant. These developers are guiding the design and delegating the implementation.
Do Agile Engineering Practices Have An Impact On AI?
What about the developers that are taking larger steps? The ones that are not actively engaged in each step. AI makes generating code easier and faster,which in turn risks producing more and more technical debt and spaghetti code.
Agile Engineering practices are all about reducing technical debt, producing quality code, and making changes easier. Without these practices, code quickly becomes messy, unmaintainable and very difficult to change.
The good news is that AI can use these practices too. As the agentic example illustrated, the prompt can instruct the AI to apply these practices while writing the code, and that will result in:
- Modular code due to the small step approach
- Clean APIs by thinking of the client 1st
- Testable modules by forcing a simplistic approach 1st before introducing complexity and dependencies
- Verifiable use cases as a side benefit of TDD approach
- Always working and integrated code that is ready to be deployed
This all results in low technical debt.
So AI makes adoption of the Agile Engineering practices easier for developers that are actively engaged with coding and working closely with the AI. The agile engineering practices make the AI produce higher quality code for the developers that are taking larger steps.
Gigantic Steps
But what about the developers who are taking gigantic steps? Those chilling at the beach.
What about the movement that is focused on writing a detailed specification up front and asking the AI to write the code?
With that, “new” problems emerge:
- Did customers 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?
- Does the customer even know what they need?
In other words
Are we building the right thing? And are we building it the thing right?
This idea of converting a lot of detailed user stories into code 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 problems and the long cycle before the customer discovered the gap.
Yes, the team built something based on the requirements, but it didn’t deliver value. That cycle was too costly and time-consuming. That problem now shifts to the AI, but it is still the same problem.
Maybe someday in the near future teams will be able to push a button, scrap what they just did, re-create it instantly, verify and validate that they built the right thing, and built the thing right, and that process will be quick and won’t be costly. But that is not a reality today.
Today, teams have to combine AI with agile engineering practices to rapidly create, steer, verify, reflect, and refine at each step.
This is otherwise known as iterative and incremental development. Taking giant steps and ignoring the code does not work. Teams need to keep the feedback loops short while they Invest in the design of the system and delegate the implementation to the AI.
“Continuous attention to technical excellence and good design enhances agility.”
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
AI amplifies the ability to maintain technical excellence while accelerating the capacity to satisfy the customer. The practices change. The human role evolves with better tooling and technology. But the principles remain true.
Repo available at: https://github.com/ruthlesshelp/gsg-vancouver-2026-talk-demo
