I suppose if you stored the code in ASTs and the LLMs all have to parse the code into ASTs when analyzing it, you could make it more efficient for them to work on code?
If you don't use Excel (or Google Sheets in my case) it's my favorite way to do financial calculations because you can easily customize contribution amounts or withdrawals in certain years by having different columns.
I personally have settled in working at big companies, where expectations are really not that high of anyone. While I'm still highly productive at work, I don't go 100% as it will just piss all the other devs off. I give it about 50% effort and when the bell rings I just close the laptop. After all, it is just a job.
I've had the opposite experience, but keep in mind that a lot of what gets worked on in large companies is glorified legacy CRUD apps. What I mean is, these applications have already been built with little thought about architecture, best practices and testing. These apps already have design flaws and bugs galore.
In these types of applications, there's already a lot of low hanging fruit to be had from working with an LLM.
If you're on a greenfield app where you get to make those decisions at the start, then I think I would still use the LLMs but I would be mindful of what you check into the code base. You would be better off setting up the project structure yourself and coding some things as examples of how you want the app to work. Once you have some examples in place, then you can use the LLMs to repeat the process for new screens/features.
I find that my usage varies based on a cycle of: 1) Using the LLM like crazy to help refactor code, extract components for re-use to speed up things in the long run 2) The refactoring has sped up the work significantly, but now I need to pause and address technical debt that the LLM introduced.
I don't think you're using the term technical debt correctly. Technical debt occurs when you intentionally choose to do something the expedient way even if it causes you to invest more time later, usually due to an important deadline, which means that an hour before the deadline is worth more than an hour after the deadline.
What technical debt is not: something done poorly due to a skill issue.