Design sync, build async: how we delegate software delivery at dLocal

A merchant asks how a displayed cost was calculated. Before anyone changes the code, the team needs to trace the data and business rules: does the question need an explanation, a clarified requirement, or a code correction?

At dLocal, we call our working model “design sync, build async”: resolve intent and technical< decisions with the people responsible for the work, then delegate implementation when expectations are clear enough. Engineers can work interactively with AI or hand a bounded task to dCoder, our coding agent for delegated implementation. In either mode, the team validates the result and captures useful lessons for the next task.

dLocal’s Approach to Task Automation

At dLocal, payment behavior depends on the market, local payment method, and applicable regulatory requirements. A change that appears straightforward in code may need different behavior across those conditions. Teams need to document the relevant business rules and review how they apply before delegating implementation, so the agent has the context needed to make and validate the change.

At dLocal, teams capture queries, calculation steps, and business rules in reusable skills—instructions and procedures engineers and agents can follow in future investigations. A tech lead manager describes a cost-breakdown skill that records what was queried and how the final cost was assembled:

“This lets us quickly perform analyses that used to take us at least an hour, and also iterate much faster on different configurations.”

Interactive work gives engineers room to challenge assumptions, refine requirements, and implement alongside an assistant. Once requirements and validation steps are documented, they can delegate bounded implementation. Independent tasks can proceed in parallel when each has enough context, clear acceptance criteria, and explicit dependencies. Engineers can move between the two modes as the work requires; the stages below describe responsibilities, not a fixed sequence.

Investigate and agree on the problem

The first decision is whether to write code at all. Establishing the problem and the intended outcome determines what work is worth delegating.

A product manager describes using an agent to investigate requests and propose priorities, with tech leads validating the implementation direction.

“We built strict "human-in-the-loop" approval gates so the agent never posts messages or creates tickets without explicit review, alongside interactive Q&A loops where the agent restates its understanding to stakeholders to validate scope and prevent misaligned work.” — Product manager at dLocal

The useful output is a shared understanding of the problem. A polished ticket is only valuable if it preserves that understanding.

Engineers use dLocal-Pi, our interactive AI environment, to explore code, ask questions, edit implementations, and run checks. It connects the model, tools, and reusable instructions with company setup and security controls.

Prepare the task and validation plan

Once the investigation establishes that a change is needed, engineers document its findings for the implementation task. dPlanner, our planning agent, researches and refines the request into requirements and, when needed, splits larger work into tasks with explicit dependencies.

Engineers review the proposed scope and technical direction before handing it over. The result should tell the next worker what must change, which constraints matter, and how to check the behavior. A business rule discovered in conversation needs to reach the ticket. A change spanning several services needs to identify the affected repositories.

A September analysis of delegated implementation tasks reported merge rates of 23.1% for medium-complexity tickets rated poor and 79.0% for those rated excellent. An LLM classified quality and complexity; this was an observational comparison in a partial sample, not evidence that the planning agent caused the difference.[2]

The ticket should document the rule, affected data, expected behavior, and checks agreed during investigation.

The next worker should be able to use the findings without reconstructing the discussion.

“The tools are most useful when they have clear context and a bounded task; they are less reliable when requirements are ambiguous or the change crosses many systems.”

Before delegating implementation, the team defines acceptance criteria and prepares a validation plan. dTestPlanner, our QA planning agent, turns tickets, larger initiatives, and solution documents into structured test plans, researching supporting context and applying domain knowledge. The plans cover expected behavior, negative scenarios, boundaries, edge cases, and error handling. QA approves the outline before the full plan is generated, then reviews and refines the result.

The value is a consistent starting point that makes important scenarios explicit. The plan specifies what to check; engineers and QA still need to execute the relevant tests and inspect the results.

“The biggest shift is that development becomes more iterative: describe the goal and constraints, ask the assistant to plan or propose a change, review the result in small increments, and run the usual tests and checks before merging. … We’ve also learned that generated code is a starting point, not proof of correctness.”

Delegate implementation and review the result

Once the task, acceptance criteria, and validation plan are reviewed, teams can delegate implementation to dCoder. The agent takes a defined Jira task, gathers codebase context and repository instructions, prepares a working environment, implements the change, runs validation, and opens a pull request for review. Blocking dependencies can hold execution until prerequisite tasks are complete.

Delegation lets engineers start independent tasks in parallel and review each result when it is ready, without continuously directing every implementation.

In producer-reported ticket-outcome data compiled in October 2026, 71.6% of tickets for which dCoder produced a pull request had reached a merged outcome.[1]

In the September sample, 72% of merged dCoder pull requests were classified as having no or low recorded human code changes. This describes code changes, not the time spent clarifying requirements, reviewing, or testing, and is separate from the October ticket-outcome figure.[2]

The team receives code and validation evidence to compare against the requirements and assess whether the change fits the surrounding system. If it misses the intent, the cause may be missing context, misleading guidance, or an implementation that failed to follow a clear requirement.

Teams can use dReview, our AI-assisted pull request reviewer, to identify potential defects and gaps in quality, security, performance, testing, and alignment with the Jira task. It can also check repository-specific rules configured in a REVIEW.md file. It operates on pull requests and is separate from dCoder’s internal review.

In addition to the validation run by dCoder, engineers and QA execute the relevant tests from the agreed test plan. Engineers assess those results alongside dReview’s findings, the requirements, and the generated code and validation evidence. If review or testing reveals a missing scenario or an incorrect assumption, they revise the requirements or plan and request a correction. The owning team decides whether to merge and release the change through its usual delivery controls after reviewing that evidence.

Vulnerability remediation is another application of this approach: dCoder can automatically generate pull requests to patch vulnerabilities detected by Dependabot. Recurring remediation work gives teams a repeatable procedure to capture—how to apply a fix, check compatibility, and validate the affected behavior. Teams can record that procedure in repository guidance or reusable skills, so subsequent fixes start with the checks and lessons established in earlier reviews.

Capture knowledge for future work

Investigations and reviewed corrections can reveal gaps in requirements, code, or operational guidance. dDetective, our operational investigation agent, brings together logs, metrics, traces, code, and operational knowledge to produce an evidence-backed diagnosis and recovery recommendations. Its investigation tools remain read-only; engineers review the diagnosis and decide what action to take.

Engineers capture useful investigation methods and domain knowledge as reusable skills: where to look, what procedure to follow, what evidence to return, and when to ask for help. Teams share these skills, automated hooks, and connections to tools and data through dPlugins, our internal marketplace for agent capabilities.

Both dLocal-Pi and dCoder can use compatible team capabilities, but the relevant instructions, skills, and tool access must be configured in each environment. Decisions made in conversation need to be recorded in the task, repository guidance, or a skill so they are available during delegated work.

dCoder can also propose reusable repository guidance from task and execution records, proposed code, developer-accepted corrections, and review feedback. Engineers review these proposals before accepted instructions become context for later tasks. This feature, Agentic Harness Self-Improvement, also consolidates accumulated execution memory under separate safeguards.

This complements manual skill creation: teams document domain expertise and repeatable procedures directly, while recorded work and reviewed corrections help refine dCoder’s context. A tech lead manager makes knowledge capture a regular practice:

“At least once a month, I use Claude Cowork to review my email and meeting transcripts. I extract new knowledge—whether developed by the team or discovered during troubleshooting, on-call work, or support—and record it in our repositories.”

Measure and improve repository readiness

AI Readiness automatically assesses repository preparation. Our focused assessment uses a large language model to evaluate Skills, Documentation, Observability & Recovery, and Code Health & Maintainability. Teams use the findings to prioritize improvements to instructions, skills, diagnostics, and code.

These improvements support both interactive and delegated work. Rerunning the assessment makes changes to measured readiness visible, but domain owners also check the guidance in use: documented setup and test commands must work, and investigation procedures must help explain real failures.

A September analysis reported higher merge rates among tasks from teams in higher AI Readiness score bands: 67.1%, 79.4%, and 84.0% for bands of 0–39, 40–59, and 60–74, respectively. The analysis used teams’ latest scores in a partial sample.[2]

We made time for this work in our AI Readiness Rally Day in October, 2026. Teams registered repositories for assessment, selected priorities, and focused on concrete improvements with support across EMEA and LATAM. The goal was to document useful team knowledge that engineers and agents could apply in the repository.

Improve the next task with reviewed lessons

The cost question illustrates what is worth preserving: not just an explanation of one number, but the queries, business rules, and investigation procedure that let the next engineer or agent examine a similar question. A reviewed implementation or recurring vulnerability fix can leave the same kind of reusable method.

“Design sync, build async” depends on that foundation. People establish intent, business rules, and acceptance criteria; agents contribute implementation and evidence; engineers and QA validate the result before the team accepts it. Capturing what they learn gives the next task a stronger starting point.

Measurement notes

[1] The 71.6% figure comes from producer-reported ticket outcomes compiled in October 2026. It covers tickets that produced a PR, including rejected and still-open outcomes—not all tasks submitted to dCoder. It counts ticket outcomes, not unique PRs, and does not measure correctness, time saved, or human effort.

[2] The September LOC-based analysis classified about 44% of its two-month ticket population using an LLM. Quality/readiness rates are reproduced as reported; denominators, outcome handling, and ticket-to-PR matching remain unverified. Readiness used latest team scores, not task-time scores. These are associations, not causal effects. The separate 72% figure measures recorded code changes on merged dCoder PRs, not clarification, review, testing, or total human effort.