Compute42 is a new Julia IDE (integrated development environment) that I have been developing over the last year or so.

In this article I will describe my experiences:

Rust and Tauri

The last couple of years I have become a fan of the Rust programming language. The compiler is your friend and your enemy at the same time, but I prefer it over other languages that I used in the past. The only thing is that GUI development in Rust is still in its infant stages, but I think Tauri is actually pretty good. I have been using that for a number of smaller projects already, but this project is quite a bit bigger and more complex.

AI assisted coding vs vibe coding

Earlier this year I started to gain some experience with vibe coding. I finally settled on using Cursor. The Auto mode (the standard Cursor AI model) is OK for smaller tasks and you can get access to more sophisticated models like GPT-5 or Gemini 2.5 Pro if needed. I decided to use the help of an AI agent for this project, because of its sheer scale. My hope was that coding together with an AI agent would speed up development quite significantly. I started off with vibe coding: just give the agent high-level descriptions of what I wanted and leave all the implementation details to the AI agent. But this soon backfired and the codebase became quite a big mess. Over time I found a way of working that seems to work for me:

• For any change that spans more than a few lines of code, first write a small design document in Markdown together with the AI agent. AI agents have a tendency to add a lot of fluff to design documents, so you constantly have to remind the agent to keep it short and simple. For example, it often adds planning, milestones and stuff like that, which I don’t really need. When you make such a design document, the chance that the AI agent implements the feature like you expect is much bigger.
• The Rust compiler is quite strict and helps to identify mistakes that the agent will make. Of course unit tests and integration tests are also crucial to ensure code quality. So make sure to request a “cargo check” and/or “cargo test” after every set of changes the AI agent makes. Assume that the AI agent WILL make mistakes when writing new code.
• You as the human programmer have to outline the software design/architecture in a Markdown document. AI agents don’t care so much about well-structured code, so you have to provide enough guidance yourself.

Software architecture

It took me quite some time to experiment with various software architectures before I settled on the current architecture. Tauri consists of a web frontend and a Rust-based backend. The Rust backend has several “handlers” that can be called by the frontend using Javascript/Typescript. So it is quite similar to the design of a web service with various HTTP handlers. In Tauri there is a built-in mechanism for these handlers to access a shared state. This does mean you have to take concurrency into account. I started off using mutexes and channels, but this became a bit of a mess. Especially mutexes with AI assistants are a disaster. In a larger codebase, where several “services” have to be coordinated and mutexes are everywhere, the AI assistant created many (potential) deadlocks in the code. I tried to split the code into services with DI (dependency injection) so it would be possible to test the services individually. I soon found out that it is not possible to run “cargo test” on a Tauri project in Windows as you can see here. I tried several workarounds, but in the end I decided to refactor the project and move all the business logic to a separate Rust library that doesn’t have any direct Tauri dependencies. This library then can be tested properly and the remaining code in the Tauri Rust backend is mostly just wrapper code. This also enables a better decoupling between the business logic and the GUI framework (Tauri), so I am happy with this solution.

The concurrency issues remained though and there were too many inter-dependencies between the various services in the business logic. I then decided to go for an actor model approach in Rust. Actix seemed to be the most promising implementation of the actor model and it is battle tested in Actix Web. It took some effort to get the AI agent to implement the first actors (because they “think” they already know the API of specific Rust libraries, but this is often based on very old versions of that particular library). Showing the agent a lot of example code often works better than showing them docs.

Frontend

For the frontend I decided to go for Vue 3. I also like Svelte, but in Svelte 5 there have been significant syntax changes, which the AI agents don’t handle very well (yet). I use Typescript instead of Javascript to prevent type related errors where possible. I started using ts-rs to export Rust structs and enums to Typescript, so I don’t have to manually keep the types on the backend and frontend of the Tauri app in sync. This actually works very well.

Software now available

I open source Compute42 on Github and recently released the first v0.1 of Compute42. Please download it and try for yourself. Let me know what you think of it. Did you encounter any bugs? Are there specific features that you would like to see in the future?