3 ms·

>> I’m clearly much more productive now. I’m doing five things at once very effectively, switching between multiple agent sessions from morning to night. Joel

by senfiaj 3mo ago

>> I’m clearly much more productive now. I’m doing five things at once very effectively, switching between multiple agent sessions from morning to night. Joel Spolsky disagrees here: https://www.joelonsoftware.com/2001/02/12/human-task-switches-considered-harmful/ https://www.joelonsoftware.com/2001/02/12/human-task-switche...

gb2d_hn 3mo ago
I feel like it depends on the task, and that's why people seem to disagree on this. Think about a manager managing 5 devs. If he is working on planning and managing work for his dev team, we don't say he is task switching, he's just taking a management role where he takes a high level view of the task at hand and then delegates the deep dive. Where it differs for devs is that we could in theory run multiple agents concurrently, but frequently, currently, we have to dive in and give the agents significant steers and this pulls us in to the detail. The same will happen for managers. The variables are the complexity of the task, the capability of the agent and the number of tasks. There are lots of scenarios where devs can run multiple tasks without too much mental overload, but I think what is hard is that we don't know when an agent will underperform on a task and we will get pulled back into developer mode. Maybe it's a case of running for as long as you can in manager mode and then accept that when one agent needs help, you have to single task with that agent (I think this is what makes us feel like we are the bottleneck, and that's where the feeling of stress creeps in). I thought about this a lot while working on https://www.agentkanban.io https://www.agentkanban.io which I use to help me partition agent chats by task, run separate worktrees etc
- coffeefirst 3mo ago
  Uh, I am an EM, and you have to treat context switching as the enemy or nothing gets done. There’s a bunch of different tactics for this. Some people hold office hours. I block off 9am for code review any only do it once per day. The programs we call agents are nothing like people.
- senfiaj 3mo ago
  >> I feel like it depends on the task, and that's why people seem to disagree on this. Think about a manager managing 5 devs. If he is working on planning and managing work for his dev team, we don't say he is task switching, he's just taking a management role where he takes a high level view of the task at hand and then delegates the deep dive. This is assuming you fully trust AI code. AI is still not perfect and sometimes might produce code with insufficient quality even when it works. For example, it can fix a bug in a wrong way, such as removing the symptoms instead of fixing the root cause. And so on. Also, I still have to review and test that generated code, especially in complex systems. Yes, AI reduces coding time, but at the expense of increasing the review / testing time, and review is not something all developers enjoy (both as reviewer and someone who is reviewed). This still doesn't seem to be something that has negligible cost of context switching. Also, AI tends to make you more lazy and care less about understanding the requirements. I'll prefer manual coding with some AI assistance for boring / repetitive tasks and finding potential mistakes for software that I care.
sscaryterry 3mo ago
I rate Joel immensely, however, that post is 25 years old.
- peterspath 3mo ago
  still true only the multitasking blocks are thinner and more...
Syntaf 3mo ago
Does Joel still disagree today? Worth noting that this article is 25 years old. The world was very very different back then, especially when it comes to software engineering. Context switching is a problem when the cost of switching contexts is non-negligible -- but in the age of agentic development is that still really true? Surely yes for some problems, but for many others I would argue it no longer is. A personal anecdote for you: At my company we have a local development CLI our devX team built, it allows for agents to interact with standing up, tearing down and managing local stacks for our software suite. When I receive customer feedback about a broken button, or a poor UX experience, I simply start up a prompt: /metal user X reported an issue on the trial balance page, they encountered a blank page when using the inception to date filter. We need to investigate the root cause, spin up a new stack, and resolve the bug. Then off to the next task, maybe some few hours later I'll check back in on the session and I'll see: > PR created: https://github.com/company/repo/pull/12758295 https://github.com/company/repo/pull/12758295 > QA URL: http://localhost:8400/<url> > Summary of root cause and fix: lorem ipsum lorem ipsum After a quick QA session I validate the fix, confirm that our claude reviewer has approved the PR and merge the PR to deploy. The mental burden of switching to this task is quite low, orders of magnitude lower than it would be 25 years ago.
- skydhash 3mo ago
  This behavior is how you get: > user X reported an issue on the trial balance page, they encountered a blank page when using the inception to date filter. It’s whack-a-mole with bugs.
- feanaro 3mo ago
  What is also lower is your understanding of the change. So yes, if you are now essentially only doing the final mile of paper pushing for the LLM, then the mental burden is lower but so is the assurance of what has just transpired. Whether this mode of working is going to be long-term viable is going to depend on how important it is for you to be aware of what has happened for the system in question, how viable the economics are for the LLM usage at this level of assurance and how much ownership you exert over the LLM used or another similarly powered one (because otherwise the LLM can be taken away from you, leaving you at the mercy of a third party with goals that do not align with your own).
kator 3mo ago
That was 2001 today Joel seems to think this is the future: https://hash.ai/ https://hash.ai/
coffeefirst 3mo ago
Also neuroscience disagrees. This really isn’t a debate. OP is wrong.

by senfiaj 3mo ago

gb2d_hn 3mo ago

I feel like it depends on the task, and that's why people seem to disagree on this. Think about a manager managing 5 devs. If he is working on planning and managing work for his dev team, we don't say he is task switching, he's just taking a management role where he takes a high level view of the task at hand and then delegates the deep dive. Where it differs for devs is that we could in theory run multiple agents concurrently, but frequently, currently, we have to dive in and give the agents significant steers and this pulls us in to the detail. The same will happen for managers. The variables are the complexity of the task, the capability of the agent and the number of tasks. There are lots of scenarios where devs can run multiple tasks without too much mental overload, but I think what is hard is that we don't know when an agent will underperform on a task and we will get pulled back into developer mode. Maybe it's a case of running for as long as you can in manager mode and then accept that when one agent needs help, you have to single task with that agent (I think this is what makes us feel like we are the bottleneck, and that's where the feeling of stress creeps in). I thought about this a lot while working on https://www.agentkanban.io https://www.agentkanban.io which I use to help me partition agent chats by task, run separate worktrees etc

coffeefirst 3mo ago
Uh, I am an EM, and you have to treat context switching as the enemy or nothing gets done. There’s a bunch of different tactics for this. Some people hold office hours. I block off 9am for code review any only do it once per day. The programs we call agents are nothing like people.
senfiaj 3mo ago
>> I feel like it depends on the task, and that's why people seem to disagree on this. Think about a manager managing 5 devs. If he is working on planning and managing work for his dev team, we don't say he is task switching, he's just taking a management role where he takes a high level view of the task at hand and then delegates the deep dive. This is assuming you fully trust AI code. AI is still not perfect and sometimes might produce code with insufficient quality even when it works. For example, it can fix a bug in a wrong way, such as removing the symptoms instead of fixing the root cause. And so on. Also, I still have to review and test that generated code, especially in complex systems. Yes, AI reduces coding time, but at the expense of increasing the review / testing time, and review is not something all developers enjoy (both as reviewer and someone who is reviewed). This still doesn't seem to be something that has negligible cost of context switching. Also, AI tends to make you more lazy and care less about understanding the requirements. I'll prefer manual coding with some AI assistance for boring / repetitive tasks and finding potential mistakes for software that I care.

sscaryterry 3mo ago

I rate Joel immensely, however, that post is 25 years old.

peterspath 3mo ago
still true only the multitasking blocks are thinner and more...

Syntaf 3mo ago

Does Joel still disagree today? Worth noting that this article is 25 years old. The world was very very different back then, especially when it comes to software engineering. Context switching is a problem when the cost of switching contexts is non-negligible -- but in the age of agentic development is that still really true? Surely yes for some problems, but for many others I would argue it no longer is. A personal anecdote for you: At my company we have a local development CLI our devX team built, it allows for agents to interact with standing up, tearing down and managing local stacks for our software suite. When I receive customer feedback about a broken button, or a poor UX experience, I simply start up a prompt: /metal user X reported an issue on the trial balance page, they encountered a blank page when using the inception to date filter. We need to investigate the root cause, spin up a new stack, and resolve the bug. Then off to the next task, maybe some few hours later I'll check back in on the session and I'll see: > PR created: https://github.com/company/repo/pull/12758295 https://github.com/company/repo/pull/12758295 > QA URL: http://localhost:8400/<url> > Summary of root cause and fix: lorem ipsum lorem ipsum After a quick QA session I validate the fix, confirm that our claude reviewer has approved the PR and merge the PR to deploy. The mental burden of switching to this task is quite low, orders of magnitude lower than it would be 25 years ago.

skydhash 3mo ago
This behavior is how you get: > user X reported an issue on the trial balance page, they encountered a blank page when using the inception to date filter. It’s whack-a-mole with bugs.
feanaro 3mo ago
What is also lower is your understanding of the change. So yes, if you are now essentially only doing the final mile of paper pushing for the LLM, then the mental burden is lower but so is the assurance of what has just transpired. Whether this mode of working is going to be long-term viable is going to depend on how important it is for you to be aware of what has happened for the system in question, how viable the economics are for the LLM usage at this level of assurance and how much ownership you exert over the LLM used or another similarly powered one (because otherwise the LLM can be taken away from you, leaving you at the mercy of a third party with goals that do not align with your own).

kator 3mo ago

That was 2001 today Joel seems to think this is the future: https://hash.ai/ https://hash.ai/

coffeefirst 3mo ago

Also neuroscience disagrees. This really isn’t a debate. OP is wrong.