The Shadow IT Department Nobody Signed Off On

Spent a bit of time this morning reading a thread from r/auscorp that scratched a very specific itch of mine. Someone on a dev team had inherited a “fancy looking dashboard” that a colleague had vibe-coded into existence with AI. Worked fine for two months. Then it needed a change, nobody who’d built it understood how it worked, and a contractor got paid real money to untangle something that was never really engineered in the first place. The original poster’s takeaway: AI should be a tool, not a crutch, and being able to prompt your way to a working thing doesn’t mean you understand the thing you’ve made.

I’ve been in IT for a long time now, DevOps and development both, and I read that post with the specific kind of tiredness you get from watching history repeat with better special effects.

Because here’s the thing: this isn’t new. One commenter nailed it. Nineties it was Lotus Notes. Naughties it was MS Access. Twenty-tens it was SharePoint. And running underneath all of it, the whole time, was Excel, the cockroach of enterprise software, somehow both the worst tool for every job and the only one anyone actually finishes using. Every generation of “easy” tooling produces the same shadow IT department: someone in finance or ops builds something clever, it works, everyone leans on it, and then eighteen months later a real developer gets dragged in to figure out why the thing is held together with string and a prayer. AI is just the latest, fastest version of that cycle. It used to take a person a few weekends to build something unmaintainable. Now it takes an afternoon.

What’s different, and what makes this genuinely interesting rather than just another “kids these days” gripe, is the speed and the confidence. Old Access databases at least looked fragile. They had that slightly beige, slightly janky feel that told you, correctly, not to trust them with anything important. A vibe-coded web app can look polished. It can look like something a team spent a sprint on. The gap between how finished something looks and how finished it actually is has never been wider, and that gap is exactly where the contractor invoice comes from.

One comment on the thread stuck with me, from someone who’d clearly thought about this properly: it comes down to accountability. If someone wants to build and own an internal tool, genuinely great, it frees up actual engineers to deal with harder problems. The issue isn’t the vibe-coding itself, it’s doing the easy ten percent and leaving the other ninety for whoever gets paged at 2am when it breaks. That’s not an AI problem, that’s an org chart problem. It existed before Claude, it existed before Access, it’ll exist after whatever comes next.

I’ll admit a bit of hypocrisy here, because I use AI for coding most days and I like it. It’s genuinely good at a lot of things I used to spend hours on. But I know what it’s doing and I know how to check its work, because I spent twenty-odd years learning the long way what “understanding the codebase” actually means. Handing that same tool to someone with no engineering background isn’t democratising software development, it’s just moving the risk downstream and hoping nobody notices until it’s someone else’s problem. Usually it’s mine, or someone like me, on a Tuesday afternoon, wondering why the dashboard that “just worked” for two months suddenly doesn’t.

None of this makes me want to ban the tool, and I don’t think the original poster wanted that either, not really. It’s more a plea for a bit of honesty about what we’re building and who’s accountable when it falls over. Every wave of “easy” tech has needed that same conversation and every time we’ve been slow to have it properly. Maybe this is the wave where we finally get ahead of it. I genuinely hope so. I’m also not holding my breath.