A Wholly US-Owned Team, in the Same Day as the Work

For the last two decades, in the United States and Canada, the principal argument for hiring a team many time zones away was the rate. It is 2026, and artificial intelligence has wiped out that value proposition. A US-based developer and their agents can produce a day's volume of code edits, tests, pull requests, and bug fixes in a fraction of the time, and more accurately, while an offshore team would still be working out what needed to be done in the first place. What that far-away team cannot do is sit in your afternoon and be sure it heard the requirement: that the prompt was entered correctly, that anyone there understood the prompt, and that they can follow the model's reasoning through to the output.

The expensive part of a far-away team was never the typing. It was the wait, and the moment you were not sure the requirement had landed.

Distance shows up as calendar time

James Herbsleb and Audris Mockus measured this in two organizations and published it in 2003 as An Empirical Study of Speed and Communication in Globally-Distributed Software Development. A change that stayed at one site took about five days in one department and about seven in the other, counted from the first code change to the last. The same kind of change that crossed sites took 12.7 days and 18 days. About two and a half times as long. The distributed changes were not larger. They involved more people. More people means more handoffs, and each handoff waits on the other site's morning.

That matches the older observation they cite from Thomas Allen: once engineers' offices were about 30 meters apart, communication fell to about the level of people miles away. Software work is full of unplanned talk. Perry, Staudenmayer, and Votta, quoted in the same paper, found developers spending about 75 minutes a day in unplanned conversation. A team that shares a day can have that conversation. A team with no overlap turns it into a ticket that waits overnight.

J. Alberto Espinosa and Erran Carmel separated the clock from the miles in The Impact of Time Separation on Coordination in Global Software Teams. Distance is symmetric. Time is not. A few hours of difference can be absorbed by shifting the day so the overlap is real. A gap of ten or twelve hours leaves almost no hour when both sides are at work. Their coordination costs split into communication, clarification, delay, and rework. The last two grow as the overlap shrinks. A fuzzy sentence in a spec does not get repaired in the meeting. It gets repaired tomorrow, after someone has already built the wrong thing.

A question asked at 4 p.m. in Chicago arrives at the start of someone else's morning. The answer comes back after your next morning. Two short clarifications become two days. That was the historical tax on a large time-zone gap, before anyone argued about hourly rates.

Language is where the requirement slips

Daniela Damian and Didar Zowghi described requirements work, in a 2003 study of globally distributed negotiations, as a communication-heavy activity that now crosses culture, language, and time zones. Inadequate communication is part of the distance, not a side issue. The requirement is a conversation. If that conversation is in a language the other person uses carefully but does not live in, you can finish the call and still not know whether you agreed.

I have been on those calls. The engineers were capable. The code often was not the problem. The problem was leaving the meeting unsure that "we'll handle the edge case" meant the edge case I had described. American English was my language and the product's language. It was not always theirs. By the time the misunderstanding was obvious, the other office was closed, and the next repair waited on the clock Herbsleb measured.

A US product team does not always work in English. Plenty of teams work in Spanish, and some work in another language entirely. The rule is the same. The person accepting the work should be fluent in the language the team uses to decide things. Fluency is how you hear the hedge, the joke that was actually a constraint, and the sentence that sounded finished but was not.

The model is strong in many languages. The brief is still yours.

Anthropic publishes zero-shot Global-MMLU scores for Claude, with English as the reference at 100 percent. Spanish is at the top of the other languages they list, or tied for it. Brazilian Portuguese sits in that same band. On Haiku 5.5 the two tie at 98.1 percent. On the larger models Spanish runs from 99.0 to 99.8 percent and Brazilian Portuguese from 98.7 to 99.4. Anthropic says gaps of less than about one point are measurement noise, and that the model is capable in many languages they did not put in the table. Languages with fewer digital resources fall off. Yoruba on Haiku 5.5 is 87.0 percent.

So Spanish and Portuguese are a fair example of Claude at its strongest outside English. That is not the same as a shared understanding of your product. The model will answer in the language you name. It will not notice that your stakeholder used "soon" to mean this afternoon. The person who reviews the agent's diff has to be fluent in the language of that sentence. For most US companies that language is English. When it is not, hire for the language it is. Do not hire for a time zone and hope the model translates the intent.

What changes when the person is in your day

An agent removes the old volume argument. The drafting, the test boilerplate, the first pass at a migration, the search through an unfamiliar Rails app: that work no longer requires a second office in another night. A developer who shares your afternoon can point the agent at one behavior, read the diff, and ask you the question while you are still in the thread.

That developer is not paying the Herbsleb delay, because the change does not cross a site boundary to get a decision. They are not paying the Espinosa rework, because a wrong reading can be corrected before the other side of the planet wakes up. They are not guessing at the requirement in a second language. The geography and the language gap stop being the schedule.

The agent does not replace that person. It makes one fluent person in the right time zone unusually productive. The judgment about what the product owner meant stays with someone who heard it clearly.

When the work is a Rails app and the conversation has to happen in your day, Rails Agency does it from the United States. The company is wholly US-owned: Ones and Zeros Consulting LLC, in Sheridan, Wyoming.