My take on AI: notes from a paradigm shift

My take on AI: notes from a paradigm shift

---

When I say AI in this post, I mean the current wave: LLMs, agents, code assistants.

What I see

We’re in a paradigm shift. It’s a shift in how we work, how we execute, and how we think about what technology can do for us.

And yet, I see a lot of people resisting. Programmers with years in this, experienced people, capable people, working the same way they did five years ago, as if nothing had moved. Or worse: convinced it’s just the new shiny toy everyone’s talking about, and that it’ll fade away if they just wait long enough.

It won’t.

The excuses are interchangeable

The reasons I hear change, but the message underneath is always the same.

• That it’s expensive.
• That the quality is bad.
• That by hand turns out better.
• That they don’t want to talk to a machine.
• That you still have to review the code it generates.
• That it gets things wrong.
• That it’s not “real engineering.”

All these phrases say the same thing when you add them up: I’m not going to use it. And the justification gets built afterward, not before. First comes the emotional decision not to engage. The technical reasons show up later to patch the gap.

The funny part is that the same programmer who dismisses AI because “you have to review the code it generates” doesn’t apply that same standard to the code they write by hand. Code written by humans also has bugs and also needs review. The standard only gets raised when it’s convenient.

It’s not a technical opinion, it’s fear

When you scratch the surface a little, things change.

It’s fear that the time invested will lose its weight. Ten, fifteen, twenty years learning a craft, and suddenly someone with less experience can deliver similar results in less time using tools that didn’t exist last year. That hurts. That destabilizes identity.

It’s fear of uncertainty. Nobody knows exactly what work will look like in five years, and the human mind hates not having a map. It’s easier to plant your foot and say “this won’t reach me” than to accept that you don’t know what’s coming.

And to cover all that, moral superiority shows up. “I write real code.” “I understand what I’m doing.” “I don’t need a machine to help me think.” It would sound good if it were a conscious choice between two valid paths. But it isn’t. It’s defense.

The bigger problem is that they got obsessed with the how (with the ritual of writing each line) and lost sight of the what. The goal has always been to solve problems and build things that serve a purpose. The way to do it has changed several times throughout the history of software, and today nobody wants to go back to doing it that way.

But not all resistance is fear

Some of it is a fair reaction to the over-promising from the sales side.

Every so often you get overstated headlines: Anthropic’s CEO saying software engineering will disappear, Nvidia’s CEO saying nobody will need to program anymore, announcements that AGI (artificial general intelligence, on par with humans) is just around the corner. And meanwhile, you sit down to actually use the tool and find it’s down, or takes five minutes to respond, or doesn’t quite finish what you asked. As with anything, nothing is perfect. But there’s plenty of good in it worth taking advantage of.

They’re probably right in part. Engineering as we knew it ten years ago is going to change a lot. But the absolutist packaging ends up doing the opposite: the person on the other side hears it, gets offended, and closes off. The marketing noise pushes people even further to the other side.

And that’s exactly why what ends up making the difference is human experience working alongside the tool. AI without judgment doesn’t get anywhere good. The human is still the most important part of the process.

It’s fair to name all of that. But it’s also fair not to use the over-promise or the product’s hiccups as an excuse to ignore what is actually changing. One thing is keynote talk, another is what’s already happened in how we work.

Programming is not software engineering

There’s a confusion we’ve been dragging around for decades: programming and doing software engineering are not the same thing. They’re very close, almost stuck together, and that’s why they’re easy to confuse. But they’re different.

Programming is the act of writing the code that solves an already-defined problem. It’s the “how.” It’s execution.

Software engineering is everything else:

• Understanding the problem before writing anything.
• Designing the solution and evaluating the trade-offs.
• Deciding what to build and what not to.
• Designing the product to be configurable, not locked to a single client or case.
• Understanding how each client uses it and what real value it delivers.
• Picking the right database for the case.
• Thinking about how the system will scale without falling over.
• Covering security from day one.
• Having metrics and traceability to know what’s going on.
• Sustaining uptime and supporting the system when something breaks.
• Integrating it with the rest of the ecosystem.
• Making sure all of that delivers value to the business that sustains it.

It’s the “what” and the “why.” It’s not just AI-assisted coding. It’s covering all of that, day in and day out.

AI eats programming much faster than it eats engineering. Whoever reduces their identity to the act of writing code is going to feel the threat hard, and they’re right to feel it. Whoever sees themselves as solving problems and designing systems sees a tool that multiplies what they were already doing.

Confusing the two things explains a good chunk of the panic.

The industry has always been like this

Anyone who’s been in this long enough knows one thing: every so often, everything changes.

• When Linux arrived: Microsoft spent years trying to discredit it (until Satya Nadella came along and integrated it), Tanenbaum (author of MINIX, the system that had inspired Linus) said it was born obsolete, and along the way it normalized something that wouldn’t be accepted as obvious for decades: teams distributed across the world working together.
• When Bitcoin arrived, banks and payment gateways did exactly the same thing.
• When the cloud arrived, suddenly you could scale your services thousands of times, and there were people saying it wasn’t “real engineering.”
• When Android arrived and ended up in everything, even fridges.
• When high-level languages appeared and people said you weren’t a real programmer unless you wrote in assembly.
• When containers showed up and nobody was sure if they were engineering or just packaging.
• When GitHub turned code into a public square.
• When the internet arrived and suddenly everything was connected.
• When the browser arrived and the web stopped being for a select few.
• When the iPhone arrived and the phone became a computer.
• When the tablet arrived and people said the PC as we knew it was no longer needed.
• When git arrived and changed how we work as a team.
• When Google and Stack Overflow showed up and people said copying algorithms from there meant you weren’t a real programmer.
• When frameworks arrived and people said using them didn’t make you a real programmer either, that you had to build everything from scratch. Symfony in PHP, Django in Python.
• When IDEs (integrated development environments) with autocomplete arrived and did almost everything for you, same story again.
• And a few more I’m surely forgetting.

Some had more impact than others, sure. But change was always there, it’s part of the nature of this industry.

Every time there were people who planted their feet and said “this won’t go far,” and every time those people ended up on the wrong side of history.

I got it wrong myself. When React arrived, I was one of those who thought it wouldn’t work. Luckily I sat down to learn, to understand why so many people were excited, and I ended up on the other side. That’s what matters: not who got it right at the start, but who was willing to adapt.

It’s a race of changes from start to finish. In university they used to tell us: “if you want to keep studying your whole life, know that’s exactly what you’re going to do in this career.” How true that turned out to be. But it’s a race for the one who loves to build, who wants to do big things and go further every time. (That ambition sometimes draws pushback, fortunately not from everyone, but that’s another story.)

Unlearning and relearning every so often is a must. It’s not optional. It’s the real skill of the craft, not the language of the moment or the framework of the day. Whoever understood that early moves light. Whoever thinks they’ve already learned enough gets left behind.

And here comes something more uncomfortable: stability and the lack of hunger kill ambition. When you’ve already reached a comfortable position, a decent salary, a role you respect, it’s easy to convince yourself that you’re done, that you’ve already done your part, that it’s the younger ones’ turn now. It’s exactly the opposite. It’s precisely when you have the context, the scars, and the perspective to build big things that you decide to just watch.

It’s time to build

What we have available today was science fiction five years ago. Things that a team of ten people used to take months to ship can now be put together by one person in an afternoon. That’s not a threat. That’s an invitation.

The difference between the one who moves forward and the one who stays still comes down to a few concrete things:

Vision. Knowing how to do things isn’t enough, you have to look further. Think about how an entire company works end to end, how processes get improved, how operations become more effective, how sales grow, how a business gets scaled, among many other things. Vision is what leads you to question why something is done the way it is, and to propose another way.

Humility. Accepting that you’re wrong every day. Really, not as a performance to seem humble. Accepting that there are things you don’t know you don’t know, and that other people are probably seeing them. Humility isn’t saying “I’m not capable”, it’s being willing to learn from scratch something you thought you already mastered.

Introspection. Stopping for a moment and asking yourself which of the things you’re defending are really yours, and which are just habit or fear in disguise. It’s uncomfortable. That’s why almost nobody does it.

Ambition. Not staying at ten kilometers when you could do a hundred. Not to compete with anyone, but because you can. Because the tool is there, and leaving it out of pride is wasting it.

And the invitation goes beyond AI. It’s time to rethink everything we’ve been doing on autopilot and ask whether it still makes sense, or whether we kept doing it just because it had always been done that way. A few questions to start:

• Does it still make sense for a deploy (shipping a change to production) to take 30 minutes?
• Does it still make sense to do manual code reviews on every PR?
• Does it still make sense to run two-week sprints (fixed work cycles)?
• Does it still make sense to build a backoffice when you can spin up the flow with AI in an afternoon?
• Does it still make sense to keep running operations on Excel?
• Does it still make sense to spend three hours a day making a marketing video by hand?
• Does it still make sense to use the same sales cycle we’ve had for years?
• Does it still make sense to write meeting minutes by hand after every meeting?
• Does it still make sense to keep paying for all the tools we’ve accumulated without reviewing what they actually deliver today?

Underneath it all, it’s really one question: does everything we’ve been doing for years still make sense? That’s the invitation. To look at all of it again, rethink how we solve problems, bring the fun back, and make it dramatically better.

And there are also new problems to solve

At the same time, a whole universe of new problems opens up.

Some examples:

• Instant cross-border payments without friction.
• Capturing customers’ attention amid the noise of AI-generated content.
• Defending against advanced attacks that now leverage AI.
• Validating identity more robustly than before.
• Keeping systems stable with 10x the features and code we had before.
• Resolving bugs in a fraction of the time.
• Building unified knowledge bases across all the integrations a company runs.
• Handling the growing dependency on AI without losing autonomy.
• Moving from prospect to sale in a fraction of the time it used to take.

Like these, many others are still waiting to be solved. There’s plenty to do and build.

Closing thoughts

I’m not writing this to convince anyone. The only thing I suggest is to stop for a moment and ask honestly what’s underneath your own resistance, if there is any. Sometimes it’s good judgment. Sometimes it’s not.

I write from the perspective of someone who wants to build and doesn’t see a ceiling on what can be done. I could be wrong about something, and if someone shows me where, I’m listening. But being open to being wrong doesn’t stop me from sharing what I think.

This is my opinion on AI. If you’re reading this and something resonates, you were probably already seeing it.