Nobody knows what to expect from engineers anymore

Almost every company right now is rolling out some sort of AI strategy, whatever that means. On company level, on tooling level, on what to buy into. Is it Claude? Is it Codex? Is it OpenAI? Is it some other tool? What about data privacy? Committees, pilots, procurement.

From an engineering perspective, all of this is happening somewhere in the background. Meanwhile the actual work has already changed, and nobody has written down what we now expect from the people doing it.

Overview

Engineering goes first

Other areas will be affected the same way. Maybe people will do spec-driven development for PowerPoint presentations, sales pitches or Excel files in the future. I wouldn't be surprised.

But engineering is one of the first domains where the full agentic stuff really takes off. So we're the ones who get to figure it out first, and that includes the uncomfortable people questions.

Two groups of engineers

In my previous post I wrote about the value every engineer still has. Looking a bit closer, I see two groups of engineers, and they experience this shift very differently.

The ones close to the product

The first group has always been closer to whatever the product is doing or the business side of things. For them, AI enablement means achieving more in less time, higher velocity, higher quality. That's exciting. It's the vibe I get whenever I listen to DHH on Lex Fridman or watch his Rails World 2026 keynote.

It's also much more natural for people who have been in engineering management or team lead positions before. In those roles you are not the one executing every instruction or writing the code yourself. You work with incomplete information, like any manager does. You validate from afar, through a pull request, a review you do together or by steering the direction. Working with agents is a lot like that.

The ones deep in the details

The second group is very good at diving deep into a technical matter, figuring out patterns and turning them into a real thing in the form of code.

The value those people brought to companies, and the identity that formed around it, came to a large part from the fact that they could do it and others couldn't. And obviously this is exactly where AI has the strongest impact.

It forces them to shift. It's also hard for this group to trust AI and to cut corners, because they are very good at being pedantic and being in the details. The AI shift is demanding the exact opposite from them. That's not a character flaw.

The gap compounds

Coming back to company AI strategy. I see several people in organisations really experimenting. They try to find a balance between not being too cutting edge and burning out on all the AI news, while constantly tweaking the harness they need for their agentic systems to achieve more with better quality.

And some people are hesitant. There are different reasons. Maybe they don't want the stress of figuring out the tooling again every week. Maybe they don't like working with agents compared to what they liked about their engineering job before. All fair.

The reality, though, is that the longer this goes on, the bigger the gap becomes. On one side are the people building harnesses, then building on top of them, and on top of that again. On the other side are the people going with the flow. The gap isn't linear, it's recursive. Every improvement to your setup makes the next one cheaper.

Nobody has the career path for this

As a company we don't have talent journeys and career paths laid out for what the market now demands from these roles. It's not only that the expectation profile is changing inside each company. It's changing across the whole industry, and the industry doesn't have it figured out either.

This gets to the point where it's really hard to evaluate people. These are the questions I keep coming back to:

• Are we being unfair to someone who is slower at adapting to agentic work, if they produce less than others?
• Should we simply expect everyone to figure it out on their own, and only look at the outcome?
• Is that ethically okay?
• If we were hiring our engineers again today, would we really hire all of them?
• What is the opportunity cost of keeping someone versus hiring someone new who is more AI native?

I don't have clean answers. I don't think anyone does yet.

The education dilemma

Then there is the question of investment. A good employer educates its people. But how much time can we invest, and when?

Some people in the company don't need it at all. Some of them are actually the ones doing the educating. So a training programme would take time away from exactly the people who are already 10x ahead of the others.

And how lasting is the investment? If we think one or two years ahead, the whole way of working with AI might have changed again. Do we do all of this again then?

Probably, yes. So the thing worth teaching is not a tool. It's the habit of rebuilding your own setup every few months.

Measure the how, not the clicks

Some companies already put AI into their performance goals. Shopify made AI usage a baseline expectation and added it to performance and peer reviews. JPMorgan reportedly rates its engineers on "what you achieve" and "how you achieve it", with AI in the second bucket.

I like the idea. Writing down that the how matters is more honest than pretending only the outcome counts. But it has to point at the right outcome. If the goal is usage, you get usage. Prompts sent, licenses activated, percentage of AI-written code. That's easy to count and says nothing.

And perception is a bad proxy too. In the METR study experienced developers were 19% slower with AI while believing they were 20% faster. The tools have gotten a lot better since, but the lesson stands. Feeling productive and being productive are different things.

So what would I put into a goal instead?

• Lead time from idea to something running in front of a user.
• Quality at the end. Bugs, rollbacks, incidents.
• Test coverage, observability and the other things we were always too busy for.
• How much the setup you built helps the rest of the team.

There's also a fairness line I find useful. Coinbase fired engineers who refused to even onboard. Their CEO admitted it was heavy-handed. I wouldn't do it that way, but the distinction behind it is right. "Won't" and "not yet" are two different things. Someone slow but trying deserves time. Someone refusing to try is making a choice.

Make the multipliers count

Back to the education dilemma. The people who are already ahead are the ones who should teach. The problem is that this usually happens on the side, unrecognised, and it eats into the very output they get measured on.

Some companies make it official with AI champions or guilds. The setup that seems to work: pick people who already use the tools well instead of volunteers, give each of them a small group of peers, hold regular office hours and share the patterns that work. The harness one person built becomes the starting point for ten others.

As described in my post on career multipliers. Tech skills plus enabling others equals more value. The 10x engineer who brings five colleagues along is worth more than the 10x engineer who doesn't. So count it. Put it into their goals, give it real time and stop treating it as a favour.

It also answers the "do we need to do this again in two years" question. A training course goes stale. A group of people who keep figuring it out together doesn't.

Start with your multipliers

Nobody has the career path figured out yet. Someone has to write a first version of what "good" looks like for an engineer in your company now. It will be wrong, and then you change it.

If I had to start somewhere, I'd start with the people who are already ahead. Give them time and recognition to bring the others along, and measure what comes out the other end. Not the clicks.

If you're one of those people, don't wait for the programme. You're probably doing it already.

Cheers,
Flo