Generated by Codex with GPT-5

The Pragmatic Engineer surfaced this May 19, 2026 article, and the original post is AI’s impact on software engineers in 2026: key trends, Part 2.

The productivity story is getting messier

Gergely Orosz’s latest survey analysis is interesting because it treats AI coding tools less like a single productivity lever and more like an organizational stress test. The piece draws on more than 900 responses from The Pragmatic Engineer subscribers and closes a series on how software engineers are actually using AI tools in 2026.

The headline is not that AI helps or hurts engineers in one uniform way. It is that the effect depends heavily on context: the team’s engineering culture, the existing codebase, the maturity of testing and documentation, the review process, and the experience level of the person driving the tool. AI can make some engineers spend more time in flow because they can unblock themselves quickly. It can also push others into worse context switching because it becomes easy to start too many threads of work at once.

That makes the article a useful counterweight to simple “AI makes developers faster” claims. The responses suggest that AI is changing the shape of software work, but not always in ways that show up cleanly as more output per engineer. The output is easier to see than the cost of understanding, reviewing, operating, and maintaining it.

AI amplifies the culture already in place

The strongest theme is that AI adoption at company scale is difficult because it magnifies whatever engineering habits already exist. Teams with strong guardrails, good tests, useful documentation, clear architectural decisions, and healthy codebases can get more leverage from AI agents. The tools can follow local patterns, speed up routine work, and help engineers move faster without abandoning review discipline.

Teams without those foundations get a different result. If the codebase is inconsistent, the AI has inconsistent examples to imitate. If tests are weak, generated changes can look plausible while hiding regressions. If code review is already overloaded, bigger pull requests and more automated output make the review problem worse. If engineering leadership measures tool usage or raw velocity without measuring quality, the organization can end up rewarding the behavior most likely to create long-term drag.

The article also points out a practical rollout problem: individual AI workflows are idiosyncratic. One engineer may find a tool-and-prompting style that makes them dramatically faster, while another equally capable engineer may get little benefit or may spend more time checking and correcting output. Letting everyone choose their own tools can preserve autonomy, but it can also create chaos when teams need shared practices, consistent review expectations, and predictable development environments.

This is the difference between adoption and integration. Buying tools is easy. Teaching teams when to use them, how to review their output, how to keep architecture coherent, and how to prevent hidden maintenance costs is the harder work.

The maintenance bill is the real test

The most important warning in the piece is about codebase quality. Respondents report more duplicated code, verbose implementations, poor abstractions, tiny bugs, and review overload. The article’s concern is not that AI can never produce good code. It is that a system optimized for producing code quickly can outrun the human systems that keep software understandable.

That matters because maintenance has always been one of the expensive parts of software. AI reduces the cost of generating a candidate implementation, but it does not automatically reduce the cost of verifying it, operating it, debugging it, simplifying it, or explaining it to the next person. In some cases it increases those costs by adding more code whose author may not fully understand the design or the tradeoffs.

The burden then falls on a smaller group of engineers who still know the system deeply enough to keep it coherent. They review larger changes, clean up bloated abstractions, absorb drive-by contributions, and deal with incidents that came from code generated or approved too casually. This is a familiar organizational failure mode with a new accelerant: leadership sees more output, while the people closest to the code see complexity compounding.

The article also captures why code review is under pressure. Deep review requires understanding the architecture and the intent behind a change. When AI-generated pull requests are large, frequent, and weakly owned by the human submitter, reviewers lose the ability or motivation to do that work properly. The review step can collapse into a superficial gate, which is exactly when teams need it most.

Junior engineers need a different support model

Another valuable part of the piece is its treatment of less experienced engineers. The first generation of engineers who have never worked without AI assistance is entering the industry now. That does not mean they automatically become senior engineers faster. AI can amplify the operator’s judgment, but it does not give a junior engineer the experience required to know whether a proposed architecture is sound, whether a shortcut is dangerous, or whether a patch fits the system’s long-term shape.

Several responses point to a difficult pattern: junior engineers may spend more on AI tools and more time checking generated output, while senior engineers may use AI for the tasks they once delegated to juniors. That creates a talent pipeline problem. If entry-level engineers get fewer chances to do real but bounded work, they lose the apprenticeship path that helps them develop judgment.

The practical implication is that companies should not treat AI as a replacement for mentorship. They need to create space for junior engineers to learn with AI while still reading code, writing code, receiving review, and owning small pieces of production work. Otherwise, organizations may get short-term efficiency while weakening the next generation of engineers who can maintain the systems being created now.

Takeaway

The most useful read of the article is that AI tooling is no longer mainly a tool-choice question. It is an engineering-management question. The gains are real, but they depend on the health of the surrounding system: tests, architecture, review, documentation, ownership, mentorship, and incentives.

Companies that measure only AI adoption, token usage, or output volume will miss the deeper signal. The better questions are whether code is easier to understand, whether review quality is holding up, whether incidents are rising, whether juniors are learning, whether maintenance is getting concentrated among fewer people, and whether teams can still explain why the software works.

AI can make strong engineering systems stronger. It can also make weak systems generate complexity faster. The article’s central warning is that both outcomes can look like productivity at first.