Operations | Monitoring | ITSM | DevOps | Cloud

Developers use Bitbucket Cloud every day to turn plans into working software. Code lives in repositories, feedback happens in pull requests, and Bitbucket Pipelines helps teams validate changes before they move forward. For an AI assistant to help with this work, it needs access to the same information. Without a direct connection, developers have to gather pull request details, pipeline results, logs, and links before the assistant can help.

Last quarter, our AI reviewer told a developer who was fixing a CSS bug to rethink how their component fetched data. The comment was well written and confidently worded. It was also about code they hadn’t touched. That’s what tends to happen when you hand an agent every team’s review guidelines at once.

The hard part of a feature flag is rarely adding it. It is remembering to remove it months later, when the rollout is over, the original context has faded, and there is always a more urgent piece of work waiting. Since April 2026, one Atlassian team has used Agentic Pipelines to clean up their monthly backlog of stale feature flags. The workflow prepares the change and opens a pull request, while engineers still review and merge the pull request.

Finding code across your repositories in Bitbucket just got a major upgrade. We’ve rolled out code search in open beta for Bitbucket Cloud: a faster, more integrated search experience built to help you find code across your workspace without interrupting your workflow. For many developers, search is one of the fastest ways to explore an unfamiliar codebase, investigate an incident, audit API usage, or scope a refactor.

AI agents can help investigate failed builds, fix flaky tests and automate other development tasks. But setting up those agents has required more Pipelines configuration than it should. Agent-powered steps often need different compute, permissions and runtime settings from ordinary build and test steps. Until now, teams have either repeated those settings across every agent-powered step or tried to make one set of global defaults work for everything.

When a team relies on automated tests in CI/CD, knowing that tests ran is only the beginning. Understanding whether the suite is healthy, which tests need attention, and how a specific test has behaved over time — that’s what drives action. Bitbucket Tests is evolving to make those answers easier to find and give you tools to improve your test health.

Routine vulnerability fixes are rarely difficult in isolation. The interruption that they cause is the problem: pick up the ticket, trace the dependency, update the package or image, regenerate files, run the checks, open the pull request, then return after deployment to close the loop. That repeated handoff was a good candidate for automation with agentic pipelines. The goal was simple: start the day with a tested pull request instead of another ticket to pick up.

You shouldn’t have to hunt through a cluttered dashboard to understand where your code is deployed. The Deployments page is where teams turn for a quick answer: what is in test, what is in staging, what reached production, and what needs attention right now. The older page made that harder than it needed to be. Our new Pipelines Deployments page makes it easier to scan, filter, and act on.

Tracking tests on non-default branches was one of the most requested capabilities during the Bitbucket Tests (beta). We heard you, and today, we’re shipping it. Most teams don’t ship from main. Integration happens on develop, stabilisation on staging, releases cut from release. Until now, Bitbucket Tests only tracked the tests from default(main) branch, leaving the branches that actually matter invisible. Multiple branch tracking in Tests changes that.

We launched Bitbucket Packages to give teams one place to manage code, pipelines, and artifacts, and we’ve been expanding it ever since, first with Maven and npm, then PyPI and NuGet. Every one of those packages has shared one trait: it lives inside a single repository and inherits that repository’s permissions. Most of the time, that’s exactly what you want. But it also means sharing a package across repositories has meant granting people access to source code they never needed to see.