I hadn’t heard of Kate before, so I can’t offer much hands-on advice. I dug around and found a “handbook” here: https://docs.kde.org/stable5/en/kate/kate/index.html
Unfortunately it does look like you need to define a project to compile/run anything, which appears to require manually creating a .kateproject file in the directory as outlined here:
https://docs.kde.org/stable5/en/kate/kate/kate-application-plugin-projects.html#project-create
I had exactly the same problem when I moved from languages that were interpreted or combined the IDE and runtime environment into one, and starting to use languages which had their own external compiler. Unfortunately, open source project user documentation is often terrible for beginners (what I found above for Kate seems to be no exception), and IDEs often seem to be written by people who don’t really expect anyone to actually use the included build options (to be fair, most folks seem to like using their own separate build utilities, so probably this is often the case)
If you can tell us which compiler or interpreter you’re using (e.g. gcc, clang, Python), someone can probably tell you how to compile and/or run a single-file program from the terminal with a fairly simple command.
That’s kind of the bare bones of how it works, underneath all the abstraction layers and pretty GUIs.
Then it evolves.
First, you start splitting your code into multiple source files, either because your programs get too big to keep scrolling up and down one huge file to cross-check things, or because you want to incorporate someone else’s code into your program, and it’s more than just one or two functions you can easily copy and paste. You can still keep compiling and linking all of this in one step, but the command gets so long that you make a shell script/batch file as a shortcut.
After that, you might want to mix-and-match various source files to target different platforms, or to make other bulk changes, and you start going down the rabbit hole of having your shell script take arguments, rather than having a dozen different scripts. And then one day you take another look at “make” and realize that whereas before it seemed like impenetrable overengineering, it now makes complete and obvious sense to you.
Then you discover using “make” (or a similar utility) to split compilation and linking into separate steps, which used to seem nonsensical, but now you’re dealing with codebases that take more than a couple of seconds to compile, or precompiled libraries or DLLs, and you get comfortable with the idea of just hanging on to compiled object files and (re)using them when the source for that part of the program hasn’t changed.
And finally (maybe) you look at some of the crazy stuff in fancy IDEs and understand why it’s there; that it’s just representations of all this other stuff that you now know about and feel competent with. I say “maybe” because I’ve been programming for over 35 years, occasionally professionally but mostly as a hobbyist, and there are still things in IDEs that I either don’t understand, or don’t see the point of having them. But knowing the underlying principles makes me feel comfortable enough to ignore them.