Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge

And Now What?

After many years of voluntarily leading projects and teams, I became an official Staff Software Engineer. After I got the title, I asked myself: “Now what?”

There is a difference between doing the work unofficially and officially owning the role. The difference is responsibility.

As you grow into a leadership position, whether as an IC — an Individual Contributor like a Staff Engineer — or as an Engineering Manager, it becomes harder to find resources that tell you exactly what to do. The expectations become more vague. If you ask ten people what a Staff Engineer should do, you may get ten different answers. That makes it harder to grow and harder to manage expectations.

I also saw some people mix up the Engineering Manager role with my role as a Staff Engineer. They overlap in some areas, but they are not the same role. A Staff Engineer leads through technical direction, influence, and leverage. An Engineering Manager leads through people management, team health, and delivery systems.

So imagine growing into a role with fewer resources, no single definition, and vague expectations.

It is hard. And in many ways, that is what leadership looks like.

Defining the Role Myself

During the early stages of my career, I worked as a solo developer. I had no one to tell me what to learn, what to improve, or what my strengths were. So I learned how to find and evaluate those things myself. I learned it the hard way.

Years later, that skill became valuable. I got promoted, and now I needed to find out how to grow within this role and what I should do next.

Instead of waiting for clear expectations, I decided to own them. Instead of waiting for someone to tell me what was expected from me, I defined those expectations and confirmed them with others. I went to my teammates one by one and asked them: “How can I help you?”

That helped me define my role within the team and among my peers.

Around the same time, I found useful resources to learn more about the role, especially the Senior Engineer to Lead: Grow and thrive in the role course. Gregor created a course for people facing the same struggles and confusion I was facing, and I joined it at exactly the right time in my career.

What Did I Learn? The Paradigm Shift

We become software engineers because we like to solve problems and create things. We are makers. In software, it is easy to create, experiment, learn, maintain, throw things away, and repeat.

But when you become a Staff Engineer, you need to let go of being only the maker. You become an enabler. You become a multiplier for your team.

You create opportunities for others to grow. Instead of doing everything yourself, you help others do it. Let’s be honest: most of us wished someone had given us more opportunities to grow earlier in our careers. So why not create those opportunities for your team?

This is a big shift, and it is not easy to make.

The team looks to you to provide the clarity they need to move forward. You need to make the path easier to understand. You need to create a paved road so the team can move toward the goal.

That requires vision and strategy. If you are missing that visionary mindset, your team will struggle to reach its goals.

You are no longer here only to pick up a ticket, an epic, or even a project and implement it. You are here to steer your team toward its goals.

In the end, you are a leader, right?

The Same Shift, Applied to Agents

Here is what surprised me: the skills I built to enable humans turned out to be the exact skills needed to lead AI agents.

For years, I practiced breaking down ambiguity, setting context, defining clear outcomes, and letting others own the craft. I thought I was learning how to be a good Staff Engineer for people.

It turns out I was also learning how to be a Staff Engineer for machines that write code.

The moment I stopped treating agents like autocomplete and started treating them like a team — assigning roles, reviewing their output, correcting course, and guarding quality — I saw what this new era really looks like.

The shift does not change. You still let go of being only the maker. You still become the multiplier.

The only difference is that your team now includes both humans and agents, and agents can iterate at a speed no human can match.

If you have already made the mental leap from coder to enabler, you are not late to AI. You are early.

My thesis is simple: the Staff Engineer skill set is becoming more valuable, not less, in the AI era. The engineers who know how to define outcomes, reduce ambiguity, create guardrails, and review work will be the ones who get the most out of AI agents.

The AI Coding Era

The Aha Moment

Last year, I did not believe LLMs and agents could code at a serious level.

They could suggest some code changes, sure. But writing code like humans? Building real products? No way.

Toward the end of the year, I picked up the official GitHub Copilot documentation and started to dig deep into it. I started with the copilot-instructions.md file, then specific instruction files, then prompts, then custom agents.

I built custom agents that act like a product team:

• Lead Engineer
• Senior Engineer Implementer
• Senior Engineer Reviewer
• QA Engineer
• Security Engineer
• Technical Writer

At first, I switched between these agents manually. Then I wondered if there was a way to involve all of them at once. That is when I saw the sub-agents feature.

I built an orchestrator agent that dispatches a feature to the whole team. I started to give it simple instructions like:

Build endpoint for user management

Then I watched the whole team work.

The result was amazing. I was shocked, and I did not know what to feel.

Should I be happy because I created this team and shaped their skills to work like that? Or should I be afraid because this means we could lose our jobs?

The Minority

After I experienced that aha moment, I started talking to my friends about it.

The majority of them still do not believe AI can code and build products. They believe it can write code, but only at a POC — Proof of Concept — level. In their view, you still need to throw it away and write it again with a human.

I do not believe that anymore, because for the last four months, I have been building and maintaining products using AI.

This does not mean agents are perfect. They are not. They make mistakes, misunderstand context, over-engineer solutions, and sometimes create bugs that look very convincing.

But that is exactly the point: they need leadership.

They need someone to define the goal, set the boundaries, review the output, and decide whether the solution is good enough. They need someone who can separate impressive-looking code from useful, maintainable software.

The Staff Engineer’s New Domain

If you look closely at what makes AI agents succeed, you will see something familiar.

The engineers who thrive with them are acting exactly like Staff Engineers to those agents.

They are not typing every line. They are defining outcomes, setting guardrails, reviewing work, and correcting course. They are creating context. They are creating leverage.

This is why engineers who lack these skills are struggling to lead AI agents to code. They have not made the shift yet. They still imagine the only valuable part of engineering is writing the implementation themselves.

But implementation is only one part of building software.

Software engineering also includes understanding the problem, gathering requirements, making trade-offs, designing systems, communicating with stakeholders, reviewing quality, managing risk, documenting decisions, and maintaining the product over time.

Agents can help with more and more of the implementation. But they still need direction.

And direction is becoming the new engineering advantage.

Don’t Take My Skills

Engineers are scared to admit that AI can and will become the coder part of the team. I understand that fear because we like to code.

So you want to tell me that AI will take that from me?

Maybe not all of it, and not overnight. But yes, a growing part of implementation will move from human hands to AI agents.

That is uncomfortable. It feels like losing part of our identity.

But the problem is that many engineers focused on only one area of building software: coding. Building software has many stages, and most of them involve understanding or communicating with humans.

You talk to humans to gather requirements. You talk to humans to verify assumptions. You write for humans through documentation, technical proposals, user manuals, and release notes. You align with humans around priorities, trade-offs, and constraints.

This is the time for engineers to let go of the idea that coding is the only valuable skill and focus on the other areas of building software.

The real AI advantage is not prompting.

It is leadership.

Who Will Survive?

We can see the market is changing, and many people are sadly losing their jobs. AI is not the only reason, but we cannot ignore that the market is changing. We need to adapt.

So who will survive?

The engineers who will survive are those who focus on the broader areas of software engineering: product thinking, business context, communication, architecture, quality, security, operations, and delivery.

They are the engineers who do not wait for the Product Owner to hand them a PRD — Product Requirement Document — so they can pick up tickets. They are involved in the business domain. They understand the users. They understand why the product exists and what problem it solves.

Why will they survive?

Because these are the people who can use AI to build products.

They know what to ask for. They know what matters. They know how to instruct agents properly and guide them in the right direction.

If you only know how to receive a ticket and write code, then yes, AI feels threatening.

But if you know how to turn ambiguity into outcomes, AI becomes leverage.

So What Can I Do?

I want to tell you this clearly: you are not late at all.

Like I said, the majority are still not here. Many engineers are still debating whether AI can write production-quality code while others are already learning how to lead agents effectively.

If you start now, you can become part of the minority. You can become a frontrunner.

Practice

Find a software idea and start implementing it using coding agents.

I am sure you have ideas here and there. Pick one. It does not need to be big. It can be a small internal tool, a personal dashboard, a CLI, a browser extension, a simple API, or anything that forces you to go beyond a single prompt.

You can start with free or paid GitHub Copilot, or Claude Pro with Claude Code.

I suggest trying CLI or TUI coding agents, not only IDE-based assistants. You may find, as I did, that CLI-based agents produce better results for larger tasks.

Once you experience it deeply, you will have your own aha moment. And after that, you probably will not stop building.

Improve Writing

LLMs understand text, so you will write to them a lot.

There is a big difference between a vague, short prompt and a detailed, comprehensive, organized prompt. The second one will almost always get you better quality code.

It is like guiding your team to build a feature.

How do you feel when you open a ticket and see that the only thing filled in is the title?

You feel frustrated and lost.

Agents behave the same way. If they do not understand what you want, they will start assuming things and building based on those assumptions. This is why most people burn tokens when they start working with coding agents.

They are not failing only because the model is bad.

They are failing because the direction is unclear.

So improve your writing. Learn how to describe context, constraints, goals, examples, edge cases, and acceptance criteria. Learn how to write instructions that reduce ambiguity.

Good writing is becoming an engineering skill.

Improve Reviewing

If agents become builders, reviewing becomes even more important.

You need to know how to read the output, challenge assumptions, check edge cases, and verify that the solution fits the business goal.

The future engineer is not someone who blindly accepts generated code. The future engineer is someone who can tell whether the generated code is good, safe, maintainable, and useful.

This means you still need strong engineering fundamentals.

You need to understand architecture. You need to understand testing. You need to understand security. You need to understand performance. You need to understand maintainability.

AI does not remove the need for engineering judgment.

It increases the value of it.

Get Closer to the Business

The more implementation becomes automated, the more valuable context becomes.

Engineers who understand the product, the users, the domain, and the business constraints will have a huge advantage. They will know what to ask the agent to build, why it matters, and what trade-offs are acceptable.

If you want to become better in the AI era, do not only study tools.

Study the business.

Ask why a feature matters. Ask who uses it. Ask what happens if it fails. Ask what the company is trying to achieve. Ask what the real constraint is.

The better you understand the context, the better you can direct agents.

Learn to Orchestrate

Do not think of AI as one chatbot that answers your questions.

Think of it as a team.

One agent can help clarify requirements. Another can design the architecture. Another can implement. Another can review. Another can test. Another can write documentation.

Your job is to orchestrate them.

You decide who does what. You decide what context they need. You decide when the output is good enough. You decide when to stop, rethink, or change direction.

That is very close to what Staff Engineers already do with human teams.

The difference is that now the loop is faster.

Final Thought

This is the Staff Engineer’s AI edge.

We already had to learn how to move from writing every line ourselves to creating leverage through others. AI agents are simply the next group we need to lead.

So do not wait until everyone believes this is real.

Start now.

Build with agents. Learn how to guide them. Learn how to review them. Learn how to turn ambiguity into outcomes.

The future does not belong only to engineers who can code.

It belongs to engineers who can lead the creation of software — through humans, through agents, and through both together.