Big balls of mud are inevitable, right? I’ve written about where these sprawling, difficult-to-maintain codebases come from and how you might deal with them. 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.
Big balls of mud are inevitable, right? I’ve written about where these sprawling, difficult-to-maintain codebases come from and how you might deal with them. 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.
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.
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.
In context
- Topic: Inteligencia Artificial — IA aplicada al negocio: casos, límites, costos y gobierno.
- Source: InfoWorld
- Published: 27/08/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Why it matters
Adopting AI in a company is less like buying software and more like hiring someone. You have to teach it the context, review its work at the start, and define what it can sign off alone and what it cannot. The stories worth reading are the ones showing somebody solving that part, not the announcement part.
I always separate two things that get mixed up: the demo and the operation. A demo needs to work once with someone watching. An operation needs to work a thousand times with nobody watching, with odd cases, dirty data, at two in the morning. The gap between the two is where the budget goes.
What usually goes wrong
The mistake I have seen repeat most is measuring nothing before starting. It gets deployed, everybody feels things improved, and when somebody asks by how much, there is no answer. Without a baseline there is no way to defend next year's budget, and that is where good projects die.
What to watch
- Where the data ends up and under what contract, especially when customer information is involved.
- Whether the organisation can change provider without rebuilding everything, which is the proof it did not get locked in.
- Which concrete process is touched and how it is measured before and after; with no baseline there is no result, only opinion.
How I read this entry
My practical advice is to fix on day one what happens when the model is wrong: who reviews, how often, and at what point it gets switched off. It sounds defensive, but it is exactly what lets you be aggressive later, because the risk stopped being an unknown.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
