The developer role is changing. AI is accelerating everything, but the shift goes deeper than that. It’s about role, responsibility, and meaning. This article is my vision of where the job might be heading. It’s not absolute truth. Not every developer will want to go this way. But it’s what I observe in the organizations where my friends and I have worked, what I experience, and what seems like the most interesting direction for building better products.

Building without understanding

Developing, today, in many organizations, looks like this. You get a user story, you estimate it, you build it, you push to prod. Repeat. The problem is, you don’t know why you’re doing what you’re doing. The decision was made elsewhere, by other people. If the feature doesn’t work, if nobody uses it, it’s not your problem. You delivered 100% of the sprint, mission accomplished.

At CBA, we aim for 100% completion rate on sprints. That’s the target. But delivering 100% of sprints isn’t the same as having real impact. When you code for months without ever seeing that impact, without ever talking to the people who use what you build, it becomes hollow. And I don’t want that.

This disconnect comes from silos. PMs define the “what,” designers the “how,” devs build what they’re given. In theory, it’s clean. In practice, it’s absurd. Developers often have technical understanding that could improve the product, but nobody asks their opinion before everything is decided. PMs sometimes have brilliant ideas, but disconnected from technical reality. And in the end, nobody is truly responsible for the outcome. The PM says “I defined the need.” The dev says “I delivered the feature.” But if it doesn’t work? Nobody. Or everybody. Which amounts to the same thing.

What I want, and what motivates a lot of senior developers I know, is ownership. Being responsible for a piece of product, not just code. If it works, it’s because of me. If it doesn’t, it’s on me to fix. Autonomy. The freedom to decide how to solve a problem, without just applying a solution already chosen by someone else. Vision. Understanding where we’re going and why. Many organizations aren’t structured to offer that. They’re structured to control. Sprints, story points, velocity, daily stand-ups, burn-down charts.

There’s a pattern I see everywhere, at my company and at my friends’ companies. You estimate a feature, usually poorly because you don’t have all the info. You promise a deadline. Reality hits, it’s more complex than expected, specs change. You crunch to meet the deadline. The feature ships, disappointing. You blame the process. You add more process. More meetings, more reviews. You become even slower. And you go back to the start. The real cause isn’t lack of process. It’s lack of trust. When you don’t trust devs to deliver, you add control. When you add control, you slow down. And the loop continues.

What AI changes

With Cursor, Windsurf, Claude, and the dozens of tools shipping every week, writing code is becoming a fraction of the work. What matters more and more is architecture, how everything fits together. Specs, what to build and why. And user context, understanding real problems.

Do all developers want this shift? No. Some want to stay executors. Others want to become ultra-specialized experts in a specific tech. But what I observe is that as AI evolves, pure expertise on a stack is becoming commoditized. AI generates quality code in any tech. Pure execution gets automated when AI takes specs and produces working code.

Today already in my team at CBA, if you’re pure tech, AI almost replaces you. You need either a very high level with review value (architecture, design patterns, security, performance), or you need to start thinking product. I think within 2-3 years, engineers who can’t think product will struggle.

What remains, and what seems increasingly important to me, is the ability to understand users, make data-driven decisions, and architect solutions that hold up.

Toward the product engineer

The teams I follow online, PostHog, Linear, and other startups doing build-in-public, have a different approach. Their engineers talk to users, do support, recruit testers, analyze data, develop opinions on what should exist, and act with urgency to make it real. The “problem → fix” cycle is direct, no telephone game between four departments.

Concretely, that means writing code, yes, but code is only part of the job. Talking to users. Designing solutions, not just implementing them. Defining KPIs. Iterating based on real feedback. Being responsible for the outcome, not just the output.

Why the dev evolving toward product, and not the other way around? Because the learning asymmetry doesn’t work the same way. A PM without technical background who codes with AI can prototype fast, but without deep understanding of architecture and system trade-offs, it produces code that works but doesn’t scale. My goal isn’t to say we’ll replace PMs, but that there’s much more overlap possible. PMs can code and devs can make product decisions.

An engineer who learns product combines a solid technical foundation with product intelligence. They code with a clear vision of why. They make better architecture decisions because they understand user context. They iterate faster because they don’t wait for a PM to tell them what to do.

For this to work, organizations need to evolve too. Clear objectives rather than filled sprints. Transparency by default. Accessible roadmaps, documented decisions, open data. Time to understand. The time saved with AI shouldn’t be used to produce even more features, but to better understand users. Direct, raw feedback, not filtered by a PM or summarized in a report.

The senior developer role as I see it isn’t really “developer” anymore. It’s someone who uses code as one tool among others, who understands users, who makes decisions, who takes responsibility for the result. Some companies get this. Others are still in “waterfall disguised as agile” mode. I know which model I want to move toward.