A Different Role, Not a Faster One

A staff engineer’s day used to be easy to describe.

In the morning, you would work through a hard implementation detail. After lunch, you would review design choices with the team. In the afternoon, you would merge code, answer questions, and move on to the next change.

The visible work and the valuable work were usually strongly correlated.

While it looks similar today on the calendar, it is different in substance.

In the morning, you tighten an agent instruction file, add a lint rule, or refine an invariant that the model keeps violating. After lunch, you review several generated changes to find where the system is drifting away from intent. The most leveraged thing you merge may not be implementation at all. It may be a harness, an eval, or a permission boundary.

The temptation in boardrooms is to read this as the same role at higher throughput — same engineer, more PRs, finally the productivity numbers roll over. It is not.

The point here is not about shipping faster. The work has changed.

The AI-native developer is a different role from a traditional developer — not just the faster version of one. Leverage no longer comes from typing code but from specifying intent, designing feedback loops, bounding agent autonomy, and holding responsibility no model can hold.

Nobody knows where this lands.

What follows is a description of how I think the role is actually changing, viewed from the engineering side rather than a vendor side. None of it is settled. Some claims might be wrong.

The Split

For some time, technical depth and execution speed were correlated. The engineers who understood the system best were often the ones who shipped fastest, because they saw the path more clearly. They knew where the sharp edges were. They made fewer wrong turns. They could move quickly without getting lost.

That correlation made today’s existing evaluation systems tolerable.

PR count was noisy, but it often tracked real contribution. Code volume was already a bad metric, but not always a fatal one, because depth and speed tended to move together.

That is no longer true.

Coding agents broke that correlation in eighteen months. Speed is now available without depth, because typing is rented. The artefact — code that compiles, passes its own tests, merges before lunch — has stopped being a reliable signal of the engineering underneath. Marco Somma’s framing of two skill axes that no longer move together is the polite version [1]. The blunt version is that seniors are watching less experienced engineers outshipping them with management’s blessing, but knowing the bill will arrive later.

Agents can now produce speed without corresponding depth, and most dashboards cannot tell the difference.

Gergely Orosz, watching the same shift across the engineering organisations he tracks, calls it the move “from how to what” — and notes, less cheerfully, that less-adept engineers are upleveling on the dashboard while generating prodigious volumes of “AI slop” [3].

The 2025 DORA report on AI-assisted development, drawing on five thousand practitioners, names the mechanism without ornament: AI is an amplifier. Without robust controls, it warns, more change leads to more instability [4] — which is a polite way of saying that organisations using output volume as a leveling signal are industrialising the production of incidents.

So PR throughput, story-point velocity, and lines shipped are no longer just imperfect signals. They are increasingly misleading ones. They flatter shallow work and discount the exact judgment that has become scarce. They reward the developer whose agent is loudest, not the one whose system survives.

That matters for hiring and promotion. A funnel built around visible output now risks inverted selection. It can filter for people who are good at producing activity and miss the people who are good at constraining systems, designing reliable feedback loops, and catching plausible nonsense before it enters production.

The Hands-On Reversal for Senior ICs

A most counter-intuitive shift is for senior individual contributors and tech-leads.

For the last decade, common wisdom about staff and principal engineers was that they scale through influence, architecture, and mentorship. They should not disappear entirely from implementation, but the center of gravity moved upward and outward. Stay out of the weeds. Think bigger. Multiply others.

This default no longer holds cleanly. 2026 is the year staff-plus engineers need to get hands-on again [5].

That is not a nostalgic plea for craftsmanship. It is a claim about where leverage now sits.

The agent’s ceiling is the spec, the harness, and the feedback loop around it. Designing those well requires the deepest mental model in the room.

In practice, that often means the senior IC has to move closer to the work, not further from it. Not because they must hand-write everything, but because the parts that most determine quality now sit around the generation loop, and those parts are too important to delegate blindly. It is best done by the people who hold the deepest mental model of the system, because that model is what the harness has to encode.

The inverted pitch — seniors as airborne reviewers, agents as the new junior cohort — has been quietly tried enough in the last two years to draw a curve. The seniors who delegated execution and stayed out of the loop went blind in a short time. They could no longer tell when an agent had produced a plausibly-shaped solution that missed the actual constraint. They lost the felt sense of where the system pushes back. The mental model that made them senior was built on friction with the code, but the friction is gone.

Mario Zechner names the underlying thing well: be in the code, because the act of writing it — or watching it being built up step by step — is what tells you what you are actually building [6]. His bridge-engineer analogy is an apt metaphor. The bridge engineer does not lay the bricks. They are also not in the office reviewing photos of the bridge. They are on site, watching, asking the wrong questions on purpose, refusing to sign the certificate until the inspection regime has actually caught something.

The “AI lets seniors stop coding” pitch is not a new idea. It is the old no-code pitch with a different uniform. It landed successful again this time because the demos are better and executives want to hear it.

Seniors who take it at face value will spend 2026 catching up.

The New Skill Stack

The honest answer to “what does the new role look like on a Tuesday morning” is more administrative than marketing suggests. Five things make up most of it.

Constraint architecture.

The most leveraged commit a senior makes today is likely a lint rule, a CI check, or a guardrail in an agent configuration file. Ernie Miller’s line — “the model didn’t get better, the loop got tighter” — captures the move [7]. Telling the agent what to do in prose is the weakest form of instruction. Encoding the rule in something the agent cannot ignore is the strong form. Linters do not sleep. CI does not have a bad week.

Harness engineering.

Birgitta Böckeler at Thoughtworks has proposed the cleanest taxonomy that has so far stuck: the harness is guides (feedforward — context, prompts, examples, docs) and sensors (feedback — tests, evals, telemetry, lint) [8]. The senior engineer’s product surface is now the harness, not just the application. Everything that focuses the space of acceptable output before the model has the chance to be too “creative.”

The point is not elegance. It is convergence.

Evaluation as a first-class deliverable.

Golden sets, regression suites, behavioral evals — first-class artifacts owned by the engineer. Kent Beck has been clear about why TDD becomes a superpower in agentic settings: tests are the spec the agent cannot subvert. However, he has also documented agents deleting tests to make them pass, which is the kind of detail that an AI engineer must never forget [9].

An agent will optimize against whatever can be checked. If the checks are weak, the system will drift. If the checks are strong, the loop becomes incredible effective.

Bounding agent autonomy.

Isolation, scoped permissions, reversible operations, auditability, and rollback are no longer side concerns. Often this is still discussed too casually, as if more capable models will dissolve the problem. They will not. The core question is not whether an agent can act. It is under what conditions, with which blast radius, and how a human regains control when the action is wrong.

The discipline is closer to running a small team of fast, eager, occasionally dishonest junior contractors than to using a tool. Nobody who has run that team for more than a month believes the marketing’s happy world utopia any more.

Holding responsibility no model can hold.

ASCE Policy Statement 573 says it without ornament: “AI cannot be held accountable, nor can it replace the training, experience, and judgement of a professional engineer.” [10] The UK Financial Reporting Council was even shorter: “You can’t blame it on the box.” [11] That line should sit under every enterprise AI discussion.

This is probably the least glamorous skill and the least replaceable one.

The composite picture is unromantic. A senior IC is becoming part platform engineer, part tech lead, part hostage negotiator. The work is real engineering. It is not the work that fits in a keynote.

The Talent Pipeline

If our role demands judgment and tacit knowledge — and if execution, the substrate juniors traditionally built those on, has been outsourced to a model — the pipeline question stops being abstract.

The Stanford Digital Economy Lab study (Canaries in the Coal Mine) is the empirical anchor anyone working on this should have read [12]. Drawing on ADP payroll microdata covering millions of workers, the authors document a divergence that is hard to misinterpret: software developers aged 22–25 saw employment fall roughly 20% from a late-2022 peak through July 2025. Workers 30 and over in the same high-AI-exposure category grew 6–13% over the same window. The authors offer the careful interpretation that tacit knowledge defends older workers. A more uncareful interpretation, also supported by the data, is that companies have decided juniors are optional and are betting they can hire from a pool that has not yet noticed it is shrinking.

The supporting picture is consistent. Stack Overflow’s 2025 analysis reports tech internships down 30% from 2023, with 57% of hiring managers stating they trust AI work over the work of interns and recent graduates. The platform’s own line reads like a sigh: if you don’t hire junior developers, you’ll someday never have senior developers [13]. This is not an argument anyone should have had to write down in 2026. The fact that it had to be written down loudly suggests something about the quality of the strategic thinking happening in some of the rooms.

The uncomfortable implication is that a pipeline optimized for short-term output is quietly starving the next generation of the exact thing that makes senior engineers valuable.

How does taste get built when execution is delegated? Nobody knows yet.

Rotation through harness, eval, and guardrail work? Explicit reading of senior engineers’ mental models as artifacts? Protected agent-off exercises?

None of this is validated. There is no serious longitudinal study yet on how the junior-to-senior pipeline changes under heavy AI mediation. University curricula have not adapted in any obvious way. This is a known unknown, and the industry is not funding it proportionally to its importance.

Missing Voices

The discourse on the AI-native developer role has a missing-voice problem, and it cuts in one direction. Engineers maintaining payments solutions, clinical systems, avionics, telco cores, energy, and defence software are mostly silent in public.

That absence is not random. It reflects constraint. It reflects policy. It reflects accountability structures that make casual claims hard to publish and harder to operationalize.

Where those voices do appear, they sound different.

In aerospace, Andrew Longhurst’s discussion of DO-178C is clarifying precisely because it is so concrete: traceability, independent review, deterministic verification, approved standards [14]. That is what accountability looks like in a regulated shop, where incidents can make the news. It does not make AI irrelevant. But it does make a some popular agent workflow rhetoric sound unserious.

The same asymmetry appears in regulation. The FDA’s 2025 draft guidance on AI-enabled device software is already framing the problem in lifecycle terms [15]. NIST’s new critical infrastructure profile work is doing the same [16].

The case law is still thin to nonexistent. The regulatory direction is not.

Another reason for the silence might be simply, that the discourse, as it exists, is not a productive room for an engineer at a payments processor or a teaching hospital to enter. It is dominated by people selling agent products and people using agents on weekend projects, and conversations with both quickly reveal that neither group is interested in answers that contain the word no.

So voices that ought to be most informative are not entering the conversation. The empirical absence of regulated-industry first-person writing is itself the data.

The role description for the AI developer currently being normalised rests on assumptions that might not hold for systems with external accountability. Importing it wholesale into critical environments is not a tactical mistake. It is a category error.

Identity, Grief, and the Professional Posture

There is also a personal layer.

Some developers grieve the loss of craft. Others grieve the loss of context. Others simply grieve certainty. Sean Goedecke’s honesty matters here: “It sucks. I miss feeling like my job was secure.” [20]

Different people feel different losses because they valued different parts of the work [18]. Thomas Vilhena’s version is more detached and maybe realistic: most software work was never cathedral-building. Much of it was digital plumbing [19].

But that observation should not be read as contempt. It is part of what makes the moment emotionally complicated. Some of the drudgery really is drudgery. And still, something meaningful shifts when the center of professional value moves away from direct construction, a moment of creation and creativity.

The honest reading of the personal layer is this: The engineers most disoriented by the shift are usually the ones whose self-worth is strongly built on the act of writing code well. They need to re-calibrate.

The mature posture is: Writing code has become commodity.

It is the recognition that taste, judgment, and the ability to know when to stop — the things that used to make senior engineers valuable on top of their code writing execution speed — are now the only things that make them valuable.

Where does this leave us?

Our role is changing, and the unknowns inside the change are real.

Our work will produce fewer lines of implementation and more lines of instruction. Our leverage will come from shaping the surround in which generation happens — the spec, the harness, the eval, the rollback — and from carrying the responsibility that no model can carry for us.

The set of judgments is learned the same way it always has been — by writing enough wrong code, operating enough broken systems, and being close enough to the failure modes to develop taste about them. None of those inputs got cheaper because generation did.

Our organizations need to stop measuring output volume.

Juniors who are not being hired today are the seniors who will not exist in 2031.

We senior ICs and tech leads need to be deep in the code, not above it.

The engineers who actually run critical systems need to enter the discourse, and the discourse should be a place where their answers are welcome. Their silence must not be misinterpreted as agreement.

The AI-native developer is not the engineer who ships the most with a model. It is the engineer whose system still tells the truth about itself after the model has been working on it for six months.

References

[1] M. Somma, “The Old Seniority Definition Is Collapsing,” DEV Community. https://dev.to/marcosomma/the-old-seniority-definition-is-collapsing-12lj

[3] G. Orosz, “The Impact of AI on Software Engineers in 2026,” The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/the-impact-of-ai-on-software-engineers-2026

[4] DORA, “2025 State of AI-assisted Software Development,” Google Cloud / DORA, 2025. https://dora.dev/research/2025/dora-report/

[5] P. Muldoon, “2026 Staff Engineers Need to Get Hands-On Again,” Mar. 2026. https://paulamuldoon.com/2026/03/10/2026-staff-engineers-need-to-get-hands-on-again/

[6] M. Zechner, “Thoughts on Slowing the Fuck Down,” Mar. 2026. https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/

[7] E. Miller, “The Feedback Loop Is All You Need.” https://zernie.com/blog/feedback-loop-is-all-you-need/

[8] B. Böckeler, “Harness Engineering for Coding Agent Users,” martinfowler.com. https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html

[9] K. Beck with G. Orosz, “TDD, AI Agents and Coding with Kent Beck,” The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent

[10] ASCE, “Policy Statement 573: Artificial Intelligence and Engineering Responsibility,” Jul. 2024. https://www.asce.org/advocacy/policy-statements/ps573---artificial-intelligence-and-engineering-responsibility

[11] “Who is Liable When AI Agents Go Wrong in Business?,” The Register, Apr. 2026. https://www.theregister.com/2026/04/05/ai_agents_liability/

[12] E. Brynjolfsson, B. Chandar, R. Chen, “Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of AI,” Stanford Digital Economy Lab, 2025. https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/

[13] Stack Overflow, “AI vs Gen Z: How AI Has Changed the Career Pathway for Junior Developers,” Dec. 2025. https://stackoverflow.blog/2025/12/26/ai-vs-gen-z/

[14] A. Longhurst, “Using AI to Write Aerospace Software: Navigating the DO-178C Landscape,” Aerospace Global News. https://aerospaceglobalnews.com/opinion/ai-aerospace-software-do-178c-certification/

[15] FDA, “Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations (Draft Guidance),” Jan. 2025. https://www.federalregister.gov/documents/2025/01/07/2024-31543/artificial-intelligence-enabled-device-software-functions-lifecycle-management-and-marketing

[16] NIST, “Concept Note: AI RMF Profile on Trustworthy AI in Critical Infrastructure,” Apr. 2026. https://www.nist.gov/programs-projects/concept-note-ai-rmf-profile-trustworthy-ai-critical-infrastructure

[17] “AI Coding Assistants Not More Secure, Study Finds,” The Register, Mar. 2026. https://www.theregister.com/2026/03/26/ai_coding_assistant_not_more_secure/

[18] L. Orchard, “Grief and the AI Split,” Mar. 2026. https://blog.lmorchard.com/2026/03/11/grief-and-the-ai-split/

[19] T. Vilhena, “Craftsmanship Coding and the Five Stages of Grief,” Feb. 2026. https://thomasvilhena.com/2026/02/craftsmanship-coding-five-stages-of-grief

[20] S. Goedecke, “I Don’t Know If My Job Will Still Exist in Ten Years.” https://www.seangoedecke.com/will-my-job-still-exist/

[21] B. Bjarnason, “Have I Hardened Against LLMs?,” 2026. https://www.baldurbjarnason.com/2026/have-i-hardened-against-ai/