Every nearshoring provider is talking about AI. Here is what we actually point it at — requirements, test coverage and code review — and why that is a deliberate choice rather than a modest one.
Every nearshoring provider is talking about AI at the moment, so rather than say it again, here is something more useful: what we actually point it at, and why.
In the work we do — legacy landscapes, integrations, regulated environments — writing code was never the slow part. The slow part is knowing what must not break. A model will write you an adapter in seconds. It will not know why a tariff from 2003 carries an exception that appears in no ticket, or which fields an undocumented interface silently expects, or that one report is wrong on purpose because finance asked for it that way in 2016. That knowledge sits with people who have spent time inside the system.
So we have a specialist whose job is not (only) to build AI products, but to make our engineers good at using it. He maintains a toolkit of agents and works with the teams on where they actually help. What is interesting is where that turned out to be.
Requirements first. An agent reads a draft specification and asks the questions a senior engineer would ask on day one instead of in week three: what happens in the empty case, which system owns this field, what is expected when the partner sends nothing at all. Cheap questions early instead of expensive ones later.
Then tests. Most systems we are asked to change have little or no test coverage — which is usually the reason nobody has changed them in years. Writing tests retroactively against existing behaviour is the least popular job in software, so it gets skipped. Agents are good at it, and they do not mind. Before we touch a billing engine we want tests describing what it currently does, including the parts nobody meant.
And review. A first automated pass catches the mechanical things — the missing null check, the swallowed exception, the block copied one time too many — so the human reviewer can spend their attention on the only question that really matters: is this change right for this system?
Look at that list again. Specification, testing, review. Those are the three things a team cuts first when a deadline gets close, and the three that decide whether software is still maintainable in five years. We point AI at them not because they are glamorous but because that is where it pays back twice — once in hours, and once in the defect that never happens.
The training matters more than the tooling. An agent in the hands of someone who cannot judge its output produces confident nonsense faster than a person ever could, so everyone learns to use these tools, not just the specialist. The skill we are building is not prompting. It is knowing when the answer is wrong.
We are not going to tell you we are an AI company. We are an engineering company that uses AI where it earns its place and says so plainly where it does not. If that is the kind of partner you were looking for, it is an easy conversation to have.
Every nearshoring provider is talking about AI. Here is what we actually point it at — requirements, test coverage and code review — and why that is a deliberate choice rather than a modest one.
We've moved into a house in the middle of Cluj-Napoca — 35+ desks, rooms to think in and rooms to argue in, and a garden that has already seen its first barbecue.
So what's next?
interested in exploring potential business opportunities with dotWhite? Use the button below to send us a message.
Or better yet, book a meeting with us in Calendly.