We in PROSA have not used Artificial Intelligence in the PROSA company seriously prior – on the code/design-level. But bicycling home from work, the excellent mathematician and programmer Per Christian Moan, stopped me – and strongly advocated me to test the new LLMs Claude or Codex. He did not do this once, but many times, almost every time we meet on the bicycle on the way home. Of course, I knew that the PROSA tool and its implementation could benefit – potentially enormously from the application of AI-based code-support tools like Claude or Codex. One urgent problem we had to solve was the porting issue. We had decided ten years ago to build the User interaction framework based on the open Eclipse framework. The choice was deliberate and at the time a large collection of functionality, library and built-in features that we could deploy. The downside is that Eclipse is a big castle of dependencies – and development, installation and configuration often turn out to be time-consuming, forcing the developer to more of a librarian than a creator and realizer of ideas. To concretize my point, the numbers speak for themselves: The PROSA-Eclipse bundle contains 2081 files and 319 folders. A tiny fraction of this huge set of files are programs that we have created – most of the files are configuration-files automatically generated or required by the Eclipse framework.
We had this implementation of the PROSA tool, that we did not have resources to maintain, due to a lot of external consultancy work and poor funding to establish a stable development and maintenance organization for years. The code was precious and some of it was very advanced – but hard to understand, even for the lead programmers. The mathematical logician Ivar Rummelhoff, who also happen to be a very good programmer – had made a mirror implementation of my belief-algorithm in the backend, implemented in the term-rewriting framework Maude. The experienced functional programmer Thor Kristoffersen had designed a way to build a views framework, carefully and thoroughly designed. The installation procedure for the tool – back in 2018 was extremely complicated. AI-frameworks for code-support seemed to be the exact tool for lifting out of despair: We were running into versioning problems with Java (we ran Java 8), outdated version of the GUI-framework Java FX, the version of the grammar framework Eclipse Xtext malfunctioned – and Eclipse not providing a safe space for experimenting and upgrading. We tried once to upgrade to newer versions in 2020 – but had to give up, the problems occurring during these sessions multiplied – and we ran out of money. Then AI entered the scene. Mayve Per Christian was right? Maybe we could us a coding framework like Claude or Codex could do the job?
My Colleague Erik Vasaasen was already using Codex for Vibe-coding – with great success, and he also pushed for us – “jumping into the realm of AI-coding”. Erik installed Codex on a ten-year-old laptop in my office. We did a few experiments on vibe-coding a graph in the tool, but the result was not accurate. A couple of conversations with several with the research scientists in SAND, including Ariel Almendral was encouraging. “Just start this and learn on the fly!” Well we started. Planning and describing constraints and restriction on the work was the first task. We used Codex to assist us in specifying the plan for porting. We specified very strict requirements on a porting that should not include vibe-alike free coding, out-of-control or impossible-to-understand automatically generated code, and fortunately – Codex agreed😊.
The language translating capabilities of the AI-engines are currently good. In addition to the code-generation-part, the infrastructure part was equally challenging. Could codex get around this monstrous infrastructure? Lots of configuration and dependencies – built into the Eclipse framework? Fortunately it could. Codex has probably been trained on Eclipse in advance.
Asking Codex for advices on how to proceed was also important. The first task was to point to the source code tree and make Codex analyse the code. Along the journey we also gave Codex some documentation we had – figures we had made. This was probably useful to the analysis done afterwards. We asked the tool for performing an automated documentation of the PROSA-specific code – and Codex proposed to introduce three layers:
1. Layer 1: The PROSA core – consisting of the language definitions and analysis engine, including a lot of responsibilities: parsing ROSA source, validation and resolving names, discover interactions, emit Maude input, parse Maude output, build sequence diagram data and export stable JSON DTOs.
2. Layer 2: The PROSA eclipse – consisting of ROSA-editor integration, validation markers, outline and navigation, commands such as analyses, sequence diagrams, protection diagrams (graphs) and tables.
3. PROSA web-application, with the responsibilities of REST endpoints, a browser editor, D3 sequence diagram rendering, D3 protection graph rendering and finally debug and diagnostic panels.
After working on this path for several days – we found several inconvenient and rather destructive paths were followed – and made some significant revisions. I discovered that Codex had started to change the original PROSA codebase – the legacy code base. That was not intended – from my side, and a couple of days were devoted to roll-back to the original code. Erik Vasaasen dropped by at the work site of PROSA and spent quite lot of hours together with me in the final phase of reconstructing the old legacy code into its original form. Together we managed to get the entire GUI front-end up and working into its 2026-edition. The result was fantastic! (see the picture below). We postponed the strict web-porting for a while and focused on the core porting.
So what is next? To be honest I do not know yet. There are so many possibilities for further experimentation and adding of new functionality – using the latest AI-based code-generators. We spent one and a half week to solve the porting problem. In 2020 we tried to do something similar – but had to leave it – unsolved. It costed us 12 000 Euros – and we were nowhere close to have any success. Guesswork of course, but performing the porting without any AI-support would have costed at least 100 000 Euros. And we had made it in just one-and-a-half week!