AI coding agents are great at writing code and terrible at deleting it, and that's the real problem nobody talks about

Published Oct 18, 2026, 10:30 AM EDT Beginning his professional journey in the tech industry in 2018, Yash spent over three years as a Software Engineer. After that, he shifted his focus to empowering readers through informative and engaging content on his tech blog – DiGiTAL BiRYANi. He has also published tech articles for MakeTechEasier. He loves to explore new tech gadgets and platforms. When he is not writing, you’ll find him exploring food. He is known as Digital Chef Yash among his readers because of his love for Technology and Food. AI coding agents have made it easier than ever to build software. I can describe what I want, let an agent handle the implementation, and move on to the next task without spending hours writing everything myself. But the more I use these tools, the more I think we're overlooking an important part of software development. We talk a lot about how much code AI can generate, how quickly it fixes bugs, and how many tasks it can automate. But what happens when a project needs less code, not more? That's a side of AI-assisted development worth paying attention to. Writing code gives the agent an easy definition of “done” The hidden blind spot in AI coding The first thing I noticed while using AI coding agents is how easily they can turn a clear instruction into working code. I can ask an agent to add a feature, fix a validation issue, or introduce a new setting, and it usually has a straightforward goal to work toward. I can test the result, check whether the feature behaves as expected, and decide if the task is complete. That makes writing code a relatively easy job to measure. There is a clear request, an implementation, and an outcome I can verify. Even when the first attempt isn't perfect, I can ask the agent to make changes until it meets the requirements. But I've realized that this way of working also shapes how I use these tools. I naturally give agents tasks that involve building something new or changing existing behavior. I rarely think to ask them what could be left untouched or whether a requested change needs a smaller solution. The agent follows the task I gave it. If I only measure success by whether the requested feature works, I'm missing an important part of the development process. AI agents can turn clean codebases into bloated messes Every new feature leaves behind more code to maintain I've also noticed how quickly a codebase can become harder to navigate when AI agents handle multiple changes over time. A feature that starts with a simple component can end up touching several files, adding new utilities, and introducing extra layers to connect everything. Each change might make sense on its own, but the overall structure can become less straightforward than it was before. This is easily noticeable when I work on an existing project. Instead of following the patterns already in place, an agent may introduce a slightly different approach to solve the problem at hand. Another task may follow a different pattern, leaving me with multiple ways of doing similar things. When I return to the project later, understanding how everything fits together takes more effort. The tricky part is that these changes don't necessarily cause immediate problems. The application can still run as expected, and the new feature can work perfectly. I might not notice the growing mess until I need to revisit an older part of the project. That's when I realize the codebase has become harder to follow than it needs to be. More code means more complexity, maintenance, and potential bugs I’ve come to realize that more code doesn't always mean better software. Even when every function works as expected, unnecessary code adds more things I need to understand, test, and maintain. A small change can become surprisingly difficult when I have to account for extra logic that serves no real purpose. I also worry about how this affects future changes. Every additional function, condition, or dependency creates another thing to consider when modifying the project. A change that should be simple might require checking several related pieces to make sure nothing breaks. The problem isn't always that the code is poorly written. Sometimes, it's that the code shouldn't exist in the first place. This is where AI-generated code can become a long-term burden. I can get a working result quickly, but the time saved during implementation doesn't necessarily translate into time saved later. I'd rather maintain a smaller, straightforward codebase than one packed with perfectly functional code that adds little value. Deleting code is harder than writing it It still needs a human I've learned that removing code requires more judgment than I initially expected. When I ask an AI agent to delete something, it needs to understand how that code is used across the project, not just whether it appears unnecessary. A function might have no obvious references but still be called dynamically or used by an external integration. Removing it without checking can introduce hard-to-spot bugs. This is where I still want human involvement. I can ask an agent to identify unused functions, review dependencies, or suggest what to remove. But I don't want to approve every deletion blindly just because the agent sounds confident. I need to understand the reason behind the change and check whether it could affect something else. My approach is to let AI help with the investigation, then review the proposed changes and run relevant tests before accepting them. I want agents to become better at deleting code, but for now, that final judgment still needs a human. The smartest code is the code you don't need AI coding agents have changed how I approach development, but I don't think writing code faster should be the only measure of progress. A good codebase isn't just about what it can do; it's also about how easily I can understand and maintain it. As these tools get better, I want them to become more thoughtful about what they create and what they leave behind. Until then, I'll keep reminding myself that sometimes, the best improvement isn't adding something new. It's knowing what not to add in the first place.