Reading time: 4 minutes

Part of my ongoing series exploring real-world software development with AI.

In my previous post, I discussed the challenge of keeping up with the volume of code AI can generate. This post covers a different challenge: when AI makes a design more complex than it needs to be.

---

I was working on my logging framework today.

Something unexpected happened. AI made it worse.

Not broken, not unusable, just more complex than it needed to be.

Today’s goal

The goal was to simplify the bootstrap of my new logging system:

• One line startup
• Simple and obvious defaults (console + file)
• Fully overrideable
• Deterministic behaviour

Simple enough. A clean, predictable startup.

All was working just fine.

Then AI Helped

With the basics working (console + file), I asked AI to improve flexibility (console only or file only).

This is where things started going wrong.

AI does what AI does best (as I’m finding):

It expanded the design.

What was originally simple:

• Apply internal defaults
• Apply overrides (properties or config files)

Became:

• Apply internal defaults
• Apply overrides (properties or config files)
• Allow request-level overrides (programmatic)
• Multiple ways to influence startup behaviour (this was the mistake)

On paper, it looked great.

More flexible. More powerful.

More… everything.

The Problem

During testing, I noticed something had changed.

Working code stopped behaving as expected:

• Config overrides were applied, then undone.
• Defaults reappeared unexpectedly.
• Multiple paths, with different designs, were influencing the same outcome.

What started as a simple design became a complex one, with all the issues complex designs bring:

• Inconsistent behaviour.
• Harder to debug.
• Harder to understand what was actually happening.

Nothing was obviously broken.

Yet something was wrong.

The Moment

After investigating the issue, I identified the problem.

AI had introduced two different ways to control the same thing:

• Properties files (internal or external) used to control configuration.
• Internal request override logic added to increase flexibility.

Nothing wrong with either design in isolation.

Together, they created competing sources of truth, introducing both complexity and confusion.

The result was configuration being applied correctly… then silently undone.

The Realisation

The app wasn’t failing due to a bug.

It was failing due to two competing sources of truth.

With the help of AI, the system became more flexible, more capable.

But at the same time, it became more confusing, introducing multiple ways to reach the same result.

Simplicity and clarity are more important than capability.

The Fix

At first, I considered fixing the problem with yet more code changes.

Doing so would have made an already more complex and less consistent design turn into a patchwork of fixes.

All to compensate for a poor design change.

So I stepped back and questioned the design itself.

The competing approaches were identified and removed.

The new feature was deleted. Specifically:

• The request-based overrides were removed.
• They were replaced by properties file overrides.
• A single design path was restored.

The complexity disappeared.

Simplicity and clarity returned, and the bootstrap behaved as originally intended.

It would have been easy to keep adding code, more config layers, more overrides.

Instead, by stepping back and questioning the AI addition, the correct design became obvious.

The flow now looks like this:

defaults → overlay (overrides) → build

Simple.

One flow. One model. No ambiguity.

The Result

With this simple correction, everything worked immediately:

• All tests behaved as designed.
• The system became predictable.
• Simplicity prevailed.
• Mental overload diminished.

And more importantly:

• I could understand the system at a glance.

What AI Gets Wrong (Sometimes)

AI is excellent at:

• Enhancing and expanding design. Something I truly appreciate and actively use.
• Adding features and possibilities.
• Suggesting flexibility, especially when asked, as in this case.

But I feel this often comes at the cost of:

• Increased complexity.
• Multiple paths to achieve the same outcome. I have found this to be a repeating pattern when using AI — something that needs to be watched closely.
• Greater cognitive overload.

This is fine for AI.

But AI doesn’t maintain the system.

AI doesn’t fix bugs at 2am.

If I need AI to explain the system to me, the design has already failed.

The Role of the Engineer

The engineer is not obsolete yet.

The role is not to reject AI.

The role is to use AI.

To constrain AI.

To guide AI.

To say:

• “Yes, that works. But it’s not better.”
• “That’s too complex. Make it simpler.”
• “I like it. But no one will use it.”

The Lesson

The best decision I made this week wasn’t adding a feature.

It was removing one.

Final Thought

AI will happily help you build a more complex system.

It’s your job to decide whether you should.

Last edited: