You can mount a ramfs filesystem, copy your project into it and work from there. This guarantees your input files are loaded in to RAM, and they will not be re-read from the much slower disk drive. However as you discovered, this is generally not a useful strategy. You already get the exact same benefit.
Ramfs is a very simple filesystem that exports Linux's disk caching mechanisms (the page cache and dentry cache) as a dynamically resizable RAM-based filesystem.
-- https://github.com/torvalds/linux/blob/v4.18/Documentation/filesystems/ramfs-rootfs-initramfs.txt
You can already trust your input files are cached in RAM, the first time they are read. Your output files are also cached, so that you do not wait for them to be written to disk.
There is no artificial limit on how much you can cache, how long it stays cached, etc. Caches only start to be dropped once you have filled RAM. Which cache is dropped first is chosen by terrifyingly elaborated algorithms. The first approximation, is we describe it as Least Recently Used. See What page replacement algorithms are used in Linux kernel for OS file cache?
Note your text editor will explicitly fsync() saved files to disk.
If you run tests of a program that involves fsync(), running these in a filesystem like ramfs may speed them up. Another strategy is to try and disable fsync() with eatmydata / nosync.so.
Some other operating systems might have specific limitations, that can be bypassed using a ramdisk. At one end, the lack of any file caching is why ramdisks were popular on DOS.
tmpfs
tmpfs works the same as ramfs, except that it can use swap space if you have one. I.e. if you need RAM for something else, the Least Recently Used algorithms may select data blocks from tmpfs and swap them to disk.
Most people stick with tmpfs, because it also lets you limit the total size, and shows the space used correctly e.g. in the df command. I'm not sure why this difference exists. The size limit in tmpfs protects you from accidentally filling your entire RAM and basically killing your system. It defaults to half of your RAM.
Other reasons why writes can slow down
The above is a simplification tailored to your case. The writes to files in your case should not need to wait for the disk. However there are some cases of writes that do. See the excellent blog post Why buffered writes are sometimes stalled. The most surprising case is a recent change to Linux called "stable page writes".