Things I've built for the fun of it.

Most “AI-assisted coding” conversations happen around CRUD apps and glue code. For this project I wanted to see just how far I could push the whole agentic coding theme. Using Claude Code, initially as a sounding board for when I needed to make a design decision I was unsure of and me building out all the code structure, as the codebase grew in size and complexity, I refined the process of actually handing the reins more and more to the AI agent instead with me steering, testing and bug-fixing.

The outcome is a C11 compiler which produces x86-64 executables, written entirely in Python with code optimisation built in so the binaries it produces are on a par with the main compilers in use today.

Something I’m really rather proud of.

This was probably my third or fourth attempt at writing a full-on ray tracer, and the first I’ve managed to get to a point where I can call it reasonably complete. As well as the core functionality guided by Jamis’ book, I’ve also added extra features such as a parallel rendering pipeline to boost performance, bounding volume hierarchies and object groups to allow for performant rendering of complex objects, blended 3D textures for somewhat more complex shading than the original book outline details.

Is it finished? Not by a long-shot. The README file on the repo shows a large list of items I’d like to add at some stage. However, I think this one has butted up against the limitations of its current architectural bounds and also what can reasonably be achieved in an interpreted language like Python. Still, I’ve viewing this as a project I’ll revisit again (and again, and again) probably restarting with a better architectural plan next time allowing for more features and a far more performant renderer.

Still, it’s worth taking it out for a spin. The repo has several test files within it and some sample images on the README page so you can see what its capable of.

This began life as an attempt to build a text editor in the vein of the old MS-DOS 6 edit program. The framework broke out of that project and took on a life of its own. This has since been published to crates.io (opens in a new tab) so is available for anyone to download and use.

I’m still actively working on this project so it sees constant enhancement and extension. My role on this has been purely one of design and architecture. The LLM has produced all the code which I’ve simply vetted before releasing. I think through this project I’ve managed to settle on a solid workflow for producing quality code at pace via coding agents.

If anyone wants to take the framework for a test drive, there’s a couple of examples that ship along with it, and I’d love to hear any feedback (either through issues/enhancement requests in the repo) or via the contact form on this site.

This began life as an attempt to build a text editor in the vein of the old MS-DOS 6 edit program. The rvision framework came out of that (and is detailed elsewhere on the Projects page).

The editor supports a full MDI interface, text search and replace, configurable tab-widths and full help system. It runs on Windows, MacOS (both Intel and Apple Silicon) along with Linux, so feel free to take it out for a test drive.

At my current workspace, we’ve adopted an external provider of S3 compatible storage. However, the provider doesn’t give any viable UI onto the storage other than a graph of total usage for the day. Whilst most of our storage use is ephemeral, it is sometimes required that we go look at an individual file for troubleshooting purposes. I’d already built a command-line toolset in Python to allow us to interrogate things, but as the file count became larger, I wanted a better toolset to handle this, so the aws-bucket-handler was born.

It uses the rvision library I built as its main UI driver and replicates some of the core functionality that the AWS console gives us for actual S3 buckets (note that the bucket handler also allows connection to real S3 too - all driven from the connection adopted in the connection dialog).

This has been developed on my own time, so whilst it is a tool generated specifically for my workplace, it’s open-sourced, so feel free to download the code and noodle around with it, or if you just want to take it for a test-drive, there’s binaries built within the repo. Setup details are in the README.md at the repo root.

There’s something I find fascinating about programming languages. Their structure, and elegance. The fact that so much can be achieved with so few key words and commands, and once you get down to the nuts and bolts of how they work under the hood, well - there’s a whole fascinating world of order that distils out of the chaos.

The Lox language is a toy language designed by Robert Nystrom, and his book Crafting Interpreters gives a guide to developing it. This interpreter is the first pass at it. The language is Turing complete so is a fully-capable instrument, but lacks robust system libraries, thus limiting its effectiveness, but as a learning tool it’s ideal.

See the panel elsewhere on CLox for a link to its bytecode compiled cousin.

This is the ‘grown-up’ cousin to the JLox interpreter. It works on the same toy language (Lox) but this time implements a JIT compiler and execution environment (much like that of Java) to gain more performance.

Whilst the language constructs are similar, this builds on the back-end constructs by introducing a rudimentary TAC (three-address code) layer to simplify the eventual executable bytecode, much in the way that a more full-featured compiler would do so before converting to assembly language.

The Lox language is a toy language designed by Robert Nystrom, and his book Crafting Interpreters gives a guide to developing it. This interpreter is the first pass at it. The language is Turing complete so is a fully-capable instrument, but lacks robust system libraries, thus limiting its effectiveness, but as a learning tool it’s ideal.

See the panel elsewhere on JLox for a link to the Lox interpreter.