THE TEXTS
Welcome to The Quiet Responsibility
Today something new starts: a steady, bilingual body of writing about everything a tech lead does that doesn’t show. Two articles a week, named seasons, one year ahead. Here is the map, and the invitation.
S1Nº 01
Your first 90 days as a new tech lead
The first months as a new tech lead shape more than most people realize, and what matters most is the trust you build, not what you manage to get done. Phase by phase: observe, map, build trust, and only then propose. Plus the three mistakes almost everyone makes.
S1Nº 02
Stop writing code: Why your most important PR is the one you never open
One of the most common mistakes new tech leads make is continuing to be the team’s best developer. Every hour you spend writing code yourself is an hour not spent on the thing only you can do: holding the system and the team together.
S1Nº 03
Code review in the AI age: Judging code no one wrote
When the code in a pull request was generated in seconds, the reviewer’s role changes fundamentally. It is no longer about typos and better names, but about judging something the author themselves may not fully understand. What happens to code review when code is no longer written, but chosen?
S1Nº 04
Prompt divergence: When the team’s most-used tool isn’t standardized
Teams standardize formatting, logging and API design, but not the way they talk to AI. The result is that the same question yields wildly different answers, and the codebase slowly pulls in different directions. Prompts have become a new kind of standard, and they can be brought together without bureaucratizing the everyday.
S1Nº 05
AI and technical debt: Faster code, faster debt?
Technical debt has always grown with the pace of work, and the pace now has a turbocharger. AI can produce code faster than the team can understand it, and code no one fully understands can become debt no matter how tidy it looks. Some of the debt mechanics change when the code is generated. Others stay exactly as they were.
S1Nº 06
The junior developer in the AI age: Building judgment when answers are free
AI gives junior developers access to senior output from day one. But output is not the same as understanding, and understanding is not the same as judgment. Here is how a tech lead can help new developers build their own judgment in an era where the answers are always one question away.
S1Nº 07
AI usage guidelines people actually follow
Many teams have been handed an AI policy by the organization. Few teams have an AI practice that lives in the everyday. What closes the gap is a one-page guideline the team actually owns, uses, and improves.
S1Nº 08
The review bottleneck: When AI produces faster than the team can judge
Generation has become cheap, judgment is still expensive. The asymmetry moves the bottleneck from production to review, and if the tech lead becomes the only quality gate, everything stops. The solution is mechanisms that scale evaluation capacity, not control.
S1Nº 09
TDRs in the AI age: When the decision was made by a model
When AI helps explore a technical choice, the team still needs to record its reasoning. A practical example shows how to document assumptions, alternatives, and the checks that remain.
S1Nº 10
Onboarding in the AI age: When new developers learn the system from a model that doesn’t know it
When new developers use AI to understand the system, the team’s shared context is tested too. How onboarding can reveal gaps, explain local choices, and make knowledge easier to share.
S1Nº 11
Architecture with AI as a sparring partner – without losing ownership
AI can help a team explore architecture choices. But proposals need to be tested against the system you actually have. A migration shows why experience, design review, and shared ownership still matter.
S1Nº 12
Decision latency in the AI age: More alternatives, slower choices
AI was supposed to make us faster, and at writing code it did. But on decisions the opposite often happens: when alternatives are free, choosing gets expensive. Third in the series on decision latency: infinite alternatives have become a new form of postponement, and closing a question matters more than it ever has.
S1Nº 13