A PM I work with asked me a question last year that I hadn’t been able to shake.
“If AI can do what your developers do — why would we still use you?”
Honest answer: I’d been asking myself the same thing. I run an engineering team in Ho Chi Minh City. And over the past year, I’ve had more than a few moments where I thought — I could probably build this myself with Cursor in an afternoon. The tool I use every day was starting to compete with the team I built.
I avoided the question for a while. Here’s where I landed after more than a year of sitting with it:
The old version of offshore development is ending. But what’s dying isn’t offshore — it’s a pitch. One that companies like ours have been making for years. And once that pitch stopped working, everything about how we operate had to change.
The Work AI Is Already Taking Over
Let me start with the uncomfortable part.
The work that used to be the main reason clients hired offshore teams? AI is handling it now. Landing page builds. CRUD-heavy admin dashboards. Feature additions from a well-defined spec. Quick technical spikes to test an idea.
Two years ago, this was the core pitch: lower unit cost than domestic engineers, with speed. That argument made sense then. It doesn’t anymore.
Today, Claude, Cursor, and v0 can turn out a working prototype of this kind of work overnight. I’ve heard from several executives — people in their 50s who would never describe themselves as “technical” — who’ve started saying: “Maybe I’ll just try building it myself.” I’ve heard that more than once in the past six months.
So the feeling that AI ends offshore isn’t wrong. It’s just that it only describes what ends for the old version of offshore. The mistake is treating the two as the same thing.
The Competitor Changed. It’s Not Another Country Anymore.
Not long ago, competition in the offshore world was simple. Vietnam vs. India vs. the Philippines. Who’s cheaper. Who delivers faster. Who can hold quality at scale. That was the game.
At some point, I looked up and the actual competition had changed. The question forming in every buyer’s mind isn’t “which country?” anymore. It’s: “Can’t we just use AI for this?”
That’s the new first hurdle. You’re not being compared to another firm. You’re being compared to an answer that’s already forming in the client’s head before the first meeting.
And here’s what I had to say honestly, about Linnoedge too: when AI became the competitor, the pitch “we develop at lower cost” became false. We’d been making that pitch. We believed it. But there’s no meaningful sense in which human labor is cheaper than AI. Or faster. That entire arena has closed.
So what do you compete on instead? That’s what the rest of this is about.
Three Things I’ve Become Certain Of
Working with our team in Ho Chi Minh City every day — and watching what happens when AI enters the workflow — a few things have become clear over the past year.
First: the era of the hero engineer is ending.
Having one brilliant engineer who can rescue a project — that sounds like a competitive advantage. I’ve always been uncomfortable with it. When I talk to the team, I put it this way: if the project needs one person to save it, that’s a sign the system is still fragile.
This isn’t anti-people. It’s the opposite. Putting one engineer in a position where everything depends on them isn’t good for them or the team. I care about the people I work with — which is exactly why I don’t want to build a structure that depends on any one of them. For me, those two things don’t conflict.
AI is accelerating the breakdown of hero-dependency. Individual technical skills are getting less scarce, fast. The shift from “people as the weapon” to “systems as the weapon” — that’s probably moved ten years in the last two.
Second: what “strong” means for an engineer has changed.
I tell our engineers: a few years ago, “strong” meant understanding a spec and writing code quickly. That’s not the definition anymore. AI writes code. What remains for humans is the ability to understand the real problem behind the spec — and the judgment to take AI’s 60-point output and raise it to something you’d actually ship.
Here’s a case from our own work. We reviewed AI-generated initial code on a project and found a React component at over 1,000 lines — UI logic and state management completely tangled together. Visually, it worked. But adding one feature meant asking “where does this go?” every single time. Cleaning it up took longer than the original build. AI builds fast. It doesn’t automatically build in a way that’s easy to change later. Choosing the architecture that survives contact with the future — that’s what “strong” looks like now.
Third: speed is no longer the differentiator. Consistency is.
With AI, most teams can move fast. So speed is table stakes now. The question becomes: do you have a system that produces the same quality regardless of who’s doing the work? Depending on individual effort and motivation doesn’t scale. A team that gets it right every time beats a team that moves fast once.
So What’s Left?
Starting from those three things, the territory that remains becomes clearer. AI can build a prototype. It can’t yet take code to production-ready quality on its own — handling design decisions, extensibility, security, and operational reliability together. And it can’t yet build the ongoing structure that feeds into the next development cycle. That’s the ground that’s left.
I’ll be honest: we don’t have this fully figured out. What I can describe is what we keep returning to in our own work.
Design the architecture before you bring in AI. AI works well when it has context. Choosing the structure, setting up the documentation, defining the types — those decisions are made by humans, and they determine whether AI does useful work or generates plausible noise. Giving AI context is increasingly the job.
Give AI distinct roles. When you try to use one AI for everything, things blur. Planner. Generator. Evaluator. Separating those roles is what stabilizes quality. Think of it less as one AI doing everything, and more like a small team with clear accountability.
Decide where humans are accountable — explicitly. “AI built it, so it must be fine” is how you end up in production incidents. The design decision of where human judgment happens — that’s the most important thing to define clearly from the start.
Since we shifted to this framing, AI has stopped feeling like a competitor. It feels like part of the team.
One Thing You Can Do Tomorrow
Here’s something concrete, if you want a place to start.
Take your development process and mark it in two colors: “AI handles this” and “humans are accountable here.” Architecture final calls. Security risk assessment. Production release decisions. Even just writing that list out tells you something — where you can automate, and where you genuinely can’t.
You can do this today. Without hiring anyone, without changing your stack. And it changes how you work with AI more than almost anything else I’ve tried.
Q1: Is offshore development actually over now that AI exists?
The old version of offshore — competing on unit cost for straightforward implementation work — is ending. AI does that faster and cheaper than human labor. What remains is the work AI can’t yet do reliably: designing architecture that AI can work inside, raising generated code to production quality, and building the operational structure that keeps things running long-term. Those three things aren’t AI-replaceable today. That’s where offshore teams that want to survive are rebuilding themselves.
Q2: How do you draw the line between what AI handles and what humans own?
The rough split: if speed matters more than long-term quality, let AI lead. If it needs to keep running in production, humans make the final call. Prototypes, proof-of-concept work, technical spikes — AI is well-suited. Architecture decisions, security risk assessment, production release go/no-go — those stay with humans. “AI built it, so it must be fine” is how production incidents happen. The line isn’t always clean, but drawing it explicitly is the starting point.
Q3: Where do you start if you want to build an AI-native development team?
Start by giving AI something to work with: specs, coding standards, type definitions. AI with context does useful work. AI without context produces a lot of plausible-looking noise. Next, separate the roles: who plans, who generates, who evaluates. When those blur, quality doesn’t stabilize. The simplest first step is to take your current development process and mark it — what can AI own, what needs a human decision. That one piece of paper changes how you work with AI more than any tool selection.
Let’s Talk — 30 Minutes
If this resonates, I’m happy to think through what it might look like for your team. No comparison decks. No sales pitch. Just an honest conversation about what your development process actually needs right now.
Book 30 minutes →Is Your Team Fighting AI, or Using It?
Back to where we started. My answer to “Is offshore development over?”
The old version is ending. But the rebuild — turning an offshore team into a development organization that actually knows how to use AI — is just beginning. The value has shifted. Not cheap labor. The ability to design for AI, and build the operational structure that makes it consistent.
I want to ask you something. Is your team currently fighting AI — trying to stay ahead of what it can do? Or has it already brought AI into how the work actually gets done?
If you’re still in the first camp, I’d be happy to compare notes. I don’t have all the answers. But I’ve been sitting with this question for over a year without looking away — and there might be something useful in talking it through together.
Shogo Harada原田 祥吾
CEO · Linnoedge Inc. · LinkedIn↗
Operating IT offshore development and overseas expansion support businesses across two bases: Tokyo and Vietnam. A leader who believes in “Systems over Spirit,” structuring cross-border businesses that often tend to be opaque. Committed to providing “reproducible quality” to organizations and clients rather than relying solely on individual skills.