Finding yourself in the AI era ✨

A small personal compass to turn yourself from afraid to excited.

Hey, Luca here! This is a ✨ bonus free essay ✨ from Refactoring. Based on our schedule it should have been a paid one! But I really care about this topic so I decided to make it free for everyone.

If you like this piece, consider subscribing to the full version of Refactoring to get one every week. It matters a lot to me and it supports our work 🙏

---

Last week, going through my reading list, I happened to read these two blog posts on the same day:

• LLMs are not fun

• Web development is fun again

Both authors, Ori and Mattias, are seasoned engineers who have been in tech for ~20 years, but they have opposite feelings about LLMs.

This is not surprising. With AI forcefully getting into their lives, most engineers I know have developed strong feelings about it, and a big divide is happening right now:

• Some folks are finding excitement, hope, and empowerment.

• Others are experiencing anger, fear, or downright grief.

In other words, some find it easy to focus on the new possibilities opened up by AI, while others can’t help but mourn what AI is taking away from them.

Also, this is a largely separate conversation from the one about job anxiety, layoffs, and the future of tech. I know excited engineers who are afraid they might lose their job, and others who feel safe but are still sad about what their job might become.

So, let’s try to unpack this and figure out how we should think about AI, our jobs, and our identities.

---

🧩 Solving puzzles vs solving problems

Let’s take a quote from the “LLMs are not fun” article:

On the engineering side, using LLMs to write code is as fun as hiring a taskrabbit to solve my jigsaw puzzles.

This is a popular analogy — plenty of people compare engineering to solving puzzles. In fact, I believe many people enjoy coding for two reasons:

• It provides strong intellectual stimulation

• It’s a constrained domain where we can feel in control, as opposed to… people stuff!

The author of the article admits it himself 👇

[I got into programming so that] I could step away from tiring, ambiguous human interaction for a while

However, it’s time for the hard truth. We are not paid to solve puzzles. We are paid to solve problems.

You might think I am nitpicking, but words matter (I am a writer, forgive me):

• We solve puzzles for our own enjoyment. Puzzles have no purpose outside of the intellectual challenge they provide.

• We solve problems to help other people. And these people pay us in return. The fact that problems can also be interesting and puzzle-like is a byproduct of that, not the main point.

We are not paid to solve puzzles — unfortunately!

So I’ll venture into another analogy.

Let’s say you are a professional gardener, and you grow beautiful gardens for clients. A big part of why you love your job is that you can do daily, blissful walks throughout the gardens, to water the plants.

Watering the plants feels awesome. You don’t talk to anyone, you reflect on your life, and you even get decent exercise.

At some point, irrigation systems get invented. You feel bad about them, because you feel they take away your job. Except, watering plants has never been your job! Your job is to grow and maintain the gardens, which includes making sure plants get enough water, which by chance includes you manually watering them.

Don’t get me wrong, finding a happy corner within your work is awesome — as long as you don’t optimize for it, at the expense of what the true goal is.

And, unfortunately, I know plenty of people who do that, intentionally or not:

• “I only use LLMs as autocomplete so I can check every single line of code“

• “It takes more time to review LLM code than to write it myself“

• “If I make AI write it, my skills will atrophy”

As always your mileage may vary and none of this is necessarily wrong, but you should keep your antennas up and intercept when your behavior is guided by your own comfort, as opposed to what is best for the team / product / business.

But, as we said before, there are also a lot of engineers who are excited about AI. What are these folks getting right that the others are not?

Let’s pull a quote from the “web development is fun again” article 👇

I remember when PHP 4 was a thing. […] If you had an idea, you could probably build it. As a solo developer, you could manage everything. From idea to execution.

For this other engineer, coding is about making ideas come true. What matters is the idea, not how complex / interesting it is to build — quite the opposite: complexity gets in the way of making things happen. The less the better.

With this mindset, AI becomes your savior against the stupid complexity of the modern web, instead of the bad guy that takes away your Legos.

However, if you are feeling bad about AI right now, this is probably not going to help. You spent what feels like a lifetime getting good at something, and that something feels it is getting less valuable by the day.

How can you think of yourself differently? How do you reframe your identity?

---

↕️ Finding a broader identity

Last week I interviewed my friend Thiago Ghisi on the podcast.

Thiago has had an incredible career in tech in over 15 years. He worked at companies like AMEX, Apple, Thoughtworks, and was Director of Engineering at Nubank up until six months ago.

So what happened then?! He went into a sabbatical, during which he took a step back and explored other things that he liked. He analyzed 15 years of his notes with Claude Code, went through his email data, social media dumps, and found patterns about his behavior.

Right now, he has just applied to start a PhD in Clinical Psychology.

So if you frame Thiago as a Director of Engineering, this is obviously a departure from what he is expected to do for his career. But if you frame Thiago as someone who has worked as a manager for 10+ years, helping people become a better version of themselves, is it still that weird?

What if later on Thiago develops a coaching program for executives and high-achievers in tech, thanks to his unique blend of engineering & psychology chops? And what if he makes great use of AI for that, which he already started doing by scratching his own itch with Claude Code?

All of a sudden you might think that all the dots have been connected, and everything Thiago has done during his life has led him to this.

The problem is: you could never spot this if you simply thought of yourself as a Director of Engineering. You need to find a broader sense of identity for yourself, one that connects more dots, and answers to a deeper why.

Career jumps don’t feel weird if you can connect them to a deeper identity about yourself.

I am not telling you to get into a sabbatical to find it, and the good news is you probably don’t need to. You can ask yourself simple questions:

• Why do I do what I do?

• What’s a broader version of what I do? — Does it still look like me?

• What hobbies do I have? — Is there any that connects with some of these broader identities?

What’s the greatest common denominator of the things you do in your life?

If you feel like you are someone who crafts great backend software, would it be comfortable to step back and say you are someone who crafts great software products, in general? Would that still feel like you?

And why software? Could you say you are someone who likes to craft useful stuff, in general? Ha, I see that 3d printer there, gotcha.

Enough with Venn diagrams?! Last one, I promise.

Now you might think, why should all these contortions be any useful? Because there is a world of difference between thinking:

1. I am a backend engineer who is an expert in algorithms and data structures, and

2. I am a software engineer who creates great products — and currently works with data structures on this team.

The first guy is going to get mad at AI for becoming equally good (or better!) at their algorithms, while the second one is more likely to say “cool! I’ll do this thing faster and move to something else”.

---

💂‍♂️ For managers: help your team navigate this

I want to close by addressing managers, because a lot of this is on you.

People can do amazing work at embracing AI individually, but it’s on you to create avenues that allow this work to turn into true leverage.

AI is like a tide that raises the floor — people get higher, but if you don’t also raise the ceiling, they may get trapped. What do I mean?

Let’s say your backend engineer sticks to their typical backend work plus adds Claude Code on top of it. By using AI to do more of the same work, more and more of their day might be spent fixing AI bugs. They might be faster than before, but 1) they are still in their lane, so there is a cap to how fast they can get, and, 2) work is now miserable instead of creative.

So we need to think intentionally about how engineers spend their time. As AI takes over some of the work, the question becomes: what do you do with this residual time?

I don’t buy the answer that you just do more of the same, so the question turns into: what’s a broader scope of work that:

1. Creates professional growth, and

2. Delivers business value?

Both are required. If the scope of work is not enjoyable or doesn’t create growth, people will hate it and leave. And if it doesn’t deliver value, what are we even doing here?!

To me, a big part of this looks like making engineers care about solving problems for people.

• Sometimes these people are customers, and that’s Product Engineering.

• Sometimes these people are other engineers from their team, and that’s Platform Engineering.

• Sometimes it’s co-workers from sales, from customer success, from operations, and it’s about empowering them to do a better job.

Understanding this means aligning how engineers see their work with what success looks like for the business. When this happens, it’s easier for AI to make people not only go faster — but go faster in the right direction. And it’s easier for people to go after new things that make sense, instead of going off on a tangent.

In other words, if people accept to move past solving puzzles and on to solving problems, do they even know what the larger problems look like?

It’s on you to make them know! Let’s get to work 💪

---

📌 Bottom Line

And that’s it for today! Here are the main takeaways:

1. 🧩 We are paid to solve problems, not puzzles — the intellectual stimulation of coding is a byproduct of our real job, which is helping people (and making money!) through software.

2. 💡 Reframe AI as an enabler, not a threat — engineers who thrive with AI focus on making ideas come true, viewing complexity as an obstacle rather than the point. AI becomes a tool against tedious work, not a rival.

3. 🪞 Find a broader identity — instead of defining yourself narrowly (e.g., “backend engineer expert in algorithms”), zoom out to something like “someone who crafts useful products.” This makes AI feel like a tool, not an existential threat.

4. 🔍 Watch for comfort-driven behavior — statements like “reviewing AI code takes longer than writing it myself” may signal optimization for personal comfort over team/business outcomes. Keep your antennas up.

5. 🚪 Managers: raise the ceiling, not just the floor — AI lifts everyone’s baseline productivity, but without expanding scope and growth opportunities, engineers get trapped doing more of the same, faster, and more miserably.

6. 🎯 Align engineers with real problems — help your team understand what success looks like for the business. When people move past puzzles and on to solving problems for people, AI becomes fuel rather than friction.

---

I wish you a great week!

Sincerely
Luca