Same Boring Problems, New Tools to Blame

I saw yet another post on LinkedIn the other day that illustrates a bad take on AI. The argument went something like this: “What’s your plan when your AI bill stops being subsidized, and your team no longer understands the system it built?” The poster went on to warn about vendor dependency, losing understanding, and the inevitable day when your “ultimate engineer” leaves the chat.

My response was simple: What’s your plan when you join another company and don’t understand the system they built?

Because that’s been my daily life for three decades.

If you’ve worked on legacy enterprise systems, none of this is surprising. You’ve inherited a 20-year-old system with millions of lines of code written by hundreds of developers, most of whom left years ago. The architecture changed directions every time the VP changed. Half the modules were built by contractors who optimized for billing rather than maintainability. Or you have a SQL query so complicated that everyone is afraid to touch it, like the one I printed and hung outside my cube to remind management of their outsourcing decisions.

Enterprise systems have always been hard to understand. Not because of AI, but because organizations are messy, priorities shift, people leave, and documentation is an afterthought. The idea that human-written code is consistently architected and easy to reason about is a fantasy. Walk into any Fortune 500 company and ask to see their core platform. I’ll wait.

One response I got was particularly revealing. Someone argued that human-built systems eventually “converge to understanding” because patterns emerge, but AI-generated code has an inconsistent architecture where “decisions are local, not systemic.”

Code always reflects the culture of the people, even when generated by AI. If you’ve worked on a system that outlasted its original developers, or even one where the original developers are still there but stopped caring two years ago, you’ve seen exactly this. If your team has no engineering rigor, no architectural standards, no code review discipline, then yes, your AI-generated code will be a mess. Just like your human-generated code already is.

AI generates the code using the patterns you constrain it to. If you don’t have any constraints, you get chaos. That’s not an AI problem. That’s an engineering excellence problem. And it existed long before anyone had an API key.

Someone else said: “It’s all well and good to generate code with AI, but it won’t be there at 3 AM during an incident to fix it for you.”

Why wouldn’t it be? I use Claude. It’s been quite good at finding defects, even subtle ones. I also count on my other tools being there at 3 AM. I’m going to have a hard time if version control is down or my pipelines won’t trigger either. This argument treats AI as if it’s a contractor who goes home at 5 PM. It’s a tool. It’s available when you need it.

The “what happens when AI gets expensive” crowd seems to have forgotten how enterprise software works. What happens when AWS jacks up prices when you’re locked into their tooling? What happens when Atlassian decides your tier costs twice as much now? What happens when your Oracle licensing audit hits?

Those aren’t hypotheticals. Those are things that happen every year to thousands of companies. And unlike cloud services, AI tools have low switching costs. I’ve taken agent configurations designed for OpenAI and used them as prompts to create the same capabilities for Claude. The intellectual property is the information, not the service. Try saying that about your AWS Lambda functions or your Salesforce customizations.

People forget history. Adjusted for 2026 dollars, a license for a C compiler you would use for professional work in 1985 cost between 750 and 1,500 per seat. Professional CNC machine tools run six figures. Businesses have been making cost/benefit decisions about automation tools for decades.

In three hours last night, I wrote a program that imports LightBurn files for my laser, auto-nests the components into multiple sheets, and exports them as files the laser can use directly. That represents many days of work for a development team that understood how to do it in the first place. I had no idea how to do it. I only understood the problem and how to test that it was solved.

Since developers cost quite a bit more than $2,000/month, businesses will still see expensive AI as a bargain... if they have the qualified engineers to drive it and define the constraints.

The people making these arguments aren’t protecting anyone. They’re rationalizing their own reluctance to adapt. Inconsistent code? That existed before AI. Vendor dependency? That existed before AI. Systems nobody understands? Missing engineering rigor? All of it existed before AI.

Stop blaming the tool for the culture it’s amplifying.