AI. Artificial Intelligence. A broad a deep topic, much more interesting than the shallow—yet endlessly discusses LLM (Large Language Model) mediafest. I can speak with at least a little authority here as my undergraduate degree it in Artificial Intelligence (I say ‘a little’ as I earned my degree back in 1988 and research has moved on¹). As with so many things, the term AI means many things to many people. For better or worse to most people AI has become synonymous with large language models, but in truth AI is a vastly broader (and more interesting) topic. For the purposes of this article though I will consider only the popular LLM based ‘AI’ most of current discussions refer to.

AI bad?

AI, like any technology is morally neutral. We can debate the ethics of how these models have been built using information harvested without the authors’ permission and whether this taints any product of the model and that is a conversation well worth having, just not here². For now let us focus on the implications of using ‘automation’ for various activities in producing Foundry modules.

Art and other content

Should art work (maps, tokens, tile assets, images in journals, etc.) be generated by LLM? This question seems inextricably linked with the aforementioned ethics of training on other’s work. I doubt the debate would be as heated if these LLMs produced output ex nihilo, we may judge the quality of what they produce but not the ethical implications of its use. Under these circumstances we may well lay claim to the output being ‘creative’ while reserving criticism to the quality of what they produced. Sadly, this is not the world we live in and both the quality of ‘AI slop’ and the questionable ethics of its source must both be considered.

In terms of the quality of the output it is hard to deny that improvement has been exponential. What was once easily identifiable as AI product is rapidly becoming very challenging to identify, especially in art that has always been more stylised like fantasy art. We rely more and more on personal attribution (‘No AI’ declarations by creatives) and efforts to watermark AI product in a manner that is difficult to conceal or remove without significant degradation in the output³.

As to the ethical considerations, that is a deep and problematic issue (we debated it back in ‘88 and evidently we still will). Personally, for art (images or prose) I use AI on private projects but would use AI only for placeholders until final art could be commissioned from human artists for projects intended for wider distribution (commercial or free).

Code

I have no talent as an artist, as such I have little stake in the outcome of the AI dispute on creative works produced by AI. I leave it to those with vested interests to debate that issue. When it comes to code I feel I have a stronger case for holding my current position (I think close to forty years in IT as software engineer and multiple other functions over my career gives me a qualifying perspective, despite now describing myself as an ’enthusiastic amateur’).

AI assisted coding is a good thing. Mindless AI churn coding is an abomination.

What is the distinction? Let’s consider someone creating a simple Foundry VTT module (its purpose does not matter other than it requires code rather that other creative content such as images or text). Person A describes the desired result to Claude and receives back all of the code and data files necessary. They place these into Foundry and check the resulting Foundry behaviour. The code apparently does what they want so they declare ‘Job Done’. This person is producing AI churn. They never looked at, let alone understood, the code the AI produced.

Next, person B makes the same description and receives back the same code. But instead of simply reviewing the resulting Foundry behaviour they review the actual code produced. They may well first review the resulting behaviour but they also review the code. They understand what the code is doing. They ensure the code makes sense. The AI has been used to speed up some of the tedium of the coding process but the developer is still in control.

Should person A be banned from using AI? No. Just as I use AI to produce images that I would otherwise be unable to produce they are using AI to produce code that they would otherwise be unable to produce. If their use of the resulting code if reserved to their private games then no harm, no foul. If code produced with AI assistance it to be distributed more broadly, then only developer B’s approach is acceptable. This is the position taken by the Foundry VTT AI content Policy too. You, as the developer are bound to understand the code you produce, AI assisted or otherwise.

I have started using Claude code extensively and it has improved my output considerably (to the point where I am more willing to release code publicly).

In software engineering we use assistive technologies all the time. AI coding assistants are just the latest and they should be treated in much the same way as any other technology.

A compiler (or interpreter) does a lot of heavy lifting for developers but they have become so commonplace that many (even professional) programmers have little idea what these programs actually do. Back in the early 80’s I was cutting my teeth on programming in BASIC. I soon realised that to get the limited hardware of the day to do really interesting things I needed t use machine code (the actual bits the machine ‘understands’). Programming machine code involves inputting a lot of numbers into the machine (in my case via long sessions typing hexadeciml nubers into the computer). This process is errorprone, one wrong humber and your program fails in ‘interesting’ ways. Worse the program ofent just fails without any sigh as to why. Enter Assaembly Languae. This is a marginally more readable way of programming. Instead of a long series of numbers you now use a text form of the instructions and the assembler transforms those basic instructions into that long series of numbers. Eventually compilers became so good that using macnine code or assemjbly language became unecessary in all but some very specialised situations. Compilers take hore human readable sets of instructions and generate those long stings of numbers the macnine craves. What many programmers fail to understand is that unlike assembly language compilers do a lot of optimisiation of the code they write. Modern compilers ar marvels of programming evolution. They automatically flatten, inline, remove, and otherwise mangle code the programmer types in to make it work as efficiently as possible.

Why am I gabbing on about this? To illustrate that ‘coding assisted’ has been around almost as long as programming. AI is just one more step in that chain.

Claude is like having a very bright intern working for me. It can run dozens of tests, set up and tear down systems many times a minute in order to track down a bug. It can generate boilerplate code (the tediously repetative code often required) and can create useful tests to ensure every part of the product’s code is exercised. It can take race of describing what has changed when submitting code back to a repository, and summarizing changes into a release. It can monitor remote tests while I get on with other things.

Is it perfect? No. But I believe its benefits far outweigh the cost of reviewing each of its outputs. It is much easier to describe a refactoring (‘Break this project into separate packages in a monorepo, rework the github workflows so that each package within the monorepo has its own release schedulu’—fifteen minutes for Claude) and review its results (thirty minutes) than if I did the same work myself (best part of a day).

Where Claude shines

In any development there are many things that should be done but that are often skipped because, well because they’re repetitive and boring. Here is my list of tasks I happily leave to Claude and simply review its output.

• Running tests and summarising the results. Yes, vitest does this too but Claude’s ‘added value’ is that it also offers solutions by tracking down whether the issue is with the test of the code under test, then figuring out what should be changed.
• Paperwork. Filling in PRs, commit messages, etc. Sure, some of what it writes is a bit stilted or hard to parse but generally it is better than anything I’m inclined to write out. Reviewing its output and simply editing it produces much more useful records.
• Maintaining consistency. Claude reviews changes, adds comments, makes sure documentations stays more or less in step with code, ensures types get updated, and more.
• Maintenance chores. Dependabot in GitHub keeps you on your toes updating any project dependencies but dealing with it can be a pain. Claude can simply review Dependabot’s suggestions, run local tests, and produce one coherent PR to close of whatever Dependabot raised.
• Code generation. A lot a code is boilerplate and repetative. Claude handles it like a star. Hand it a JSON file, ‘give me a zod specification to validate this.’, done.
• Experimentation/exploration Claude has been great for figuring out issues. Could I do them myself? Probably but Claude runs multiple experiments and reports back while I do other things. For example, ‘My dev server is failing to report the catalogue content’, off Claude trots and a couple of minutes later, ‘it looks like some development work has built a version of the client into dist/ that does not contain the API-key. Rebuild with EMMA_DEFAULT_KEY set to a valid catalogue API-Key should fix the issue.’ Job done.

This all seems to work best when:

• You have a greenfield development. Legacy code, especially a large amount of ’legacy’ code (you know the sort I’m talking about, that code where no one dare tread), tends to degrade Claude’s performance.
• You are dealing with well understood domains. Building a website with a NodeJS server, Postgres database, using SvelteKit, etc. This is a function of Claude’s training data. Go too far of the beaten track and again Claude’s performance tends to degrade.

Conclusion

Despite misgivings about the use of AI (the danger that people ’turn off their brain’ and leave AI assistants to their own devices) I have found that I produce more, higher quality, code with AI assistance. As a solo developer having the extra ’eyes’ checking and a device to perform the repetitive, boring, even error-prone tasks is a boon.