Digital Product Development with AI Agents

No, and we no longer issue the Scrum Alliance certification. We do not run DevOps or Continuous Integration, Agile Testing or Architecture as courses either. That content is now worked on inside this service, on your teams' code: below we tell how we apply continuous integration, architecture, testing and TDD with AI agents today. When a whole team needs to go deeper on a topic, we add an in-company training within the same service.

First, a minimum safety net of tests; coverage comes later. Without tests, integrating often only integrates errors faster, and with agents, faster still. So we start with characterization tests (golden master): they pin down how the system behaves today, even if that behavior has bugs. With that net, the team moves to trunk-based development: small changes, integrated into the main branch several times a day, with the pipeline as the only gate. What is not ready yet is hidden behind feature flags, not in long-lived branches. And environments are defined as code (infrastructure as code), so the team and the agents reproduce them the same way every time.

A quick test: how long does the pipeline take to say whether a change broke something? If it is over the 10 minutes XP proposes, the team will dodge it, and so will the agents. If you want to know more: Continuous software delivery (in Spanish).

In parts, with decisions the team makes and validates along the way, with no full redesign. What makes a system malleable for a person also makes it malleable for an agent: tests that warn quickly, modules with clear boundaries and names that say what the code does. This is how we work on architecture:
· Quality attributes first: we agree with the business which ones matter (ease of change, security, availability) and they get prioritized like any other backlog. Monolith or microservices is decided by those attributes.
· Hexagonal architecture (ports and adapters): it separates the domain from the database and external services, so each part can be changed and tested separately.
· Architecture refactoring in small steps, with tests that pin the current behavior before moving anything: the agent proposes and the tests verify.
· Architecture in the pipeline: quality metrics are measured on every integration, so the design does not degrade without anyone noticing.

The agent speeds up every step, above all understanding code nobody documented. Architecture decisions are still made by the team.

Writing tests stops being the bottleneck; deciding what to test does not. An agent generates hundreds of tests in minutes, and many only repeat what the code already does: they always pass and protect nothing. What we work on with the team:
· Testing quadrants: which tests guide development and which critique the product, what gets automated and what does not.
· Automation pyramid: many fast unit tests and few end-to-end ones, chosen for the journeys that matter. With agents it is easy to invert it, and the pipeline becomes slow and fragile.
· Automated end-to-end tests: an agent walks through the application like a user, and even records a video of the journey; if a screen changes, the test breaks. We tell it in This meeting could have been a video (in Spanish).
· ATDD: the team defines the acceptance criteria with the business before building, and the agent turns them into tests.
· Exploratory testing: the time automation frees up goes to what an agent does not see: usability, edge cases, the business context.

A quick test: break one line of code on purpose (that is the idea behind mutation testing). If no test fails, those tests do not protect that part.

The code is still the team's, and so is the responsibility. Collective code ownership says anyone on the team can change any part of the code. With agents, the risk is the opposite: code nobody on the team understands. We avoid it with three practices:
· Nobody integrates code they cannot explain, whoever wrote it.
· TDD and ATDD/BDD: the team writes the test or the acceptance criterion first, and the agent writes the code that meets it. The intent stays in human hands.
· Design-centered review, with the team's standards verified by static analysis, so people look at what a tool does not see.

If you recognize yourself in any of these lines, the bottleneck is in how it is built:
· "A small change takes us weeks."
· "Nobody dares touch that module."
· "Every release breaks something that worked."
· "Only one or two people understand the system."
· "Before every release, we test everything by hand."

When the lines change, the bottleneck has moved.
· "I don't know what my team is up to" or "It never delivers what it commits to": it is in how the team works.
· "What we build does not move the business": it is in what to build and why.

This front can be hired on its own. During the diagnosis we confirm where it is best to start.