That is five years at AWS, and the badge reached me six months after the date it marks — the milestone was January; it was only printed now. It is yellow — you start at AWS on a blue badge and swap it for the yellow one at five years; the red one comes at ten, and that one I have not seen. The colour is the only part that changes with time; the rest of the badge has been the same since day one. If it had come in January, I would have had an answer ready. It came on an ordinary day, and I did not.

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 almost 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 wanted to be doing every day was AWS cloud and Terraform, and that was not what my day had for me — on that front, the challenge looked small.

That is not disappointment, it is information. I came into a pure DevOps role and ended up specialising in observability — I went deep there, on the golden signals out of Google's SRE book. Doing that is where I realised I missed working on applications.

What I then wanted from AWS was specific: to work with AWS cloud and Terraform every day, with far more exposure than I had.

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.

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.

What I found

It worked. What I knew about AWS finally consolidated, new things built, far more practice with Terraform than I had before. It was exactly what I had gone to AWS for, and it was what gave me pleasure at that moment.

All of it was true, and it stayed true for years. What changed came later.

What changed, and why it is structural

Cloud-enablement projects are broadly alike, and what makes them alike is where the client stands, not which company it is: almost always a first contact with public cloud, right after the AWS landing zone stabilises. It is the same point on a curve, visited by different companies. The variation is in the logos and the org charts, not in the problem being solved. That is what five years in this kind of engagement let me see.

Working with AWS cloud and Terraform every day delivered exactly what I asked of it: depth. What it stopped delivering was a new problem. After enough time in the kind of engagement I usually get staffed on, I no longer saw technical development there for myself as an application architect, and I realised I needed a new challenge.

It was always like this, and I only saw it now

All three times what I changed was the object of the work rather than the company — and I only saw it the third time.

At Accenture, moving into digital, I paid a toll: I was staffed on a Siebel CRM project, and what was taking me forward happened beside it — Node and Docker, outside working hours. At Globo what took me forward was inside the assignment: there was plenty to learn, and it was doing observability that showed me what I wanted was application work. At AWS it is outside it again: the role has not worn out, the new problem ran out, and the work taking me past it is not what I am staffed on.

A pattern you can name is one you can recognise before it turns into resentment. All three times I recognised it in time. It is not a method; it is what happens when you pay attention to what actually interests you. But 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 it is not my main activity on the projects I work on. The projects are not yet fully focused on AI: AI is present as tooling, and the tasks inside them are being reinvented daily with better use of those tools. It is not AI Native yet.

The problem that caught me is making the use of AI reliable, repeatable and observable — observable in the same sense I learned at Globo, only pointed at a model instead of at a system.

And that part can be shown, because it is running. This site is published by an agent loop I built and operate: personas that disagree by construction before anything gets written, and a fresh-context gate that is the only one allowed to merge — not by agreement, by mechanism. This article went through that loop before it reached you.

In practice, what takes my time is deciding what the harness blocks, what it advises, and what it merely documents, and then proving that split is still true after someone changes something. Getting it wrong is expensive in both directions: a guarantee that only exists in my memory is not a guarantee, and a gate that goes green having verified nothing is worse than no gate. I run two different harnesses over the same kind of work, one internal and this one, public — that is what lets me tell what belongs to the model from what belongs to the setup around it, and improve the setup each time round.

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 — my interest going where the assignment does not, which is exactly what had happened before.

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. It is precisely because nothing is decided that imagining is what is left.

Picture your day if text stops being the main way you talk to AI: almost everything on the surface changes, and the problem of making it reliable, repeatable and observable stays exactly the same. I do not know how to solve that problem yet. It is the part I most want to see.

What I have, in the meantime, is a ceiling I can describe precisely and a parallel practice, unglamorous, mostly late at night. 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. Imagine it with me.