4 ms·

For me, a team of junior developers that refuse to learn from their mistakes is the fuel of nightmares. I'm stuck in a loop where every day I need to explain to

For me, a team of junior developers that refuse to learn from their mistakes is the fuel of nightmares. I'm stuck in a loop where every day I need to explain to a new hire why they made the exact same beginner's mistake as the last person on the last day. Eventually, I'd rather spend half an hour of my own time than to explain the problem once more... Why anyone thinks having 3 different PRs for each jira ticket might boost productivity, is beyond me. Related anime: I May Be a Guild Receptionist, But I'll Solo Any Boss to Clock Out on Time

simonw 2y ago
One of the (many) differences between junior developers and LLM assistance is that humans can learn from their mistakes, whereas with LLMs it's up to you as the prompter to learn from their mistakes. If an LLM screws something up you can often adjust their prompt to avoid that particular problem in the future.
- skerit 2y ago
  > One of the (many) differences between junior developers and LLM assistance is that humans can learn from their mistakes One would think so, but I've had some developers repeat the same mistake a hundred times, where eventually they admit they just keep forgetting it. The frustration you feel when telling a human for the Xth time that we do not allow yoda-conditions in our codebase is incredibly similar to when an AI does something wrong.
- albrewer 2y ago
  > often Often being about 30% of the time in my experience
abc-1 2y ago
Darn I wonder if systems could be modified so that common mistakes become less common or if documentation could be written once and read multiple times by different people.
- danielbln 2y ago
  We feed it conventions that are automatically loaded for every LLM task, do that the LLM adheres to coding style, comment style, common project tooling and architecture etc. These systems don't do online learning, but that doesn't mean you can spoon feed them what they should know and mutate that knowledge over time.
noodletheworld 2y ago
It may not be as stupid as it sounds. Randomising LLM outputs (temperature) results is outputs that will always have some degree of hallucination. That’s just math. You can’t mix a random factor in and magically expect it to not exist. There will always be p(generates random crap) > 0. However, in any probabilistic system, you can run a function k times and you’ll get an output distribution that is meaningful if k is high enough. 3 is not high enough. At 3, this is stupid; all you’re observing is random variance. …but, in general, running the same prompt multiple times and taking some kind of general solution from the distribution isn’t totally meaningless, I guess. The thing with LLMs is they scale in a way that actually allows this to be possible, in a way that scaling with humans can’t. … like the monkeys and Shakespeare, there probably a limit to the value it can offer; but it’s not totally meaningless to try it.
- horsawlarway 2y ago
  I think this is an interesting idea, but I also somewhat suspect you've replaced a tedious problem with a harder, more tedious problem. Take your idea further. Now I've got 100 agents, and 100 PRs, and some small percentage of them are decent. The task went from "implement a feature" to "review 100 PRs and select the best one". Even assuming you can ditch 50 percent right off the bat as trash... Reviewing 50 potentially buggy implementations of a feature and selecting the best genuinely sounds worse than just writing the solution. Worse... If you haven't solved the problem before anyways, you're woefully unqualified as a reviewer.
  - skeledrew 2y ago
    There should be test cases ran, coverage ensured. This is trivially automated. LLMs should also review the PRs, at least initially, using the test results as part of the input.
    - horsawlarway 2y ago
      So now either the agent is writing the tests, in which case you're right back to the same issue (which tests are actually worth running?) or your job is now just writing tests (bleh...). And for the llm review of the pr... Why do you assume it'll be worth any more then the original implementation? Or are we just recursing down a level again (if 100 llms review each of the 100 PRs... To infinity and beyond!) This by definition is not trivially automated.
nico 2y ago
> For me, a team of junior developers that refuse to learn from their mistakes is the fuel of nightmares. I'm stuck in a loop where every day I need to explain to a new hire why they made the exact same This is a huge opportunity, maybe the next big breakthrough in AI when someone figures out how to solve it Instead of having a model that knows everything, have a model that can learn on the go from the feedback it gets from the user Ideally a local model too. So something that runs on my computer that I train with my own feedback so that it gets better at the tasks I need it to perform You could also have one at team level, a model that learns from the whole team to perform the tasks the team needs it to perform
- freeone3000 2y ago
  Continual feedback means continual training. No way around it. So you’d have to scope down the functional unit to a fairly small lora in order to get reasonable re-training costs here.
  - nico 2y ago
    Or maybe figure out a different architecture Either way, the end user experience would be vastly improved
  - regularfry 2y ago
    That's not quite true. The system prompt is state that you can use for "training" in a way that fits the problem here. It's not differentiable so you're in slightly alien territory, but it's also more comprehensible than gradient-descending a bunch of weights.
    - immibis 2y ago
      If you treat it as vectors instead of words, it might be differentiable.
- sdesol 2y ago
  > This is a huge opportunity, maybe the next big breakthrough in AI when someone figures out how to solve it I am not saying I solved it, but I believe we are going to experience a paradigm shift in how we program and teach and for some, they are really going to hate it. With AI, we can now easily capture the thought process for how we solve problems, but there is a catch. For this to work, senior developers will need to come to terms that their value is not in writing code, but solving problems. I would say 98% of my code is now AI generated and I have 0% fear that it will make me dumber. I will 100% become less proficient in writing code, but my problem solving skills will not go away and will only get sharper. In the example below, 100% of the code/documentation was AI generated, but I still needed to guide Gemini 2.5 Pro https://app.gitsense.com/?chat=c35f87c5-5b61-4cab-873b-a39886d78870 https://app.gitsense.com/?chat=c35f87c5-5b61-4cab-873b-a3988... After reviewing the code, it was clear what the problem was and since I didn't want to waste token and time, I literally suggested the implementation and told it to not generate any code, but asks it to explain the problem and the solution, as shown below. > The bug is still there. Why does it not use states to to track the start @@ and end @@? If you encounter @@ , you can do an if else on the line by asking if the line ends with @@. If so, you can change the state to expect replacement start delimiter. If it does not end with @@ you can set the state to expect line to end with @@ and not start with @@. Do you understand? Do not generate any code yet. How I see things evolving over time is, senior developers will start to code less and less and the role for junior developers will not only be to code but to review conversations. As we add new features and fix bugs, we will start to link to conversations that Junior developers can learn from. The Dooms day scenario is obviously, with enough conversations, we may reach the point where AI can solve most problems one shot. Full Disclosure: This is my tool
bbatchelder 2y ago
Even with human junior devs, ideally you'd maintain some documentation about common mistakes/gotchas so that when you onboard new people to the team they can read that instead of you having to hold their hand manually. You can do the same thing for LLMs by keeping a file with those details available and included in their context. You can even set up evaluation loops so that entries can be made by other agents.
- ghuntley 2y ago
  correct.
- cyanydeez 2y ago
  The problem with LLMs is they have a defacto recency bias, so they only really remember that last few things you said. I've yet to see any real LLM manage a proper listing of rules.

simonw 2y ago

One of the (many) differences between junior developers and LLM assistance is that humans can learn from their mistakes, whereas with LLMs it's up to you as the prompter to learn from their mistakes. If an LLM screws something up you can often adjust their prompt to avoid that particular problem in the future.

skerit 2y ago
> One of the (many) differences between junior developers and LLM assistance is that humans can learn from their mistakes One would think so, but I've had some developers repeat the same mistake a hundred times, where eventually they admit they just keep forgetting it. The frustration you feel when telling a human for the Xth time that we do not allow yoda-conditions in our codebase is incredibly similar to when an AI does something wrong.
albrewer 2y ago
> often Often being about 30% of the time in my experience

abc-1 2y ago

Darn I wonder if systems could be modified so that common mistakes become less common or if documentation could be written once and read multiple times by different people.

danielbln 2y ago
We feed it conventions that are automatically loaded for every LLM task, do that the LLM adheres to coding style, comment style, common project tooling and architecture etc. These systems don't do online learning, but that doesn't mean you can spoon feed them what they should know and mutate that knowledge over time.

noodletheworld 2y ago

It may not be as stupid as it sounds. Randomising LLM outputs (temperature) results is outputs that will always have some degree of hallucination. That’s just math. You can’t mix a random factor in and magically expect it to not exist. There will always be p(generates random crap) > 0. However, in any probabilistic system, you can run a function k times and you’ll get an output distribution that is meaningful if k is high enough. 3 is not high enough. At 3, this is stupid; all you’re observing is random variance. …but, in general, running the same prompt multiple times and taking some kind of general solution from the distribution isn’t totally meaningless, I guess. The thing with LLMs is they scale in a way that actually allows this to be possible, in a way that scaling with humans can’t. … like the monkeys and Shakespeare, there probably a limit to the value it can offer; but it’s not totally meaningless to try it.

horsawlarway 2y ago
I think this is an interesting idea, but I also somewhat suspect you've replaced a tedious problem with a harder, more tedious problem. Take your idea further. Now I've got 100 agents, and 100 PRs, and some small percentage of them are decent. The task went from "implement a feature" to "review 100 PRs and select the best one". Even assuming you can ditch 50 percent right off the bat as trash... Reviewing 50 potentially buggy implementations of a feature and selecting the best genuinely sounds worse than just writing the solution. Worse... If you haven't solved the problem before anyways, you're woefully unqualified as a reviewer.
- skeledrew 2y ago
  There should be test cases ran, coverage ensured. This is trivially automated. LLMs should also review the PRs, at least initially, using the test results as part of the input.
  - horsawlarway 2y ago
    So now either the agent is writing the tests, in which case you're right back to the same issue (which tests are actually worth running?) or your job is now just writing tests (bleh...). And for the llm review of the pr... Why do you assume it'll be worth any more then the original implementation? Or are we just recursing down a level again (if 100 llms review each of the 100 PRs... To infinity and beyond!) This by definition is not trivially automated.

nico 2y ago

> For me, a team of junior developers that refuse to learn from their mistakes is the fuel of nightmares. I'm stuck in a loop where every day I need to explain to a new hire why they made the exact same This is a huge opportunity, maybe the next big breakthrough in AI when someone figures out how to solve it Instead of having a model that knows everything, have a model that can learn on the go from the feedback it gets from the user Ideally a local model too. So something that runs on my computer that I train with my own feedback so that it gets better at the tasks I need it to perform You could also have one at team level, a model that learns from the whole team to perform the tasks the team needs it to perform

freeone3000 2y ago
Continual feedback means continual training. No way around it. So you’d have to scope down the functional unit to a fairly small lora in order to get reasonable re-training costs here.
- nico 2y ago
  Or maybe figure out a different architecture Either way, the end user experience would be vastly improved
- regularfry 2y ago
  That's not quite true. The system prompt is state that you can use for "training" in a way that fits the problem here. It's not differentiable so you're in slightly alien territory, but it's also more comprehensible than gradient-descending a bunch of weights.
  - immibis 2y ago
    If you treat it as vectors instead of words, it might be differentiable.
sdesol 2y ago
> This is a huge opportunity, maybe the next big breakthrough in AI when someone figures out how to solve it I am not saying I solved it, but I believe we are going to experience a paradigm shift in how we program and teach and for some, they are really going to hate it. With AI, we can now easily capture the thought process for how we solve problems, but there is a catch. For this to work, senior developers will need to come to terms that their value is not in writing code, but solving problems. I would say 98% of my code is now AI generated and I have 0% fear that it will make me dumber. I will 100% become less proficient in writing code, but my problem solving skills will not go away and will only get sharper. In the example below, 100% of the code/documentation was AI generated, but I still needed to guide Gemini 2.5 Pro https://app.gitsense.com/?chat=c35f87c5-5b61-4cab-873b-a39886d78870 https://app.gitsense.com/?chat=c35f87c5-5b61-4cab-873b-a3988... After reviewing the code, it was clear what the problem was and since I didn't want to waste token and time, I literally suggested the implementation and told it to not generate any code, but asks it to explain the problem and the solution, as shown below. > The bug is still there. Why does it not use states to to track the start @@ and end @@? If you encounter @@ , you can do an if else on the line by asking if the line ends with @@. If so, you can change the state to expect replacement start delimiter. If it does not end with @@ you can set the state to expect line to end with @@ and not start with @@. Do you understand? Do not generate any code yet. How I see things evolving over time is, senior developers will start to code less and less and the role for junior developers will not only be to code but to review conversations. As we add new features and fix bugs, we will start to link to conversations that Junior developers can learn from. The Dooms day scenario is obviously, with enough conversations, we may reach the point where AI can solve most problems one shot. Full Disclosure: This is my tool

bbatchelder 2y ago

Even with human junior devs, ideally you'd maintain some documentation about common mistakes/gotchas so that when you onboard new people to the team they can read that instead of you having to hold their hand manually. You can do the same thing for LLMs by keeping a file with those details available and included in their context. You can even set up evaluation loops so that entries can be made by other agents.

ghuntley 2y ago
correct.
cyanydeez 2y ago
The problem with LLMs is they have a defacto recency bias, so they only really remember that last few things you said. I've yet to see any real LLM manage a proper listing of rules.