Aardvark Daily

Please visit the sponsor!

Back to BASICs with AI

Warning, today's column is targeted mainly at programmers and other geeks, especially those who may be playing with AI coding agents.

Back in the late 1970s and early 1980s, regular folk discovered that they could write computer programs.

This was mainly due to the use of the BASIC programming language.

Whereas previously, programming a computer required the use of cryptic languages such as FORTRAN, ALGOL, APL and similar, usually by way of a compilation process that also made debugging difficult and time-consuming.

By comparison, BASIC was simple, easy to understand and interpreted.

This meant that with just a few hours learning, anyone could begin cutting their own code and producing software that did what *they* wanted, rather than having to find someone else's software and adapt to it.

However, there was one big problem with BASIC and untrained programmers.

Classically trained programmers were taught the importance of sofware design and structuring.

With relatively unstructured languages such as FORTRAN and BASIC, this usually involved lots of flow-charts and other bits of documentation that had to be done before the first bit of code was typed.

Those new to programming and lured in by the ease and simplicity of the BASIC language running on a microcomputer often didn't care for such preparatory work. Instead, when writing a new program, they would simply sit down at the keyboard and type:

10 CLS

and proceed to simply type code from the hip -- effectively trying to design the structure of the program as they coded.

While this was okay for relatively trivial bits of software, the lack of structuring mechanisms within the BASIC language itself, combined with a lack of planning and design, often resulted in what was referred to as "spaghetti code".

After a few pages of typing, the resulting program was often buggy, difficult to read and confusing, even for the person that had written it.

The sad reality is that the less structured the language, the more work has to be done before coding to create a design that is not just a jumble of obfuscated computer commands.

As a result of this, there were a huge number of BASIC programs that were little more than a buggy mess. Without any prior planning, someone had simply sat down with an idea and started typing. A hundred GOTO statements later, these programs often "kinda worked" but were certainly not something to be proud of and if there was a need to make changes further down the track then even the smallest alteration could have far-reaching effects by breaking stuff that used to work.

Now, if you've played with AI vibe-coding then this may start to sound familiar.

That's because vibe-coding has become the 2026 equivalent of 1980s BASIC.

Now anyone can sit down with an AI agent and type "make a program that does xyz", just like that BASIC "programmer" could sit down and type "10 CLS" -- without having done any planning, structuring or even data definitions.

Just like in the old days, it's pretty easy to get a simple program running with vibe-coding and it'll probably impress the hell out of your friends and family.

However, just like the old days, such a piece of software will soon become a mess of bugs, errors, inconsistencies and obtuse logic once it goes beyond the point of "trivial".

The big problem I see with many vibe-coders is that they think the AI agent will do *all* the work for them.

Here's the truth: it won't.

I've been spending quite a bit of time exploring the options with vibe-coding recently and looking at what others have been doing. I'm pretty sure I've got a handle on how to use it effectively and why so many folk eventually find their projects falling apart when they attempt to create real-world systems this way.

The biggest hurdle to vibe-coding agents is that of retaining adequate "context" information. The effect of this is that if you're just typing away at a keyboard and expecting the AI to handle everything, you reach a point where every time you make a change, something else stops working or disappears.

I've seen this myself on even relatively small projects. You ad an extra input field on a screen and suddenly, seemingly at random, a chunk of previously working code just vanishes, as if by magic. When you ask for that to be restored the system apologises and then deletes or forgets something else.

The solution is pretty simple but it does require you to be a *real* programmer.

I've had really good success by going back to the fundamentals of structured programming.

The most effective approach seems to be to spend as much time as is necessary to do your structuring and top-down refinement to the point where you can define individual processes with formal contracts that define input, logic and output.

THIS is when you call on AI to cut the code.

Have AI code each process individually, relying on that input, logic and output contract to define exactly what the code does.

The final step is to link these processes (coded by AI) into the final functional system.

In a world of multi-core CPUs and hyperthreading,I'm a great fan of message-driven paradigms where messages are used, not only to transfer data between processes but also to synchronise execution of those processes and avoid the potentially frustrating need for locks and potential race conditions in highly concurrent designs.

So far I'm having great success and Python seems well suited to this sort of approach.

The most important aspect however, is that I'm having fun again with programming. By not expecting AI to do all the work, I'm actually getting some really good results with very little frustration and all I'm using is the free version of Google Gemini as my agentic AI coding tool.

Ah... nice to write a column (at last) which frees my inner geek for a while.

Carpe Diem folks!

Please visit the sponsor!

Here is a PERMANENT link to this column

Rank This Aardvark Page

Change Font