A 90-Day Roadmap to Establishing AI Coding Agents in Thailand-Laos Development Teams

Does it end with "Trying out Claude Code was convenient," or does it progress to "the entire team can now use it at the same quality level"? This gap depends not on individual skill, but on the repository's rules, review standards, and CI setup. Development agents like Claude Code can produce results within days when used by a single individual. However, to align quality across a Thailand-Laos development team that mixes expatriate staff and local engineers, a design separate from individual usage is required—covering everything from CLAUDE.md preparation to review standards, handling language barriers, and setting outcome metrics. This article explains this entire design as a phased 90-day roadmap. The content is written so that offshore development managers and tech leads can read it as a procedure they can apply starting tomorrow.

An individual mastering an AI coding agent and aligning quality standards across an entire team are completely different challenges. In mixed Thailand-Laos teams, language, review culture, and development environments differ between expatriate staff and local engineers, and this gap tends to surface as a barrier to adoption. For example, even with the same review comment, if it is written assuming the reader can "read between the lines" of Japanese nuance, the intent may not reach local engineers, causing misalignment in decisions about whether to accept code generated by the AI agent. The next H3 section organizes the concrete shape of this difference and barrier.

The premises are completely different between an individual trying out Claude Code and a team adopting it. In individual use, an engineer installs Claude Code on their own machine, gives instructions suited to their own working style, and reviews the output themselves—end of story. It's enough for the rules to exist in their head; there's no need to share them with anyone.

In team adoption, on the other hand, it's necessary to establish a state where all members can operate with the same understanding of how instructions are written, the acceptance criteria for output, and how reviews are conducted. What's at stake is whether a rules file placed in the repository, such as CLAUDE.md, functions as a shared team asset, and whether the review checklist items and CI verification criteria remain consistent across members.

If a PoC proceeds while overlooking this difference, it's easy to fall into a situation where things move fast when expatriate staff use it, but quality becomes inconsistent once it's rolled out to the local team. Operations that depend on individual proficiency collapse as soon as member turnover or division of labor across sites occurs. From the earliest stage of adoption, aiming for something reproducible as a system rather than as individual skill is the premise underlying the entire 90-day roadmap.

When introducing this to development teams in Thailand and Laos, you commonly run into three barriers: language, review culture, and environmental differences.

The language barrier has the greatest impact. When CLAUDE.md and the system prompt are written only in English, there are reported cases where members whose native language is Thai or Japanese misread the intent, causing the AI to output an implementation that differs from the instruction. In fact, on teams where the language of review comments and instructions varies inconsistently, the same fix request can go back and forth three times without the intent getting across. Which language to standardize on for instructions and review comments needs to be decided as a design matter early in adoption.

The next largest is the review culture barrier. In settings with a strong tendency to follow instructions from superiors, there are cases where the AI's implementation gets treated as "an answer handed down from above" and gets merged without question. It's essential to explicitly state in the review standards the premise that an AI's proposal is a hypothesis subject to verification.

The environmental difference barrier is, compared to the previous two, not particularly difficult to address. If the Node.js version or local permission settings aren't aligned between the head office team in Bangkok and the site in Laos, the same instruction can produce different output and execution results. Simply identifying the differences in the development environment and pinning down versions resolves most of this.

Because these three barriers hinder adoption in combination rather than individually, the next chapter addresses them together as part of preparing the prerequisites.

There are teams that can start using an AI agent without hesitation from day one of adoption, and teams that continue to face review rejections from day one due to misinterpretation of instructions. What creates this gap is whether preparation was done in advance. Specifically, two things need to be put in place before adoption: explicit documentation of instructions via CLAUDE.md or AGENTS.md, and review standards that include merge conditions. Especially for teams like those in Thailand and Laos, where development sites and decision-makers are physically separated, you can't rely on verbal or chat-based supplementary explanations—so fixing these two points as documentation prevents misalignment down the line.

What you write—and what you don't write—in CLAUDE.md significantly affects how easy the operation becomes afterward.

Claude Code reads CLAUDE.md located directly under the repository root and works while grasping the intent behind coding conventions and directory structure. It's practical to limit the content to implicit knowledge that's hard to convey verbally—naming conventions, prohibited libraries, test execution commands, and whether Thai or Lao language comments are permitted. Conversely, writing in project background explanations or lengthy philosophies puts pressure on the context window and can cause the essential constraints to be skipped over.

In Thai and Lao development sites, there's a tendency for mismatches to occur between instructions written in English by expatriate staff and the implementation habits of local engineers. As a way to address this barrier, adding a single sentence explaining "why this rule is necessary" in CLAUDE.md increases local members' sense of understanding more than a mere list of prohibitions. For example, writing something like "Thai comments are acceptable, but function names and log output must be unified in English" together with the reasoning reduces the number of points raised during review.

AGENTS.md is suited for extracting shared instructions in teams that also use agents other than Claude Code. It's sufficient to start with a minimal set of rules and add to it as failures occur. Detailed setup procedures are also covered in the Claude Code Team Adoption Guide.

Making human review mandatory for changes involving external API integration or payment logic, while allowing minor fixes to pass with automated checks alone—whether or not this line is drawn in advance becomes the deciding factor for adoption. Introducing this without clarifying review standards tends to create the assumption that "code written by AI is highly trustworthy," which loosens verification and increases rework in later stages.

Turning merge conditions into a checklist prevents inconsistent judgment even among local teams. Unit tests passing, naming conventions matching the CLAUDE.md rules, and diff comments left on AI-generated sections—incorporating these into the Pull Request template prevents variation in standards among reviewers.

In Thai and Lao work sites, since concentrating reviewers among expatriate staff tends to create approval-wait bottlenecks, it's important to distribute review authority to local senior engineers as well. Documenting merge conditions explicitly means the criteria for adopting or rejecting AI proposals no longer depend on individual experience and become reproducible across the whole team. There's also the practical benefit of reducing review burden while suppressing variation in quality.

Narrowing the scope for the first 30 days and starting with tasks where the impact of failure is small is the fastest path to adoption. Rushing a company-wide rollout tends to invite pushback from the field, and this is especially true in Thai and Lao development teams, where wariness toward "a new tool handed down from above" is strong. It's ultimately faster to first try it on a small scale within a subset of teams and then expand the pattern that worked in later periods. The next section concretely outlines the criteria for selecting tasks during this period and how to proceed with setting up rules.

Many teams struggle to decide which tasks to assign to Claude Code during the first 30 days.

The selection criterion is "whether the specification is clear and the correct answer is close to unique." CRUD API implementation, adding UI components that follow existing patterns, generating unit tests, and maintaining README/API documentation all have little variation in specification and fall within the domain where AI coding agents excel. Conversely, implementations involving business logic decisions or feature additions where requirements are only shared verbally should be avoided. Entrusting tasks with ambiguous specifications to AI increases the number of points raised during review and can lead to an "it's not usable" evaluation on the ground.

Refactoring existing code is a case where judgment tends to be split. An effective approach is to entrust it to AI when tests are already in place, and to have a human write tests first when they aren't. For test generation itself, it's better to start with things where inputs and outputs are clear, like unit tests, rather than things that are heavily environment-dependent, like E2E tests, since this makes it easier to narrow down the cause when something fails.

Documentation generation also has significant value as a byproduct and, since its review burden is low, is well-suited as an initial task.

Whether documented failure records have more reproducibility than verbal instructions—this is what determines the outcome of the first 30 days.

There's a tendency to try to perfect the rules written in CLAUDE.md, but in practice, it works better to operate with it incomplete and add failures as they occur. This is because gaps and omissions in specifications often only become visible for the first time in the output when the AI coding agent is actually made to implement something, rather than through prior imagination.

Specifically, add to CLAUDE.md not just what was pointed out in review but also "why it was pointed out." Writing not just "the naming convention is wrong" but also "align it with the existing UserRepository pattern" makes it possible for Thai and Lao members to reproduce the same outcome the next time the same instruction is given. A practical approach is to accumulate failure logs in a separate file or Issue template and reflect them into CLAUDE.md at the end of the month. If they remain confined to an individual's chat history, knowledge transfer breaks off the moment the person in charge changes.

Deciding at this stage whether to unify the rule documentation in English or to include parallel Thai/Japanese annotations also reduces the amount of rewriting needed later during harness setup.

When there are only a few issues pointed out, documentation is sufficient, but when the same issues occur repeatedly, documentation alone cannot fully prevent them. By moving rules from human-readable documents to mechanical constraints such as Linters and CI, review burden is reduced while quality is stabilized. At this stage, the concept of harness engineering becomes central.

Rules written in CLAUDE.md have a weakness in that their enforcement can easily fluctuate depending on the reader's interpretation. Even if there is a statement like "follow the naming conventions," the extent to which an AI coding agent strictly adheres to it can vary from execution to execution. To narrow this gap, rules should be moved into pre-commit hooks and Linter configuration files, translating them into a mechanically enforced system.

Specifically, naming conventions, import order, and detection of unused variables are left to the Linter, and hooks are set up to automatically run formatters and tests before commits. In CI, static analysis and test coverage checks are run when a pull request is created, and changes that do not meet the criteria cannot be merged. This ensures that code generated by Claude Code and code written by humans are evaluated by the same standards, allowing reviewers to focus on design decisions and logical validity.

As an exception, it is worth considering relaxing some CI checks for prototype branches or commits that only involve documentation fixes. Imposing the same level of strictness on all changes tends to extend the lead time for small fixes, which can become a factor in team attrition. The key point of harness engineering lies in shifting the standards to be upheld from "writing" to "enforcing." Conducting a monthly review of rules and promoting only the frequently occurring issues to mechanical constraints helps keep operational burden in check.

When Thai speakers, Lao speakers, and Japanese speakers give instructions to an AI coding agent within the same repository, in which language should they write to ensure their intent is accurately conveyed?

The conclusion is that a two-layer structure tends to be manageable: unifying rule descriptions in CLAUDE.md and commit messages in English, while allowing supplementary verbal or chat instructions in the local members' native languages. Having a decision axis such as X for cases where specifications and constraints are centralized in English, and Y for cases where daily task requests and questions can be in the local language, can reduce both translation costs and the risk of misunderstanding at the same time.

There are reports that when instructions mixing Thai, Japanese, and English are passed directly into a prompt, the AI coding agent may misidentify the syntax's priority language, resulting in variable names or output formats that differ from what was intended. Since the accuracy of multilingual NLP varies by language, it is safer to clearly state important constraints (naming conventions, prohibitions, output formats) concisely in English, while supplementing background explanations and business context in the local language.

The same applies to review comments: preparing English templates for feedback on AI-generated code, and adding annotations in Japanese or Thai only where local members find it difficult to understand, can help minimize discrepancies in the interpretation of review standards. Maintaining a shared glossary document with aligned translations of frequently used technical terms is also one way to improve the reproducibility of instructions.

Decision axis: Whether the AI coding agent, which has been used as an individual's personal ingenuity, can be institutionalized as a team standard.

In Days 61–90, building on the rules and harness accumulated during Days 1–60, the focus shifts to demonstrating results through numbers. The main work involves visualizing effectiveness through KPIs such as the number of review issues and lead time, and transferring skills and hooks from individual assets to team assets.

When designing KPIs, the axis should be comparing trends from the early stage of introduction; setting absolute value targets tends to diverge from actual on-the-ground conditions. The basic approach to effectiveness measurement is to track "how things have changed compared to before the AI agent was introduced."

Number of review issues records the number of revision comments on code generated by the AI coding agent, per Pull Request. Issues tend to increase immediately after introduction, but it is desirable for this number to decrease as CLAUDE.md and review standards become established. If the increase continues, it may be worth suspecting that the rules themselves do not match the actual implementation patterns in the field.

Lead time is the time from task initiation to merge. Tasks with a narrower scope, such as boilerplate implementation or test code, tend to show a greater reduction effect, while tasks involving complex specification changes tend to be harder to shorten. Without measuring by task type, judging based on averages alone can lead to mistaken conclusions.

Rework rate is the proportion of cases where fixes were required after merging. If this remains persistently high, it may indicate that oversights are occurring during review, or that the constraints on the harness side are insufficient. These three metrics become useful material for judging AI ROI (AI return on investment) when viewed in combination rather than individually. Methods for continuously designing KPIs are also discussed in detail in How to Measure Effectiveness After Introducing an AI Agent.

The way individual members learn to use AI coding agents through trial and error is lost the moment that member leaves. If, at the 90-day mark, you still find situations where "you need to ask that person to know how to write the instructions," it's a sign that team asset-building has not yet been completed.

The targets for extracting as Agent Skills should be limited to recurring routine tasks. Examples include procedures for adding API endpoints in a specific framework, validation patterns for multilingual text including Thai and Lao, and naming conventions for test code. Know-how buried in individual prompt histories should be reformatted into a form that produces the same result no matter who invokes it.

Similarly, pre-commit hooks and CI integration hooks should be included in the repository and shared, rather than left as individual local environment settings. When local linter settings are manually installed on each person's PC, configurations tend to drift between locations, leading to situations where the types of errors detected differ between the Thailand office and the Laos office.

For Skills and Hooks that have been made into assets, reference links should be set up from CLAUDE.md, and updates should be reviewed through Pull Requests. The goal is to ensure that even when the person in charge is transferred or leaves, the next member can continue to use the AI agent at the same level of quality.

Even when teams follow the 90-day roadmap, why do some repeat the same failures? In many cases, they fail to advance tool adoption and rule development simultaneously, deprioritizing one or the other. Here, we address the failure of stopping at license distribution alone, and the failure of remaining limited to expatriate staff without spreading to local members, and present ways to avoid these pitfalls.

Decision criterion: Whether you stop at distributing licenses or go on to establish rules determines how well the practice takes root.

Immediately after distributing Claude Code licenses to the entire team, it may appear that adoption is spreading. However, if members are allowed to use it without CLAUDE.md or review criteria in place, the way instructions are written and how reviews are conducted will vary from person to person, making it easy for the quality of generated code to become inconsistent. When one person merges generated code as-is while another rewrites it line by line, it becomes difficult to measure AI ROI (AI return on investment) across the team as a whole.

The way to avoid this is to communicate the rules decided in Days 1–30 and the harness from Days 31–60 at the same time as tool distribution. Specifically, it is effective to prepare required items in CLAUDE.md, clearly document review criteria, and set up mechanical constraints through pre-commit hooks and CI before handing out licenses. If tool distribution and rule development are treated separately, rules added later tend not to take hold, since everyone's individual approach has already become fixed. The procedures for setting up CLAUDE.md, Skills, and Hooks introduced in Claude Code Team Adoption Guide serve as a concrete reference for putting this sequence into practice.

Even when Japanese expatriate staff have mastered Claude Code, there are cases where it fails to spread to local engineers whose primary languages are Thai or Lao. At first, it's easy to assume that "showing how to use it will naturally spread adoption," but in reality, if an atmosphere in which local members find it hard to ask questions, or resistance to English-centric documentation, is left unaddressed, the tool remains isolated as the personal skill of the expatriate staff.

The key to spreading adoption is creating a situation where local members can take on the reviewer role. Rather than having expatriate staff draft the initial version of CLAUDE.md and review criteria on their own, setting up an opportunity during Days 31–60 to review them together with local senior engineers makes it more likely that the rules will match on-site language and practical sensibilities. It's also effective to prepare instruction templates that can be written in Thai, Lao, or English.

If, by the time you measure performance indicators, it turns out that "only the expatriate staff are using it," team standardization ends up being merely superficial. Adding usage frequency per member and the number of rule revisions proposed by local engineers to the KPIs makes it possible to catch imbalances in adoption early. Operations in which Skills are cultivated under local members' leadership, as introduced in Claude Code Team Adoption Guide, can also serve as a useful reference.

Q1. What team size should Claude Code adoption start with? More important than size itself is whether you can narrow down the target tasks. A pattern that tends to take root well is trying it out with a small team of about 3–5 people on routine implementation and test code generation, solidifying CLAUDE.md and review criteria, and then rolling it out organization-wide. Even with larger headcounts, limiting the initial rollout to a subset of teams can reduce the burden of rule adjustment.

Q2. Does accuracy drop when instructions are given in Thai or Lao? If the structure of the instructions is ambiguous, accuracy drops regardless of language. In environments where Thai, Lao, and English are mixed, misunderstandings can be reduced by clearly documenting rules for variable names and commit messages in CLAUDE.md, and by writing instructions concisely with separated conditions. It is the state of documentation, rather than the language itself, that affects accuracy.

Q3. If results aren't achieved within 90 days, what should be reviewed? First, check whether the KPI settings match on-the-ground realities. When the number of review comments or the rework rate fails to improve, it is often because the scope of target tasks is too broad, or because review criteria have not been shared with local members. It can also be effective to go back to the Day 31–60 stage and adjust the harness or review criteria.

Q4. Can the same roadmap be used for teams without expatriate staff? Yes, it can. In fact, since local senior engineers take the lead from the outset, there is an advantage in that the tool is less likely to become isolated as an individual skill. The common thread is that CLAUDE.md development and building consensus on review criteria are led primarily by local members. For a more detailed approach, see Claude Code Team Adoption Guide — How to Standardize Development Workflows with CLAUDE.md, Skills, and Hooks.

Q5. At what stage should security and PDPA compliance be considered? It is advisable to consider these during the stage of aligning prerequisites before adoption. The handling of personal data contained in code or configuration information needs to be confirmed early on, also from the perspective of relevant laws such as Thailand's PDPA. A related practical checklist is organized in Compliance Checklist for Balancing Thailand's PDPA Compliance and AI Utilization.

What should you tackle first to establish AI coding agents within 90 days without losing your way? The answer lies not in scale, but in maintaining the right order.

In Days 1-30, narrow the target tasks to standard implementations and test code generation, growing your CLAUDE.md while logging failures. In Days 31-60, migrate those rules into Linters, pre-commit hooks, and CI, creating a state where instruction interpretation remains consistent even in environments where Thai, Lao, Japanese, and English are mixed. In Days 61-90, verify the effectiveness using KPIs such as the number of review comments, lead time, and rework rate, and share the accumulated skills and hooks as team assets.

Common pitfalls along the way include distributing tools without establishing rules, and cases where only expatriate staff use the tools without spreading adoption to local members. Both can be avoided by deciding upfront "who ultimately guarantees quality." Detailed roadmap steps and concrete examples of standardization can also be found in Claude Code Team Adoption Guide and What is Harness Engineering?. Building up steadily without skipping stages leads to adoption across the entire team.