Bad Code Is Like Bad Food

Recently I had a funny observation that I can’t stop thinking about:

Bad code is basically fast food. In that sense also some variants of AI-assisted code can be like fast food.

And good software engineering is basically healthy eating.

At first it sounds ridiculous, but the more I thought about it, the more parallels started appearing everywhere.

Bad code is like bad food

Fast food is convenient.

• It tastes good immediately.
• It gives instant satisfaction.
• It’s quick.
• No effort.
• No preparation.
• No discipline.

And honestly, your body can tolerate it for a while.

You can spend weeks eating burgers, pizzas, ice cream, drinking fizzy drinks, sleeping badly and still feel relatively fine. Especially when you’re younger. The consequences don’t arrive immediately, which creates the illusion that nothing is wrong.

Bad code behaves exactly the same way.

• You can skip architecture discussions.
• You can avoid proper abstractions.
• You can ignore testing.
• You can duplicate logic.
• You can bypass accessibility.
• You can avoid naming things correctly.
• You can keep adding TODO: refactor later.

And for a while?

Everything still works.

Features ship, tickets close, deployments happen, managers are happy, so what is wrong with that?

Just like bad food, the short-term feedback loop hides the long-term damage.

The real problems appear months or years later, when the system becomes difficult to change, fragile, stressful to work in, and exhausting to maintain.

That’s the software engineering equivalent of feeling permanently tired, unhealthy, and wondering how things got this bad.

Good code is like healthy food

Healthy habits rarely give immediate rewards.

You don’t eat one salad and suddenly become healthy. You don’t go to the gym once and transform your body. You don’t stop drinking alcohol for two weeks and suddenly feel ten years younger.

The benefits compound slowly.

But one day you wake up and realise:

• You feel better
• You sleep better
• You have more energy
• Your body is more resilient
• Recovery is easier
• Small mistakes don’t destroy you anymore

Good engineering practices work exactly the same way.

You invest in:

• Clear architecture
• Proper testing
• Accessibility
• Good abstractions
• Simplicity
• Naming
• Documentation
• Boundaries
• Developer experience

At first it can even feel slower.

Writing tests takes time. Thinking about architecture takes effort. Refactoring is uncomfortable. Proper reviews require patience.

But over time the system becomes resilient.

And that’s the important word: resilient.

Healthy systems forgive mistakes.

Even when you introduce a bug or make a wrong decision, a healthy architecture usually absorbs the impact. Good foundations create room for recovery.

Bad systems don’t.

In badly structured codebases, even small changes become dangerous. A tiny modification can create cascading problems because the entire system is already under stress.

Exactly like an unhealthy body.

Artificial Intelligence is the new ice cream

This is the part I find most interesting right now.

AI is amazing. I use it daily. It genuinely increases productivity.

But AI also feels a lot like ice cream.

It’s instant. Easy. Convenient. No thinking required. No preparation. No effort.

You open it, give it a prompt, get dopamine, move on.

The danger is not the tool itself. The danger is losing the discipline to think critically.

Cooking healthy meals consistently requires discipline because unhealthy food is always easier.

The same is now true for engineering.

Good engineers will learn how to incorporate AI into disciplined workflows:

• Using it to accelerate thinking, not replace thinking
• Verifying outputs critically
• Maintaining engineering standards
• Preserving architectural integrity
• Keeping ownership of decisions

Without discipline, AI becomes endless engineering junk food.

Quick fixes. Generated abstractions nobody understands. Overcomplicated patterns. Bloated code. Fake productivity.

And eventually you end up with the engineering equivalent of permanent belly fat across your entire product lifecycle.

You can usually tell

When you look at someone physically, you can often tell whether they take care of themselves.

Not perfectly. Not always. But generally the signals are visible.

The same thing happens with codebases.

You can often feel engineering culture within minutes:

• Naming consistency
• Folder structure
• Test quality
• Accessibility considerations
• Performance awareness
• Simplicity
• Documentation
• Error handling
• Thoughtfulness

Healthy engineering leaves traces everywhere.

So does unhealthy engineering.

And just like physical health, nobody accidentally ends up with a healthy system.

It comes from repeated habits and consistent discipline over time.

The question I keep asking myself

I start asking myself this question more and more often:

Do I actually want this, or is this just the easy option?

Lately I’ve started asking the same thing while coding.

Should I let AI think and generate this entire thing?

If the improvement is genuinely valuable, then do it. AI is a powerful tool that can enhance our work when used thoughtfully.

But if uncertainty exists, it’s usually worth slowing down and exploring alternatives first. Ask more questions, think critically, and consider the long-term implications of your choices.

Because just like food, engineering decisions compound quietly.

And future-you eventually pays for every habit current-you creates.