What does it mean to be a Staff Engineer in the AI era?

When I sat down to write What does it mean to be a Staff Engineer?, I was motivated by the lack of clarity that comes with the title.

Staff engineer means different things in different companies, yet the role often sits somewhere at the crossroads of three of the most important disciplines in a tech company: business, product, and engineering. With all due respect to everyone else involved, this is written from the point of view of a staff engineer.

Since writing that post, I have been thinking about a different question: what does it mean to be a staff engineer in the AI era?

How do I feel about AI? What do I actually do differently today? Should we still review code the same way? Should more of our workflows be automated? What does any of this mean for the job itself?

There is one thing I can say with confidence: I haven’t felt this good about software engineering in a very long time.

Here is why.

Do Staff Engineers still write code?

While staff engineer can mean many different things depending on the organisation, there is one thing that tends to happen rather quickly once you get the title: you stop writing much code. That is putting it conservatively.

You read books like Software Engineering at Google and remind yourself that software is read far more often than it is written. You tell yourself that this is the natural progression of the job, and that your impact is supposed to come from somewhere else now.

You read code instead of writing it. You try to understand systems rather than individual changes. You think about architecture, performance, technical debt, organisational boundaries, dependencies, and what the system should look like six months or two years from now. And now, theoretically, you finally have the seniority to influence those things.

Sometimes you still write code, but often only enough to prove something works, build a prototype, or give someone else a direction they can continue from.

You tell yourself that this is fine. You tell your manager that it is fine. You sit with other staff engineers and tell each other that it is fine.

The only problem is that it often doesn’t feel fine at all.

You became an engineer because you liked building things. Then, after becoming supposedly better at engineering, you somehow ended up spending less time engineering. Eventually, you start doing in your free time what you were paid to do until yesterday.

You write code.

Staying sharp

I was never someone who constantly built huge side projects. I can really think of only two substantial ones.

One was logging software I built on Linux for my ham radio hobby. The other was the FairwayHub ecosystem, which eventually became its own company before I scaled it down recently because, very simply, it wasn’t making money and it was costing money to run.

Between those projects, I was never a LeetCode person either. I did, however, love Project Euler.

If I had my laptop with me and nothing better to do, that was where I would often end up. Small algorithmic problems, usually simple enough to understand quickly, but interesting enough to make you think about how to solve them properly.

I have been fascinated by that kind of problem for a very long time. One of my earliest lessons in performance came from effectively killing a Pentium II MMX with 128 MB of RAM by trying to load files into memory that had absolutely no business being loaded into memory at once.

I didn’t know the word streaming yet. I learned the idea rather quickly.

That kind of experimentation still gives me the same feeling today. Small problems where I can think about algorithms, memory, performance, data structures, and trade-offs without spending three weeks understanding the surrounding organisation.

And in the AI era, I enjoy it even more.

Another thing that always helped me stay sharp was reading code and talking to people about code. That might sound boring, but it worked for me.

By reading the code, I could see what was actually happening instead of relying only on architecture diagrams or presentations. API contracts helped me understand coupling. Dependencies showed me where boundaries were real and where they existed only on paper. Sometimes you start by looking at one function and end up questioning whether an entire system is moving in the right direction.

That naturally leads to conversations with engineers. Interestingly, not being the person who wrote the code sometimes makes those conversations easier. You don’t have the same attachment to the implementation, so you can look at it from the outside and ask different questions, especially around performance, coupling, failure modes, or what happens when the system scales.

But there is also a trap here.

Reading code without understanding the product and business logic behind it only gives you part of the picture. If you limit yourself to the engineering part of a problem, one of two things will eventually happen: you will find something that a lot of smart people, tests, linters, and production traffic somehow missed, or you will start nitpicking because finding something wrong becomes the only visible way to justify why you were reading the code in the first place.

Neither is particularly useful.

So I kept reading code, but I became much more careful about when a comment was actually worth making.

AI gave me some of the job back

And then AI happened.

When people ask me how I feel about it, the best description I have is that I feel like I finally arrived in Disneyland.

I have never actually been to Disneyland, so this comparison may be completely wrong, but you get the point.

I can understand unfamiliar code faster than I ever could before. I can ask questions about parts of the system I don’t work with every day and get enough context to know what I should investigate properly. I can understand product and business logic from code faster because I no longer have to manually follow every branch, every DTO, every API client, every database query, and every service boundary just to form the first hypothesis.

I can explore ideas without needing half a day of uninterrupted focus, and perhaps most importantly for someone in a staff role, I can actually build things again.

There were many days in the past where I had an idea at work, knew exactly what I wanted to try, and also knew there was simply no chance of implementing it between meetings, reviews, discussions, planning, interviews, mentoring, Slack, and everything else that comes with the role. By the time I got a few hours of uninterrupted time, the day was usually over.

AI changed that equation considerably. I can prototype something between meetings. I can test an architectural idea. I can explore a codebase I don’t know. I can automate repetitive work instead of adding it to an imaginary TODO list that I know I will never finish.

It also gave me the chance to finally do something with years of small scripts and tools I had written for myself to understand and manage different architectures. They existed in different forms, solving one problem here and another one there, but I never really had the time or energy to turn them into something coherent.

With AI, I could.

That eventually became Enola, my pet project for analysing software architecture and helping both humans and coding agents understand how systems fit together.

In many ways, it is just a more serious version of things I had already been doing for years: reading code, finding relationships, understanding dependencies, and trying to make architecture less dependent on what happens to be in somebody’s head.

AI didn’t give me the ideas behind it. Most of those were already there. It gave me enough leverage to actually build them.

And that, for me, is a pretty big deal.

Do you still need to understand what AI builds for you?

There is one discussion around AI that seems to come back endlessly: do we still need to learn programming languages and technologies properly, or can we simply tell AI what we want and trust it to figure out the rest?

For me, the answer is somewhere in the middle. I care much less about remembering syntax than I used to, but I still believe you need to understand how something works if you want to direct it, judge the result, and take responsibility for it.

How can I tell someone how to build something if I have no idea how I would build it myself?

That does not mean I need to remember every API, every function name, or every detail of the syntax. But I do need to understand the constraints, the trade-offs, the likely failure modes, and enough of the technology to know whether the result makes sense.

Do I miss writing code manually? Absolutely not.

For context, I started with BASIC on a Commodore 64. My second programming language was C, followed by C++, and at one point I was very proud of how fluent I was in both. I could keep an absurd amount of syntax, language rules, standard-library details, and compiler behaviour in my head.

Fast-forward a couple of decades and I was learning Go. Even then, long before the current AI wave, I remember asking myself what exactly had gone wrong when we needed several different ways of declaring essentially the same variable in the same language.

And that was Go.

We haven’t even started talking about some of the languages and ecosystems that came afterwards.

So no, I don’t miss juggling syntax in my head. I don’t miss remembering which keyword goes where, which package contains which helper, or which particular variation happens to be considered idiomatic today. That was never the interesting part of engineering for me.

The interesting part is understanding the problem, choosing the right abstractions, thinking about data flow, performance, failure modes, coupling, architecture, and what trade-offs make sense for the job.

If AI lets me spend less time remembering syntax and more time thinking about those things, great.

But removing the need to type everything yourself is very different from removing the need to understand what you are building. I am quite happy to give up the former. I have no interest in giving up the latter.

AI is not the deterministic part

One thing that gets lost in a lot of discussions around AI is that AI itself is not deterministic.

That is fine. We had deterministic tools long before LLMs appeared.

Compilers are deterministic. Linters are deterministic. Type systems are deterministic. Tests can be deterministic. Static analysis can be deterministic. Scripts that check architectural constraints can be deterministic.

The interesting part is not replacing all of those things with an LLM. The interesting part is connecting them.

A staff engineer should be in a very good position to do exactly that: use AI to explore, reason, generate, explain, and connect information, then use deterministic tools to verify what can be verified deterministically.

That is where I see a lot of the leverage.

The job is not to become the person who writes the longest prompt. The job is to understand which problems require reasoning, which problems require guarantees, and how to build a workflow where one complements the other.

AI did not make the staff engineer role less relevant to me. It made it more interesting.

But not everything is cool

Of course, there is another side to this, and this is where my small rant begins.

Writing a document with AI, telling me that some of the data in it came from another AI tool, and then expecting me to verify everything as if you just completed some huge piece of research is not productivity. You moved the work. You did not remove it.

Opening a pull request with thousands or tens of thousands of generated lines isn’t impressive either. Huge pull requests were a bad idea before AI, and they did not somehow become a good idea because generating them became easier.

The same goes for documents, messages, designs, migration plans, and pretty much everything else. If you created it, you still have to read it. If you send it to someone, you should understand what you are sending. If you open a pull request, you should know what the code does. If you make an architectural proposal, you should be able to defend the assumptions behind it.

AI can generate things much faster than humans can review them, but that does not mean humans should stop reviewing them. It means we need to get better at deciding what should be generated in the first place, and what still deserves proper human attention.

Who is accountable for AI-generated code?

This matters even more when the consequences are operational. If I am the person expected to wake up at two in the morning because something broke, I am not particularly interested in hearing that nobody read the generated code before merging it.

And if you are the person expected to wake up at two in the morning, you should care too. Not only because it will ruin your night, but because the company is paying us to build systems we can actually operate. Your wife, husband, partner, kids, dog, or whoever else happens to be sleeping next to you did not agree to participate in your AI experiment either.

The ability to generate more software does not reduce accountability. It just gives you more software to be accountable for.

That distinction matters.

The multiplier changed

I don’t think AI replaces the things I considered important about being a staff engineer before. If anything, it makes them more important.

Understanding business context still matters. Understanding product decisions still matters. Knowing when an engineering problem is actually an organisational problem still matters. Knowing when not to build something still matters. Knowing who needs to be involved in a decision still matters. And being willing to take responsibility for that decision still matters.

What changed is the amount of ground one person can cover.

I can explore more. I can build more. I can understand unfamiliar systems faster. I can test ideas that previously would have remained diagrams or documents because I simply didn’t have enough time to implement them.

And after years of slowly moving away from the part of engineering that made me an engineer in the first place, that feels surprisingly good.

Maybe that is what I like most about this moment.

AI didn’t make me feel less like a software engineer.

It gave me a way to feel like one again.