Know When to Stop Patching

One of the biggest lessons I learned while working with AI wasn't about prompting.

It wasn't about context windows.

It wasn't about choosing the right model.

It was about recognising when neither the AI nor I were solving the right problem.

Software development has a habit of encouraging incremental fixes.

A bug appears.

You fix it.

Another edge case appears.

You patch that too.

Eventually the code works—but it becomes increasingly difficult to understand why.

AI can unintentionally reinforce this pattern.

If you ask it to solve today's problem, it will usually do exactly that. If another problem appears tomorrow, it will solve that one too. Before long you've accumulated a series of perfectly reasonable fixes that, taken together, have become an increasingly awkward design.

I saw this happen more than once while building the Auspice Darer Framework.

We would spend time refining an approach, improving it a little with each iteration, only to realise that the underlying architecture itself needed to change.

The breakthrough rarely came from writing another patch.

It came from asking a different question.

Instead of asking:

"How do we fix this?"

I started asking:

"Why does this keep needing to be fixed?"

That simple change in perspective often revealed that the recurring problem wasn't the implementation.

It was the design.

When that happened, the answer wasn't another workaround.

It was to simplify the architecture.

Sometimes that meant introducing a new service.

Sometimes it meant removing an unnecessary abstraction.

Sometimes it meant throwing away an approach entirely and replacing it with something much simpler.

At first, that can feel like wasted effort.

In reality, it's usually the opposite.

Every redesign removed complexity that would otherwise have needed maintaining for years.

One thing I also learned is that the AI won't necessarily recognise when it's trapped in this cycle.

It may continue producing increasingly sophisticated solutions to a problem that shouldn't exist in the first place.

That's not a weakness.

It's simply doing what it has been asked to do.

As the human developer, you have the wider perspective.

You can recognise patterns that span weeks or months of development.

You can see when the same class of problem keeps returning.

You can decide that it's time to rethink the architecture rather than refine the workaround.

Looking back, I think this is the biggest difference between writing code and designing software.

Writing code solves today's problem.

Designing software reduces tomorrow's.

That's why architecture matters.

And that's why the most valuable question you can ask—whether you're working alone or with AI—isn't:

"How do I fix this?"

It's:

"Should this problem exist at all?"

If the honest answer is "no", then stop patching.

Redesign the architecture.

Your future self will thank you for it.