The fix is a pull request.
The merge is still yours.
Datadog Bits Code starts from a production finding: an Error Tracking issue, an APM recommendation, a slow query, a flaky test, a security finding. It reads the trace, the logs, the runtime variables and your repository, then proposes a pull request with a fix and tests. We scope which repositories, services and teams it may touch, wire the triggers that matter, and leave the merge with an engineer. Agents own the analysis. Humans own the outcome.
Quick facts
Related
- Bits AI, the whole family and the guardrails
- Bits Investigation, the finding that often comes first
- Error Tracking, the issue the pull request fixes
From the stack trace to the diff, with the evidence attached
The error has been in the backlog for a quarter. Everyone knows roughly where it is. Nobody has had the afternoon to open the trace, find the line, write the fix and write the test. Bits Code takes the issue, reads the trace and the runtime variables, finds the line, writes the fix and the test, runs CI, and opens the pull request with the finding it came from. The afternoon is now a code review.
Input: a finding and the context around it. An Error Tracking issue, an APM recommendation, a Code Security finding, a profiler hotspot, a flaky test or a slow query. With it come the logs, traces, profiles, Live Debugger variables and repository context that explain it.
Output: a pull request with its working. A targeted change and unit tests. Bits Code iterates on CI failures before opening the pull request, and the pull request carries the investigation summary, the originating finding and the test results. The diff is visible in Datadog before the pull request exists.
Where the engineer sits: on the review and the merge. Datadog states it plainly: the agent proposes pull requests, and engineers decide what to merge. Automated runs go through the same review. Nothing reaches a branch anyone deploys from without a person approving it.
Triggered by what production already found. Fix with Bits on a high-impact issue. A Code Security Campaign across many repositories. An automation on a schedule or a telemetry condition. A freeform session from Slack or the Bits AI page.
Access to every repository, an automation on every issue, and a review queue that fills faster than anyone can read it
How it bills. Bits Code draws on AI Credits, the meter shared across the Bits AI family, sold on demand or in monthly bundles that reset on the first of each calendar month and do not roll over. Each code fix consumes credits. Datadog describes flexible rate limits and cost controls for Bits Code, and administrators can cap AI Credit usage for the organisation and per user, with Bits Code usage counted against the user who started the session. Datadog states that Bits Code is generally available to all Datadog customers. Its documentation lists GitHub, GitLab, Azure DevOps Cloud and Bitbucket Cloud as supported source control providers. We publish no rates. The lever is which findings trigger a session and how many repositories are in scope, and both of those are decisions we make with you rather than defaults.
The configuration traps. Source Code Integration is connected to the whole GitHub organisation because that was the quickest option, so the agent can see the repositories nobody wanted an agent in. An automation is set to open a pull request for every new Error Tracking issue, and by Friday the review queue has forty proposals for issues nobody had triaged. A Code Security Campaign is run across every service at once, and the dependency bumps land on teams who were not told. The pull requests are good, and that is the problem: a good pull request that nobody reviews is a backlog with better formatting. Each of these is the agent being productive against a scope that was never drawn.
Field noteThe most common gap we see is the review queue nobody staffed. The agent is scoped well and its pull requests are sound. They sit open for weeks because the team that owns the service was never told the agent would be sending them, and merging is not in anyone's week.
Field noteThe pattern we keep finding is Source Code Integration set up for the whole organisation. The agent is well behaved, and it can nonetheless read repositories that were out of scope for every contractor the company has ever had.
Field noteThe findings that produce the best pull requests are the ones with a trace and a runtime variable attached. An Error Tracking issue with a full stack trace yields a small, correct diff. A vague recommendation with no trace yields a plausible one, which is more dangerous.
Field noteThe automation runs on a schedule and the pull requests arrive in a batch, each one formatted the same. The one that matters, a dependency with a real vulnerability, looks identical in the queue to the refactors around it, and the queue has no way to say which is which.
Scope the repositories. Pick the findings. Staff the review before the first pull request opens.
We start with a Datadog HealthScan, read-only and fully automated. It reports whether Source Code Integration is in place, what Bits Code can reach, which automations trigger it and what it has proposed. The setup then runs within Managed Observability onboarding.
- Scope the repositories, services and teams. Datadog lets administrators control which repositories, services and teams the agent can access. We start with the services that matter at 2am, and the repositories behind them, and nothing else.
- Set up Source Code Integration properly. Unified service tagging so the finding maps to the right repository and the right commit, and the integration connected to the scoped repositories rather than the organisation.
- Choose the findings that trigger a session. High-impact Error Tracking issues with a stack trace, APM recommendations with a trace, and Code Security findings above an agreed severity. Not every issue, and not on a schedule to begin with.
- Name the reviewers. For each scoped service, the engineers who will review the agent's pull requests and the time in their week it will take. A pull request without a named reviewer is not opened.
- Set the rate limits and cost controls. Datadog's administrator controls for Bits Code, plus a monthly credit budget with an owner, so the review queue cannot outgrow the reviewers.
- Run it on the backlog, then hand over. The agent is pointed at the ten oldest known-cause issues, the pull requests are reviewed as a batch, and the merge rate sets the baseline. The scope, the triggers, the reviewers and the controls are documented.
Access is admin on the Datadog organisation. Repository access is granted by you through Source Code Integration to the repositories you choose; we specify the scope and you connect it. We do not hold credentials to your source control.
A pull request that nobody merges is the backlog with a nicer diff
New services ship with new repositories. A team is reorganised and its reviewers move. An automation keeps running against an issue class that was fixed properly in March. Managed Observability reviews every proposed pull request against what was merged, every month, and keeps the scope matched to the estate. Fixes in the runtime we operate under Critical Support go through the same review, by our engineers.
Every month, proposed meets merged. Pull requests opened, reviewed, merged, changed before merging and closed unmerged, per service. A low merge rate on one finding class means that trigger comes off. A high one means the scope can widen.
Scope follows the estate. New repositories and services are added to the scope deliberately, with a named reviewer, or not at all. Repositories that leave the critical set leave the scope.
The triggers are kept honest. Automations that produce pull requests nobody wanted are retired. Finding classes that produced good fixes get a trigger. The agent is pointed at the backlog that matters, not at the one that is easiest.
Our fixes get the same review. Where a finding sits in the runtime we operate, our engineers review the agent's pull request, merge it or rewrite it, and record which. The agent proposes. The engineer who signs the deploy is a person.
We operate the stack. You own the product.
A code agent with access to everything and a review queue nobody staffed is a liability with a green CI badge. We scope it to the repositories that matter, point it at findings with evidence, and put named engineers on the review. An implementation partner connects it and leaves. A managed partner reads the merge rate every month and adjusts the scope. We are the second kind. The scope, the automations and the record stay in your Datadog and your repositories, and you can take it in-house whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Bits Code, answered plainly
Is Bits Code the same as the Bits AI Dev Agent?
Yes. Datadog introduced the code-fixing agent as the Bits AI Dev Agent and now names it Bits Code in its documentation and navigation. It reads a production finding with the trace, logs, profiles, runtime variables and repository context behind it. It writes a targeted fix with unit tests, iterates on CI, and opens a pull request that carries the originating finding and the test results. Datadog states it is generally available to all Datadog customers.
How is Datadog Bits Code billed?
Through AI Credits, the meter shared across the Bits AI agents. Datadog sells credits on demand or in monthly bundles that reset on the first of each calendar month and do not roll over, and each code fix consumes credits. Datadog also describes flexible rate limits and cost controls for Bits Code, and administrators can cap AI Credit usage for the organisation and per user. We do not publish prices. We decide which finding classes trigger a session and which repositories are in scope, and we set a monthly credit budget with a named owner.
Does Bits Code merge code on its own?
No. Datadog states that the agent proposes pull requests and engineers decide what to merge, and that automated runs go through the same human review. The proposed diff is visible in Datadog before the pull request is opened. We add a rule of our own: no finding class triggers a session until a named reviewer for that service has agreed the time in their week, because a correct pull request nobody reviews is still a backlog.
Which repositories can it see?
Only the ones administrators allow. Datadog lets you control which repositories, services and teams the agent can access, and the access is granted through Source Code Integration on your side. We scope it to the repositories behind the services that matter at 2am and widen it deliberately, with a reviewer named for each addition. Datadog also states it operates with zero data retention with third-party AI providers, which is a question we are asked in every due-diligence conversation.
What does Critical Cloud do with Bits Code every month?
Under Managed Observability we review the pull requests the agent opened against the ones that were merged, changed or closed, per service and per finding class. Triggers with a low merge rate are retired and the classes that produced good fixes are widened. New repositories enter the scope only with a named reviewer. Credit consumption and the rate limits are checked against the budget. Where a finding sits in the runtime we operate under Critical Support, our engineers review and merge the agent's pull request themselves. Agents own the analysis. Humans own the outcome.
- Datadog products: every product, and how we implement and run each one
- Bits AI: the agent family and the guardrails we run it under
- Code Security: the findings a Code Security Campaign turns into pull requests
- Error Tracking: the issues Fix with Bits starts from
A fix proposed from the evidence. A merge decided by a person.
Tell us which Error Tracking issues have been in the backlog longest. We will show you what Bits Code proposes for them, which repositories it should be allowed to see, and who should be reviewing its work.