[slt2021]

sorry but these examples are not impressive at all and by no means a representative of any serious programmer's workload.

Programmers are paid not to bang out code, but rather to figure out the mess and crap of the existing codebase and how to selectively add one-two lines to change system's behavior and keep stability of the system.

[simonw]

Part of the trick of making the most of LLMs is figuring out what kind of things to apply them to.

I wouldn't expect much from them for figuring out gnarly changes in huge existing codebases (at least not yet).

But they've been actively encouraging me to write smaller, tighter tools - the good old Unix philosophy - for which they are extremely well suited.

[Source_Code]

This comment makes me feel as if I've been taking a wrong approach to using LLMs in my day to day work. I haven't been able to get much value out of them as a large majority of the work I do requires a good deal of context with some repo specific problems.

Our existing tooling and helpers lack modularity to begin with. I'm now thinking it would be a better approach to start with having it build smaller tools and patch them together in more useful and interesting ways myself as opposed to being upset that it can't deliver complex, context aware solutions.

Still not buying into the hype that LLMs will replace all software engineers by 2030 due to thinking the nature of our work is not to write code but to solve problems, regardless of the tools we are using, but I definitely see potential productivity gains from using the tool with a different approach to what I have previously attempted.