cd /news/ai-tools/how-to-kill-a-zombie · home topics ai-tools article
[ARTICLE · art-134224] src=dev.to ↗ pub= topic=ai-tools verified=true sentiment=↓ negative

How to kill a Zombie?

A developer behind the AI system Contenox describes repeatedly attempting to shut down the project, only to revive it, and argues that AI-generated code creates bugs that conventional code review cannot catch. The engineer recounts a permissions bug where name-based KV storage left existing users with stale token grants, concluding that engineers should almost never use AI to write code.

by read4 min views1 publishedSep 18, 2026

We all have our Zombies; no, not the ones you think of from movies. I’m talking about software, like pet projects and ventures. My Zombie is Contenox—how do I know it is one? Well, each time I try to kill it, it comes back bigger and stronger, with much more hunger than before the kill.

Had that problem? I hope not; it’s daunting, eats your time, eats your opportunities, and, well, your health and money.

Let’s step back a little: why did I even want to kill it?

Contenox is an AI system... best to skip this section though...

...made specifically to work best with non-frontier models and local models; the performance is competitive even against frontier harnesses. Adequate token caching and proper multi-layer security, coupled with a potentially high-margin, latency- and privacy-optimized distributed LLM proxy router I wrote and deployed, tons of spare cloud credits, and some budget for user acquisition, and very good feedback from pilot users testing the system—everything is just waiting for a go-to-market campaign.

...Sorry we are back, let's go:

You might be thinking this is almost certainly a humblebrag post disguised as a complaint, meant to build hype for an upcoming launch… Let me assure you: No, it’s not.

I’ll share a little story, as it may be relevant if you also like me to use AI to code “for you” or “with you”; call it what you want.

There is always that point where you let your guard down and vibe through a feature: LGTM, tests passing, system deploys, traffic flows, security, and usage meters verified and working in production. Looks perfect; code is clean, and servers hum.

Then a new requirement: Let’s bolt that on — you sat down and wrote the architecture blueprint, filled the harness-belt with tools, and started prompting — worked again. You hit deploy; CI passed, rollout is all green, traffic flows — everything as expected.

But then you want to alter the allocation, change some perms for some user groups, some configs, minor operational details; you change the envs or fill the forms, whatever is your case, and boom, it hums again— nothing to see here?

Until you log in as a user of that and see the old token allowance still granted. And? What now?

Now you look at your code for the first time.

A bit of coffee, a bit of digging, and after trying to see the code in a wall of AI-generated “docstrings”

I figured out that permissions were stored by name, and updating the name created a new KV-pair so new users inherited the new perms and token grants just fine; existing users referenced the old value, which was never deleted.

Yes, after finding this bug, I wished I had prompted the problem away. Now, obviously you blame AI, fix the bug, and call it a day, don’t you?

Sidenote → Let me be blunt here: A code review will never catch this bug BECAUSE the original code was AI-generated; no one spent the time to think through the original implementation and design. There IS NO WAY that someone will ever remember that the perm table is a KV schema IF this would have been noticed at all. THIS MEANS that the diff of the new feature is meaningless noise to the reviewer

Back to my Zombie-case: Let’s consider this: What if you never coded without AI? And what if you even lack the intuition of, well, that you should go and test this scenario?

Well, in that case: You did not build your product; you summoned it.

__

Still here? good. Look, I’m a hardcore engineer, coding since the days when stuff like systemd could generate flamewars — not the best — but I can smell and fix slop.

Following the trends and marked pivot after pivot, layer after layer, Contenox is now a utility that, by its very nature, becomes the root cause of situations like this.

No matter how I spin or frame the story, all my research, learning, testing, building, and comparing it against other solutions lead me to conclude:

→ We software engineers SHOULD never (almost) use AI to write code. Yet there we are, sitting on mountains of code, digging into it without an AI harness, which would make us question our own sanity, when we discover: We paid for AI, driving LoC up and burning tokens by reimplementing primitives like UUID.

Yet I assure you the law of sunk cost fallacy will make us and me swipe the card to try that new direction or feature that may change it all.

So help me out: How to kill a Software Zombie?

*cover is AI generated

── more in #ai-tools 4 stories · sorted by recency
── more on @contenox 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/how-to-kill-a-zombie] indexed:0 read:4min 2026-09-18 ·