The idea started while I was testing some Fortran code. I thought it would be convenient to run fpm once and then simply modify the source files and have the project rebuild or rerun automatically.
At first, I began implementing the project myself, but I did not have enough time to continue. So I decided to experiment with GPT. My first attempts with the normal GPT 5.2 model were not very successful. After some trial and error, I realized that creating a dedicated project and using the PRO version for the initial prompt was important.
In the first main prompt, I specified several strict constraints. The most important ones were:
- Keep the design simple, user-friendly and maintainable.
- Ensure portability across platforms.
- Use the latest fpm version available on GitHub.
- Use fpm as a dependency.
- Do not reimplement fpm.
- Do not add comments.
- Do not duplicate code.
- Use pure and elemental procedures where possible.
- Avoid unnecessary temporary variables.
- Consider performance.
- Minimize CPU usage.
- Minimize memory usage.
- Provide the entire code so it can be copied and pasted directly.
- ā¦
Using PRO, the initial reasoning phase took around 30 minutes. During that phase, I occasionally checked what GPT was planning and refined the prompt when I saw it heading in the wrong direction.
The first generated version was not very good. I noticed many issues that I could have fixed myself, but instead I described each problem as a new prompt and asked GPT to improve the code iteratively, always respecting the original constraints. I compiled the code locally, reported errors and warnings back to GPT, and asked for corrections.
After several iterations, I obtained a working version. Then I opened a new chat within the same project and asked for a full review focusing on logic, correctness, portability and performance. Some suggestions were good, some were not. At this stage, it was very important to give precise instructions such as:
- Fix only this specific issue.
- Do not introduce helper variables or helper functions.
- Do not modify unrelated parts of the code.
- Always provide the entire modified module.
- ā¦
I found that without these constraints, the AI sometimes rewrote large parts of the code or removed functionality unintentionally.
Next, I asked GPT to propose a more maintainable architecture for long-term development. It suggested splitting the code into multiple modules. After reviewing the proposal, I accepted a modular design. Over time, GPT started respecting my initial constraints without me having to repeat them in every prompt.
After splitting the code into multiple modules, I provided a simple Bash script to combine all src and app files into a single file when needed, so I could pass the complete code back to GPT. From that point on, I asked GPT to return only the affected modules or procedures instead of the entire codebase.
At one point, the code base became much larger and less readable, although it was working. I maintained a single test case that always had to pass. I then asked GPT to reduce duplication and simplify the code without changing functionality, performance, or the user interface. After several iterations, the structure improved.
In the final stage, I opened another chat and requested a complete review focusing on logic, correctness, performance, syntax, usability, and maintainability, explicitly stating that the public API and functionality must not change. After that review, the code was essentially ready.
Throughout the whole process, whenever I noticed a problem, instead of fixing it manually, I described it and asked GPT to correct it.
When I had a working version, I also requested stylistic improvements, such as using type my_type instead of type :: my_type, choosing more descriptive variable and procedure names, and improving overall consistency. Here, fortitude were also very useful.
Then I asked GPT to use FACE for coloring, again specifying: do not reimplement FACE, use it as a dependency, do not modify the user interface, and do not change any functionality.
Finally, once everything worked and passed CI, I asked GPT to generate professional, production-ready documentation using FORD style only, not Doxygen style, because it often mixes Doxygen-style comments into FORD documentation.
That was more or less the overall workflow.
Each PRO prompt took around 30 minutes of reasoning time, but I used that time to do other things. In total, I worked on the project for about 7 days, definitely not full-time, mostly in the evenings after work, while also developing other Fortran codes myself. 
I would say it is interesting to use AI in many aspects: code review, documentation, styling, unit testing and maybe optimization. It seems to work quite well nowadays. On the other hand, I sometimes miss the time when I developed my FEM and optimization codes myself. It was a lot of fun to solve the problems on my own. Sometimes it took a long time to find a reshaping or indexing bug, but now it seems AI can often detect such issues in seconds.