The details in the examples below are composites from several companies and situations I have observed over the last 2 years. I am not writing about specific people. I am writing about a pattern that is becoming more common and that few people talk about out loud.
It was a normal Thursday. I opened the dashboard with the team's metrics. Velocity was stable. Incidents were within the normal range. Features were shipping almost every week. On paper, a healthy engineering organization.
I closed the dashboard and opened a pull request that I had to review. Forty minutes later, I realized one thing that made me uncomfortable -- I could not remember the last time anyone in this company had made an architectural decision consciously. Not reactively, when something was already on fire. Not by accident, as a side effect of someone's feature. But consciously, sitting down, looking at the system as a whole, saying "this is where we are going and why."
The answer was -- a long time ago. Maybe never.
And at the same time, everything was working. That is the trickiest part.
Over the last two years, I have been watching a pattern that few people talk about directly -- AI assistants have allowed startups to delay the payment for engineering management by one or two years longer than was possible before. And this delayed payment is growing invisibly, until it stops being invisible.
This is not an article about how AI hurts engineering. AI is a great tool, and teams that use it really are faster. This is an article about something else -- that speed without direction creates an illusion of health, and an illusion of health is the worst state for an organization, because there is no motivation to get out of it. You know the feeling of a warm bath? That's what it is.
If you are a founder looking at your team and thinking "we are doing fine", maybe this article is for you. If you are an engineering manager who feels that something is wrong but cannot name what, also for you.
What a healthy team looks like on the surface
Imagine a startup. Fifteen engineers, five of them seniors, the rest mids and juniors. The product is B2B SaaS, the market is growing, customers are happy. The team uses Cursor, Copilot, Claude Code, the whole set. Features ship fast. A junior with an AI assistant closes in one day what three years ago would have taken a mid-level engineer a week.
The founder looks at this and sees that the machine is working. He presses a button, the button works. He asks for a feature, the feature appears. He looks at Jira, tickets are closing. All the metrics he is used to looking at are green.
What could be wrong?
First. AI hides the absence of judgment
Here is what AI gives an engineer -- the speed of writing code. Here is what AI does not yet give -- the speed of making decisions about which code to write.
When a senior wrote a feature in 2020, he spent 20% of the time typing code and 80% thinking. Which invariants must this system support? How does it integrate with what is already there? What will break in six months if we do it this way? Typing code was the bottleneck, so it felt like the job was to write. In reality, the job was to think.
AI made typing code ten times faster. It did not make thinking faster. So now, when a junior with AI finishes a feature in a day, it does not mean he did the same work that a senior used to do in a week. He did the typing. The thinking was either done by someone else (usually not) or it was not done at all (usually this).
The code comes out working. It passes the tests. It closes the ticket. But it carries assumptions that nobody thought through, and these assumptions become part of the system.
The founder does not see this. From his point of view, the feature is done.
Second. The vacuum of technical leadership
In a healthy organization, there is a person whose job is to think about the system as a whole. Not to write code (although she can), not to manage people (although she can), but to own the technical vision. You can call this person different names -- CTO, VP Engineering, staff engineer, principal. The name does not matter. The role does.
This person makes decisions that a regular engineer does not have the authority or context to make -- where we are migrating in a year, which technologies we do NOT pick, where we consciously pay technical debt for speed, and where we do not. Without this person, every engineer makes locally optimal decisions in his own ticket, and in a year you have a system that is the sum of fifteen local optima. This is never a healthy system.
In many startups, this role is either not filled, or filled formally. The founder hired a CTO but does not let him have influence, because he was the first engineer himself, he built the MVP himself, and internally he is not ready to hand over technical decisions. The CTO tries for some time, then leaves. The position stays open, or it is closed quietly with the words "we have a flat structure now."
After that, technical decisions are made by the founder, in passing, at status meetings, in three minutes, without context. Or they are not made by anyone, each person does what he is used to.
Third. Dysfunctional behavior that nobody can correct
Here is where the least pleasant part begins.
Imagine there is a person in the team who codes poorly. Not a disaster, but noticeably worse than the rest. He reacts defensively to code reviews. When someone suggests changing the approach, he hears it as a personal attack. He may answer aggressively, may sabotage the discussion, may just ignore it.
In a healthy organization, this is fixed quickly. Not because the person is fired, but because there is someone whose job it is to say -- "Listen, here are our code review standards, here is how we communicate, here is what needs to change." This is a conversation led by a manager or a tech lead. Unpleasant, but routine. After it, either the person adjusts the behavior, or it becomes clear that he does not fit, and that is also resolved.
In an organization without engineering management, this conversation never happens. Other engineers cannot have it, they do not have the mandate. The founder does not have it, he does not see the problem, because he does not sit in code reviews, and his metrics are green. HR does not have it, it is not their area, or there is no HR. So the behavior becomes fixed. Slowly, the rest of the team learns to go around this person, not to put him on critical tasks, not to give him complex reviews, silently rewriting his code.
This is another form of technical debt, organizational debt. You cannot see it in the code, but it shapes the code.
Fourth. Engineers who take on the role without a mandate
In such a vacuum, someone always appears who starts doing the work of an engineering manager informally. Usually it is the person who hurts the most, a senior who sees where this is all going.
He starts doing careful code reviews. He writes design docs that nobody asked for. He raises architecture questions at meetings. He tries to set standards. He does all of this without authority, without recognition, without time allocated for this work, because officially he is an IC, and his KPIs are closed tickets.
This is the fastest path to burnout in engineering. Not overtime, not hard technical tasks, but responsibility without a mandate. When you see a problem, try to solve it, and the system silently answers you -- this is not your role, nobody gave you this authority, go work on your tickets.
In a year, this engineer leaves. Usually to a company where roles are defined more clearly. The founder is surprised -- "but things were fine, he was productive." Yes, he was. At the cost of an internal resource that lasted for a year.
Fifth. Technical debt as a symptom, not a disease
When an incident finally happens in such a company, performance degrades, something fundamental breaks, a customer complains about a bug that cannot be reproduced, a conversation about technical debt begins. "We have a bad codebase. We need to refactor. We need to rewrite that module."
This is the right conversation, held at the wrong level.
The codebase is bad not because the engineers are bad. It is bad because nobody owned the technical vision for two years. Every engineer made reasonable local decisions. The sum of these decisions is a codebase that has fifteen different patterns for the same thing, three approaches to error handling, two testing styles, and no consistency in how things are named.
Refactoring will not fix this. In a year, it will be the same with the new code, because the process that produced this codebase has not changed. As long as there is no person whose job is to own the technical vision, the codebase will regress to its natural state, the total entropy of fifteen separate judgments.
What to do about it
I am not going to sell you a silver bullet. But there are a few things I would do first if I came into such an organization as a founder or a new engineering leader.
First, admit that the role exists, even if it is not filled. Engineering management does not disappear when you do not hire a CTO. It is just done chaotically, most often by the founder himself in moments of crisis. The question is not whether there should be engineering management. The question is whether it will be conscious or accidental.
Second, if you hired a CTO or VP Engineering, let him make technical decisions. Even the ones you do not agree with. Especially the ones you do not agree with. Otherwise, you are paying a senior salary to a person who is functionally your secretary for technical questions, and in a year he will leave. This is not theory. This is the most common scenario I see.
Third, do not confuse velocity with health. A team that closes tickets fast can be healthy, or it can be a team that takes on debt faster than it pays it back. The difference between these two states is invisible in metrics for the first year and a half. Then it becomes very visible.
Fourth, if you have a person in the team who informally plays the role of a tech lead without a mandate, recognize it officially. Give her time, authority, influence on decisions. If you are not ready, say it honestly, so that she can decide whether she wants to stay. The worst option is to silently consume this work without calling it work.
Fifth, AI does not remove the need for technical judgment. It amplifies it. When a team produces code five times faster, the cost of a bad architectural decision also grows five times, because a bad pattern spreads through the codebase faster than you can notice it.
Coming back to Thursday
That Thursday, I closed the pull request, left a comment, and went to the kitchen to make coffee. While the kettle was boiling, I was thinking about that dashboard with green metrics and about my thought -- "I cannot remember the last time anyone made an architectural decision consciously."
Strange thing, the metrics were not lying. They were just measuring the wrong thing. They were measuring how much we do. They were not measuring whether we think about where we are going.
And this, it seems, is the real task of engineering management in 2026/2027. Not to write code, AI assistants and juniors do that now. Not to review every PR, that is not realistic at the current speed. But to think about where the team is going, when it goes faster than ever, and when nothing in its metrics shows the direction.
Someone has to do this. If nobody does, you are not in a healthy team. You are in a team that is lucky, for now.