Tools Change. Engineering Principles Still Matter.

This week, I had lunch with ex-colleagues from SBS.

At some point, they told me they were still receiving release emails for t-tool. That made me smile, because it brought me back to the very beginning of my career at Callataÿ & Wouters.

I had been hired to work on COBOL — maybe not the sexiest start for a young engineer ^^”. Since there was no open spot on any project team at that moment, I joined the BBT (Black Box Testing) team.

That is where I discovered test scenarios, test cases, regression pain, and the first attempts to automate tests with Selenium IDE.

The idea was good

The idea behind Selenium IDE was not wrong.

Manual testers were repeating the same scenarios again and again. Regression testing was time-consuming, repetitive, and not exactly the most exciting part of the job.

So the idea was simple: give people a tool to automate those repetitive flows.

And at first, it looked like a productivity gain.

People could record scenarios quickly. They could create more and more automated tests. It felt like we were moving faster.

But that was only the beginning of the story.

The implementation was the real challenge

The problem was not Selenium IDE itself.

The problem was how it was used.

Everyone had their own scenarios on their own machine. Nothing was really shared, versioned, reused, or maintained in a common way.

If a scenario had to run on another machine, it often failed. If the application changed, many scenarios broke. If two people automated similar flows, there was no real reuse. If something had to be refactored, it was painful.

In the beginning, everything felt fast.

A few months later, the maintenance cost appeared.

And that is often where automation projects start to hurt.

Not because automation is a bad idea, but because automation without engineering discipline creates a new kind of debt.

The engineering around the tool

That experience made me realize something important early in my career.

Automation is not only about the tool.

It is about the engineering around the tool.

Versioning matters. Reuse matters. Maintainability matters. Sharing matters. Naming matters. Refactoring matters. Execution stability matters. A common way of working matters.

Those are not “nice to have” details.

They are the difference between automation that helps a team and automation that becomes another thing to maintain.

I remember spending a weekend building a small Java Swing prototype to make this easier in our context — the prototype that would later become t-tool.

The goal was not just to automate more tests.

The goal was to create a framework around automation, so that people (in this case non-technical people) could contribute without having to deal with all the technical complexity behind it.

The same pattern with AI

Looking at AI today, I see a very similar pattern.

The tools are much more powerful, of course. Generating code, tests, documentation, specifications, or scripts in minutes is impressive.

And I use these tools myself. A lot. Maybe too much? ^^”

But the trap is the same.

At the beginning, everything feels incredibly fast. You generate a lot. You move quickly. You feel productive.

But speed alone is not the goal.

The real question is not:

How fast can we generate something?

The real question is:

How do we integrate this into a proper software delivery flow?

Because once the first excitement is over, the usual questions come back:

• Can we trust the output?
• Can we review it?
• Can we test it?
• Can we maintain it?
• Can we trace why something was generated?
• Can we safely put it in production?
• Can another person understand it later?

If the answer is no, then we did not really remove complexity.

We just moved it somewhere else.

AI belongs in the delivery system

For me, AI should not be treated as a shortcut around software engineering.

It should be integrated into software engineering.

That means using AI across the delivery flow, but with structure around it:

• specifications
• architecture
• implementation
• testing
• CI/CD
• reviews
• quality gates
• feedback loops
• human control

The goal is not to generate as much as possible.

The goal is to deliver better software faster, while keeping quality and maintainability under control.

That distinction matters.

Because if we only optimize for short-term speed, we risk creating a mess that will become painful six months later.

The lesson keeps coming back

Selenium IDE was not the problem.

AI is not the problem either.

The problem starts when we believe that a powerful tool removes the need for engineering discipline.

It does not.

Tools change.

The abstraction level changes.

The speed changes.

But the fundamentals remain the same.

We still need clear context. We still need maintainable systems. We still need validation. We still need feedback loops. We still need people who understand what they are building.

Tools change.

Engineering principles still matter.