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.
Very good article. I feel that corporate executives as a class are causing this huge mess from a simple lack of understanding of software engineering. Throw more bodies at the problem has never worked in software engineering, in fact that's a surefire way to make things worse and slower.
Throwing more bodies + AI at the problem is even worse because the speed at which things get worse is much faster. If you have people that don't understand the implications of what they are doing, you're on the path of heading over a cliff some day.
AI is a useful tool, when put into the hands of someone that is competent. They can fire junior devs and refuse to hire them as much as they want, this strategy will come home to roost sooner rather than later.
If a C-level executive thinks that AI can replace their engineers, then I say do it now. Go all in and replace them all right now. Use only AI and a few VP-level AI whisperers and let the catastrophic failure that this will result in happen faster so we can get back to reality quicker.
I’ve never used Next.js. To be honest, Express has always gotten the job done without too much hassle. In theory, what are the benefits of using Next.js over Express?
Nice site though!