Four unchanging responsibilities for engineering leadership in 2026
The traditional thing to do at the start of a year, especially in tech, is to prognosticate. It’s impossible to ignore the improvements in AI over the last year, particularly in LLMs (and let me tell you, Claude Code with Opus 4.5 is very good). But rather than add yet another think piece about how AI is changing coding, I’m going to call out four core engineering leadership responsibilities that aren’t changing in 2026. While the tools evolve, the fundamental expectations of the role remain the same.
1. Personal responsibility still matters
I could have written this as “people still matter.” Your team is made up of people. Whether they’re junior or senior, using Copilot for building function definitions or jamming with Claude Code, one thing remains true: engineers are still responsible for the output of their software development work.
Before generative AI, you could never say “but the autocomplete did it” or “it came from Stack Overflow” as an excuse for why your code was buggy or didn’t adhere to your team’s standards. The same is true now, but the bar is higher: one prompt can generate thousands of lines of code. AI can produce a lot more code that looks polished and sophisticated (and therefore high quality) to the untrained eye, making it harder to catch issues. But the developers using it are responsible for that code!
The mistake people make is conflating the task with the role. It’s like saying calculators replaced accountants. Calculators automated arithmetic, but arithmetic was never the job. The job was understanding financials, advising clients, making judgment calls, etc. The calculator just made accountants faster at the mechanical part.
– AI Can Write Your Code. It Can’t Do Your Job. – Terrible Software
The mechanics of how we’re building software are changing, but our responsibility isn’t. And as engineering leaders, that responsibility includes making it clear what ownership looks like in an AI‑assisted world, and giving our teams the expectations, guardrails, and review practices that help them consistently ship high‑quality AI‑generated code.
2. Product engineers still matter
This responsibility extends to the expectations we set for the engineers on our teams. I’ve said before that I usually hire product engineers. They work well at a startup where we constantly need to put ourselves in the shoes of our customers to make good decisions. That approach is all the more critical when you’re using an agentic coding tool like Claude Code.
Paraphrasing a senior engineer at the first offsite last year where we hacked together on Claude Code: “I’m enjoying working with it, but sometimes I feel more like a product manager than a developer.” In today’s coding environment, engineers need to get comfortable with putting their product hats on, because much of their interaction with LLMs is done in prose, explaining the problem as much as working with agentic AI to build the solution. As leaders, we need to hire, coach, and reward that kind of product thinking, not treat it as a nice-to-have.
3. Tech debt still matters
Managing technical debt has always been one of the most critical engineering leadership responsibilities, but AI tools are now making it a higher-stakes game. AI tools don’t eliminate tech debt. In fact, they often multiply it. Even with AI agents, you still have to prioritize where to spend your time and energy. Are you fixing bugs, refactoring a service, or shipping new features?
Your architects are worried about tech debt, because agentic coding tools generate a lot more code, often with more complexity. So PRs (pull requests) can be larger and (as I mentioned above), the code can be quite polished, making the reviewer less likely to catch issues. All of this means architectural drift can be harder to detect.
Generative AI tends to follow patterns in the codebase (“when in Rome”), because it’s using this as context. While that can be good for consistency, it can quickly take antipatterns from localized tech debt and replicate them. In our recent work with AGENTS.md and spec-driven prompting, we’ve found that agents will tend to copy existing patterns even when specifically instructed not to.
Those of us in engineering leadership know that like all debt, you take on tech debt in order to gain speed. But you need to actively manage it, and that requires visibility and oversight at a level higher than individual developers working with agents.
4. PRs still matter
Commits represent the forward motion of a codebase. And PRs are the primary form commits have taken for many organizations’ SDLCs (software development life cycles). Often, we’re packaging one or more commits into a PR that becomes the unit we can check, review, merge, and deploy.
As we use AI more in our development, PRs have had to adjust. Keeping them small is a struggle, but in a call a few months ago with a fellow CTO, they mentioned Graphite, who introduced the concept of a stacked PR. The core idea is still small PRs, a long-standing best practice. Stacked PRs just organize those small changes differently, with workflow support for code review and merging. Thankfully, there are some open-source alternatives, because (hats off to them!) they’ve been acquired by Cursor and it’s not clear yet what will happen to Graphite’s tech.
While PRs often feel like purely developer territory, overseeing their quality and flow is a key part of your engineering leadership responsibilities. But PRs contain a ton of useful data about your team’s velocity, the way your team works together and with AI, and your codebase’s quality. They can give you insights into where your management and process change efforts are having a measurable impact.
These are all tied to your fundamental responsibilities as an engineering leader—and these unchanging responsibilities need better tools for you to execute on them effectively.
Engineering leadership responsibilities in a world in flux
If you have read one of the many “end of 2025 / start of 2026” think pieces, you’re likely feeling that our industry is very much in flux. This is spot on. AI is changing how code gets written, reviewed, and shipped. What hasn’t changed is your core engineering leadership responsibilities: understanding what’s happening in your codebase and leading your team through it.
The traditional ways we try to do that (dashboards built on tickets, time logs, or self‑reported status) weren’t designed for AI‑accelerated development. They’re derivative views of the work, one or two steps removed from where the real action is: the code, the commits, the PRs, and the architecture. That gap is exactly why these unchanged responsibilities feel harder to manage.
So what do you do about it? You stop managing from the edges of the process and start managing from the ground truth: the codebase itself. Instead of relying on derivative data, you use code‑first, AI‑native intelligence to see how your organization is actually building software, so you can understand:
- Where velocity is real versus noisy
- Where tech debt is compounding
- Where teams are blocked
- Where AI is genuinely helping (or just generating more code)
Flux is a code-first engineering intelligence platform built around that philosophy. It gives you, the engineering leader, ground-truth visibility into velocity, strategy, team focus, and quality so you can lead with confidence in a world where everything is in flux.
