In 2013, I worked at FCamara and was part of a group called the Critical Operations Team. From time to time we’d meet in a way that broke from the usual routine. No meeting room, no slides, no rigid agenda. It was more of an informal gathering, something like a scrum with pizza.

We’d go to a pizza place, eat, talk about day to day work, and somewhere in between there’d be these improvised talks. Nothing formal, just someone sharing experience while everyone ate.

One of those times, the one talking was Fábio Câmara.

He told us about his path, how he built his consulting practice, the decisions he made along the way, and how that ended up putting him in a position far above average. But what stayed with me wasn’t the technical part or the projects. It was one sentence.

He said that at that point in his life he already had enough wealth. Then he added that if everything were taken from him, money, assets, position, he knew he could build it all again.

It wasn’t empty optimism. It was real conviction, because he actually knew how to get rich again. And that didn’t come from luck or a single lucky break. It came from understanding the mechanisms behind value, understanding how the game works underneath.

He didn’t follow the path everyone else followed. He had developed his own way of looking at opportunity and making decisions.

One of the examples he gave makes this clear. There was a time when one programming language dominated the market. Almost everyone bet on it. It was the obvious path, the one that seemed safest.

At the same time, another technology was emerging. Less popular, less obvious, with few people betting on it. Most people ignored it.

He chose to look at that second option. While most followed the herd, he spent time on something that wasn’t consensus yet. Over time that became an advantage. Few people had that skill, so demand went up and supply stayed low. He positioned himself early and landed projects worth far above average, simply because he had a rare skill at that moment.

The language itself mattered less. What I keep thinking about is his pattern of decision: see it first, learn it first, act on it first.

Today it’s impossible not to draw the parallel with artificial intelligence.

There’s a strong narrative saying AI will replace most technical roles. And that’s partly true if you look at isolated, repetitive tasks. AI already automates a lot, and it will automate more.

The problem is when companies and people treat that as a total replacement of the human factor. In the name of efficiency and cost cutting, a lot of people remove humans from the loop without thinking through the trade-offs. We’re already seeing this play out in large companies: aggressive cuts, strategy repositioning, then adjustments once they realize efficiency without judgment doesn’t hold up a complex system for long.

AI is a powerful tool, but it’s still just that, a tool. It produces output, suggests paths, automates pieces of the work. But someone still has to decide if that output makes sense, understand the context, and take responsibility for the system working or failing.

There’s something in this that keeps bothering me.

Even inside the companies at the front of artificial intelligence, like OpenAI or Anthropic, there’s still massive demand for software engineers. Not because AI hasn’t evolved, but because it changed the type of problem, it didn’t eliminate the problem. The work didn’t disappear, it shifted.

If in some cases AI helps write code, in others it increases the need for infrastructure, integration, security, validation, reliability. And all of that is still software engineering. Underneath it all, what holds everything together is still the human capacity to build, interpret, and decide.

This is where the idea of diligence starts to make practical sense.

Diligence in software engineering isn’t just about writing clean code. That’s a small part of it. Diligence is noticing what’s being built and what the consequences of that are over time. It’s not treating technology as a trend, but as a decision with trade-offs. It’s knowing when it’s worth following what everyone else is doing and when it’s worth looking at the less obvious path. It’s reading the context before rushing to a solution.

When I think about Fábio’s story alongside the current moment with AI, I keep coming back to the same question. Is the advantage in following the dominant flow faster than everyone else? Anyone can do that. Or is it in something much harder to measure, which is seeing where the flow is about to change before it changes?

And that doesn’t come from luck. It comes from constant attention, continuous study, and mostly from a kind of discipline that doesn’t show up in any immediate metric.

In the end, technology always changes. Tools go obsolete, languages come in and out of fashion, architectures evolve. But the ability to understand the system, choose well where to invest time, and execute with consistency keeps being the difference.

I keep wondering if what holds up best over time isn’t about being right all the time, but about being ready to rebuild whatever’s needed when the scenario changes.