AI-era engineering
Everyone is coding. Nobody is talking.
The problem with faster code generation isn't only what gets shipped. It's what engineers stop learning from one another.
By Mike Salari. Staff mobile engineer · 500+ technical interviews from the hiring side.
5 min read
I've worked on mobile teams long enough to remember when a difficult pull request could turn into the best conversation of the week.
Someone challenged a boundary between modules. Someone else questioned why we cached a value. A third engineer knew about an older app version that would break if we changed the contract. The review took longer than clicking approve, but by the end, more people understood the system.
The code wasn't the only thing the team produced. It produced shared understanding.
That part is easy to lose when everyone is rewarded for moving faster.
AI coding tools have made it much easier to produce an implementation. They can draft tests, refactor a component, explore an unfamiliar API, and propose changes across multiple files. The standard for the output is the same regardless of who wrote it: can the engineer responsible explain what it does, why the design fits, and what might break?
The troubling pattern isn't an engineer using AI. It's a team changing how it works because producing code is now faster than reviewing it.
The queue nobody planned for
Imagine that five engineers can each prepare a larger change in an afternoon. The team still has the same five engineers to review those changes. It still has the same test environment, release process, and people who know the tricky corners of the product.
Output capacity increased. Verification capacity did not necessarily increase with it.
The consequences are mundane. Pull requests become longer. Reviews focus on whether the tests are green rather than whether the change belongs in the architecture. Comments become shorter. A design choice that would once have been discussed in a meeting arrives as 900 lines of apparently finished code.
One person approves because the change looks reasonable. Another approves because the first person did. A third engineer inherits the result six weeks later and has to reconstruct why it works that way.
None of this requires a dramatic failure. It can happen while the release dashboard looks excellent.
The metric that bothers me is not how many lines an engineer generated. It's how many consequential decisions the team can still explain.
The review that teaches nothing
A useful code review does at least two jobs. It checks the change, and it transfers context.
When I review a mobile change, I want to know whether it behaves correctly after navigation, session changes, old app versions, background execution, and network interruption. I also want the author to know why I asked those questions.
If an AI tool writes the first implementation and the engineer accepts it without understanding the trade-offs, the review can become a second round of automated approval. The tool proposes. Another tool summarises. Humans press merge.
That may be enough for a low-risk mechanical change. It is a poor habit for changes that affect data ownership, authentication or persistence.
I don't want every PR to become a seminar. A one-line fix doesn't need a meeting. I do want teams to notice when the value of a review lies in the reasoning, not the diff.
A practical test: choose your last substantial PR. Without opening the AI conversation or the final diff, explain the alternative you rejected. Explain what might have failed if you had chosen it. Explain who would notice first.
If those questions are difficult, the number of PRs merged this month may be telling you less about your growth than you think.
What disappears from your career
The cost can show up when you try to describe your work outside the company.
A senior interview rarely ends with a list of technologies. Someone will ask why you made a decision, what the other options were, who disagreed, and what changed after you shipped.
You can have a very busy year and surprisingly little to say about those questions.
Perhaps the agent generated the implementation and you handled integration. Perhaps the tickets were so small that nobody owned the end-to-end behaviour. Perhaps you never had to defend a design because every review was rushed through.
That does not make you a weak engineer. It means the work environment may not be giving you enough opportunities to practise a part of the job that becomes more important with seniority.
People grow through responsibility, feedback and hard technical conversations. More output helps only when some of that output turns into better judgement.
The awkward question for engineering leaders
If your team can generate code twice as quickly, what have you changed about review capacity, test coverage and ownership?
I would be much more impressed by a team that could answer that question than one showing me a chart of AI adoption.
There are good answers. Smaller changes, explicit owners, design reviews reserved for consequential decisions, stronger automated checks, and time set aside for engineers to explain unfamiliar code to one another.
There are also teams where AI improves both delivery and learning. Engineers use it to explore alternatives and spend more time on architecture and debugging. That is a good outcome worth protecting.
The tool doesn't choose the team culture. The decisions around the tool do.
Three things I'd change this week
First, don't send a large AI-assisted PR without a short note explaining the decision that mattered most. A reviewer should not have to reverse-engineer your reasoning from the code.
Second, protect some reviews as conversations. If a change affects a public API, persistence model or shared service, involve someone who can question the contract, not only the syntax.
Third, keep a record of decisions you personally owned. What changed, why you chose that approach, who depended on it, and what happened afterwards. Those notes are valuable for future design discussions, performance reviews and interviews.
You don't need to reject AI to do any of this. You need to resist the idea that using AI makes engineering judgement optional.
A faster implementation is useful. A team that can still explain its system is much harder to replace.
If a busy year has left you with plenty of shipped work and few decisions you can explain, that is the gap the Engineer Career Rebuild closes: your CV and LinkedIn rebuilt around the decisions you really owned, for one target role.
