# AI coding agents vs. big balls of mud > Source: > Published: 2026-08-27 09:00:00+00:00 Big balls of mud are inevitable, right? I’ve written about [where these sprawling, difficult-to-maintain codebases come from](https://www.infoworld.com/article/3801853/where-big-piles-of-mud-come-from.html) and [how you might deal with them](https://www.infoworld.com/article/3806755/how-to-deal-with-a-big-pile-of-mud.html). It seems like there isn’t very much you can do about them. But now that we have AI coding agents, maybe there is. Look, we all start out with great intentions. We have a beautiful design, we implement it carefully and lovingly, and we swear that this time we aren’t going to make compromises and we will always “do the right thing” even if it takes longer. And that actually works for a while. You build the product, and it starts selling. You build a little business around it, and pretty soon you have people working for you. You hire a salesperson or two, and you hire a support team. Your company is making money! Like many businesses, it’s not a huge viral success, but it delivers a modest, steady income. You sell support contracts. Maybe you pick up some money on your customers’ credit card transactions. You have a bit of cash in the bank, and you don’t have trouble making payroll, but it’s not a slam dunk. Things are steady, but that next customer is always important. And that is the root of the big ball of mud. One day your sales guy comes and says that he can make a big sale if we add this one feature that we hadn’t really planned on. He’s pushing hard for it, and the CEO says to do it. And oh, by the way, we need it by the end of the month. So the feature gets done on a very compressed schedule, meaning corners are cut, things are hacked, and those pie-in-the-sky software engineering principles you started with are set aside. Or maybe you start with a certain coding paradigm, and over the years that coding paradigm gives way to new coding methods and techniques. Any code written 20 years ago is going to look old, out of date, and all “big-ball-of-mud-ish.” There are many codebases still running today that were beautifully done in procedural code, and now they have layers of object-oriented code laid on top of them. That makes for a big ball of mud, too. But is this all inevitable anymore? Given that agentic coding is already powerful and amazing, and only getting more powerful and amazing every day, I’m not so sure it is. Now, if the sales guy needs a feature by the end of the month, it’s possible that—with the help of AI—you could actually do the implementation in the compressed time frame. Not only that, but you could certainly instruct the agent to do it while following your initial design and high standards for coding, right? Sales deadlines may never change, but the time required for a software development team to implement a feature has compressed dramatically in the last year. And that raises the question about the code itself. If, as I’ve written, [the code doesn’t really matter](https://www.infoworld.com/article/4208036/when-code-no-longer-matters.html) to humans anymore, then can we even have such a thing as a big messy codebase? If the agent can understand your entire codebase, make changes, fix bugs, and add features with ease, what, then, is the problem? When the CEO backs the sales guy and says “build that feature by the end of next week,” is that really a problem anymore? If you care about the code, then you can have your agent write clean, maintainable code that is up to your standards. If you don’t care about the code because you’ve abstracted it away behind the agent, well, then your agent can probably build that feature in short order no matter what paradigm you use to code. Either way, agentic coding seems to have solved the big ball of mud problem, no?