Does AI make nearshore developers obsolete?

AI lowers the value of low-context execution work and raises the value of engineers who can judge output and own production code. We put the research side by side and say what each source does and does not prove.

It is a fair question, and it comes up almost every month: if AI writes a growing share of the code, why would you still add developers from Kosovo to your team?

The honest answer is that the question is too blunt. Some work is losing value and some work is gaining value, and both live inside the same job title. Below I put the available research side by side, say what each source does and does not prove, and describe what that means for the choice between your own team, an integrated nearshore engineer, and a vendor that processes tickets. Where the research stops and our own analysis starts, I say so.

The short answer

For certain well-defined tasks, less capacity may be needed. First versions, boilerplate, test scaffolding, documentation and simple screens move faster than they did two years ago. Any team that uses the tools seriously notices this.

That is not the same as product teams disappearing. No research shows that organisations need a fixed percentage fewer developers. What exists are task-level measurements, surveys about usage and trust, usage data from model providers, and expectations reported by employers. Those four kinds of evidence measure different things, which is exactly why the debate feels so messy.

Our own conclusion, and this is a tre plus position rather than a research finding: the model of the cheapest possible remote hands is under pressure. The engineer who uses AI as a tool, can push back on its output and takes responsibility for production code is becoming more valuable.

What AI demonstrably changes already

The clearest shift happens inside tasks. Code generation, test scaffolding, documentation, first versions of an interface and repetitive conversion work have all become faster. That is not a sales claim: it is where developers reach for the tools most often themselves.

The Stack Overflow Developer Survey 2025 is the most useful gauge here, and it is survey research among respondents who sign up themselves. The picture it paints is a double one: adoption is high, trust in the output stays limited. Developers use the tools daily and still review, debug and rewrite what comes out. That reviewing is work a human has to be able to do, and it requires knowledge of the codebase.

The Anthropic Economic Index of 28 April 2025 looks from the other side: usage data from one provider about how its own models are being used. It shows that coding agents pick up many tasks on their own, and at the same time that feedback loops and human validation remain in place around them. Anthropic notes itself that the dataset only reflects usage of its own products and is therefore not a representative view of the market. It is also worth remembering that a model provider has an interest in the narrative that its products absorb a lot of work.

The distinction missing from most discussions: automating a task is not replacing a job. A developer who only converts tickets into code performs few tasks that resist automation. An engineer who pushes back on a product decision, plans a migration in stages, spots a security risk in a generated query and knows the maintenance history of four-year-old code is doing something else. Both are called developers. They are not replaceable in the same way.

Why the studies seem to contradict each other

Read three headlines about AI and productivity and you get three directions. Not because one of the researchers is wrong, but because they measure different things with different people.

DORA 2025: survey and field research

The DORA report State of AI-assisted Software Development 2025 is survey and field research among software teams. Its core message is that AI mostly amplifies what is already there. Teams with clear priorities, a healthy delivery flow and solid review and testing habits get more out of it. Teams with unclear priorities and a broken pipeline amplify their problems too: more output that nobody can properly assess. Tools alone do not produce a mature engineering organisation.

What it does not prove: that a specific team with a specific toolset gains a specific amount of speed. It is self-reported data at organisation level, not measured cycle time per ticket.

Stack Overflow 2025: survey with self-selection

The survey shows what developers do and how they feel about it. Its strength is scale, its weakness is self-selection: the people who fill it in are not automatically a cross-section of all developers. So use it for direction (broad usage, mixed trust), not as proof of return.

METR: an experiment with a small group

The METR productivity research is the most interesting piece of evidence, because it measures instead of asking. In the 2025 study, experienced open-source developers worked on tasks in their own codebase, and the striking result was a slowdown rather than a speed-up: participants believed they were faster than they were. In the update of 24 February 2026, newer measurements may point towards acceleration, but METR is cautious about them, because selection effects in who participates and which tasks are chosen can distort the outcome.

What this means for your team: it is an experiment with a small group in a specific situation, namely highly experienced people in code they already know inside out. That is the situation in which AI adds the least. In unfamiliar code or on routine work the picture can be different. Turning precise percentages from this research into staffing decisions is not defensible, and METR says as much itself.

World Economic Forum: employer expectations

The Future of Jobs Report 2025 surveys employers about what they expect. In it, AI and machine learning, big data and software development appear simultaneously among the roles and skills employers expect to grow fastest. That is useful as a signal about where companies think they will invest, and it is explicitly not a proven future outcome. Employer expectations have been wrong before.

Eurostat: official statistics

Eurostat publishes figures on ICT specialists and hard-to-fill vacancies. Two things matter there: a substantial share of the enterprises that recruited ICT specialists had difficulty filling those vacancies, and a share of enterprises has ICT functions performed by external suppliers.

That second point is where summaries usually go wrong. External suppliers performing ICT functions does not mean those companies outsourced their entire IT department. It can be a single function, the maintenance of one system, or a temporary assignment. The statistic says something about the habit of using external capacity, not about how much of the organisation that covers.

What explains the differences

Line the sources up and five factors decide the outcome: the type of task (new and well-defined versus old and entangled), the experience of the developer, the state of the codebase, the team process around review and testing, and the measurement method itself. A study set up differently on any one of those five arrives at a different conclusion. That is not a contradiction, that is the subject.

Which nearshore model is under pressure

From here on this is tre plus analysis, based on what we see in client teams rather than on research.

The model heading for trouble is the model that was always fragile, except now it shows faster. Its markers: price is the main argument, work arrives as isolated tickets, several handovers sit between the question and the code, the developer does not know the product, quality control happens on the client side, and there is no long-term ownership because people rotate.

In that setup, the developer's contribution is exactly the part AI absorbs first: executing specified work without context. If your own team can finish a ticket with AI in an hour, a cheap pair of hands that takes two days and sends back three questions is no longer a saving. Add the review and rework on your side and the arithmetic tips over completely.

Which nearshore model can get stronger

This is our analysis too. The setup we believe is getting stronger looks different: engineers work in the same sprint, the same backlog, the same tooling and the same code review as the in-house team. They know the domain, they sit in the conversation where the decision is made, and they are still there next year.

In that setup AI is the engineer's tool. It speeds up the writing, it does not take over the judging. Anyone who has to be able to reject a generated solution needs product knowledge, production experience and the freedom to say no. That is the opposite of a vendor paid per delivered ticket.

It also matches what DORA says about amplification: when a team is in good shape, AI returns more. So the order is not cheap capacity first and quality later, but a healthy team and process first, then capacity that fits into it. What that looks like in practice is on dedicated developers and nearshore developers.

Why proximity still matters, especially with AI

This is the part most often overlooked. AI makes the outcome of work less predictable rather than more predictable. A generated solution can look right and still carry the wrong assumption. You will not catch that in a specification. You catch it in a conversation and in review.

Unpredictable work needs short feedback lines: asking a question before someone spends half a day going the wrong way, looking at a pull request together, explaining a choice to the person who knows the domain. A shared European working day makes that practical. Kosovo has no time difference with the Netherlands and Belgium, so a question raised in the morning stand-up is answered the same morning.

That is a practical argument, not a productivity claim. I am not going to attach a percentage to it, because I cannot substantiate one. What I do see: the more AI output needs verifying, the more the ability to talk it through matters. The location question itself, nearshore versus offshore, is covered in nearshore versus offshore development.

Which setup fits which situation

The matrix below is a tre plus position, meant as a thinking aid. It is not a research finding and not a promise about results.

That last row is deliberately blunt. We provide capacity inside your team, not an outsourced project with a guaranteed result. If you need the latter, we are the wrong partner, and it is better to know that up front than three months in.

How do you recognise an AI-native nearshore engineer?

In interviews I see two traps. The first is judging on frameworks: someone knows the right words and the codebase still turns out to be too much. The second is new: judging on prompting skill. Working smoothly with an assistant is a knack, not a profession.

What we look at ourselves, and this is our way of working rather than a standard from research:

Understanding the problem

Does someone ask why a thing should be built before moving to how. Can they propose a simpler alternative than the one requested.

Production experience

Has someone maintained code that was live, with users complaining and logging that wakes you up at night. That changes how a person looks at a generated solution.

Review and tests

Can someone assess another person's pull request properly, and write a test that actually fails on the problem it is meant to catch.

Security and data handling

Does someone see the difference between a query that works and a query that returns too much. Do they know which data does not belong in an external tool.

Error handling and documentation

What happens when the integration goes down, and can someone write a decision down so a colleague understands it a year later.

Being able to argue with AI output

The strongest signal: can someone explain why they threw a suggested solution away. Anyone who never does that is not reviewing.

Does AI change the cost calculation?

Yes, but not in the way most calculations suggest. Fewer lines of code written or fewer hours of typing does not automatically mean lower total product cost. A large part of the cost sits in maintenance, in onboarding new people, in defects found late and in work that has to be done twice.

What we think you should weigh instead: how quickly something valuable is live, the quality of what gets delivered, how maintainable the result stays, whether the same people are still around next year, and how much product knowledge remains inside your team. A cheap solution that has to be re-explained every quarter is not a cheap solution.

I am not going to produce new calculations here, because that would suggest a precision that does not exist. For the build-up of what a developer actually costs an employer, see what a developer really costs per month.

When nearshore is not a good choice

There are situations in which I would advise against adding capacity now, however strong the candidate is.

If nobody on your side can make technical decisions, even a strong engineer ends up waiting for answers. If the work is a few weeks with a clear end, that is an assignment and not a role. If the search is only about the lowest rate, you end up in exactly the model we believe is under pressure.

If you work with sensitive data without agreements about access, storage and which data may go into external tools, that is the first thing to sort out. And if the expectation is that one AI developer will solve every product problem, that expectation will not be met, by anyone.

Conclusion

The question is not whether AI makes developers obsolete. The question is which kind of development work still adds value next to an assistant that can write code.

Our answer, as a position: do not buy more developers, add the right engineers to a team that can actually use AI well. Nearshore has a future where proximity, context, ownership and AI skill come together. Where those four are missing, the model was already fragile before AI existed.

If you want to know which role fits your situation, start at hire AI engineers and developers. If the conversation is mainly about capacity inside an existing product team, nearshore developers is the better entry point.

Six questions we get often

Does AI mean fewer software developers are needed?

Certain well-defined tasks take less time, which can lower the capacity needed for that work. There is no percentage that holds for every organisation, and none of the sources in this article offers one. According to the Future of Jobs Report 2025, employers expect demand for AI, data and software skills to grow, and that is an expectation rather than a measured outcome.

Will AI replace nearshore development?

Our analysis: AI does not replace collaboration, judgement and ownership. What is under pressure is the model of cheap execution capacity without product context. Anyone using nearshore that way should take that seriously.

What is a nearshore AI engineer?

An engineer who works inside your team from a country in the same working day, and who uses AI tools as part of the craft: a faster first version, then reviewing, testing and correcting it themselves. It is not a separate job title with us, it is a requirement about how the work is done.

When do you need an AI Automation and Data Engineer?

When the bottleneck is not in your product but between your systems: integrations, dataflows, reporting and work that happens by hand every week. That is different work from building features. See AI automation and data engineers.

Why does timezone overlap still matter?

Because AI output has to be verified and verification takes conversation. A question answered the same morning prevents half a day spent in the wrong direction. That is a practical advantage, not a measurable productivity gain I am going to promise here.

Is nearshore with AI automatically cheaper?

No. Fewer hours of typing is not the same as lower total cost. Maintenance, onboarding, rework and continuity account for most of the bill. So compare time-to-value and maintainability, not just the monthly rate.