How dLocal built and scaled AI agents across the SDLC with Port

dLocal now runs an internal agent called dCoder that handles 45% of its engineering tickets from start to finish, from reading the ticket to opening a reviewed pull request. Teams using it perform more than 20% better, the equivalent of a 20% larger engineering team at zero added headcount. That is the result. This study is about how they got there with Port, and why the work was in the harness, not the agent.

About dLocal

dLocal (NASDAQ: DLO) runs payments for Google, Uber, Microsoft, and Amazon across more than 40 emerging markets in Latin America, Africa, and Asia. It processes over 500 million transactions a month, growing more than 50% year over year, against a 99.99% uptime SLA. Behind that sit 400 engineers across 60 teams.

The Challenge

Before Port, the bottleneck at dLocal was scattered context, not a missing tool. Engineers spent hours onboarding to separate systems, stitching together incomplete data, and switching between tools to answer questions that should have been a single query. CTO Alberto Almeida read it as a context problem rather than a tooling one, and he could see it getting worse as agents entered the picture. An agent working off scattered, outdated information does not just slow down. It makes confident, costly mistakes.

The Solution

dLocal put Port in first as the source of truth across their engineering systems, then built dCoder on top of it. The agent runs the routine work, and Port holds the context and the guardrails it runs inside.

The loop is straightforward. When a ticket comes in, dCoder pulls the context it needs from Port: the service catalog, the infrastructure, the repositories, and who owns what. It scopes the work, writes a plan, writes code against the organization's own standards, runs security and QA checks, and opens a PR. A developer reviews it and approves. Port reports on all of it, so managers see DORA metrics, PR status, and how the agent is performing in one place.

"Developers are still accountable. They just don't need to do the grunt work. Port is the interface." Alberto Almeida, CTO, dLocal

The Results

The number Almeida watches above any other is coverage. dCoder now handles 45% of all engineering tickets autonomously. Across 2025, the supporting numbers moved with it:

• Deployment frequency up 60% to 70%
• Lead time down 50%
• MTTR down 50%
• New-engineer onboarding 80% faster

Teams running dCoder perform more than 20% better, which is where the 20% capacity gain at no new headcount comes from. The point of the 45% is not that the agent replaces engineers. It is that they stop spending their day on routine tickets and spend it on the problems that actually need them.

3 Key Learnings

1. Building a semantic layer for agents is where to start

Almeida is blunt about this: scattered, outdated information misleads agents and produces costly mistakes. Context is the prerequisite to quality, because better context means fewer hallucinations. As he put it, Port is the single source of truth, and without it you would have to build all those connections yourself.

Port's context lake ingests and unifies data across the SDLC in real time, covering environments, services, tools, policies, and the business systems around them. Because that graph is built for agents to read, dCoder can answer complex questions in a single request instead of many, which is where the 80% reduction in token cost comes from.

dLocal did the unglamorous work alongside it. They cleaned up and enriched their data, and documented their decisions, architecture, and patterns. Port's flexible data model let them map their own business logic, try different agent capabilities and team setups, and swap underlying tools without changing what developers see. As Almeida put it, the flexibility let them move faster than they thought possible.

2. Governance prevents chaos

dLocal scoped the agent before they scaled it. Port defines the access policies, what dCoder is allowed to execute, and the standards it has to meet across teams. On top of that, dLocal added audit trails, approval gates, and rollback, so the agent operates inside set boundaries and every action can be undone.

The visibility runs both ways. Managers see overall health, which tickets the agent handled, and rejection rates at a glance. Developers see exactly what dCoder did and why. As Almeida put it, Port is embedded in everything they do, which is what gives them a full view of what the agents are executing.

3. Measurement drives continuous improvement

dLocal measured before they deployed. Port's Engineering Intelligence dashboard set the baselines first, then tracked agent coverage, PR rejection rates, DORA metrics, and developer NPS as dCoder rolled out. With those numbers in front of them, the team could see where the agent fell short and fix both the agent and the processes around it, rather than guess at adoption. The result is a repeatable loop: measure, find the gap, close it, extend coverage.

"Today, the agent does 45% of all our tickets. The single metric I care about the most is end-to-end agentic coverage. I go to Port and see the agent's work, rejection rates, and how engineers code differently. My entry point for all of that is Port." Alberto Almeida, CTO, dLocal

Conclusion:

dLocal did not build dCoder and then bolt context onto it. They built the foundation first, and the agent became possible once Port held the context, the guardrails, and the reporting in one place. That is the order that keeps an autonomous SDLC running rather than demoing once: the agent does the work, developers stay accountable, and Port is the interface for both.

Sign up for the Port Platform here.