This article was inspired by a recent post from Ignacio Solorzano, where he shared insights from interviews with developers across Latin America and the US.
👉 Original post: https://www.linkedin.com/posts/nachsolorzano_latam-developers-have-the-same-ai-tools-as-share-7426638406690115584-dU20
As a Brazilian, Ignacio’s post immediately resonated with me. Not because I think this is a “LATAM problem”, but because it reflects a pattern I’ve seen repeatedly throughout my career, particularly while working in Europe with nearshore and offshore engineering teams.
The geography changes. The dynamics often don’t.
When AI Changes How Value Is Demonstrated
In many parts of the world, becoming a software engineer is hard-earned.
It usually represents years of study, real personal investment, and deep technical expertise. That resonates with me from my own experience. Like many others, I started programming young, driven by curiosity, experimentation, and a sense of possibility.
When AI suddenly accelerates execution or abstracts away parts of the work, the reaction is revealing. As Ignacio captured in his post, it can feel like “cheating”.
Not because AI is inherently bad, but because it quietly changes the rules of how value has traditionally been demonstrated.
That reaction is human. It’s not resistance to progress. It’s uncertainty about where one’s value now sits.
What I’ve Seen Working in Europe
Most of my professional experience has been in Europe, often working with distributed teams and nearshore or offshore models.
Across different countries and cultures, I’ve worked with highly capable engineers whose scope was often limited to execution. The model made sense for a long time. Differentiation came from delivery capacity, predictability, and cost efficiency.
AI changes that equation.
Execution is being compressed everywhere. What used to be a clear advantage is now closer to table stakes. That doesn’t diminish the talent in these teams. If anything, it highlights how underutilised that talent has often been.
The Opportunity AI Creates
The real opportunity AI introduces is not faster coding. It’s broader ownership.
AI makes it possible for teams, especially those historically positioned around delivery, to:
- own problems end-to-end
- engage earlier in solution design
- experiment faster and more cheaply
- move from “implementation partner” to “outcome owner”
Deep technical and domain knowledge, which many of these teams already have, becomes a multiplier rather than something hidden behind execution-only roles.
This is where the conversation becomes genuinely exciting.
Why This Matters Beyond LATAM
Although Ignacio’s post uses LATAM as the lens, the implication is much broader.
Europe, and many regions that rely heavily on distributed engineering models, are at a crossroads. AI can be treated as:
- a productivity layer on top of existing structures
or
- a lever to rethink ownership, incentives, and trust
The first path delivers incremental gains.
The second unlocks entirely new forms of value creation.
The risk is not slow AI adoption. The risk is adopting AI without expanding the scope of what teams are allowed to own.
A Better Question to Ask
The most important question is no longer:
“Is AI-generated code real engineering?”
As Ignacio’s post hints, the better question is:
“What can we now own that we couldn’t before?”
Teams that ask this early will not just adopt AI more effectively. They will change how they are perceived and how much value they create.
A Question About the Next Generation
Martin Fowler recently wrote about the importance of preserving the joy and playfulness that drew many of us into programming in the first place. That resonates deeply with me.
But alongside that, AI also creates a structural opportunity: to expand who gets to own problems end-to-end. For teams that have historically been scoped to execution, that shift in ownership may be just as important as preserving the joy of the craft itself.
It also raises a bigger, unresolved question.
If AI fundamentally changes how software is built, where will the next generation of software engineers come from? Are we at risk of removing the curiosity and experimentation that pulled many of us, myself included, into programming as teenagers? Or will entirely new roles, skills, and entry points emerge, giving that curiosity somewhere new to land?
I don’t think this is the end of software engineering.
But I do think it’s the end of a particular version of it.
What replaces it, and who gets to shape that future, is still very much an open question.