AI does not make you better by itself. It makes you faster, which means it amplifies whatever is already there: good engineers get leverage and bad habits get velocity. The first draft was never the expensive part, because knowing whether it is right, fits the system, and can be owned in production is the real work. AI rewards clear thinking and exposes vague requirements, and it never transfers accountability. The model did not merge the pull request. You did.
There is a comfortable story going around: AI writes garbage, invents things, and produces slop. It is convenient because it lets us blame the new tool instead of the old system. But most AI slop is human slop with a faster feedback loop. The instructions were thin, the standards were tribal, and the architecture lived in one senior engineer's head. AI just stopped letting us pretend the process was ever clean. Write the standards down and the AI gets better. So do the humans.
The easiest mistake in engineering is assuming the person before you should have known better. A strange workaround, an awkward abstraction, a manual deploy step: sometimes the work really is careless, but a lot of the time it is context you do not have. Before criticizing a design, walk a mile in the author's context, then fix what is still broken.
One of the fastest ways to read the health of a platform is to ask whether you can deploy its code right now, safely, using the process the team claims to trust. A clean answer means deployment is a repeatable, disciplined process. An answer that routes through Dave, or Sarah, or a specific Jenkins, or a forbidden Friday, means you have found a fragile system protected by institutional knowledge instead of engineering discipline. Every time a deployment requires a specific human instead of a repeatable process, you have found technical debt disguised as expertise.
Context switching is real, but it is not the disease. The cost of interruption is a symptom of a deeper problem: we build software delivery around fragile human memory, where the engineer is the only place the working model of the system actually lives. AI raises the stakes by quietly turning individual contributors into orchestrators of small AI teams, which means even more context to carry. The fix is not heroic focus, it is durable context that lives in the system instead of in one person's head.
Most teams that say they want CI/CD really just want the deploy button to hurt less, so they reach for CD first. That is the wrong order. The first problem is CI: trunk-based development and meaningful automation. Get those right and CD becomes a controlled move of a known-good main branch instead of a faster way to ship uncertainty.
AI made execution dramatically faster, but most teams are not bottlenecked on execution. They are bottlenecked on planning and validation, and AI does little for either by default. Speeding up the middle of the delivery system just backs the work up at review, testing, and deployment. The fix is to improve the whole loop, from intent to plan to change to safe production, not only the part that writes the code.
Working yourself out of a job does not mean making yourself useless. It means removing the broken, fragile, one-person-dependent parts of your work so the system no longer needs babysitting. The best engineers do not protect a little kingdom of broken things. They make the kingdom unnecessary, and earn their way into bigger problems.
Cost-adjusted software engineering judges work by the value it creates against the full cost of building and operating it, not just whether it shipped. You can pay up front through testing, CI/CD, and clear ownership, or pay forever through incidents and rework.
