AI Doesn't Replace Senior Engineers

AI is changing software engineering faster than most of us expected. Over the past six months, I've watched my own workflow transform. I routinely run multiple coding agents in parallel, delegating implementation tasks, reviewing their work, correcting mistakes, and coordinating with QA and business stakeholders while the agents keep working. Work that once required hours of hands-on coding can sometimes be completed in minutes, and I've reached a point where if I don't have at least two agents running during business hours, I feel like I'm underperforming.

A typical morning starts with identifying a few important tasks and handing the first one to an agent. While it works, I move to a second agent and give it another task. If both are still running, I might start a third. As agents finish, I review their changes, correct their approach where necessary, and test the implementation myself. Meanwhile, QA and business subject-matter experts provide feedback, new requirements come in, and I have to make sure new work doesn't collide with what's already in progress or introduce regressions. I'm spending less time producing every line of code and more time directing the work, evaluating the results, and keeping everything moving in the same direction.

I don't think this trend is going to reverse. Fewer engineers will be needed to produce the same amount of software, and some of the work we once considered essential to the job will simply become cheap enough to automate. But I think we're at risk of confusing the ability to build software with the ability to make good decisions about software.

The cost of building software is changing

When a business stakeholder asks for a new feature, AI can help turn that request into a working prototype (or maybe 5 variants to really ramp up the engagement) remarkably quickly.^[1] The barrier between an idea and a demonstration of that idea is collapsing, which is exciting because we can explore ideas that previously weren't worth the development cost, get feedback sooner, and iterate faster. But a working prototype doesn't answer every important question. Should this feature extend an existing data model or introduce a new one? Where should the data live? What happens when an operation fails halfway through? Are we collecting sensitive information, and what will this decision mean for the system six months from now?

AI can help answer all of these questions. It can lay out options, explain trade-offs, and recommend a path forward. In my day-to-day work with coding agents, I regularly have these discussions as part of the implementation process, refining the approach as we uncover more about the problem. The issue isn't that AI can't reason about the options; it's that someone needs to recognize which questions matter in the first place and know enough to evaluate the answers. A nontechnical stakeholder might skim a detailed discussion, see a recommended solution, and approve it without realizing which assumptions remain unresolved or which trade-offs they're accepting. The recommendation can be perfectly reasonable on its own terms and still be wrong for the business.

Experience changes the questions you ask

A senior engineer doesn't necessarily know the answer to every technical question, but years of experience bring something valuable: accumulated exposure to the consequences of decisions. They've seen seemingly reasonable shortcuts become expensive maintenance problems, watched changes in one part of a system break something seemingly unrelated, and learned that a passing test suite doesn't necessarily mean a feature meets the business's actual needs. That experience changes the questions they ask, the assumptions they challenge, and the risks they recognize before those risks become incidents.

Sometimes that means choosing a different architecture or asking the business another question, and sometimes it means deliberately not solving a problem yet. I've had AI planning sessions push toward finalizing a data model early, when what we really needed was a working proof of concept. The business needed to see and interact with something before it could give us meaningful feedback, so committing to an architecture too soon would have optimized for requirements we hadn't fully understood. The right next step wasn't necessarily the most technically thorough one; it was the one that helped us learn what we needed to know.

More code doesn't mean fewer decisions

AI is changing what an individual engineer can accomplish. Instead of personally producing every line of code, I'm directing more implementation, checking results, resolving conflicts, and making sure the work fits together. One experienced engineer can now oversee work that previously required a larger team, but that leverage depends on being able to evaluate what the agents produce and recognize when their work doesn't fit the bigger picture.

The consequences of a decision haven't become cheaper simply because the code was cheap to produce. A UI bug might be fixed with a quick patch, but a decision that exposes sensitive data or corrupts production records can have consequences that no patch can undo. We need to distinguish between decisions that are easy to reverse and those that aren't, and know when a quick prototype is an appropriate learning tool versus when a shortcut creates unacceptable risk. AI can help us make those distinctions, but we still need a reliable way to establish that the right questions were asked, the relevant risks were considered, and the solution is appropriate for the system we're building.

The role is changing, not disappearing

I don't believe senior engineers are immune to the contraction AI will bring to software development. If one experienced engineer can direct several agents and deliver what previously required a larger team, businesses will need fewer engineers. The job itself will change, too. In many organizations, senior engineers already combine architecture, implementation, technical advising, and translating business needs into technical reality. Those responsibilities don't disappear just because AI can write the code.

For small and midsize businesses in particular, that bridge matters. They may not have separate architecture, security, infrastructure, and platform teams, so they rely on experienced technical people to understand the business objective, navigate the options, recognize the risks, and help decide what should actually be built. AI makes it easier to create software, but it doesn't automatically make it easier to understand the systems we're creating, the obligations they introduce, or the consequences of getting the decisions wrong.

The value of experienced engineering isn't simply in writing code. It's in knowing what should be built, which questions haven't been asked, and what the business needs to understand before moving forward. AI can increasingly handle implementation, allowing engineers to accomplish more than ever before. The challenge is making sure we're building the right thing, not just building it faster.