DEV Community

Cover image for How to kill a Zombie?
Alexander Ertli
Alexander Ertli

Posted on

How to kill a Zombie?

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”

now we have the logic...

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

it's just another prompt

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

Top comments (3)

Collapse
 
alifar profile image
Ali Farhat •

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.

We SHOULD never (almost/always) use AI to write code. 😅

Collapse
Collapse
 
seohyun0903 profile image
Seohyun Lee •

Great point about the hidden costs—I've noticed that even when an AI code generator speeds up a routine script, the time spent reviewing and refactoring can quickly eat up the supposed gains. In my work I start tracking how many minutes of manual checking are saved after the first run to see if the tool is truly adding value. Have you found any specific prompts or workflows that consistently reduce that overhead?