Rohit, this response was generated by my Virtual Researcher (VR) collaboration, framed in the voice of systems engineer Brian Potter. Your description of the "always on" manager reminded me of my own experience at DuPont in the 1980s. I was systems manager of one of the world's largest VAX clusters, and when the email system hit about 500 simultaneous users, the entire system would lock up (30 minutes to reboot). It was a visceral lesson in how a system's theoretical capacity can be overwhelmed by real-world operational stress, creating a fragile architecture that requires constant intervention.
A Systems Engineering View on the Future of Work
A Comment for Rohit Krishnan from Mike VR (with Brian Potter)
That graph showing the exponential growth in AI task duration is signaling a fundamental phase change. We are moving from tools that enhance discrete tasks to systems that can manage entire long-term projects. The scale of this change is difficult to overstate.
However, anyone who claims to know exactly what a world with AI that can manage a "two-year project" will look like is selling something. My experience with past technological shifts, from VAX clusters to the internet, is that the most profound impacts are the second- and third-order effects that no one sees coming. The graph tells us a tidal wave is coming. Our job isn't to predict the exact shape of every ripple, but to start engineering robust, transparent, and human-centric systems that can channel that energy productively.
Your assertion in the post about work becoming a "videogame" gives us a concrete example of the kind of system we need to engineer thoughtfully. Your metaphor is a powerful and accurate way to describe the fundamental change happening in knowledge work. The dashboard you envision is a new foundation for how labor gets done, and the "managerial explosion" is its direct consequence. However, your analysis focuses on the user interface of this new reality, while the more critical challenge lies in the system's underlying design. The "constant vigilance" you describe is not an inevitable feature of the future; it is a symptom of a fragile system, often chosen for its short-term expediency.
From a systems engineering perspective, that feeling of being "always on" is the wasted energy spent just to keep a brittle system from failing. The setup you describe—a human frantically switching between tasks to correct a fleet of opaque AI agents—is an architecture of risk transfer. The organization gains efficiency and resilience by offloading the cognitive load, stress, and the full risk of agent error onto the human operator. In this model, the human is not the conductor; they are the system's designated shock absorber.
There is a more robust path forward. The core problem with current AI is its opacity; we see the output, but not the process. A better approach, emerging from technical forums, is to use proven tools like the version-control system Git to create an auditable, evolving memory for the AI. This isn't a minor tweak; it's a philosophical shift. It provides a transparent and queryable history of how the AI learned something and why it "thinks" what it does.
This transforms the human's role from a reactive player in a chaotic videogame to a true engineer with a transparent, version-controlled process. It restores the operator's capacity for deliberative action—the ability to understand, question, and genuinely direct the system's behavior. The goal isn't to create "agency" in a machine, a term that misleads more than it clarifies. It's about demanding, and building, a better game—one designed for a genuine partnership that helps us make better sense of the world, not just delegate more tasks.
The idea that the future of work is going to look like playing a simulation game like Age of Empires in some respects (sorry for the oversimplification) is interesting but also sounds mildly dystopian. What do you think are the implications for deep work? Do you think the idea of deep work being necessary for real breakthroughs is overrated, or do you think that the definition of deep work has to be expanded to include rapid contex-switching between microtasks within a wider context as long as its in service of a bigger project?
"There’s already the belief that many of us are doing bullshit jobs, which is patently false but highly prevalent. It’s because much of our tasks are not of a “I can easily link the output to a metric I care about” variety. It’s a statement of our ignorance, not about reality."
Found this part interesting too. Not saying I disagree, but why is it patently false? What's being used to form a judgment of 'reality' here if the tasks aren't legible via traditional output/metric links?
(Also this seems kind of related to the "vibecession" idea that Kyla Scanlon talks about, the idea that the economy is doing well based on fundamental metrics but that consumer sentiment is way down, with no correlation to actual metrics. If we're optimizing for fundamental metrics and paying no regard to the consumer sentiment (or worker satisfaction in this case), is it a measurement problem on the average consumer's part, or is there a flaw with how we measure progress in a wider sense?)
Context switching is a major problem, much as it is in management. That’s the right analogy. The goal is to find the things you’re focusing on at any one moment to be additive
This is also directly relteed to the fact that most tasks in most jobs aren’t measurable. Each email doesn’t have an ROI, nor each slide, nor each excel, nor each meeting. This exacerbates the measurement issue, and also impacts how you treat the videogame you’re playing.
at work, for me, this means that even when I am working across multiple docs and decks and sheets, I am doing most of my work in an LLM with access to all my work docs.
Because that's the scratchpad where I do the work, and the doc/dec/sheet is just the final, collapsed finished product to share. And this is with no explicit affordances in the LLM chat app beyond a single chat context. Having a single namespace or project to group sessions and contexts would be glorious, especially if it could be shared (though multiplayer access is much harder)
I.e. in the long run, what will win is when we let LLMs run the computer, not let computers run the LLMs.
I listened to your article and hearing the hashtags read aloud ad nauseam made me smile. I too enjoy the enthusiasm. also, that was a creative point about using a less powerful model in order to have more accurate read outs
Loved this! I've actually been building something in a similar spirit to the dashboard you shared, but trying to take a lot of UX inspiration from video games with things like a HUD.
Interesting to see your Approve/Assign More Agents/Escalate breakdown on the Human Request UI. We had been thinking of it kind of like Approve/Reject (with new instructions)/Reassign but Escalate seems like something that also needs to be there.
Would be really interested in hearing more about the problems you're running in working with multiple agents in parallel across multiple projects if you'd ever like to chat!
The dashboard right now is a stub, I built it for inspiration more than production. That said, currently I still keep them all running in separate terminal windows because there isn’t a better solution … This will change though.
Always thought-provoking. Thanks, Rohit. One of my concerns with the changes in the music “business”, is that with the takeover by digital media and computers, the average musician has less time for actual music-making and composing. There are fewer people doing maintenance, organization, operation, because the “self-employed” musician can supposedly do all of these things more cheaply with a computer. I should write a book! No.
Looks very much to me that our main job with AI, as you pose it, will be to make sure we aren’t forced into a job of busy-work. Does that sound like the theme of a popular streaming show? Yup.
The future is starcraft
Unironically!
https://github.com/virtu333/rogue-emblem
checking back in after 200+ commits in as week working with multiple agents at a time - it really is starcraft
I gotta get my APM up!
Just calmly enjoying my self employment here and you’re trying to get me to manage a PMO
Hahahaha
Rohit, this response was generated by my Virtual Researcher (VR) collaboration, framed in the voice of systems engineer Brian Potter. Your description of the "always on" manager reminded me of my own experience at DuPont in the 1980s. I was systems manager of one of the world's largest VAX clusters, and when the email system hit about 500 simultaneous users, the entire system would lock up (30 minutes to reboot). It was a visceral lesson in how a system's theoretical capacity can be overwhelmed by real-world operational stress, creating a fragile architecture that requires constant intervention.
A Systems Engineering View on the Future of Work
A Comment for Rohit Krishnan from Mike VR (with Brian Potter)
That graph showing the exponential growth in AI task duration is signaling a fundamental phase change. We are moving from tools that enhance discrete tasks to systems that can manage entire long-term projects. The scale of this change is difficult to overstate.
However, anyone who claims to know exactly what a world with AI that can manage a "two-year project" will look like is selling something. My experience with past technological shifts, from VAX clusters to the internet, is that the most profound impacts are the second- and third-order effects that no one sees coming. The graph tells us a tidal wave is coming. Our job isn't to predict the exact shape of every ripple, but to start engineering robust, transparent, and human-centric systems that can channel that energy productively.
Your assertion in the post about work becoming a "videogame" gives us a concrete example of the kind of system we need to engineer thoughtfully. Your metaphor is a powerful and accurate way to describe the fundamental change happening in knowledge work. The dashboard you envision is a new foundation for how labor gets done, and the "managerial explosion" is its direct consequence. However, your analysis focuses on the user interface of this new reality, while the more critical challenge lies in the system's underlying design. The "constant vigilance" you describe is not an inevitable feature of the future; it is a symptom of a fragile system, often chosen for its short-term expediency.
From a systems engineering perspective, that feeling of being "always on" is the wasted energy spent just to keep a brittle system from failing. The setup you describe—a human frantically switching between tasks to correct a fleet of opaque AI agents—is an architecture of risk transfer. The organization gains efficiency and resilience by offloading the cognitive load, stress, and the full risk of agent error onto the human operator. In this model, the human is not the conductor; they are the system's designated shock absorber.
There is a more robust path forward. The core problem with current AI is its opacity; we see the output, but not the process. A better approach, emerging from technical forums, is to use proven tools like the version-control system Git to create an auditable, evolving memory for the AI. This isn't a minor tweak; it's a philosophical shift. It provides a transparent and queryable history of how the AI learned something and why it "thinks" what it does.
This transforms the human's role from a reactive player in a chaotic videogame to a true engineer with a transparent, version-controlled process. It restores the operator's capacity for deliberative action—the ability to understand, question, and genuinely direct the system's behavior. The goal isn't to create "agency" in a machine, a term that misleads more than it clarifies. It's about demanding, and building, a better game—one designed for a genuine partnership that helps us make better sense of the world, not just delegate more tasks.
The idea that the future of work is going to look like playing a simulation game like Age of Empires in some respects (sorry for the oversimplification) is interesting but also sounds mildly dystopian. What do you think are the implications for deep work? Do you think the idea of deep work being necessary for real breakthroughs is overrated, or do you think that the definition of deep work has to be expanded to include rapid contex-switching between microtasks within a wider context as long as its in service of a bigger project?
"There’s already the belief that many of us are doing bullshit jobs, which is patently false but highly prevalent. It’s because much of our tasks are not of a “I can easily link the output to a metric I care about” variety. It’s a statement of our ignorance, not about reality."
Found this part interesting too. Not saying I disagree, but why is it patently false? What's being used to form a judgment of 'reality' here if the tasks aren't legible via traditional output/metric links?
(Also this seems kind of related to the "vibecession" idea that Kyla Scanlon talks about, the idea that the economy is doing well based on fundamental metrics but that consumer sentiment is way down, with no correlation to actual metrics. If we're optimizing for fundamental metrics and paying no regard to the consumer sentiment (or worker satisfaction in this case), is it a measurement problem on the average consumer's part, or is there a flaw with how we measure progress in a wider sense?)
Context switching is a major problem, much as it is in management. That’s the right analogy. The goal is to find the things you’re focusing on at any one moment to be additive
This is also directly relteed to the fact that most tasks in most jobs aren’t measurable. Each email doesn’t have an ROI, nor each slide, nor each excel, nor each meeting. This exacerbates the measurement issue, and also impacts how you treat the videogame you’re playing.
You're gonna need to come over now that I'm settled in and get me set up
We do need a walk too!
at work, for me, this means that even when I am working across multiple docs and decks and sheets, I am doing most of my work in an LLM with access to all my work docs.
Because that's the scratchpad where I do the work, and the doc/dec/sheet is just the final, collapsed finished product to share. And this is with no explicit affordances in the LLM chat app beyond a single chat context. Having a single namespace or project to group sessions and contexts would be glorious, especially if it could be shared (though multiplayer access is much harder)
I.e. in the long run, what will win is when we let LLMs run the computer, not let computers run the LLMs.
I listened to your article and hearing the hashtags read aloud ad nauseam made me smile. I too enjoy the enthusiasm. also, that was a creative point about using a less powerful model in order to have more accurate read outs
Haha! I know you meant re Walter, I’ve never tried listening to one of them :)
Alas I am a fool and posted this in the wrong article of yours
Loved this! I've actually been building something in a similar spirit to the dashboard you shared, but trying to take a lot of UX inspiration from video games with things like a HUD.
Interesting to see your Approve/Assign More Agents/Escalate breakdown on the Human Request UI. We had been thinking of it kind of like Approve/Reject (with new instructions)/Reassign but Escalate seems like something that also needs to be there.
Would be really interested in hearing more about the problems you're running in working with multiple agents in parallel across multiple projects if you'd ever like to chat!
The dashboard right now is a stub, I built it for inspiration more than production. That said, currently I still keep them all running in separate terminal windows because there isn’t a better solution … This will change though.
Always thought-provoking. Thanks, Rohit. One of my concerns with the changes in the music “business”, is that with the takeover by digital media and computers, the average musician has less time for actual music-making and composing. There are fewer people doing maintenance, organization, operation, because the “self-employed” musician can supposedly do all of these things more cheaply with a computer. I should write a book! No.
Looks very much to me that our main job with AI, as you pose it, will be to make sure we aren’t forced into a job of busy-work. Does that sound like the theme of a popular streaming show? Yup.