The engineering career ladder made perfect sense when code was expensive to produce. A junior learned syntax and patterns. A mid-level learned how to build features end-to-end. A senior learned architecture and trade-offs. A staff engineer learned strategy and influence. Each level was gated by coding ability — your value was measured by how much complexity you could wrangle into working software.

Then Cursor published research showing their agents producing 1,000 commits per hour across 10 million tool calls. Not toy commits on a demo project. Real changes, on a real codebase, with minimal human intervention.

Code is now essentially free. Not literally free — you're still paying for Cursor subscriptions and inference budgets — but compared to what a team of engineers used to cost to produce the same output? It's not even close. What does the career ladder measure when anyone can ship code?

The old matrix was fit for purpose

The junior → mid → senior → staff progression assumed three things: coding ability is the scarce resource, learning takes years of hands-on practice, and each level unlocks access to more complex work.

If you wanted complex software built in 2015, you needed people who'd spent years developing the muscle memory. Understanding a large codebase took months. Writing clean, maintainable code took practice. Debugging production issues at 2am took experience.

All of that is still true. But the bottleneck has shifted. The hard part isn't writing the code anymore — it's knowing what code to write, securing what gets built, and operating it at scale once it's running.

Nick Durkin, Field CTO at Harness, put it bluntly: "By 2026, every engineer effectively becomes an engineering manager. Not of people, but of AI agents."

What's actually valuable now

I've spent the last few years moving between roles — Head of Engineering at Cotiss, now Principal Engineer at Prosaic. And the thing I've noticed is that my value has shifted dramatically away from writing code.

When code production is commoditised, value moves to everything around the code:

Securing it. Agent-generated code ships fast. Who's checking it for vulnerabilities? Who understands the attack surface? Security isn't a nice-to-have anymore — it's the difference between shipping confidently and shipping scared.

Architecting it. Agents can implement whatever you specify. But someone still needs to understand the business requirements deeply enough to know what to specify. What are the trade-offs? What will scale? What won't? That judgement doesn't come from prompts.

Operating it. The code ships. Now what? Who's on-call? Who understands the failure modes? Who can debug a production incident when the agent that wrote the code is long gone?

Orchestrating it. This is the new skill. Understanding business context, product requirements, and technical constraints well enough to specify clearly what agents should build — and then validating they built the right thing.

Cursor's research called this "taste, judgement, and direction." I'd call it something simpler: understanding the business deeply enough to give good instructions.

The new hybrid roles

Here's my take on where this goes. The future isn't junior → senior. It's hybrid roles that span disciplines.

Product-engineer. Someone who understands user outcomes and technical constraints. They don't just build what's in the ticket — they understand why it's in the ticket and whether it's the right thing to build.

Security-architect. Someone who can secure agent-generated code at scale. Not just running a scanner — actually understanding the threat model and building secure systems.

Business-technologist. Someone who translates strategy into specifications. They sit between the CEO's vision and the agent's implementation, making sure nothing gets lost.

These aren't new roles invented from scratch. They're the natural evolution of what senior engineers have always done — but with the coding part increasingly handled by agents.

The key insight: you need to understand more of the business deeply to stay valuable. Security. Org structure. Go-to-market. Operations. The more context you hold, the better your specifications, the better your agent-driven outcomes.

Entry level evolves

What happens to junior engineers? Stanford's research is sobering — early-career workers aged 22-25 in AI-exposed jobs saw a 16% employment decline, while workers aged 35-49 grew by 8%.

But I don't think entry-level disappears. It transforms.

The baseline shifts from "can you code?" to "can you specify, verify, and operate?" Entry-level becomes prompt engineer plus systems thinker. IEEE Spectrum's reporting quotes a hiring manager saying you need to "slot in at a higher level almost from day one."

That's brutal if you're expecting the old training path — start with simple tickets, learn the codebase over six months, gradually take on harder work. That path assumed coding reps were the training ground.

But it's also an opportunity. If you can think in systems, understand business context, and validate outcomes — you can contribute faster than any previous generation of engineers. The barrier to producing working software has never been lower. The barrier to producing the right working software is higher than ever.

Organisational agility as the competitive advantage

Here's what's been rattling around my head: software engineers used to be the bottleneck.

Want a new feature? Wait for engineering capacity. Want to test a hypothesis? Wait for engineering capacity. Want to pivot the product? Wait for engineering capacity.

Now? Agents can ship fast. The bottleneck moves elsewhere.

The question isn't "how fast can we code this?" anymore. It's "how fast can the organisation decide what to build and validate it works?"

Engineers who understand business context — who can move between product, operations, security, and strategy — can now capitalise on that agility instead of being constrained by it. The organisations that win will be the ones where engineers aren't waiting for briefs. They're helping shape them.

A caveat — this is about SaaS, not science

Everything I've said applies to the world I know — traditional SaaS, product engineering, building applications. The stuff most of us do day to day.

If you're doing deep tech — building compilers, writing ML frameworks, working on kernel internals, pushing the boundaries of computer science — the calculus is different. That work still requires deep, specialised knowledge that agents can't replace. The science matters.

But here's the thing. Most of us aren't doing that. Most of us are standing on the shoulders of giants — using frameworks, libraries, and platforms that brilliant people built — and assembling them into products that solve business problems. That's not a knock. That's the whole point of good abstraction. It means there's a clear path even in this era: the scientists keep pushing the frontier, and the rest of us get radically better tools to build on top of it.

The engineers who understand that distinction — who know when they're doing science and when they're doing integration — will navigate this shift much better than the ones who think writing CRUD endpoints is a craft that can't be automated.

The opportunity

I started my career in retail at Spark NZ. Moved into support at Vend. Learned to code on the job. Became an engineer, then a lead, then a manager, then a Head of Engineering, then a founder, then to principal engineer hands on with AI. That path made sense because each step built on coding ability.

The next generation's path looks different. It's less about climbing a ladder and more about expanding across disciplines. Less about depth in code and more about breadth in context.

The ladder isn't dead. But the rungs have changed. And if you're still climbing the old one, you might be wondering why the top doesn't look like what you expected.

The good news? This is an opportunity for engineers who want to expand beyond code. The people who've been frustrated that "just write the code" never seemed to capture the full value they could bring — this is your moment. The organisations that figure out how to deploy these people effectively will move faster than anyone thought possible.

The ones that keep hiring for the old ladder? They'll keep being confused about why their engineering investment isn't translating into outcomes.