A few years ago, when Agile was becoming widely adopted, many companies introduced tools like Jira, created sprint boards, and started organising their work differently. But having Jira didn’t automatically make a team Agile. The tool was there to support a methodology, not replace it.
Today, we see something similar happening with AI.
There are plenty of discussions about which AI coding assistant or agent to adopt, which model performs best, or which platform offers the most capabilities. These are valid questions, and choosing the right tools certainly matters. But we sometimes jump to those questions too quickly, before asking something more fundamental: what are we actually trying to improve?
At Paylume, we’ve spent the past six months developing and refining an AI-assisted software delivery methodology, building on our experience creating payment solutions. Rather than starting with the tools, we’ve been looking at the challenges we already know from software delivery and exploring how AI can help us address them.
And while we’ve made significant progress, we’re still adjusting our approach with every iteration. Some of our most interesting lessons have come from things we didn’t initially anticipate.
When writing code is no longer the longest part
One of the first things we noticed was how AI changed the balance of work across the team.
Our business analysts and architects work with specialised AI agents to refine requirements, challenge assumptions, explore different scenarios, and propose technical solutions. Instead of simply documenting what we already know, we can use AI to identify what we might have missed.
But we also discovered that this creates a new challenge.
During one iteration, we started refining requirements with a relatively broad scope, as we might have done in a traditional project. The agents kept identifying additional questions, dependencies, and scenarios worth exploring. Each answer seemed to lead to another question, and before long, we realised we were getting close to designing the entire system rather than the functionality we wanted to deliver in that iteration.
The agents weren’t doing anything wrong. We simply hadn’t defined the boundaries clearly enough.
We adjusted our approach to be more explicit about what belongs in an iteration and, equally importantly, what doesn’t. The agents can still propose solutions and challenge our thinking, but the team decides which questions need answers now and which can wait.
This experience also highlighted how our roles are evolving. When implementation can happen much faster, more attention shifts towards understanding the business problem, making architectural decisions, and ensuring requirements are clear enough to produce the expected result.
That doesn’t mean we need to know every answer in advance. Quite often, we ask an AI agent to propose a solution that satisfies several business or technical constraints. We discuss the alternatives, challenge the proposal, and make the decision ourselves.
AI helps us explore the possibilities, but our experts remain accountable for the outcome.
Building confidence through independent validation
Another area where we’ve adapted our methodology is quality assurance.
We wanted to avoid having the same AI agent implement a feature and then validate its own interpretation of the requirements. There is an obvious risk that the implementation and the tests could share the same assumptions or misunderstandings.
Instead, we work with two independent streams.
While development agents implement the functionality, a dedicated QA agent proposes end-to-end test scenarios based on the approved requirements, without access to the implementation code. A human QA engineer then reviews and challenges those scenarios, checking the expected behaviour, edge cases, and potential gaps before the agent implements the tests.
Both streams can progress in parallel, and once the implementation is ready, we run the independently developed tests against it.
Of course, having all tests pass doesn’t guarantee that the software is perfect. Both sides could still misunderstand the same requirement, and no test suite covers every possible situation. But this independence gives us an additional level of confidence and allows our QA engineers to spend more time on critical thinking rather than repetitive implementation work.
What interests us here isn’t simply that AI can write tests. It’s that AI makes it easier to introduce additional verification without making the delivery process unnecessarily heavy.
When documentation becomes part of quality assurance
Keeping documentation up to date is another challenge most engineering teams will recognise.
Requirements evolve, architectural decisions change, and implementation details move forward. Documentation often struggles to keep up, leaving teams with information that is incomplete or no longer reflects the actual system.
To address this, we introduced a dedicated AI agent that maintains our project knowledge base. After a feature has been implemented and validated, the agent analyses the repository and updates our wiki, tracking the relationships between requirements, use cases, architecture, and implementation.
This gives our teams an accessible source of knowledge and allows other AI agents to retrieve relevant project information without repeatedly analysing the entire codebase.
But we discovered an additional benefit that we hadn’t fully anticipated.
While updating the wiki, the agent started identifying inconsistencies between the specifications and the code.
In one case, our QA agent had already detected that certain payment messages were being rejected, but the reason wasn’t immediately clear. During a documentation update, the knowledge agent compared the payment specifications with the API validation schema and identified the missing field responsible for the rejection.
The field was valid according to the ISO 20022 specification, but our implementation didn’t accept it.
What we find particularly interesting about this example is how the different parts of our methodology complemented each other. One agent detected an unexpected behaviour, while another helped identify its root cause by examining the consistency between our documentation and implementation.
We originally introduced this agent to solve a documentation problem. It ended up providing another useful perspective on software quality.
A methodology that keeps evolving
These examples are not the result of a perfect methodology designed six months ago and followed without question.
They’re the result of combining applying high-quality software delivery standards with the capabilities of AI, applying them in real delivery projects, and continuously refining our methodology based on what we learn.
There is also a human aspect that we shouldn’t underestimate. Not everyone in a delivery team has the same technical background or the same level of comfort with AI. A methodology needs to work for business analysts, architects, developers, QA engineers, and product owners, not just for people who already know how to work with AI agents.
And just as with Agile, we don’t believe there is a single process that every organisation should adopt exactly as written. The methodology needs to fit the people, the project, the existing tools, and the constraints of the organisation.
At Paylume, we’re continuing to refine ours through real delivery work, using what we learn in each iteration to improve the next.
AI tools will continue to evolve, and some of the agents we use today may look very different a year from now. But the engineering challenges we’re trying to solve will remain familiar: understanding requirements, making good decisions, maintaining knowledge, and delivering reliable software.
For us, that’s where the real opportunity lies. Not simply in adopting AI, but in using it to continuously improve how we deliver software.
