Tech lead in the AI age: From expert to frame-setter

Introduction

For many years, the tech lead role was tied to one thing: being the person who knew the most.

The one who could answer fastest. The one who made the right calls. The one who saw the solution before the rest of the team had finished phrasing the problem.

But that role was never the whole truth.

And in the AI age, that becomes clearer than ever.

Not because competence matters less, but because knowledge is no longer scarce. Everyone on the team now has an “expert” in their pocket.

The difference is no longer who knows the most, but how the knowledge is used and aligned.

When the right answer is no longer the bottleneck

Progress used to stall on one thing: “We don’t know how to do this.”

Today the situation is often the opposite: “We have ten possible solutions – which one do we pick?”

AI produces suggestions fast. Code, architecture, patterns, alternatives.

But it doesn’t give you:

• context
• consequences over time
• understanding of your system
• ownership of the choice

The result isn’t less uncertainty – it’s more.

And you feel it in the everyday:

One developer uses AI to generate structured logging with correlation IDs. Another gets simple string logging. A third introduces a new error-handling pattern.

Everything works. Everything gets approved.

But after a few weeks, no one quite knows what “the way we do it” is.

The problem isn’t a lack of answers. It’s a lack of structure around them.

From expert to frame-setter

It’s easy to read this as a shift in the role. But really, it’s a clarification.

A good tech lead was never primarily the person who knew the most. The role was always about something more subtle:

Keeping standards coherent. Creating direction. Making sure the system holds together.

What you may know as the quiet responsibility – keeping the standards coherent over time (Read more).

What changes now isn’t what the role is, but how visible it becomes.

When everyone is senior, and no one “knows the most”

In many teams it makes no sense to talk about “the best developer”.

You have:

• experienced developers
• strong opinions
• high professional quality

The challenge isn’t competence.

It’s divergence.

Senior developers make good choices. But they don’t necessarily make the same choices.

And it shows in practice:

The same endpoint gets implemented three times: once with a service layer, once directly in the controller, once in a “clean” variant.

All three are professionally defensible. All three can be argued for.

But the system starts to diverge.

This isn’t a competence problem. It’s a coordination problem.

AI amplifies the differences

Put AI on top of this, and the differences grow.

Now everyone has:

• access to different suggestions
• different prompts
• different preferences
• different interpretations

Two seniors + two AI answers = four directions.

And it doesn’t stop there.

One developer asks: “How should we structure this?”

Another asks: “Give me a quick solution.”

They get different answers. Both feel right.

Without structure, you don’t get better solutions. You get more fragmentation.

This isn’t a new phenomenon – just an accelerated version of something we already know: from technical debt, where the problem is rarely one bad decision, but many small ones that were never aligned (Read more (in Norwegian)).

How the team uses AI

So the first shift isn’t technological, but operational.

AI in itself doesn’t produce quality. The practice around it does.

Without structure, you quickly see:

• AI-generated code with varying style and quality
• inconsistent patterns in the same codebase
• solutions not understood by the people implementing them
• a growing need for cleanup

A classic example:

One developer uses AI to generate mapping between DTO and domain. The next developer uses AutoMapper. A third writes it by hand.

None of the choices is wrong, but the system loses consistency.

What does that mean in practice?

As a tech lead, you should define:

• When do we use AI, and when don’t we?
• What is “review-ready” code here?
• How do we evaluate suggestions before adopting them?
• How do we document choices made with AI support?

A concrete move many teams are missing:

A short AI usage guideline in the repo.

Not as policy, but as part of the everyday:

• “Understand before you merge”
• “Explain complex choices in the PR”
• “New patterns are adopted together”

It’s the same principle as for standards in general: they only work when they’re actually used in the everyday (Read more (in Norwegian)).

Quality in a world of generated code

When code can be produced in seconds, quality assurance moves:

Before:

• Focus on how to write good code

Now:

• Focus on how to evaluate good code

That requires:

• a shared understanding of quality
• clear standards
• consistent review processes

Because without a shared understanding, every individual – and every AI – will pull in their own direction.

A familiar pattern:

A PR looks “tidy”. The code is structured. The names make sense.

But:

• errors are handled differently
• logging lacks context
• the pattern deviates from the rest of the system

Everything looks right locally, but breaks the whole.

Practical moves

• PR templates that make quality explicit
• automated enforcement where possible
• example code that shows what “good” actually means

The point isn’t more rules. It’s making the expectations clear in practice.

Less focus on “the right solution”

In an AI-driven environment, one thing becomes clear:

The perfect solution is rarely the problem.

The problem is:

• that the choice isn’t understood
• that it isn’t anchored
• that it can’t be evaluated later

Again, we see the same pattern:

Not one wrong decision, but many small ones that were never made explicit.

What should you optimize for?

• understandable choices
• documented context
• the possibility of revision
• shared ownership

Not perfection.

From control to mechanisms

When complexity rises, it’s tempting to tighten up:

• more rules
• more control
• more approval

But that creates bottlenecks.

Instead, you have to build mechanisms:

• clear standards
• automated enforcement
• good defaults
• low friction for the right practice

Standards only work when they feel like support, not control. Otherwise they lose ownership and adherence.

The tech lead as synchronization point

In practice, your role becomes this:

You are not the expert. You are the synchronization point.

You make sure that:

• standards hold together
• the tech stack evolves in one direction
• decisions stay understandable over time
• deviations are deliberate and documented

You don’t own every choice, but you own the whole.

The actual value

In a strong team it’s easy to underrate the role:

“Everyone’s good, after all.”

That’s exactly why the role is critical.

Not to elevate individuals, but to make sure the sum doesn’t fragment.

And you notice it first when it starts to hurt:

• when onboarding takes longer
• when bugs are hard to trace
• when small changes have unpredictable consequences

The challenge isn’t in individual choices, but in the absence of shared direction.

Closing: Leading what no one fully understands

AI doesn’t make development easier. It makes it faster and harder to survey.

You can no longer be the one who knows the most –

but you can be the one who:

• creates structure
• gives direction
• makes quality concrete
• keeps the system coherent

Your value isn’t having the answers.

It’s making sure the team doesn’t diverge when facing them.

That is the quiet responsibility.

And in the AI age, it isn’t less important. It is the role itself.