An Opportunity To Simplify

It is hard to create a "simple" system.

There have been so many times in my career where I've got two components which don't quite fit together. So what do we all do in this situation?

Do we spend the time required to re-architect the system? Redesign the interfaces to component A and component B? Revisit our fundamental data structures?

Do we fudge. We mash together some dodgy script to transform the data between the two components using tools which themselves are their own mini-programming languages with their own syntax and oddities. Then call it a day.

Why? Because the time required to make the necessary change was deemed too great. A lot of mechanical work would have been required to implement and test the changes, even if the time to re-design it was, itself, deemed valuable.

We want software systems that are simple to understand and simple to change. This was true pre-2023 and it will be true forever. But systems take time and effort to simplify. Simple isn't easy.

A story of improvement. But also not.

I had a project recently in which I decided to re-implement the test harness. I had reached the limits of the test framework, setups and helpers, which was resulting in a lot of boilerplate and difficult-to-maintain tests. For example, many of the tests would fail with obtuse error messages which required seeing this error previously to know even how to start to debug them.

The new implementation was a relative dream. The setups and fixtures were now sane, the flow was much easier to follow, and I was no longer needing to perform hidden re-wiring of the app to make it more testable.

Amazing right? My life was now sunshine and rainbows right? Debugging failing tests was now a dream right? Everything was now simple right?

Obviously you can see where this is going.

...No. Not quite.

The problem I had was that the old testing framework was incompatible with the new one, and migrating the tests required a significant amount of manual work to rewrite the test modules, setups, mocks, and general structure.

I spent hours migrating as many modules as I could over to the new framework. But it got to the point where I couldn't justify spending more hours on just "simplifying" the test system.

And thus, there I was, with two test harnesses and a mix of testing styles. I had arguably made the system more complicated, even if it was as clear as day that the new system was better. New developers to the project would quickly get confused about which was the "right" method to write their tests. Sometimes if they worked on a module with just the old style, they wouldn't have even seen or known about the new one that was available.

AI to the rescue...?

Cue sometime in early/mid 2025 (I can't remember exactly).

I finally had a tool which I could use to perform the highly manual task of fixing this mess. I directed my new robot companion to take a look at the new test framework, pointed it to a module with the old test framework, and then set it loose.

Absolute disaster.

It often left the tests in a half-completed state. Too often it wouldn't even compile. I caught it hallucinating new test data too many times.

AI agents simply weren't ready for this.

AI to the rescue... take 2

Fast forward a year to sometime in Q1 2026. We know the general story here: AI agents suddenly "got good".

After finding some time to let them loose on my embarrassment of a situation, after a couple of hours of some gentle prodding, working through all the modules, and even adding some new features to the harness along the way, I finally had it.

The system was now, finally, "simple".

Less code. Less complexity. Less magic.

Don't just use your newfound superpowers to sling yet more feature code into the abyss.

Use them to improve your systems in ways that were simply impractical in the "olden days".