I've been developing a moderately popular (for an indie) game for over 4 years at this point (full time). C++, SFML, SQLite. Same as you: no coding assistants, no agents, etc. I also don't use git. [1]
One of the largest speedups is from how much of the codebase I can keep in my head. Because I started from an empty C++ file, the engine reflects how I reason and organize concepts (lossless compression). Thus most of the codebase is in my brains RAM.
I don't see how LLM agents are going to improve my productivity in the long run. The less a person understands their code (organized logic), the more abstracted the conversation is going to become when directing an agent. The higher up the abstraction ladder you go, the less distinct your product becomes.
[1] And very, very rarely have I wished I had it for a moment. Not using git simplifies abstracted parts of development. No branches, no ballooning of conceptual tangents, etc. Focus on one thing at a time. Daily backups and a log of what I worked on for the day suffices should I need to revisit/remember earlier changes. I've never been in a situation where I change I made over a week ago interfered with todays work.
I definitely feel like understanding the system is a big part of what makes it relatively easy to maintain/understand.
My game is just in my spare time while I'm looking for work and the scope of the project is small so that I can finish it, release it, and start working on the next one. I'm not trying to build an engine or anything. Just a game. Not even the best game I can make.
I can iterate on it fast because I know the structures. I can refactor it fast because I've built an intuition for a process over time that keeps code amenable to changes over time. I know I'm not going to make the right decisions at the start so I avoid committing to generalizations, etc.
Editing code is pretty fast for me. Again, years working with a particular setup. I still have expandable snippets, multi-cursor editing and a host of macros for common editing motions.
Checking changes... pretty fast. I'm getting to the point where I might invest in using dynamic reloading for my in-development builds. I suspect it will take a few hours to do at most. Not a big deal. For now I have a basic system that just watches for file changes and recompiles/re-runs the program.
In a different context, working on a team in a large multi-million line codebase... I dunno what other people find it's like but I've never found it terribly slow to write/edit code or ship features. I can usually knock most tasks out at a reasonable pace especially when my familiarity with the area of the code I'm working in increases. I usually find my priorities shift with the demands of users, the business, etc. Some times I work on shipping new features quick. Other times it's making sure what we ship the right things and done well so that we don't leak PII.
Either way... actually writing the code isn't the slowest part, in my experience. It's all the other stuff: the meetings, the design, maintenance, documentation, understanding the problem domain, actually shipping the code to production, etc that takes up the most time for me.