The learnings in this blog post are based on the session, “Accelerating the SDLC at scale: How Axel Springer uses Rovo Dev to ship faster”, presented at Atlassian’s Team ’26 conference. You can check out this session and others on demand.
Every engineering organization feels pressure to ship faster, but increasing velocity alone isn’t really the most useful goal. Martin Bilt, Lead Product Excellence at Axel Springer, frames this challenge differently. According to Bilt, the more important question is whether engineers are spending their best hours on work that moves the product forward or on the repetitive scaffolding around it.
Axel Springer is a global media and technology company behind brands such as Business Insider, Politico, BILD, and idealo. Headquartered in Berlin and active in more than 25 countries, the company has spent more than 70 years evolving from a traditional publisher into a technology-driven media company by repeatedly betting on technology well before it felt safe or comfortable.
This technology-driven culture has shaped the company’s approach to AI in software development. Adopting AI was never a question for Axel Springer; their real question was, “Where do we start? And how quickly can we get up to speed?”
Axel Springer placed Rovo Dev in the middle of how several engineering teams build software. This pilot focused on real workflows, measurable outcomes, and the day-to-day friction that prevents engineers from spending more time on meaningful problem-solving.
Speed is a byproduct, focus is the goal
Axel Springer found that a more important outcome than velocity alone was redirected attention. Rovo Dev helped move senior engineering time away from repetitive setup work and toward the problems that matter most.
The company used a simple framework to think about where AI could help. Work fell into four categories: quick wins, strategic bets, time sinks, and fillers. AI was especially useful for high-frequency, low-complexity work that creates backlog noise. That insight led to a sharper question: “If an AI agent can complete something in seconds, why was it on a senior engineer’s plate in the first place?”
“The real question is not how to ship faster. It’s wherever we are working on the right things. Faster output of a wrong work is not a win. It’s more of a waste if it ships sooner.”
–Martin Bilt, Lead Product Excellence, Axel Springer
Adopting Rovo Dev did more than automate tasks; it exposed how teams had been prioritizing work and where time was really going.
The biggest gains came from context, not coding
The most important finding from the pilot was that the largest time savings did not come from generating code. They came from planning, documentation, understanding unfamiliar code, and debugging.
For every new story, an engineer often needs to read the Jira ticket, find relevant Confluence pages, understand what has already been implemented, identify which files need to change, and mentally load all that context before writing a single line of code. That context-loading phase is usually invisible in sprint estimates, yet it can take 30 to 45 minutes per story.
When the AI already has that context, the engineer and AI can begin with a grounded plan before the first file opens. The code may be written faster, but the larger benefit is that the right work gets done with less overhead.
The strongest gains came when context loaded faster, allowing engineers to spend less energy reconstructing the work and more energy solving the problem.
Starting small with four teams and three assumptions
The pilot began with four teams at different stages of AI maturity. Each team had its own workflows, habits, and level of skepticism. Axel Springer had more than 30 possible use cases, but that list wasn’t a strategy. The team narrowed the work to concrete areas where friction was high, and learning could happen quickly.
They started without a six-month roadmap, a long evaluation document, or a strategy paper. The approach was to act, observe where the uplift was real, and adjust.
Three assumptions guided the pilot.
- Engineers would adopt AI if it were useful in their workflow.
- Documentation would be the lowest-risk starting point.
- Code understanding would help engineers move faster, especially in unfamiliar or legacy systems.
All three assumptions were confirmed. Every team adopted Rovo Dev, although the depth of adoption varied by team and by person. Some engineers explored it alongside the tools they already used. Others moved deeper into it from the first week. Both behaviors were useful signals.
Documentation became more than a low-risk entry point. It became one of the highest-value use cases, and engineers consistently named it among the areas where they saved the most time. Code understanding also proved valuable for legacy systems and unfamiliar areas where engineers previously spent hours learning what another team had built before they could make a change.
The teams also went beyond the original hypotheses. They created workflows that had not been proposed and found use cases that had not been anticipated. The hypotheses got the pilot started. The teams took it further.
Documentation that compounds
The first major impact came from documentation. Axel Springer wanted documentation that worked for engineers, product managers, and stakeholders. It needed to be current, reliable, available, and ready to use.
The team built a GitHub Action triggered on every merge. Rovo Dev reads the diff and generates two outputs: a technical markdown file for engineers and AI agents, and a higher-level Confluence page for the broader team. The Confluence page also becomes a knowledge source for Rovo agents.
There is no manual step and no delayed promise to document work later. From the moment a ticket is picked up to the moment code is merged, the documentation updates automatically. Documentation stops being debt and becomes a byproduct of the work itself.
Axel Springer then expanded on the idea by embedding Rovo Dev prompts directly into Confluence documentation pages. For example, an engineer can add a prompt that briefs a repository and generates a Mermaid diagram of a screen flow. A second prompt below the diagram can create or update detailed sections for every screen in that flow, populated directly from the code.
The documentation page becomes self-maintaining because the prompt lives next to the output. A product manager or engineer does not need a GitHub account, terminal, or IDE to update the documentation. They can iterate directly on the Confluence page until the output looks right.
The goal is documentation that compounds, not one that decays. If it isn’t documented, it gets forgotten. If it is documented in a way that evolves with the system, it gets better with every iteration.
Vulnerabilities fixed before engineers notice them
The second major loop focused on security. Axel Springer uses Snyk and Wiz for continuous security scanning. When a vulnerability is detected, the tools trigger a work item in Jira.
Rovo Dev pulls the relevant context, including services, dependencies, CVE details, and ownership information. It analyzes the blast radius, drafts a fix, and opens a pull request. In many cases, the engineer first learns about the vulnerability when they approve the fix.
That removes the need for a triage sprint, a growing security debt backlog, or for a senior engineer to be pulled out of feature work to investigate. The system handles the issue before it becomes visible overhead. After the fix is merged, the scan result is confirmed, the work item is closed, and the next scan cycle starts automatically.
“If an AI agent can do something in seconds, why was it on the senior engineer’s plate at all? AI doesn’t just [do the] task. It exposes how badly we were prioritizing them in the first place.”
–Martin Bilt, Lead Product Excellence, Axel Springer
Additional workflows teams brought into daily work
Beyond documentation and vulnerability handling, pilot participants found additional ways to use Rovo Dev in everyday workflows.
One workflow lives directly in the repository. On command, Rovo Dev fetches the Jira ticket, normalizes the branch name, checks the Git state, creates the branch, inspects the codebase, and produces a grounded implementation plan and execution checklist. Jira tickets, Confluence pages, service ownership in Compass, and other context are available where the engineer codes.
With the CLI available in the terminal and CI pipelines, an engineer starting a new story no longer has to interpret a ticket alone and hope the scope is understood correctly. They start with a plan grounded in the actual codebase.
Another use case is sprint reporting. A team lead might previously have spent 30 minutes on a Friday afternoon writing a summary from memory, reading Jira comments, and preparing for the sprint review. Now, the summary can be generated with a single command. Rovo Dev reads the tickets, pulls request context, includes work that may not have had a ticket, understands the sprint’s scope, and tailors the summary for the right audience and channel.
The time saved by any single sprint summary isn’t dramatic on its own. Across every sprint, team, and quarter, the savings accumulated across the development process to make a meaningful impact on time spent.
Rovo Dev also powers a pull request description workflow. The workflow reads the diff against the main branch, understands the change, maps it to the developer checklist, and generates a complete pull request description in line with team or company standards. It can include a plain-language summary, test notes, and a checklist that is prefilled where possible and left open where human judgment is required.
Standards that once depended on whoever reviewed the pull request can now run on every pull request because the workflow file lives in the repository.
“The right question is not what AI is capable of. It’s where the highest-leverage friction we can remove right now is. Focus on concrete use cases, not strategic frameworks.”
–Martin Bilt, Lead Product Excellence, Axel Springer
Compass and the context layer
Axel Springer uses Compass as a service catalog. The team extended it with Forge and MCPs so components, owners, and dependencies stay up to date with code changes. The service map can be updated with code merges rather than relying on someone to remember manual updates.
This service map was built by a non-engineer in a matter of hours, including time spent working on train rides. The result is that engineers who inherit a service can understand what they are inheriting, because the system keeps context up to date.
That broader context layer is what makes the workflows work. The AI models are powerful, but according to Bilt, without context, they are just chatbots with development capabilities. Rovo Dev sits in the middle and connects the systems teams already use: Jira for tickets, Confluence for documentation, Compass for service ownership and dependencies, Jira Service Management for incident history, Jira Product Discovery for ideation, GitHub for code search and repository actions, Figma for design systems and specs, Snyk and Wiz for security signals, and Microsoft tools for mail and documents.
With that context, AI doesn’t just know what the team is building; it can also understand why the work matters, who owns it, and what depends on it. Deeper context creates stronger AI.
What Axel Springer’s engineers said changed
The architecture mattered because it changed how people worked. A principal engineer in the pilot summarized the shift by saying that code, docs, and direction were finally talking to each other and providing context.
A frontend developer described a new starting point for tasks. Instead of asking whether AI could help, they began by thinking about how to start the task with Rovo Dev and how to write the right prompt.
That is a different cognitive mode. Once engineers begin thinking this way, the workflow becomes part of how they approach the job.
How adoption happened
Every step of adoption was executed intentionally. Axel Springer’s rollout followed five specific moves:
- Start with a kickoff that introduces the tool and creates immediate interest.
- Short, hands-on introductions brought the tool to each team without relying on theory-heavy presentations.
- Team leads and principal engineers became internal allies who owned real use cases and built momentum from within.
- Observing existing engineering habits revealed the right interfaces, so adoption began with workflows people already knew, rather than adding new ones to learn.
- Demand grew on its own, and the strongest adoption signal came when people no longer needed a push.
The rollout also recognized that every team includes people at different points of readiness. Axel Springer described four groups: watchers, experimenters, integrators, and natives. The rollout was not optimized for natives because they would find their way regardless. The leverage came from helping watchers begin experimenting and showing experimenters what integration looked like in practice.
The principle was to start where people are, not where you want them to be.
The measurable outcomes
The post-pilot survey showed measurable results.
- 50% of code review suggestions were acted on, not only seen.
- Active development time per pull request dropped by 30%.
- Engineers saved about 2.5 hours per week.
- 87% of engineers reported spending less time on repetitive tasks.
These were real numbers from a real pilot rather than a controlled experiment. Behind each metric was a decision to work differently.
Model selection needs governance
One lesson from the pilot was that model selection can’t be left unmanaged. If engineers lack guidance, they may reach for the most powerful model every time because it feels safest. That can become expensive quickly, and it isn’t always the right choice.
Axel Springer treated model choice as a governance decision. Teams need visibility into how models are being used and education on which model is right for which task. The goal is to control costs without losing quality.
The ceiling rose without adding headcount
The shift affected more than engineering workflows. Product managers could ship live product documentation rather than just written specs. Designers could create systems and structured handoffs for AI, not only static designs. Engineers could focus more on architecture and cross-stack debugging rather than routine bug fixes.
The capability ceiling increased without increasing headcount.
Enablement is a continuous practice
Sustaining the shift requires more than a strong rollout. Enablement can’t be a one-time workshop. Axel Springer treated it as a continuous practice with three loops.
Learn
Knowledge needs a home. Axel Springer created an AI center of practice to hold best practices, guardrails, and model updates so that every team does not have to start from zero. A community also supports the work through Slack channels, shared prompt libraries, and always-on learning. Engineers can access a GitHub repository where tooling and guidance live in one place.
Carry
Knowledge that stays in the center does not reach teams. Champions in each team bring practices into squads. Artifacts such as skill files and repeatable prompt patterns make knowledge portable across teams and domains. What used to disappear in Slack threads becomes a file that a new engineer can open on day one.
Scale
The system needs mechanisms that keep it current without constant manual effort. Agent markdown files in repositories capture stack standards and patterns, so prompts, agents, and code generation begin with team context. The learning loop also matters because new models arrive quickly. What teams learn in production flows back into the center of practice, and champions bring real experience into the community.
The loop is never done; it just keeps moving to the next improvement.
Where to start
Engineering attention is always under pressure from backlog work, context switching, and repetitive scaffolding. The most useful question is not how to use AI in general. The better question is: where can the highest-leverage friction be removed right now?
Axel Springer started with four teams and three assumptions. Months later, engineers were asking for Rovo Dev on their own. That was the signal that the work had become valuable in practice.
Start by finding one team, one repetitive task, and, in two weeks, whether the uplift is real.
Speed matters, but focus matters more.
