The badge arrived. Five years at AWS, six months after the date it commemorates — the mark itself was January; the object only reached Brazil now. A marker that shows up late is a better prompt than a round number: it makes you count when you were not expecting to.

So I counted. And what I want to write about is not the five years. It is the turn underneath them.

2021: what I went looking for

I had just left Accenture after thirteen years — my career started there, in 2008 — and gone to Globo, to be in an environment where I thought I would learn a lot about software engineering.

What I found there was not disappointment; it was information. I came in as DevOps, and at some point I became the application reference — outside the role I had been hired into. That is how I found out I liked application work, and how much I had been missing it. Nobody assigned me that. It happened next to the assignment.

What I then wanted from AWS was specific: hyper-exposure to leading-edge technology, becoming cloud native, working with public cloud every single day. That is what I was after when I went.

And here is the part that is less flattering and more useful. When I went to AWS Professional Services, I did not know the difference between the Solutions Architect role and the ProServe Cloud Application Architect one. What I saw was an advantage: I had spent years in the consulting business, and I could tell that would count for ProServe. So I chose by where my history was worth most, not by understanding the job.

If you are reading this in the middle of your own turn, that is probably where you are too — looking at doors you cannot tell apart, and deciding by where you have a chance. That is not a failure of research. It is what the information available to a candidate actually supports.

What I found

It worked, and I will say so plainly, because the honest version of a turn has to include the part that paid off.

I got real contact with leading-edge technology, finally consolidated what I knew about AWS, built new things, and got far more practice with Terraform. Those were my goals, and that is what gave me pleasure at that moment.

Read that last phrase again, because I chose it deliberately. At that moment. All of it was true, and it stayed true for years. What this piece is about is what changed afterwards.

What changed, and why it is structural

Over time I started seeing that cloud-enablement projects are broadly alike. I would end up with clients in their first contact with public cloud, right after the AWS landing zone stabilised.

That sentence looks like a complaint and it is not one. It is a description of a curve. The engagements repeat because the clients sit at the same point on it — same problem, different company names. The variation is in the logos and the org charts, not in the problem being solved.

And that distinction is the whole thing, because the two look identical from the inside and need opposite responses. Fatigue is about you. You are tired, you need a break, and the work is interesting again in three months. Structural repetition is about the work. No amount of rest touches it, because nothing in it was ever going to vary.

The hyper-exposure delivered exactly what I asked of it: depth. What it stopped delivering was a new problem. Which is how I reached the point where I no longer saw technical development for myself as an application architect — after enough time in the kind of engagement I usually get staffed on. Not the role exhausted in the abstract. The role, inside that kind of engagement.

The second time, not the first

Writing it out, the shape is familiar, and that is the part I did not see while it was happening.

Globo was a ceiling inside a role, and the way past it was outside the role I was hired into. AWS is a ceiling inside a role, and the work taking me past it is again outside what I am staffed on. Twice, the technical growth came from somewhere nobody allocated me to.

Both times I noticed before it turned into resentment, and both times what I changed was the object of the work rather than the company — I did not spend two years complaining and call that a plan. I am not certain that qualifies as method. It might just be what happens when you pay attention to what actually interests you. But it is a pattern, and it repeated cleanly enough that I would tell a peer to go looking for it in their own history.

The challenge now

I see a lot of similar problems over time, and I want to keep developing technically.

AI engineering is what is letting me go further. And I want to be exact about what that means, because it is easy to make it sound like more than it is: it is not my main activity on the projects I work on. That is the entire claim. Not hidden, not unsanctioned, not against anything — simply not what the engagements I am on are about.

The reason it happens anyway is much plainer than a strategy. I am going past business hours, across many days, because I got excited about what is possible with AI. That is the engine — enthusiasm outrunning the assignment, which is exactly what happened the first time too.

What I do not have

I do not have the ending. I am employed, I am not announcing anything, and I have not made the decision this piece looks like it is building toward.

What I have is a ceiling I can describe precisely, a parallel practice that is real and unglamorous and mostly happens late, and eighteen years underneath both that make the new thing an extension rather than a restart.

If you are somewhere similar — the role is fine, the problem stopped changing, and the interesting work is happening next to your assignment rather than inside it — that is worth naming out loud before it becomes something worse. You do not need to have decided anything yet. I have not.