Case in point: VSCode has a multistage "upgrade project to the latest .NET runtime with Copilot" process that takes several minutes of processing punctuated by frequent authorization prompts for even the most trivial project, resulting in the functional equivalent of
find . -iname '*.csproj' | xargs sed -E -i.bak 's/(<TargetFramework>net)8(\.0<\/TargetFramework>)/\110\2/'
along the happy path.It has many more features than my shell command, of course, but none that I care about when migrating trivial projects from runtime version n-1 that are unlikely to hit breaking runtime or compiler changes that don't elicit warnings from the toolchain.
If it’s not already a thing, it will be soon, the mental health aspects of all professions moving at unsustainable speeds and what that will do to people.
Nobody will take care of us. Ever.
I don't think any vague claim of "speed" has anything to do with fatigue.
I do think the parallel world monitoring and validating N work fronts, followed by rounds of fixes where you lay there waiting for the agents to converge, is the defining factor.
Instead of you hunkering down and hammering out a single task where your full attention can be focused 100% on a problem, your mindset is a kin to juggling N balls and hoping to not let any of which to fall.
So it's not really about speed but throughput, and keeping up with the throughout rate is mentally taxing.
ask it for recipes, weather, directions, explain baroque art, etc.
arguably still a common use case...
Like in my experience the real burn is if there is some sort of feedback edge where an agent is producing stuff that eventually it has to reconsume.
Like if there is a dag of agents doing something its almost fine.
But if there is a loop somewhere without a huge amount of damping then you have an issue.
If you have ever been a human debugging in the middle of an agent it produces like so many commands and tests for you to do. Like way more than a human would.
I'm pretty sure they do the same thing to each other. Like the loop will amplify the yapping.
Yep, this is happening in lots of companies. I know my small company has about ~1/3rd of the developers working on one (different ones, all semi-personal projects).
I sometimes wonder if we are drawn to building these because it feels like one of the remaining challenges and a desire not to be an "LLM text shuttle". Additionally/alternatively, you can go as fast as you want with building a software factory and you aren't held back by the "bottlenecks" (PR review, QA, etc).
Working on my software factory is the closest to a "flow state" I've been able to achieve since LLMs turned the corner earlier this year and replaced the vast majority of our code-writing work.