---
title: "The Weight of Experience: When Yesterday's Senior Becomes Tomorrow's Bottleneck"
description: "Companies hire technical leadership for mastery of Scrum and the old agile guard, a paradigm that AI-native engineering is making obsolete. The analogy is cruel: it's like naming the paper-check banker to lead in the age of instant payments."
author: "Anderson Henrique"
date: "2026-06-30T23:43:48.308522Z"
updated: "2026-06-30T23:55:41.503069Z"
category: "philosophy"
tags: ["AI","Software Engineering","Technical Leadership","Cyborg Developer","Hiring","NTLabs"]
canonical: "https://www.ntlabs.dev/en/blog/peso-experiencia-engenharia-ia"
locale: "en"
---

I've talked to a lot of people over the past few months, in interviews, in hiring loops, in backchannel conversations about who should lead whose engineering. And I walked away from almost all of them with the same uneasy feeling: **the processes are inverted.**

Companies keep hiring technical leadership by the same criterion as ever: years on the road, command of Scrum, fluency in the agile vocabulary, the scars of a thousand sprints. Résumés that prove, above all, **mastery of a paradigm**. The problem is that this paradigm, "agile" development as we know it, is becoming yesterday's fashion right before our eyes. And the experience accumulated in it, which should be an asset, is quietly turning into a liability.

## The check-and-wire analogy

Picture a banker with 40 flawless years of career: four decades of mastery over paper checks, wire windows, clearing delays, the teller line. Nobody understands "money" the way they do. Now picture an instant-payments world (money that moves in seconds, programmable, 24/7, with no intermediary) and a fintech that decides to hire this banker as head of product.

Here's the cruel part: **all that experience isn't neutral.** It isn't a zero that merely fails to help: it's a negative number. Forty years of checks built intuitions, "best practices" and deep reflexes that, in the instant-payments world, are precisely the wrong moves. Experience, in this specific case, isn't an advantage. It's **ruin.**

Not because the person isn't brilliant. But because their most valuable asset, a mental model refined over decades, was built on a foundation the ground just swallowed.

## Why "agile" is the paper check in this story

Let's be honest about what Scrum solved. It was an organizational response to a **fundamental scarcity: the production of code.** Writing software was slow, expensive and risky. So we created ceremonies to manage that slowness: estimating uncertainty in story points, slicing work into sprints, syncing humans in standups, shielding the team from scope change with rituals.

Almost the entire agile apparatus exists to administer the **cost and unpredictability of typing code.** It was the accounting of scarcity.

And that scarcity is ending. When a significant share of implementation gets orchestrated with AI, the constraint stops being "how much code can we produce this sprint" and becomes **"how well can we specify, validate and architect intent."** The bottleneck migrates from the hands to the judgment. And when the bottleneck moves, every process optimized for the old one becomes theater: the standup becomes theater, the story point becomes theater, the sprint becomes theater.

The CTO hired for mastery of that theater will, with the best of intentions, **trim the ship for a wind that has stopped blowing.**

## The inverted processes I see in interviews

The clearest symptom isn't a lack of knowledge. It's the **inversion of the question.** Watch the order of operations:

- *Velocity* and team capacity get discussed before what makes a specification good enough for a machine to execute faithfully.
- Productivity gets measured by code shipped, in a world where generating code became a commodity and the expensive part became **reviewing, validating and understanding** what was generated.
- AI gets treated as an autocomplete tool that "speeds devs up," when it is in fact a **paradigm shift in the unit of work.**
- The process gets shielded from change, when the competitive edge has become the speed of *re-architecting* in the face of it.

These are leaders trying to fit a new reality into old categories. And old categories are stickiest precisely when they've been successful. **Nobody abandons a map that worked their whole life just because the territory changed.**

## The distinction that keeps the thesis from becoming prejudice

Here I have to be surgical, because it's easy to read all this as "fire the seniors and hire the juniors who play with AI." That's not it. That would just trade one dogma for another.

Experience and obsolescence **are not the same thing**. They merely tend to travel together. What ages badly isn't the knowledge; it's the **attachment to the paradigm** in which that knowledge was acquired. There are two kinds of seniority, and the market is confusing them:

1. **Seniority-as-inventory:** the value lies in *knowing the answers* of a specific paradigm. That one depreciates as fast as the paradigm changes, and the paradigm has never changed this fast.
2. **Seniority-as-method:** the value lies in *knowing how to ask good questions*, modeling problems, reading trade-offs, smelling risk. That one is antifragile. An engineer with twenty years of architectural taste and the humility to throw away their own reflexes is, today, **the most valuable person in the room.**

The market's problem isn't hiring experienced people. It's hiring for the *wrong* experience: rewarding the inventory of a dead paradigm instead of the method that survives its death. The right question in a 2026 technical-leadership interview isn't *"how many years of Scrum do you have?"* It's *"tell me about the last time you had to throw away something you were very good at."*

## What we're building instead

At **NTLabs**, our bet has a name: the **Cyborg Developer**. We don't believe in "AI that replaces the engineer," nor in the nostalgia that "deep down nothing changes." We believe the unit of competence has stopped being the individual or the model, and has become the **intra-action** between the two, the central thesis of our *Developer Mental Model Framework (DMMF)*.

In practice, this rewrites what we ask of technical leadership. Less guardian of ceremonies, more **architect of intent**: someone who designs the boundaries within which human and AI collaborate, who turns judgment into executable specification, and who measures the team by the quality of its decisions and validations, not by how many lines survived the end of the sprint.

Experience still matters. It just moved to *where* it matters. The check-and-wire banker who understands, in their bones, what liquidity, risk and trust are has everything it takes to be brilliant in the instant-payments era, as long as they accept that the way money moves now is different. The senior who thrives in the coming years isn't the one with the most answers. It's the one with the method to **keep asking the right questions after the old answers stopped working.**

Obsolescence never comes from time on the road. It comes from the day you decide the road has already ended.

---

*This post is part of our reflection on **transparent engineering** at NTLabs: how we build, hire and think about software in the age of the Cyborg Developer.*