AI is removing the middle class of software engineering?

That framing landed with a lot of people, but the comments sharpened it. The strongest consensus was that AI is an amplifier, not a replacement. In healthy teams, it speeds up repetitive work, boilerplate, prototyping, and tests. In unhealthy teams, it scales sloppiness, hides bad decisions behind green CI, and floods senior engineers with review work. Several people described the same pattern in production. Code compiles, tests pass, and the change looks polished, yet it quietly worsens performance, duplicates logic, ignores system boundaries, or solves the literal request instead of the real problem. The result is not obviously broken software on day one. It is a codebase that gets harder to reason about, slower to change, and more fragile under real load. A lot of the discussion pushed blame up a level. The recurring view was that the biggest failure is managerial and organizational. Companies are rewarding PR volume, feature velocity, and even AI tool usage itself, while cutting QA, shrinking review time, and expecting a few experienced engineers to absorb the risk. Several commenters said the old checks still exist, like tests, CI, code review, and architecture review, but they were designed for a world where change volume was naturally limited. AI removed that brake without replacing it with an equally strong validation mechanism. This is why many people rejected the idea that more code equals more productivity. Fast output can simply move work onto reviewers, on-call engineers, and whoever inherits the system later. The comments also made the article’s “middle class” framing more concrete. What looks most exposed is the developer whose main value was turning well-scoped work into implementation, whether that person is junior, mid-level, offshore, or long-tenured but disengaged. Some called this the automation of the Stack Overflow engineer. Others said the real loss is not just jobs but the training pipeline. If juniors use models to skip the hard parts, and seniors spend their time reviewing slop instead of mentoring, fewer people build the judgment needed to run large systems later. That concern sat alongside a more cynical one. Many said the industry already had a quality problem because business incentives favored shipping over craftsmanship, and AI simply accelerates that existing trend. There were dissenters. Some argued this is not new and that bad process, not AI, is the main culprit. Others said lots of software work really is routine CRUD, where AI can reduce toil without much downside if the architecture is already constrained. A few described mature “agent layer” workflows with strict standards, analyzers, tests, and review tooling that keep generated changes small and predictable. But even these success cases mostly reinforced the same point. AI helps when a strong engineer or strong process sets the box. It does not remove the need for judgment, and it does not rescue teams that are already unclear about what good software looks like.