Effectively Using Async Coding Agents
Boost developer productivity with async coding agents. Learn how Tembo automates multi-repo tasks, enforces standards, and speeds up software delivery.
Since the first stone tool was created, we as humans have not stopped creating, iterating, and automating. We’re even closer to a fully automated world than when the steam engine was created. The common expression “If only I had an extra arm” to help has plagued not only those who work with their hands but also those who would benefit from ceding off parts of their brain to do other tasks. Though we are not simply machines, nor is it possible for us to effectively multitask. BUT, you know what/who is capable of working like machines? Machines. We are now incredibly equipped to start pushing tasks off to autonomous, asynchronous agents.
Though just knowing what asynchronous machines can do doesn’t really provide any value other than cramming more information into an already overworked brain. In this article, we will discuss what Asynchronous execution is, how to effectively use asynchronous agents, and how Tembo can help.
Understanding Asynchronous Execution
Asynchronous execution in AI coding agents enables concurrent processing and non-blocking operations. Unlike synchronous models that process requests sequentially, asynchronous agents decouple the initiation of a task from its completion, allowing the system to handle multiple code generation or analysis tasks simultaneously. This is typically achieved through event-driven handlers, task queues, and worker pools, ensuring that long-running operations do not block the user interface or prevent other tasks from starting.
The primary benefits of this model include significantly higher system throughput and improved scalability, often achieving 3–10 times the performance of synchronous systems under heavy workloads. By overlapping I/O operations with computation and distributing tasks across multiple CPU cores or machines, asynchronous agents provide a more responsive experience in multi-user environments and large-scale development projects. Although this architecture introduces higher development complexity and potential queuing overhead for simple tasks, it is the superior choice for resource-intensive applications that require efficient horizontal scaling and background processing.
How Async Agents Differ from Chat-Based Assistants
Interactive AI assistants function like a skilled pair programmer looking over your shoulder. They respond to your prompts in real time, suggest completions, and help you think through problems.
Async agents invert this relationship:
- Chat-based tools optimize for rapid iteration within a single context window.
- A chat assistant might help you write a function.
- Async agents optimize for complete task execution across an entire codebase.
- An async agent will implement a feature, run the test suite, and fix any failures before you see the result.
This model enables parallelization. A developer can dispatch five agents to five different tasks simultaneously. Each agent works in its own isolated container, unaware of the others. The developer's role shifts from executing work to reviewing completed work.
Coordinating Multi-Repository Changes
Most production systems do not live in a single repository. We split our code across frontend applications, backend services, infrastructure configurations, and shared libraries. A single feature often touches three or four repos before it reaches our users.
When we sit in a chat window with an AI assistant, we work within one context at a time.
Here’s a common workflow:
- We get help writing a new API endpoint in the backend repo.
- We close that conversation.
- Open the frontend repo.
- Start a new session to build the component that consumes that endpoint.
The AI, specifically the synchronous chatbot, has no memory of the backend work. We then spend hours playing electrician, waiting for the connection to provide a “light” or an indication of connection.
Async agents can operate across repository boundaries in a single task. We define the work once, specify the affected repositories, and the agent coordinates changes across all of them. The backend gets its new endpoint. The frontend gets its new component. The shared types library gets updated interfaces. Each repository receives a pull request that references the same parent task.
*CAVEAT: Cross-repo task orchestration requires careful scoping*.
We cannot simply tell an agent to "add user authentication" and expect coherent results across five repositories. I did say we’re closer than the steam engine, but not human-level reasoning close.
The task definition must specify which repos are involved and what role each plays. A well-structured task might read: “Add email verification to the signup flow. Backend repo handles the verification endpoint and email sending. Frontend repo adds the verification input screen. Infrastructure repo updates the email service configuration." Taking it a step further, it is best practice to name those actual Repos. Tembo.io helps with this name reasoning, which we will discuss later.
Maintaining consistency across these changes demands explicit contracts. If the backend Pull Request introduces a new response shape, the frontend PR must expect that shape. Async agents handle this by analyzing the changes holistically before generating code. The agent understands that a new field in the API response requires a corresponding update in the client's type definitions.
This is something we see often in our customers' usage, so much so that we created a docs page for it:
Title: Add pagination to GET /api/users endpoint
Requirements:
- Cursor-based pagination (not offset-based)
- Default 50 users, max 200 per request
- Backward compatible for existing clients
Response Format:
- Data array with user objects
- Pagination object with next_cursor, has_more, and total_count fields
Technical Details:
- Endpoint: routes/api/users.ts
- Utils: utils/pagination.ts
- Database: Add index on users.created_at
- Documentation: Update openapi.yml
Dependency management in distributed changes also introduces sequencing concerns. Some PRs must merge before others. The infrastructure change that provisions a new queue must land before the backend change that publishes to that queue. Async agents can flag these dependencies in PR descriptions, giving us clear merge ordering. We review the full set of changes, understand the relationships, and merge in the correct sequence.
Instead of managing four separate coding sessions across four repos, we manage one task that produces four coordinated PRs. Our review process examines the complete feature rather than disconnected fragments. We catch integration issues before they reach main branches because we see all the pieces together.
This model works best when we invest in clear repository boundaries and documented interfaces. Tembo does this via Rule files via tembo.md and AGENTS.md, we’ll discuss that further later on.
Choosing the Right Agent for the Task
Not every task requires the same model. Understanding the strengths of each option lets us match the tool to the work. Let’s explore a few!
Claude Code for Deep Reasoning
Claude Code defaults to claude-opus-4-5. This is where we send complex refactoring tasks, architectural migrations, and work that requires understanding subtle dependencies across a codebase.
Opus excels when the task involves ambiguity. If we need an agent to evaluate multiple implementation approaches and select the best one, Opus will reason through tradeoffs rather than grab the first solution. The cost is time and computing. Opus tasks take longer and consume more resources.
For faster iteration, claude-4-5-sonnet provides a strong balance of capability and speed. Sonnet handles most feature implementation work without the latency of Opus. When we need quick fixes or straightforward additions, claude-4-5-haiku delivers results in seconds rather than minutes.
Agent-Human Equivalency Matrix:
| Model | Human Equivalent |
|---|---|
claude-opus-4-5 | Staff Engineer / Software Architect |
claude-4-5-sonnet | Senior Full-Stack Developer |
claude-4-5-haiku | Junior Developer / Rapid Responder |
Codex for Structured Implementation
Codex runs on OpenAI's GPT-5 family, with gpt-5.2 as the default. The Codex agent performs well on tasks with clear specifications and a bounded scope. If we hand it a detailed ticket with acceptance criteria, it produces clean implementations that match the requirements.
The gpt-5.1-codex-max variant adds extended reasoning for more complex problems. This is useful when the task requires multiple steps of logic or when we want the agent to think through edge cases before writing code.
For high-volume, low-complexity work, gpt-5.1-codex-mini offers speed at reduced cost. Batch operations like updating import statements across dozens of files or applying consistent formatting changes benefit from the mini model's efficiency.
Agent-Human Equivalency Matrix:
| Model | Human Equivalent |
|---|---|
gpt-5.1-codex-max | Principal Engineer / Systems Thinker |
| Mid-to-Senior Level Developer |
gpt-5.1-codex-mini | Release Engineer / Scripting Specialist |
Cursor for Provider Flexibility
Cursor supports the broadest range of underlying models. Beyond Claude and GPT options, we can route tasks to gemini-3-pro, gemini-3-flash, composer-1, or grok.
This flexibility matters when we have specific model preferences or when we want to compare outputs across providers. Some teams find that certain models perform better on their particular codebase or coding style. Cursor lets us experiment without switching agent infrastructure.
Agent-Human Equivalency: The Jack of All Trades
Guardrails Through Rule Files
Async agents work without direct supervision. So how do we ensure the agent follows our conventions when we are not watching? Rule files. These are markdown documents in our repository root that provide persistent context to the agent before it begins any task.
The Purpose of tembo.md and AGENTS.md
Tembo looks for configuration files in a specific order: tembo.md, AGENTS.md, CLAUDE.md, .cursorrules, and several others. It uses the first file it finds. We only need one per repository.
The rule file becomes part of the agent's context for every task. When Tembo receives an issue assignment, it loads the rule file, includes the content in its working context, and follows the guidelines when generating code. This happens automatically. We define the rules once, and they apply to every pull request the agent creates.
Think of the rule file as onboarding documentation for an autonomous teammate. We explain how we build, how we test, and how we structure our code. The agent reads this before touching anything.
Defining Architectural Standards
A minimal rule file includes build commands, code style conventions, and project structure. Here is what that looks like in practice:
# Project Context
Express + TypeScript API with PostgreSQL database.
## Commands
- `npm install` - Install dependencies
- `npm run dev` - Start dev server on port 3000
- `npm test` - Run Jest test suite
- `npm run db:migrate` - Run pending migrations
## Code Style
- TypeScript strict mode, explicit return types on all functions
- Zod for request validation
- Conventional commits: `type(scope): message`
## API Conventions
- All endpoints return standard response shape with data, error, and pagination fields
- Cursor-based pagination using `utils/pagination.ts`
- Rate limiting via `middleware/rateLimit.ts`
## Structure
- `/src/routes` - API route handlers
- `/src/services` - Business logic
- `/src/utils` - Shared utilities
- `/tests` - Test files mirror src structure
## Guidelines & Safety
- **IMPORTANT**: All new endpoints must include OpenAPI annotations in `openapi.yml`
- **WARNING**: Never expose internal IDs in API responses. Use public UUIDs only.
Emphasis markers help flag critical rules. Using IMPORTANT or WARNING before a guideline signals that the agent should treat it as a hard constraint rather than a suggestion.
Scoping Agent Autonomy
Rule files let us control how much freedom the agent has. A sparse rule file gives the agent latitude to make decisions. A detailed rule file constrains it to specific patterns.
If we want the agent to always use a particular testing framework, we state that explicitly. If we want to avoid certain dependencies, we list them. The agent cannot read our minds. It can only follow what we write down.
Version Control for Agent Rules
The rule file lives in our repository. It goes through the same review process as any other code change. When our conventions evolve, we update the file and commit the change.
This creates an audit trail. We can see when rules changed and why. If an agent starts producing unexpected output, we check whether someone modified the rule file. If we onboard new team members, they can read the rule file to understand both human and agent expectations.
Tembo recommends reviewing rule files quarterly to remove deprecated guidelines and add new patterns as they emerge. Stale rules create confusion. Current rules create consistent output.
Deploying Asynchronous Agents into your Workflow
We can’t help you grow another arm, but we can definitely help you get your other menial tasks taken care of. Tembo is the tool to get your async agentic enterprise off the ground.
We covered a lot of ground. Async agents change how we work by letting us delegate complete tasks rather than babysit chat sessions. We explored how multi-repo coordination turns four separate coding sessions into one unified task with coordinated PRs. We broke down when to reach for Claude and when to reach for Codex or Cursor. We showed how rule files like tembo.md give us guardrails that enforce our standards without requiring us to watch over every keystroke.
Async agents multiply what we can accomplish.
Building this infrastructure from scratch takes months. Integrating with Linear, Sentry, GitHub, and Slack adds more months. Maintaining it pulls us away from the product work we should be doing.
Tembo handles all of this out of the box. We connect our repos, define our rules, and start delegating. The agents run in isolated environments, submit PRs we can review, and iterate based on our feedback.
Want to see it in action? Book a demo with us!