I no longer work in tech, but I still write simple applications to make my work life easier.
I frequently use what OP refers to as chat-driven programming, and I find it incredibly useful. My process starts by explaining a minimum viable product to the chat, which then generates the code for me. Sometimes, the code requires a bit of manual tweaking, but it’s usually a solid starting point. From there, I describe each new feature I want to add—often pasting in specific functions for the chat to modify or expand.
This approach significantly boosts what I can get done in one coding session. I can take an idea and turn it into something functional on the same day. It allows me to quickly test all my ideas, and if one doesn’t help as expected, I haven’t wasted much time or effort.
The biggest downside, however, is the rapid accumulation of technical debt. The code can get messy quickly. There's often a lot of redundancy and after a few iterations it can be quite daunting to modify.
I have a similar approach, but the mess can be contained by asking for optimizations and refactors very frequently and only asking for very granular features.
> The code can get messy quickly. There's often a lot of redundancy and after a few iterations it can be quite daunting to modify.
i forsee in the future an LLM that has sufficient context length for (automatic) refactoring and tech debt removal, by pasting large portions of these existing code in.
Even without LLMs, at least with statically type languages like C#, ReSharper can do solution wide refactoring that are guaranteed correct as long as you don’t use reflection.
I don’t see any reason it couldn’t do more aggressive refactors with LLMs and either correct itself or don’t do the refactor if it fails static code checking. Visual Studio can already do real time type checking for compile time errors
Cursor has recently added something like this ‘Bug Finder’. It told me that finding bugs on my entire codebase would cost me $21 or so, so I never actually tried, but it sounds cool.
>The biggest downside, however, is the rapid accumulation of technical debt.
Is that really related to the LLM?
Even in pre-LLM times, anytime I've scrapped together some code to solve some small immediate problem it grows tech debt at an amazing rate. Getting a feel for when a piece of code is going to be around long enough that it needs to be refactored, cleaned up, documented, etc. is a skill I developed over time. Even now it isn't a prefect guess, as there is an ongoing tug of war between wasting time today refactoring something I might not touch again with wasting time tomorrow having to pick up something I didn't clean up.
> The biggest downside, however, is the rapid accumulation of technical debt. The code can get messy quickly. There's often a lot of redundancy and after a few iterations it can be quite daunting to modify.
What stops you from using o1 or sonnet to refactor everything? It sounds like a typical LLM task.
I frequently use what OP refers to as chat-driven programming, and I find it incredibly useful. My process starts by explaining a minimum viable product to the chat, which then generates the code for me. Sometimes, the code requires a bit of manual tweaking, but it’s usually a solid starting point. From there, I describe each new feature I want to add—often pasting in specific functions for the chat to modify or expand.
This approach significantly boosts what I can get done in one coding session. I can take an idea and turn it into something functional on the same day. It allows me to quickly test all my ideas, and if one doesn’t help as expected, I haven’t wasted much time or effort.
The biggest downside, however, is the rapid accumulation of technical debt. The code can get messy quickly. There's often a lot of redundancy and after a few iterations it can be quite daunting to modify.