3 ms·
The models are good enough these days that I see it like managing a team of juniors. The LLMs need guidance and oversight, and about the same amount of time I'd
by taberiand 2mo ago
The models are good enough these days that I see it like managing a team of juniors. The LLMs need guidance and oversight, and about the same amount of time I'd spend reviewing code from a junior I spend on the LLM output. I think generally it's best practice to work in a way that "commit and hope it works (because it passes all the CI/CD automated testing and verification, and it's a change gated behind feature flags and has an identified and minimal blast radius, etc)" is possible
- vekker 2mo agoI feel like these days it's more like managing a team of seniors who are technically very competent, but may not always have the full domain context of the problem they're solving. And/or they forget parts, if that context is too large. And/or they have a poor temporal dimension (deprecated badly maintained information polluting the context). They also tend to overengineer solutions if not guided well. If you think about it, in that respect it's not that different from managing actual human senior engineers. I think this is why focussing one's limited human attention more the input (defining clear requirements) as well as on validating the output (good CI/CD including end-to-end automated tests) is far more important than manual code reviews and micro-managing the development process.
- jurgenburgen 2mo agoReviewing LLM code is quite different from junior code. With juniors you tread carefully and give feedback only on important points to encourage growth. With LLMs you channel the inner sailor and nitpick so much that even a senior would start to cry.