RIVER Group has been a distributed team from the start. Our people work from Auckland, Wellington, Christchurch, and overseas. Building AI products across time zones is different from building traditional software remotely. The iteration cycles are faster, the feedback loops are tighter, and the coordination overhead is higher. Here is what we have learned about making it work.
Why AI Teams Are Different
Remote software development is well-understood. Established teams have been doing it effectively for over a decade. Remote AI development introduces complications that standard remote playbooks do not address.
Faster iteration cycles. AI development involves rapid experimentation: try a prompt, evaluate the output, adjust, try again. These cycles happen in minutes, not days. In a co-located team, two people can iterate on an AI system in real time. In a distributed team, asynchronous iteration on fast-cycle work creates lag that compounds.
Subjective quality assessment. Software correctness is largely objective: it works or it does not. AI quality is often subjective: is this summary good enough? Is this classification accurate enough? Calibrating quality standards across a distributed team requires deliberate effort that co-located teams achieve through osmosis.
Context-heavy work. AI development for enterprise clients requires deep domain context. The AI needs to understand the client's data, processes, terminology, and edge cases. Distributing that context across a remote team is harder than distributing technical specifications.
The Playbook
Synchronous Windows, Not Synchronous Days
We do not require everyone to be online at the same time all day. We require overlapping windows: specific hours when the team is available for real-time collaboration.
For our NZ-based team, the core window is 10am-2pm NZST. During this window, AI iteration sessions happen in real time: two or three people working on the same problem, sharing screens, evaluating outputs together.
Outside the window, work is asynchronous. Design work, documentation, code review, data preparation: tasks that do not require real-time collaboration fill the non-overlapping hours.
4 hours
daily synchronous overlap window for distributed AI development teams
The discipline is protecting the window. No administrative meetings during the overlap. No individual deep work. The window is for the work that requires multiple minds in real time.
Written Context, Always
The biggest failure mode in remote AI teams is context loss. Someone understands why the AI system behaves a certain way, but that understanding lives only in their head. When someone else encounters the same behaviour, they cannot explain it, debug it, or build on it.
Our rule: if you learned something about the AI system's behaviour, write it down. Not in a formal document. In a shared channel, a comment in the code, a note in the project board. The medium does not matter. The habit does.
Specifically, we document:
- Prompt decisions. Why this prompt structure and not another. What we tried. What failed. What succeeded and why.
- Quality calibration. Examples of outputs that are good enough and outputs that are not. With explanation of the boundary.
- Edge cases. Inputs that produce unexpected behaviour. With analysis of why and how we handle them.
- Client context. Domain-specific knowledge that affects how the AI should behave. Terminology, process variations, cultural factors.
Pair AI Sessions
The most effective pattern we have found for remote AI development is pair sessions: two people working on the same AI problem in real time, sharing a screen.
One person drives (writes prompts, configures the system, runs evaluations). The other observes, questions, suggests alternatives. They swap every 30-45 minutes.
This is not pair programming. It is pair evaluation. The value is not in typing efficiency. It is in quality calibration. When two people evaluate AI outputs together, they develop shared standards faster than any written guideline can achieve.
We schedule 2-3 pair sessions per day during the synchronous window. Each session is 60-90 minutes, focused on a specific problem.
Weekly Quality Calibration
Every Friday, the team reviews a sample of the week's AI outputs together. Not to find problems (though we do). To calibrate quality standards.
We take 5-10 real outputs from the week's work, present them without commentary, and each person scores them independently. Then we discuss the scores. Where scores diverge, we discuss why. The goal is not agreement on every output. It is shared understanding of what "good enough" means.
This ritual prevents the slow drift of quality standards that happens when individuals evaluate AI outputs in isolation. Over months, without calibration, one person's "good enough" can diverge significantly from another's.
The calibration sessions are the single most valuable meeting on our calendar. The discussion about why you scored this output a 7 and I scored it a 4 is where shared standards actually form.
Mak Khan
Chief AI Officer
Asynchronous Decision Records
AI development involves many small decisions with large downstream consequences. Which model for this task. What confidence threshold for human review. How to handle this edge case. How to structure this data pipeline.
In a co-located team, these decisions happen in conversations and are absorbed by the team through proximity. In a remote team, they disappear.
We maintain a simple decision log: what was decided, why, what alternatives were considered, and who made the decision. Not every micro-decision. The ones that affect how the system behaves in production.
The log is not bureaucracy. It is context preservation. When someone three months from now asks "why does the system handle this edge case this way?" the answer exists in the log, not in someone's memory.
What Does Not Work
Full asynchronous AI development. We tried it. AI iteration cycles are too fast and too subjective for fully asynchronous work. The lag between "I tried this" and "here's feedback" kills momentum and degrades quality.
Large team video calls for AI evaluation. More than three people evaluating AI outputs in a video call is unproductive. Two to three is ideal. The evaluations are too subjective for large-group consensus to work.
Relying on documentation alone for quality standards. Written quality guidelines are useful as references. They do not replace the shared understanding that develops through real-time evaluation and discussion. Both are necessary.
The Tools
We keep our tooling simple:
- Screen sharing for pair sessions (any video tool works)
- Shared project board for task tracking and decision logging
- Version-controlled prompt libraries for prompt management
- Shared evaluation sheets for quality calibration data
- Chat channels organized by project and by topic (not by function)
The tooling is less important than the practices. Any reasonable set of collaboration tools works if the team follows the practices consistently.
Remote AI teams work. Ours has delivered production AI systems for enterprise clients across multiple industries, all from distributed locations. The key is not better tools or more meetings. It is deliberate practices that address the specific challenges of AI work: fast iteration cycles, subjective quality, and context-heavy development. Protect the synchronous window, write the context down, pair on evaluation, and calibrate weekly. Everything else is detail.