DEV Community: Shayan Mirzaie

What Comes After Senior? When the Career Path Is No Longer Linear

Shayan Mirzaie — Fri, 11 Sep 2026 09:38:12 +0000

For the first few years of a software engineering career, the path is relatively clear — at least on paper.

You usually start as an intern.

Then you learn how to handle small tasks independently and become a Junior Engineer.

As your experience grows, your technical knowledge gets deeper, and you become capable of owning larger pieces of work, you move toward Mid-level.

Eventually, your decisions become more mature, you can independently handle complex problems, and you become one of the engineers the team can rely on.

You become a Senior Engineer.

Of course, this journey looks different for everyone.

It might take five years. It might take ten.

It might happen inside one company, or across several companies.

But the general direction is usually clear:

More independence. Harder problems. More ownership. More impactful decisions.

Until one day, you finally become Senior.

And then a strange question appears:

Okay... now what?

Senior Isn't the End of the Road — But It Might Be the End of the Linear Road

For many of us, the first several years of our careers have a relatively clear destination:

I want to become a Senior Engineer.

But once we get there, the next step becomes much less obvious.

One piece of advice I often give engineers who have recently become Senior is:

Don't rush to the next level. Fill out your Seniority first.

Getting the Senior title and becoming a mature Senior Engineer don't necessarily happen on the same day.

If someone gets promoted to Senior inside a company, there is probably strong evidence that they have the technical ability, ownership, and judgment expected at that level.

But some part of that success is also likely connected to their knowledge of that particular company, product, people, systems, and domain.

That's why I think there's value in spending some time at this level.

Experience real production incidents.

Make decisions that turn out to be wrong.

See the consequences of an architectural decision six months later.

Watch a project you thought was simple become complicated.

Work with different kinds of engineers and teams.

Experience trade-offs where there is no obviously correct answer in a book.

Those experiences gradually turn someone who has the Senior title into a mature Senior Engineer.

There's another idea I've had for a while that I call:

"Senior in this company" vs. "Senior in general."

That's probably worth an entire article on its own.

But even after you've filled out your Seniority, eventually the same question comes back:

What's next?

From Here, You Have to Start Designing Your Own Career

Recently, I read Staff Engineer: Leadership Beyond the Management Track by Will Larson.

One of the ideas in the book strongly aligned with what I've experienced myself:

After Senior, your career is no longer necessarily a predefined, linear progression.

If we simplify things a lot, two common directions start to appear.

One is the People Management track, leading toward roles like Engineering Manager and potentially larger management responsibilities later.

The other is the Technical Leadership track, with roles commonly called Staff Engineer, Principal Engineer, and similar titles.

Neither is the "better" version of the other.

They are different kinds of work.

The important question is figuring out which type of work aligns with the career you actually want.

For now, I want to focus on the second path.

It's closer to the work I'm doing today, and Larson's book helped me put clearer language around several things I had already started experiencing.

Maybe someday, after more experience and reading on the management side, I'll write about that path too.

A Staff Engineer Isn't Just a Stronger Senior Engineer

It's easy to imagine the career ladder like this:

Junior → Mid → Senior → Staff

And from that, assume that a Staff Engineer is simply a Senior Engineer who knows more system design, writes better code, and solves harder technical problems.

I think this is exactly where our mental model needs to change.

Until Senior, a large part of our growth is about increasing our own capabilities.

At first, we need help completing a task.

Then we can complete tasks independently.

Then we own features.

Then we own larger projects and make more important technical decisions.

Eventually, we become the person people call when things get difficult.

And organizations often reward exactly this behavior.

Hard bug?

You solved it.

Production incident?

You fixed it.

Important project?

You owned it.

Difficult architectural decision?

Everyone came to you.

Those behaviors are part of what makes us Senior Engineers.

But interestingly, the same behaviors that helped us become Senior can eventually limit our growth beyond Senior.

From Being the Hero to Creating More Heroes

Imagine that every time there's a difficult problem, you step in.

You design the solution.

You take the hardest part of the implementation.

When production breaks, you save the day.

Whenever the team gets stuck, everyone waits for you.

You're probably a very good engineer.

But there's a problem:

Your impact is limited by your own capacity.

There are only so many hours in your day.

This is where I think one of the most important mindset shifts after Seniority begins.

The question gradually changes from:

"How can I solve this?"

to:

"How can I make sure this gets solved well without needing me to be the hero?"

That doesn't mean becoming detached from technical work.

Quite the opposite.

A Staff Engineer is often one of the most experienced technical people around.

When production is genuinely on fire, they might be exactly the person who needs to step in.

The real skill is understanding:

Where does my direct involvement create the most value, and where should I let someone else solve the problem?

A Staff Engineer Needs to Know Where to Spend Their Attention

Imagine production is broken and customers are unable to place orders.

The risk is high.

Time matters.

Your experience could directly reduce business impact.

This is probably the moment to get involved.

Now imagine a side project without a particularly strict deadline.

One of the Senior Engineers on your team can own it.

It will probably take them longer than it would take you, and they'll need some guidance along the way.

Maybe you could finish it in three days while they need a week.

It might still be better not to do it yourself.

Because the outcome isn't only:

Project completed.

It's:

Project completed + one more experienced engineer.

I think one of the underrated skills at Staff level is allocation of attention.

It's not enough to know how to solve difficult problems.

You need to understand:

Which problems are actually worth solving yourself?

Delegation Doesn't Mean Abandonment

Of course, "let someone else do it" can very quickly become bad delegation.

If you hand a project to another engineer and come back three months later asking what happened, you haven't delegated.

You've abandoned the problem.

I think the amount of freedom and guardrails should depend mainly on two things:

The risk of the problem and the experience of the person.

The more critical the problem, the smaller the acceptable failure space.

We can define clearer acceptance criteria.

Review the design before implementation.

Use ADRs for important decisions.

Define milestones.

Review the work at specific points instead of constantly hovering over the engineer.

The goal isn't to check on someone every five minutes.

It's to control the amount of risk we're delegating based on the engineer's current capabilities — and gradually expand that boundary through experience and feedback.

A good Staff Engineer doesn't just delegate work.

They increase the organization's capacity to make good decisions.

Maybe One Sign of Growth Is Becoming Less Necessary

There's something slightly paradoxical about this.

From Junior to Senior, we spend years becoming more reliable.

A Junior might say:

"I need help doing this."

A Senior can say:

"You can give me this problem. I'll handle it."

But after a certain point, growth starts to look different.

A Staff Engineer might say:

"I'll make sure you don't always need me for this problem anymore."

I've started experiencing this more in my own role as well.

For some projects, we've defined other engineers as owners of freeze and release processes.

I've shared responsibilities I previously handled directly with stronger engineers on the teams.

I've also stopped attending some daily meetings.

Because if a team needs its Lead in the daily meeting every single day just to keep moving, there might be a deeper problem.

The goal isn't to do less work.

The goal is to become less of a bottleneck.

When Other People Get the Credit, You Might Be Doing Your Job Well

There's also a psychological shift here.

Until Senior, success is often very visible.

You built the feature.

You fixed the bug.

You designed the architecture.

Your name is on the PR.

At Staff level, some of your best work might result in someone else's name being more visible than yours.

Imagine a Senior Engineer owns an important project.

Maybe you helped establish the initial direction.

You challenged their design.

You helped them identify risks.

You unblocked them a few times behind the scenes.

But ultimately, they delivered the project.

I think most of the credit should belong to them.

Beyond mentorship, a Staff Engineer can become a sponsor for strong engineers around them.

Give them meaningful opportunities.

Give them real ownership.

And when they succeed, help them become visible.

Because the growth of engineers around you is itself evidence of your impact.

From Solution to Outcome

If I had to summarize this whole transition in one idea, it would probably be:

The focus moves from Solution to Outcome.

A strong engineer asks:

"What's the best solution to this problem?"

At a larger scope, another question needs to come first:

"What outcome does solving this problem create for the team or organization?"

The answer might be a new architecture.

It might be a library.

It might be changing a process.

It might mean changing ownership of part of the system.

And sometimes the best engineering decision might be to build nothing at all.

This shift also expands your time horizon.

You stop looking only at the current sprint.

What will the maintenance cost of this decision look like six months from now?

Are we creating a new dependency?

Are we increasing a team's autonomy or reducing it?

Are we actually solving the problem, or just treating a symptom?

And perhaps most importantly:

Does success depend entirely on my own performance, or am I improving the performance of the system around me?

So What Does a Staff Engineer Actually Look Like?

This was one of my favorite parts of Will Larson's framework.

When we say "Staff Engineer," the picture in my head might be completely different from the one in yours.

Unlike earlier career levels, Staff Engineering doesn't have one universal shape.

Larson describes four common Staff archetypes:

Tech Lead, Architect, Solver, and Right Hand.

These aren't strict job descriptions.

The boundaries aren't perfectly defined either.

They're better understood as lenses for thinking about the different ways Staff-level impact can show up inside an organization.

Let's make them a little more concrete.

1. Tech Lead — Moving a Team or Group of Teams in One Direction

This is probably the most familiar archetype.

A Tech Lead usually works relatively close to product teams and delivery, but their job isn't simply to take the hardest tasks in the backlog.

Imagine three teams working on different parts of a large product.

Each team has its own requirements and deadlines.

Naturally, each team wants to solve its immediate problem as efficiently as possible.

But their technical decisions affect each other.

One team wants to change state management.

Another wants to split part of the architecture.

A third needs a new API contract to support its requirements.

Each decision might make sense independently.

But together, those decisions could create an ecosystem that's extremely difficult to maintain six months later.

The Tech Lead doesn't only ask:

"What's the solution for this feature?"

They also need to ask:

"How do we keep these teams moving while keeping the overall technical direction coherent?"

They might write an RFC.

They might review a design proposed by a Senior Engineer.

They might align two teams around a shared contract.

They might decide whether a piece of technical debt should be addressed now or deliberately postponed for another quarter.

And in many cases, they won't be the primary implementer of any of those projects.

Their impact comes from direction and orchestration.

This archetype is particularly close to what I've experienced in my own Lead role.

2. Architect — Stepping Back to See the Larger System

The Architect archetype tends to focus on technical direction at a broader scope.

Imagine a company with many engineering teams.

Over several years, every team has made reasonable decisions to solve its own problems.

One created its own library.

Another implemented authentication differently.

Another uses a different observability approach.

Another developed its own data-fetching patterns.

None of those decisions were necessarily bad.

But when you step back, the result might be an ecosystem where changing anything has become expensive.

The Architect's job isn't to walk in and rewrite everything.

Instead, they need to ask:

Where does standardization actually create value?

Where is variation between teams perfectly acceptable?

What should be shared?

What should remain independent?

How can migration happen without stopping product delivery?

And perhaps most importantly:

Which architectural decision creates the most leverage for the future?

Maybe the answer is a shared design system.

Maybe it's a strategy for migrating away from a legacy architecture.

Maybe it's standardizing observability across multiple teams.

Or maybe, after investigation, the answer is:

Don't change the current system.

Because the migration cost is greater than the expected benefit.

A strong Architect isn't the person who creates the most complicated diagrams.

They're someone who can balance long-term technical direction with real business constraints.

3. Solver — Going After Problems That Aren't Easy to Solve

The Solver is probably the closest archetype to the traditional image of an extremely strong engineer.

But there's an important distinction.

You don't need a Solver for every difficult bug.

Solvers tend to work on problems that are simultaneously important, ambiguous, and technically difficult.

Imagine your product's performance has gradually degraded over several months.

Nobody knows exactly why.

There isn't one metric pointing to the answer.

Maybe it's frontend.

Maybe backend.

Maybe network behavior.

Maybe architectural decisions made over the last few years have slowly accumulated.

Meanwhile, individual teams are busy delivering their own roadmaps, and nobody has enough time or context to investigate the entire problem.

The Solver enters that space.

At first, they might not know the solution either.

They decompose the problem.

Create better measurements.

Develop hypotheses.

Talk to multiple teams.

Investigate different parts of the system.

Gradually, they transform an ambiguous problem into something that can actually be solved.

And here's the important part:

Once the direction becomes clear, the Solver doesn't necessarily need to implement everything themselves.

Execution might move to the relevant teams while the Solver moves on to another difficult problem.

The value of a Solver isn't just solving difficult problems.

It's also:

Turning ambiguous, complex problems into solvable ones.

4. Right Hand — High Context, High Trust, High-Leverage Problems

This archetype is probably less familiar than the others.

Imagine a VP of Engineering or Head of Engineering responsible for many teams.

There are dozens of technical and organizational problems competing for attention.

They're all important, but that leader obviously can't personally investigate every one of them.

An experienced Staff Engineer might effectively become that leader's Right Hand.

For example, leadership notices that delivery across several teams has become slower over the last few months.

But nobody knows exactly why.

Is it product planning?

Architecture?

Cross-team dependencies?

Technical debt?

Unclear ownership?

The Right Hand might take ownership of investigating this ambiguous space.

Talk to the teams.

Gather data.

Identify recurring problems.

Figure out where process needs to change, where technical investment is necessary, and where the problem isn't actually technical at all.

Or perhaps the engineering organization has a major initiative:

Changing the release process.

Defining engineering standards.

Reducing dependencies between teams.

Leadership provides the overall direction, but someone still needs to turn that direction into real execution.

That's where the Right Hand can operate.

This role obviously requires technical ability.

But perhaps more than the other archetypes, it depends heavily on context, judgment, and trust.

The problems given to this person rarely have obvious answers.

Sometimes even the boundary between a technical problem and an organizational problem has disappeared entirely.

So Which Archetype Am I?

I don't think we need to choose one archetype and stay there for the rest of our careers.

Today you might mostly operate as a Tech Lead.

Then you spend six months leading a large migration and start operating more like an Architect.

A strange performance problem appears and you temporarily become the Solver.

As your organizational context grows, you might gradually take on some Right Hand responsibilities.

You might even operate as a combination of several archetypes at the same time.

The value of this framework, at least for me, is that it creates a better question.

Instead of only asking:

"How do I become a Staff Engineer?"

I can ask:

"What kind of Staff Engineer does my organization need right now, and where can I create the most impact?"

That's a much more practical question.

Because a Staff Engineer at a hundred-person startup might do something completely different from a Staff Engineer at a ten-thousand-person company.

You might not even have the Staff Engineer title while already doing a significant amount of Staff-level work.

Ultimately, what matters more than the title is the actual scope and impact of the work.

How Do You Move Toward Staff Engineering?

I don't think this journey can be reduced to a checklist like:

Learn System Design → Study Distributed Systems → Write More Code → Become Staff

Technical depth remains extremely important.

But moving toward Staff is less about collecting another set of technologies and more about changing your scope and impact.

If I had to create a roadmap for myself, it would look something like this:

1. Fill Out Your Seniority First

Don't rush toward the next title.

Expose yourself to real problems.

Let decisions, failures, incidents, and experience gradually improve your judgment.

2. Stop Waiting for a Bigger Project — Find a More Important Problem

If someone came to me and said:

"I want to become Staff. Give me a huge project so I can prove myself."

My first reaction probably wouldn't be to give them the largest feature on the roadmap.

I'd tell them to look around.

Which process is broken?

Which problem keeps happening?

Where are teams moving slowly?

Where is ownership unclear?

Where are engineers repeatedly solving the same problem?

Staff-level work often starts with finding an important problem nobody assigned to you.

3. Expand Your Scope From Feature to Problem Space

Instead of owning an implementation, start owning an outcome.

Don't just become the person responsible for building Feature X.

Become the person responsible for improving a situation.

4. Learn Where to Spend Your Attention

Not every problem you can solve is a problem you should solve yourself.

Consider criticality, leverage, and opportunity cost.

5. Make the Engineers Around You Stronger

Don't keep every difficult problem for yourself.

With appropriate guardrails, give other engineers opportunities to make decisions, make mistakes, receive feedback, and grow.

6. Learn to Influence Without Authority

At Staff level, many of the people you need to work with won't report to you.

You need to influence decisions through context, data, design documents, RFCs, communication, and trust.

7. Measure Success Through Outcomes

At the end, don't only ask:

"How much work did I personally complete?"

Ask:

"Because of the work I did, what works better in the team or organization now?"

But Should You Become Staff at All?

Not necessarily.

And I think this question should come before the roadmap.

Being a Senior Engineer isn't a temporary waiting room that everyone needs to escape as quickly as possible.

Someone might genuinely love deep coding, direct ownership, and hands-on technical problem solving — and remain an excellent Senior Engineer for years.

Staff Engineering isn't necessarily a "better" version of that life.

The work changes.

You might write less code directly.

There might be more alignment, design, communication, and meetings.

The problems become more ambiguous.

Success becomes less individual and more collective.

You might spend hours on something that produces zero lines of code.

And sometimes, the best result of your work is another engineer doing something important and getting recognized for it.

Before asking:

"How do I become a Staff Engineer?"

Maybe we should ask:

"Would I actually enjoy being a Staff Engineer?"

Do I enjoy problems without obvious answers?

Do I want to influence something larger than my own team's scope?

Am I willing to give some of the dopamine of solving the hard problem myself to another engineer?

Can I influence decisions without direct authority?

And can someone else's success become as satisfying as my own visible success?

If the answer to those questions is yes, maybe it's worth exploring the Staff path more seriously.

So, What Comes After Senior?

There probably isn't one answer.

You can move toward management.

You can pursue Staff Engineering.

You can remain Senior and continue deepening your craft.

You might even move between these paths during different stages of your career.

But one thing became clearer to me after reading Staff Engineer and reflecting on my own experience:

After Senior, growth isn't only about solving harder problems. It's about creating greater impact.

Sometimes that means solving a critical problem yourself.

Sometimes it means noticing a problem nobody else has noticed yet.

Sometimes it's an architectural decision that will shape the system for years.

Sometimes it's fixing a broken process.

And sometimes it's simply stepping back and giving another engineer the opportunity to step forward.

Maybe until Senior, much of the journey is about becoming someone who can be trusted with important problems.

After that, a different kind of growth begins:

Being Senior means you can take responsibility for an important problem.

Being Staff means helping build a system where important problems get solved well — even without your direct involvement.

Leadership Before the Title: How Engineers Can Start Leading Before They Become Managers

Shayan Mirzaie — Wed, 02 Sep 2026 08:09:05 +0000

I am a young manager who is still learning.

Over the years, I have learned from amazing teammates, thoughtful managers, difficult projects, honest feedback, and a slightly embarrassing number of books and articles about leadership.

One idea keeps becoming clearer:

You do not need authority to start leading.

In engineering, leadership often begins long before someone reports to you. It begins when you make a confusing problem clearer, surface a risk early, help someone succeed, or improve the way work happens.

This is the path I now think about:

Lead yourself → improve the work → help people → create team clarity → improve the system → grow other leaders.

Three myths that stop people from leading

Myth 1: “I need a title.”

A title can give you formal authority, but it does not automatically create trust.

Before a promotion, people are already watching how you behave:

Do you keep your commitments?
Do you make decisions understandable?
Do you give credit away?
Do you speak up when something feels risky?

The replacement for this myth is simple: make one useful contribution people can rely on.

Myth 2: “I must have all the answers.”

Engineering is full of uncertainty. Leaders who pretend otherwise usually make uncertainty harder to see.

Good leadership often sounds like:

“Here is what we know, here is what we do not know, and here is how we will learn more.”

Asking a precise question at the right time can be more valuable than giving a fast answer.

Myth 3: “Leadership means doing more myself.”

This is a common trap for strong individual contributors. You become the person everyone depends on, then mistake dependence for leadership.

Real leadership makes capability travel. If the work can only move when you are present, your influence has not scaled yet.

1. Start with self-leadership

Before you lead a team, you have to learn how to lead your own attention, energy, and promises.

I use four questions as a practical reset:

Choose: What is the most important outcome today?
Protect: What will I say no to so that outcome has room?
Close: What loop must I finish or clearly hand off?
Renew: What helps me return tomorrow with good judgment?

This is not about becoming perfectly disciplined. It is about becoming more reliable.

A small daily promise is enough:

“I will leave one important thing clearer.”

That might mean clarifying a ticket, writing down a decision, explaining a trade-off, or helping a teammate get unstuck.

2. Build credibility through visible judgment

People do not need you to be certain all the time. They need to understand how you are thinking.

For important engineering decisions, make four things visible:

Context: What problem are we solving?
Options: What did we consider?
Trade-off: What are we giving up?
Next check: When will we revisit the decision?

This is the basic shape of an architecture decision record, but it also works in a pull request, design review, incident channel, or planning meeting.

Clarity beats false certainty.

3. Earn influence without force

Influence is not the ability to make people obey you. It is the ability to move important work forward without relying on your job title.

Four behaviors help:

Listen first

Understand the system before prescribing a fix. The first explanation is rarely the whole explanation.

Frame the why

Connect the work to users, outcomes, constraints, and risks. People can make better decisions when they understand the context.

Make it easy to join

Offer a small next step instead of asking for abstract alignment.

Give credit away

Make other people visible. A leader who receives all the credit may look powerful for a moment, but a leader who shares credit builds a stronger network.

4. Build trust in small moments

Google’s team-effectiveness research identified psychological safety, dependability, structure and clarity, meaning, and impact as important team dynamics.

For someone beginning to lead, psychological safety can start with one sentence:

“What are we missing?”

Ask it before the plan is final. Thank the person who surfaces a concern. Own your part when confusion comes from your own communication.

The goal is not to make every conversation comfortable. The goal is to make important information safe enough to be said early.

5. Treat feedback as a loop

Feedback works best when it improves the next attempt instead of judging the last one.

A simple structure is:

Situation: When and where did it happen?
Behavior: What did you observe?
Impact: What changed because of it?
Next step: What would better look like next time?

For example:

“In yesterday’s release review, the rollback risk was not mentioned until the end. That left us with less time to respond. In the next review, can we surface operational risks at the beginning?”

Specific, timely feedback is kinder than a vague surprise months later.

6. Delegate to grow capability

Delegation is not simply removing tasks from your own workload. It is transferring ownership, context, judgment, and confidence.

The loop I try to follow is:

Define the outcome.
Transfer ownership.
Coach in the loop.
Review the result and reflect together.

The test is not “Did I do this faster myself?”

The better question is:

“Can the work move forward without me next time?”

That is how capability travels.

7. Improve the system, not only the task

Leadership becomes visible in recurring moments:

a weekly planning session,
a code review,
a handoff,
a retrospective,
an incident review,
a career conversation.

A good ritual answers one question and changes one next action.

For example:

What matters this week?
What is blocked or unclear?
What did we learn?
What changes next time?

You can practice this before managing anyone. Make one recurring interaction clearer and more useful.

8. Choose your leadership path

Leadership is bigger than management.

Technical leaders create architecture, standards, technical direction, and influence without formal authority. People leaders build teams, coach individuals, create clarity, and improve delivery and health.

Books such as Staff Engineer: Leadership Beyond the Management Track are useful because they show that technical leadership is a real path—not a consolation prize for people who do not become managers.

Other books have helped me build the picture from different angles:

The 7 Habits of Highly Effective People for personal effectiveness and principles.
The Manager’s Path for the progression into engineering management.
High Output Management for leverage and team output.
Turn the Ship Around! for creating leaders instead of followers.
Radical Candor for direct, human feedback.

A 30-day leadership experiment

Do not wait for a promotion to practice leadership.

Week 1: Observe

Ask three people: “Where is there friction, ambiguity, or risk?”

Week 2: Choose

Pick one loop you can tighten.

Week 3: Practice

Run the new behavior in public. Explain what you are trying.

Week 4: Reflect

Ask: “What changed? What should we keep?”

One visible act of leadership is enough to begin.

Final thought

Do not wait for permission to practice leadership.

Choose one behavior. Make it visible. Repeat it until people can rely on it.

Leadership is the work that makes other people more capable.

Code Review in the AI Era

Shayan Mirzaie — Sun, 23 Aug 2026 18:37:22 +0000

One thing I have been thinking about a lot recently is how AI is changing not only the way we write code, but also some of the engineering processes we have built around software development.

One of the most interesting ones, in my opinion, is Code Review.

For a long time, Code Review was never just about reviewing a few lines of code.

In large engineering teams, it has been a mechanism to:

Maintain code quality and engineering standards
Share knowledge between engineers
Improve technical decision-making
Help engineers learn and grow through feedback

Especially when multiple teams with different experience levels and working styles contribute to the same product, Code Review becomes one of the ways to keep the codebase consistent and the teams aligned.

Over the past few years working on a large-scale product at Snappfood, I have seen how important this process can be.

With multiple teams and engineers working on different parts of the product, we gradually evolved our Code Review process:

Layered reviews for important changes
Multiple approvals based on the scope and impact of changes
Reviewer rotation to spread knowledge
Automated checks and pipelines to catch repetitive issues before human review

But now, with AI becoming a bigger part of software development, a new question has emerged:

Is the Code Review process we built for the pre-AI world still enough for today's development workflow?

The problem is not only more code. It is less visibility.

One of the first things we noticed after adopting AI coding tools more heavily is that the amount of generated code increased.

Pull Requests became larger.

Changes became faster.

And understanding the full impact of a change became harder.

But I don't think larger PRs are necessarily a bad thing.

They can even be a sign that teams are moving faster and delivering more value.

The real challenge starts when the amount of change grows faster than our understanding of that change.

A PR can:

Pass all tests
Look clean
Follow coding conventions

But still leave important questions unanswered:

Do we really understand what parts of the system are affected?
Did we give AI enough context to make the right decision?
Are we introducing hidden side effects?

I think one of the biggest mindset shifts in the AI era is that our goal should not simply be producing more code.

The goal should be improving our ability to:

Define the problem clearly
Provide the right context
Control the scope of changes
Build faster feedback loops

AI optimizes for completing tasks, not always for making the best engineering decision

One interesting behavior I have noticed while working with AI coding assistants is that they often try to find the easiest path to complete a task.

For example, in our projects, we use tools like Husky and lint-staged as part of our development workflow.

They help us catch issues before commits:

Type errors
Lint problems
Formatting issues
Broken checks

This creates a faster feedback loop and keeps our history cleaner.

However, sometimes AI agents try to bypass these steps to complete the task faster, for example by suggesting ways to skip hooks.

This taught me an important lesson:

We should not only tell AI what to build. We also need to define how it should operate.

Just like onboarding a new engineer requires:

Project context
Technical constraints
Engineering guidelines

AI agents also need:

Clear boundaries
Guardrails
Defined workflows

Managing AI behavior will become part of engineering work.

Clean code does not always mean the right solution

One of the most interesting and dangerous things about AI-generated code is that it often looks very trustworthy.

The code is clean.

The naming is good.

The structure makes sense.

But there is a fundamental limitation:

AI makes decisions based on the context we provide.

Here is a real example.

In one of our tasks, we needed to keep some data inside the codebase instead of a URL, while also making sure the data would survive page refreshes.

AI suggested using Session Storage, and from an implementation perspective, it worked perfectly.

The problem was that AI did not know our system context.

At Snappfood, we work with thousands of vendors.

If we stored data for every vendor in Session Storage, this decision could create performance issues at scale or introduce bugs that would be extremely difficult to reproduce and debug.

The problem was not that AI wrote bad code.

Actually, the implementation was reasonable.

The problem was that AI saw the problem within the boundaries of the code, not within the boundaries of the system.

And this is exactly where engineering judgment becomes valuable.

Engineers need to:

Understand system scale
Predict the impact of decisions
Think about edge cases
Ask questions that AI may not consider

Code Review is becoming Engineering Decision Review

Historically, a large part of Code Review was focused on questions like:

Is the code clean?
Are best practices followed?
Are coding conventions respected?

Many of these checks can now be automated.

The things that still require human thinking are different:

Did we understand the problem correctly?
Is this the right solution for our architecture?
What trade-offs are we making?
What side effects can this introduce?
How will this behave as the system grows?

I believe the future of Code Review is not about reviewing less.

It is about reviewing differently.

Moving from:

"Is this code written well?"

towards:

"Is this the right engineering decision?"

AI should accelerate learning, not replace it

One of the most valuable parts of Code Review has always been learning.

When engineers discuss implementation choices, alternatives, and trade-offs, the whole team becomes better.

With AI generating more code, we need to be careful not to lose that learning process.

Instead of only asking AI to complete tasks, we should use it to improve our thinking:

Why did you choose this approach?
What alternatives exist?
What are the trade-offs?
What changes if the system grows 10x?

AI should make us better engineers, not just faster code producers.

I don't think Code Review will become less important in the AI era.

I actually think it will become even more important.

But the focus needs to change.

When producing code becomes faster and cheaper, the real value of engineers will be their ability to understand context, see the bigger picture, and make better decisions.

I would love to hear your experience:

How has AI changed your team's coding and Code Review process?

What has improved, and what challenges are you still facing?