A mission statement from RISC OS Technologies

And a look at the use of AI in programming.

About a week ago Martin Eastwood, who is using the name RISC OS Technologies for his efforts with the operating system, published a mission statement – and rather than just quote it and leave it at that, it’s worth looking a little deeper into what’s behind it – chiefly, his use of AI to develop software, and the reaction it has caused. First, however, it does need to be quoted in full:

As readers will hopefully know, last year Martin produced a new theme for RISC OS, Frosted, which was very well received. Since then, his focus has shifted to software development, even though he isn’t actually a programmer – for that he makes use of artificial intelligence assistants (which from this point I’ll just refer to as AI). As this is a contentious issue, leading to a large part of the sentiment expressed in the mission statement above, it’s worth taking the opportunity to look at that in more detail.

Vibe coding

There are different ways of using AI in software development, and the simplest, possibly least contentious method is to have the AI help by distilling documentation, explaining how to achieve something in a way that is hopefully easier for the programmer to understand.

At the other end of the scale there is what’s known as ‘vibe coding’. This is a relatively new term for an equally new approach to software development. Putting it very simply, it involves telling the AI what you want, in however much detail is needed, so that it can then produce the software that was described.

It’s slightly more complicated than that because the code produced by the AI at first is unlikely to be exactly what was required (the description might need refining) – or bug free. The process therefore involves feeding back any problems to the AI, so that it can then try to address them. This happens as many times as necessary, until the result is a piece of software that fits what was wanted.

There are other ways to use AI that sit between the two examples above, such as just having it solve specific problems (or write individual functions within a broader project), but vibe coding is what Martin does – and there are both pros and cons to doing this. I will briefly touch on the most obvious pro, but it’s the cons that people have issues with, and are therefore the reason for the wording of Martin’s mission statement, so I will look at those in a little more detail.

The benefits of vibe coding

The major appeal is that software can be developed much, much more quickly than it could when someone is writing it by hand. It also makes software development more accessible to people who may not be developers – or allows developers at any level to produce software that would otherwise beyond their means.

With the RISC OS community being as small as it is, the number of people developing for RISC OS – or, indeed, developing RISC OS – is very small. It’s not difficult to see, therefore, that with vibe coding employed a lot more can be achieved a lot more quickly than it otherwise would, and things can be moved forward at a higher pace than without.

However, as I noted above, it’s an area that causes a great deal of contention, so we must look at the most obvious cons.

Copyrights and licences

A significant issue is whether the code produced by the AI is original, or whether it has made use of code from other projects; code that it has ‘seen’ by way of it being used in its training data. It’s all but inevitable that AIs are going to do that, because of the way they work. For all intents and purposes, you can think of them as having a near perfect memory of everything that they’ve ever ‘learnt’, so if their training data includes a function to (picking a random, but quite trivial and therefore silly example) draw a circle on the screen, when the software they’re being used to develop needs to draw a circle on the screen, they’re going to produce code that either includes that pre-existing code explicitly, or it’s going to produce something based on it, and therefore very close to it.

Someone, somewhere, had already written that piece of code as a part of something else, and it will therefore be that developer’s intellectual property, and subject to their choice of licence.

This particular problem hit Martin very recently with the initial release of an emulator, which he announced on the RISC OS Open Ltd (ROOL) forums. That emulator, vibe coded with the aid of an AI, had RPCEmu at its core, the sources for which are available under the Gnu General Public Licence (GPL) version 2. The impression I got when I read the discussion was that Martin didn’t understand the implications of that licence at that point, so wasn’t initially using (or complying with) it at first, and this resulted in a discussion that became very heated and, in places, quite ugly.

This problem isn’t exclusive to RISC OS. Wherever AI is being used in this fashion, there is a very strong possibility that it’s going to be using code drawn from other project sometimes small amounts, other times significant chunks – and which is therefore subject to whatever licence has been chosen by the developers of those projects.

The upshot of this is that people who use it in this way do need to be very careful about where the AI may have sourced its code from, and whether that code is subject to a licence that (a) permits it to be used at all, and (b) whether it’s compatible with the one they intend to use.

I imagine (hope?) the AIs clearly indicate where code has been reused in this way, in which case it’s down to the vibe coders to look carefully at the output – but for a large project this will be an equally large task, and for a non-programmer an even larger one.

Identifying problem code

Another important issue is the ability of the developer (if they are able) or other programmers to review the resulting code to ensure it is truly without problems.

I noted above that another approach to using AI in programming is to have it just produce individual functions, which the programmer can then look at in turn, adapt, and fix if necessary – or even just disregard and write new functions based on what the AI produced.

A small function is a lot easier for a human to look at and review than an entire application or other tool – which means any problems in that function will be much easier to spot and address.

The vibe coder can perform all manner of tests on the software produced by the AI, and after a number of iterations of feeding issues back to the AI and getting new versions, that testing might not show up any problems. However, sometimes bugs can be subtle, and may not be obvious from the outset – especially in a large project. In that, a programmer simply looking at the code to identify issues is a vastly larger job than to do so with an AI-written function.

It’s also possible for a piece of software to contain bugs that aren’t necessarily obvious through code review, and only triggered in very particular sets of circumstances, and which may not show up for many years. Note: this applies equally to software developed by humans, as well as AIs.

This is an issue that worries some people who are firmly anti-AI in software development, because if a serious bug crops up in an application developed through vibe coding – particularly if it’s several years down the line – they fear that it might not be fixable if the person who tasked the AI to create it is no longer around, or perhaps doesn’t understand enough about the bug to be able to instruct the AI to deal with it.

If the software is open source, then one counter to that argument is that you can look at the source code yourself and try to fix the bug – but the practicality of doing that depends on the nature of the code the first place; how well written it is, and how human readable.

Another possible solution would be to follow the vibe coder’s original approach, and also use vibe coding to fix the problems. However, the person doing that might not have access to the same AI, with the same learning data, etc. behind it, and this might be detrimental. In fixing one bug, it could introduce more, or even lead to fundamental changes to the software, or the code behind it, requiring even more feeding back to the AI until something functionally equivalent is produced.

Again, though, this is equally true when developers fix bugs in software they’ve developed via traditional methods; new bugs can be introduced as a result of fixing others – but human programmers are less likely to fundamentally change the software as part of their process, unless they are making a conscious decision to make significant changes, perhaps by rewriting or refactoring code to make it more efficient.

This being another contentious issue with vibe coding, it has also caused the discussions on the ROOL forums to become somewhat heated.

Acceptance into open source projects

Both of the above issues can be a factor in why some open source projects flat out refuse to accept submissions from developers who have used AI for their work – especially where it’s been used for vibe coding, because that can result in submissions that include significant amounts of code, in a short space of time, all of which needs to be reviewed.

The teams behind those projects may not be large, and probably have lives beyond their software projects – so won’t have the sort of time needed to review all of that code.

In conclusion

There are more pros and cons to all this, and even the more obvious ones mentioned above can have even more subtleties attached to them, which are beyond the scope of RISCOSitory. In truth, that could be said of the main bulk of this post, but I felt it worth attaching some sort of explanatory post to Martin’s announcement, albeit perhaps an oversimplified one.

The bottom line, though, is that vibe coded software is now a thing, both on RISC OS and elsewhere – and there’s no getting away from that.

When it comes to its use, at the end of the day that’s down to the individual users of the platform:

• If you want this software for RISC OS – and some of what Martin has produced this way looks like it could be very useful, or could move the OS forward more rapidly than it otherwise would – then use it.
• If you don’t want vibe coded software, then don’t use it – it’s as simple as that; nobody is forcing it on you.

Here in the RISCOSitory bunker, I’m not entirely confident in software produced this way. I therefore won’t use it on what I’d call mission-critical systems – the ones I rely on for work. RISC OS hasn’t fallen into that category for me for a long time, so I have no real qualms about running this type of software on it. On other platforms, though – platforms on which I have important data – I’m much more wary, and would rather steer clear of it unless I have no choice.