10 PRINT "THE TEACHER SMELLS"
20 GOTO 10

It was hardly sophisticated software, but like many children introduced to programming on a BBC Micro, it was enough to make me curious.

I enjoyed programming as a kid. There was something fascinating about typing a few instructions and making the computer do something, even if that something was filling the screen with a childish observation about a teacher.

My older brother an actual software engineer later taught me languages such as Pascal. Then came Visual Basic 3, followed by versions 4, 5 and 6, and I started creating all sorts of things.

The early days of Kempsoft

One of my creations was a small application for cataloguing my video collection, using Microsoft Access as its back end. When DVDs arrived, the application naturally had to evolve to support those too.

Netflix had nothing to worry about, but it worked.

I also remember writing a warp-speed calculator in Delphi with a friend. It could tell you how fast Warp 1 through Warp 9.9 would be in miles per hour, kilometres per hour or even metres per second.

Essential software, obviously.

I believe my friend may still have the source code printed out somewhere. We even branded our creations using our own imaginary company names.

Mine was Kempsoft.

There was absolutely no Microsoft influence behind that name. Honest.

Nearly 30 years later, my business is called Andy Kemp Consulting Ltd, which proves that although the technology has moved on, my imagination when naming companies has not.

At least nobody can accuse me of hiding what the company does.

The software engineer I nearly became

The plan was to take my interest in programming further. I wanted to study for an HND in Software Engineering and then progress to a degree.

Unfortunately, I had spent rather too much of sixth-form college enjoying myself and not quite enough time studying. I did not get the results I needed, so I had to find another route into technology.

I joined a traineeship as a systems engineer, intending to work towards an MCSE in Windows NT 4.0 and Microsoft Exchange 5.5, remember those days?.

Before long, I was a 19-year-old junior systems engineer travelling to Luxembourg to support a large American bank.

While most of my friends were back in the UK at university (a lot of who were studying software engineering), I was living in a foreign country, earning what felt like decent money and helping customers with all sorts of technology including OS/2 Warp.

If you asked me to configure some of those systems today, I would probably have to start by finding the documentation or being honest probably come and ask my AI service of choice. I have forgotten a lot of the individual commands, settings and workarounds that seemed so important at the time.

But remembering every setting was never the most valuable skill.

I learned how to enter an unfamiliar environment, understand the problem, work with the people around me and find a solution.

I learned by doing.

I should probably also admit that I never completed the NT 4.0 MCSE. It was not because I had lost interest in technology. I discovered that I enjoyed working with customers and solving their problems considerably more than I enjoyed sitting exams.

That decision shaped the next three decades of my career.

I became a systems engineer, consultant and architect rather than I’ve starting on becoming that software engineer I had originally imagined becoming.

But the desire to create things never completely disappeared.

Building again

Nearly 30 years later, AI has unexpectedly brought me back to it.

I can take an idea, discuss it with an AI companion, explore how it might work and begin turning it into something tangible. It can help me understand an unfamiliar framework, scaffold an application, explain a piece of code, diagnose an error and iterate on a feature.

The gap between having an idea and seeing a working version of it has become dramatically smaller.

This is often described as vibe coding. Depending on who you ask, that description can be enthusiastic, dismissive or somewhere in between.

For me, it means that I no longer need to have every piece of syntax or every framework committed to memory before I can begin creating something. I can describe the outcome I want, work through the implementation with an AI companion and learn as I go.

In some ways, that does not feel entirely different from arriving in Luxembourg at 19 and having to understand unfamiliar systems. The technology has changed beyond recognition, but the ability to ask questions, investigate, experiment and solve problems remains just as important.

A companion, not a replacement

AI has not replaced nearly 30 years of experience. It has given me a new way to apply it.

It can generate code much faster than I could write it myself. It can also generate code that is wrong, incomplete, insecure or based on assumptions that do not apply to the environment in which it will run.

It does not know the customer as I do.

It does not understand why one requirement matters more than another unless I provide that context. It cannot decide what should be trusted, where sensitive data should live, how identities should be protected or whether a design is appropriate for production.

It can propose an architecture. It cannot accept accountability for it.

Those decisions are still mine.

That is why I see AI as a companion rather than a replacement. It works alongside my experience. It removes friction, helps me explore possibilities and allows me to create things that might previously have remained ideas in a notebook.

But I remain responsible for understanding, testing and securing what we build together.

When the vibe meets reality

Getting the first version of an application working can now happen remarkably quickly.

Then the application needs to do something in the real world.

It needs to send a notification. Store some data. Authenticate a user. Call an external API. Run somewhere other than my laptop. Recover when something fails.

Every one of those apparently small requirements introduces another dependency, credential and architectural decision.

That is where the vibe ends and the engineering begins.

The first requirement I encountered was a familiar one: the tool needed to send me an email.

Adding some SMTP code was straightforward. Deciding which service should deliver the email, where its credentials should be stored, how the sending domain should be protected and what would happen when a free tier disappeared was considerably more interesting.

And once the tool could notify me, it started to feel like more than a script.

That led to another thought:

What if this was not only useful to me? What if other people could log in and use it too?

Those questions will shape the next parts of this series.

Vibe coding might help me create a working prototype.

Nearly 30 years of experience tells me whether it should ever become a product.

Next in the series: Then It Needed to Send an Email—a practical look at transactional email services, why I moved from SendGrid to SMTP2GO and why an SMTP credential should never appear in your source code.