This was the quote I found most impactful from my company’s recent engineering learning session on agentic workflows. While the rest of the learning session was generally pretty benign, this quote really stuck with me. As I mull over the ways that software engineering as a craft continues to evolve and change, I find that I keep coming back to it. After some reflection, I think this quote is interesting because it actually contains two key assertions:
- It claims that the ability to multitask and change focus quickly is now the more important skill in a post-AI software engineering world.
- It also implies that in the past, what made a good engineer great was their ability to focus deeply on a complex problem.
The Era of Deep Focus
The idea that deep focus was a vital skill of the software engineers of yesteryear was both obvious and enlightening to discover. On the one hand, any programmer who has spent hours or days slowly grinding through a particularly complex problem knows that flow state is an essential part of unpacking complexity. On the other hand, I had never thought of it as an essential skill the same way language fluency or design pattern understanding is. On some level, it seems that deep focus could be at the core of any serious field of study. The human brain can only hold so many complex thoughts at once, which makes it difficult to pick up and put down difficult problems quickly without losing essential context. If this is correct, it follows that engineers capable of deeper focus can store more details in their head at once, and thus make fewer mistakes or locate more disparate connections.
Beyond the applications of deep focus to productivity, I also began to wonder about the importance of deep focus as a requirement to learn any highly specific craft. In the modern era, I’m sure this applies to roles like Lawyer, Doctor, or Accountant, but I would imagine it applied arguably more so to the artisans of all human history. In my mind, any craft which required a highly specialized set of intellectual skills likely required deep focus as a prerequisite skill in order to achieve excellence. Within this context, the concept that deep focus is no longer required for the application of most highly intellectual fields becomes a far more impactful shift. It suggests in my mind that the way highly skilled work is done has forever changed.
The Era of Short Attention
If the era of deep focus has ended, one must assume that the essential skill for a software engineer to possess is now the ability to multitask. Indeed, I find myself increasingly flicking between different agents. Each working on solving slightly different problems, or researching slightly different questions. Where I previously had to focus intently on a single problem or approach, I now try to split my attention between multiple problems. I’ve found that in many ways, this is actually more difficult than focusing deeply on a single problem. The role of the human software engineer is much more akin to herding cats. It is much more valuable to be able to redirect an agent with only a few moments of thought, than it is to deeply describe the problem and expected direction to the agent. Along these lines, I found I had to remove as much human interaction from the agents task as possible. Diagnosing and redirecting agents when they get off course if bad enough, so leaving sharp edges or tools which might cause the agent to hang was essential. This included:
- Running each agent in a sandbox environment where changes are easy to rollback and the machine is easy to reset if needed. This also prevented them from interacting with each other.
- Removing all permission checks from the agent. This allows it to execute any command, write any file, and run any script without human oversight. I’m lucky that my company support this functionality by adding guard rails to other parts of the sandbox environment to avoid any unexpected consequences.
- Using detached services and non-interactive test systems. Where I used to run a script like
run-serviceand then connect to the service using Postman or curl, now I use scripts likestart-service,restart-service, andsend-requestto ensure the changes can be verified without human interaction.
Ironically, I think this creates an environment where the agent itself is able to perform “deep focus” in its own way. It allows the agent to make decisions, execute on them, and verify its changes without having to break focus and ask for my help. In turn, this allows me to run multiple agents in parallel which would previously have been impossible.
Is “AI User” Even a Skill?
While reflecting on this post and the way that my own thoughts on AI have evolved over the past 2 years, I find that the ways I expected to leverage AI in my work have changed repeatedly. What previously seemed like an essential part of my workflow now seems like a worn out tool that hasn’t kept pace with changes in technology. Upon reviewing my previous post, The AI 10x Developer, I found that my use of Roo code didn’t go far enough. Using a single agent session which required constant permission checks and oversight for validation limited my ability to work on multiple projects or approaches at once.
Additionally, I suggested in that post that users of tools like Roo code first asked the AI to generate a design doc, then reviewed that doc, then executed it. While that was good advice at the time, I think that approach is now largely unnecessary. Previously, I think the design doc acted like a boot strap to help the agent reach “deep focus”, but now almost all agents will do some internal planning, to do list preparation, and approach revision before executing. This effectively renders the design doc approach redundant. Never-the-less, it suggests that as AI agents continue to improve, the concept of deep focus will remain, specifically for the AI agents themselves.
In place of these “tips and tricks” for prompting, I now leverage agents operating in sandboxes with as much data as possible available to them. All of the companies code, all of the engineering wiki, all of the documentation for any external service we use. This has proven to be an effective approach because agents seem to struggle when navigating online resources and directories, but excel at managing file systems and directory trees. Just as the design doc and to do list prompting of 18 month ago seemed cutting edge, I find myself wondering how much skill there is to being an AI User at all. Certainly it takes skill to review the code and ensure the agents are making smart choices, but the ways which agents operate seems to evolve so quickly that any specific structure to prompting is only valid until the next major LLM release.
Conclusion
Work has forever changed. Regardless of how AI ends up being integrated into daily life, the 10x developer of the next decade will certainly use AI in some capacity. What continues to amaze me is the rate at which AI trends and tools seem to rotate. OpenAI was once thought the AI juggernaut that had revolutionized our world. In fact, many of my friends refer to all LLMs as “ChatGPT” the same way you might call a tissue a Kleenex or a copier a Xerox machine. In spite of this, if you ask almost any developer today what AI tool they use most often, the majority of them will say they use Claude Code. I have no doubt that in another 18 months there will be new tools which are preferred above all others, and in turn, these tools will have different “tips and tricks”.
Looking forward, it seems the only thing we can count on as developers is our ability to adapt to new environments quickly. For younger developers who have grown up in the era of 15 line JavaScript packages and Blockchain Web3 based application, I imagine this is a skill which comes quite naturally. Never the less, it seems this is an essential mindset for developers hoping to stay relevant in the coming years. Just because you had a workflow which was effective a year ago doesn’t mean you need to stand by it. The landscape is forever evolving, and regardless of how it shifts, toward deep focus or away, into agentic teams or deeply capable long running individual instances, developers must continue to adapt.