Posted on by Adam Wespiser
There’s an overwhelming feeling that being a software engineer today is worse than a couple years ago, and AI is at the center of it. I’ve heard this from several engineers, from start-ups to big tech, and experienced it to a degree in my own work. It’s never been easier to generate code, but instead of feeling super-capable after a burden is lifted, the job can feel like we’re running to stand still. It’s not the eight Claude Code windows we have open, or the annoying PR review bot making helpful suggestions only 20% of the time. Instead, the problem is that organizations expect “AI speed” and to get it they push people harder, accept only faster timelines, and monitor individual throughput. Layer on some layoffs, market pressure, a colder funding environment, and the situation seems to degrade both teams’ trust and people’s sense of where the market is heading. It’s like we’ve forgotten that developing software is rate-limited by expert judgment, not code throughput. AI can be used for cost savings, but that often comes at the expense of knowledge workers required to build, run, and extend production software.
The strange part, is that engineers do not feel obsolete. They feel overloaded. Instead of a forboding pall around the office while we train our machine replacements, engineers are being asked to supervise more work on faster deadlines, absorb more ambiguity, all while remaining accountable for production outcomes that haven’t gotten any simpler. AI changes how software engineers work. It does not make the work disappear. Yet, the lessons on how AI works have not fully diffused through organizations. This explains a lot of the pain software engineers are experiencing— the project failures and delays today, along with the wins, become the institutional memory of tomorrow. We just don’t know how long it will take to close that gap.
In large, complex software projects, tighter deadlines often mean we’re asking for something impossible: onboard instantly and make production changes faster than our understanding allows. Changes in these systems are only partly constrained by how fast you can write code. They are constrained by how fast you can reduce ambiguity, learn from a domain expert, and reason deeply about the system. AI or not, the production risk remains, but we haven’t fully committed these lessons to organizational memory.
This mistake is treating faster code generation as faster development cycles, as AI can’t fully speed up activities like discovery, risk modelling, review, coordination, or the need to know who actually owns a system. This is a shortcoming of AI: you can create pull requests, but depending on the project, generated code is more unstable than code written by experienced engineers, and the likelihood of rework higher. Not every application of AI is like this, but the current model of AI agents assumes that knowledge can be gleaned from code alone, plus running tests. Production systems rarely work like this. Instead of well-typed functions and documentation, we have systems with spooky-action-at-a-distance effects: code paths which seem real and are never used, feature flags that make the system behave entirely differently between environments, and ownership boundaries that exist socially long before they are reflected in code. The dangerous failure mode is not always code that fails to compile. It is code that looks reasonable, passes local checks, but is wrong in non-obvious ways that aren’t apparent until code ships. AI agents can help with parts of this, but faster code generation does not mean better engineering.
Eventually, the bill comes due. Some teams will absorb this transition well: they will treat AI as a tool to accelerate the parts of work, not a shortcut, and invest the saved effort into technical discipline and the human networks that make production software possible. But these environments are far from universal. The unfortunate part is many organizations use AI as a pressure multiplier: more delivery, less help, faster timelines, and the same accountability when reality pushes back.
It is comforting to believe this cannot last, that the hype cycle will burn itself out, and that organizations will eventually relearn what software engineering actually requires. Maybe they will, but there is no law that says the next phase of the industry has to feel better than the last one. Markets can stay bad longer than people can stay optimistic, and organizations can keep confusing motion for progress for a very long time.
The right response is not to moralize at engineers for feeling pessimistic. A lot of them are reacting accurately to the environment they are in. They are not obsolete. They are tired. That is not the same as resisting the future. A lot of the misery comes from being told engineers are becoming obsolete while also being asked to carry more work. Until organizations manage that honestly, the crisis will not be one of engineering productivity. It will be one of confidence.