Engineering Management in AI Era

Every day I can see how AI changes engineering management by making software implementation faster and cheaper. Smaller teams now own larger parts of a product, engineers are expected to work across the stack and think more about product decisions. In the AI era, coding capacity becomes less important, while judgment, ownership, and system quality become the real bottlenecks.

TLDR

Smaller teams do more

The most obvious change is team size. Today, even a normal product feature involves three or four engineers. There is a frontend part, a backend part, maybe a database change, analytics, tests, and some deployment work. Usually these parts are split between different people, so frontend engineer waits for the API, the backend engineer waits for product decisions, and then everyone waits for reviews. The actual code may take only a few hours, but the whole feature can take days because of all the coordination around it.

AI removes these handoffs. A good engineer now does more of the full feature alone, even if they are not an expert in every part of the stack. They use AI to understand unfamiliar code, get help with a small database change, write the tests, and move on. This is the reason teams become smaller. A team of three strong engineers with broad ownership moves faster than a team of ten people with strict frontend, backend, and platform roles.

Everybody is more full stack

I do not think specialists will disappear. You will still want a strong database engineer when the database problem is actually hard. You will still need people who deeply understand infrastructure, security, performance, and other difficult areas. What changes is that product engineers will need these specialists less often for normal work. A frontend engineer can make a small backend change without creating another ticket, and a backend engineer can fix something in the UI without waiting for someone else.

To me, this is what “full stack” means in the AI era. It does not mean that everyone becomes equally good at React, Postgres, Kubernetes, and security. It means that an engineer owns the problem and can move through enough parts of the system to solve it without handing every piece to another team. The specialist is still there for difficult problems, but routine work becomes much less dependent on them.

Product thinking is more important

If AI gets better at implementation, engineers who only know how to take a detailed ticket and turn it into code become less valuable. AI is already quite good at this kind of work when the task is clear. The more useful engineer is the one who understands why the task exists, whether the requirement makes sense, and whether there is a simpler way to do it.

This makes the shift from outputs to outcomes even more important. I wrote about the difference between the two in more detail in Outputs and Outcomes Mindset: delivering a feature according to requirements is an output, while the actual effect this feature has on users or the business is the outcome. AI makes producing outputs much cheaper, so engineers spend more time thinking about whether those outputs lead to useful outcomes.

This means engineers need more product thinking. Instead of giving someone a fully described task and asking them to implement it exactly, teams can give more context and more ownership. Explain the problem, explain why it matters, explain the limits, and let the engineer work out the solution. For engineering managers, this also changes the main question from “who has time to take this ticket?” to “who understands this problem well enough to own it?”

Managers give context, not just tasks

A lot of engineering management today is basically traffic control. Managers spend time deciding who is working on what, who has free capacity, which team owns a dependency, and who can review a change. This made sense when implementation itself was slow and expensive. With AI, engineers can build a first version quickly, so what slows them down is lack of context, not capacity.

An engineer may not know which tradeoff is acceptable, whether some strange behavior is intentional, or which part of the system is safe to change. If they do not know these things, AI simply helps them build the wrong thing faster. This is why I think one of the main jobs of an engineering manager is to make sure engineers understand the problem well enough to make decisions without asking for approval. The goal is not just to keep everyone busy; it is to make sure people can move fast without constant blocks. As I shared in How to Be a Good Manager article, give people freedom while providing trust, support, and direction.

AI helps create bad code much faster

The obvious downside is that AI can generate a lot of code very quickly, and that code can look fine at first. It compiles, the names look reasonable, there may be tests, and the pull request looks clean. At the same time, the implementation can still be bad because it adds too many abstractions, or solves a simple problem in a more complicated way than needed.

This creates a problem for code review. If an engineer used to create one big pull request every few days, another engineer could spend some time reviewing it carefully. If the same engineer can now create several meaningful changes every day, someone still has to review all of them. At that point, AI has not removed the bottleneck; it has only moved it from writing code to reviewing code.

Fewer blocking reviews and better guardrails

I do not think every normal change should need human approval forever. Instead, more quality checks should move into the system itself. If one part of the codebase is not allowed to depend on another, this should be enforced automatically. Common security issues are scanned automatically, and risky features are easy to disable or roll back.

Today, a lot of engineering quality depends on another engineer opening a pull request and remembering a long list of things to check. That approach becomes harder to scale when code becomes much cheaper to produce. Risky changes, architecture, security, large migrations still need human review. But using senior engineers to approve every routine detail is expensive, and AI makes that cost much more visible.

Engineers own what they merge

If teams reduce blocking reviews, engineers need to take more responsibility for what they ship. “AI wrote it” cannot be an excuse. If you asked AI to generate, check, and merge the code, then it is your code. You are fully responsible for it. When changes breaks production, you own the problem. If you do not understand the change well enough to be responsible for it, you should not merge it. Do not forget about leaving the code in a better shape than you found it.

Eventually this will become an important rule for teams that use AI heavily. AI is another way of delegating work, but delegation does not remove responsibility. Managers understand this idea because if they delegate work to someone on their team, they are still responsible for the result. Engineers need the same mindset when they delegate implementation to AI.

Architecture is even more important

It may look like architecture matters less when AI can write more of the implementation, but the opposite is true. AI is very good at copying patterns that already exist in the codebase. If the codebase has good patterns, this helps a lot. If the codebase has bad patterns, AI will copy those too and can spread them much faster than before.

Because of that, clear module boundaries, good naming, simple APIs, useful documentation, and consistent project structure become even more important. The codebase itself becomes part of the instructions for AI because agents look at existing code to understand how new code is written. This also means senior engineers and architects still matter a lot. A good technical decision now influences much larger amount of code, while a bad decision can spread just as quickly.

Technical debt can grow very fast

One of the biggest risks is that AI makes it much easier to create code, but it does not make it equally easy for humans to understand a large system. The codebase can therefore grow faster than the team’s understanding of it. At first this can look great because features keep shipping, pull requests move quickly, and everyone looks productive. After some time, however, nobody fully understands how everything works together.

At that point, engineers can start asking AI to change parts of the system that they only partly understand. AI adds another layer, then another agent works around that layer later, and the system becomes harder to reason about while still looking productive from the outside. This is why managers need to separate “we produced a lot of code” from “we made good engineering progress.” Sometimes the best change is deleting code, removing an abstraction, or deciding not to add another service.

The junior engineer problem

AI also creates a problem with junior engineers. For a long time, juniors learned by doing simple work such as fixing bugs, building small features, writing tests, and getting feedback from senior engineers. AI is already very good at exactly this kind of task, so from a company point of view it can be easier to give simple work to an agent instead of a junior engineer.

That works in the short term, but there is an obvious long-term problem. If every company wants only senior engineers, there will eventually be fewer new senior engineers. I think companies will need to teach juniors in a different way. They may spend less time proving that they know framework syntax and more time learning how to understand a problem, check AI output, debug real issues, find bad assumptions, understand architecture, and explain why one solution is better than another. In other words, we may need to teach judgment much earlier.

Performance reviews change

AI makes it very easy to look productive because engineers can create more code, more pull requests, more tickets, and more documents. None of this automatically means that they are doing better work. At the same time, two engineers with the same experience can now have very different output depending on how well they use AI. One person may use it mostly as autocomplete, while another may use agents to understand the codebase, test several solutions, write implementation, create tests, debug errors, and automate routine work.

The mistake would be to turn AI usage itself into a performance metric. Number of prompts, token usage, or AI-generated pull requests do not tell us much about value. Managers should still care about whether the engineer solved useful problems, made good decisions, improved the system, took responsibility, and helped the team move faster. AI makes activity easier to create, so managers need to care even more about outcomes.

Teams will need fewer coordinators and more owners

If these changes continue, I think engineering teams will become smaller and engineers will own bigger parts of the product. Specialists will still exist, but they will spend more time creating good patterns, tools, and guardrails for everyone else instead of being involved in every feature. There will probably be fewer routine blocking reviews and more automatic checks, and engineers will be expected to own what they ship.

Engineering managers will also spend less time moving work between people and more time making sure everyone has enough context to make good decisions (RACI framework can help with giving an overall context a lot). This does not make management less important. If engineers can move faster, bad direction becomes more expensive because a team with the wrong goal can build the wrong thing much faster than before. AI gives the team more power, so management has to make sure that power is used in the right direction.

Coding is cheaper, but good decisions are not

For a long time, engineering organizations were built around one main problem: writing software takes a lot of time. AI is changing that because we can now produce code much faster, but we still need people to understand customers, choose the right problems, make good tradeoffs, keep systems simple, and take responsibility when things go wrong.

I do not think the best engineering teams in the AI era will be the ones that write the most code. I think they will be the teams that can give a small number of good engineers a lot of ownership without losing control over quality. That means better context, better tests, better guardrails, simpler architecture, better monitoring, and engineers who can think about the product instead of only thinking about implementation.

For engineering managers, the job becomes less about managing how much code the team can produce and more about creating a system where people can make good decisions quickly. The upside is that smaller teams can do more, engineers can work across the stack, and companies can move faster. The downside is that without good ownership and technical rules, AI can help a team create bad software just as quickly as good software.

Less people management

The whole point of engineering culture was to build a comfortable environment where the best of the best shine, and the company strives for retention and happy engineers. Perks, equity, nice policy on time off, sane management were the pillars of good engineering culture, which involved heavy emphasis on people culture and relationships.

Nowadays we see companies firing people left and right. Companies fire seasoned specialists to replace them by cheaper engineers that are happy to have at least some job, which creates unhealthy competition on the market. Companies always focus on making money, so firing a team of engineers with high salary and getting cheaper engineers plus premium subscriptions to coding AI agents makes total fiscal sense.

This changes the engineering management as well – no need to nurture and care so much about engineers, since “where would you go if you are fired” reason. This is not good or bad, it just another view on people management problem. More competition, more stress, but this is world we live in.