People
We need to address cognitive load
One of the most important insights to emerge from discussions counters assumptions some may have about the use of AI: the fact it’s increasing cognitive load rather than reducing it.
This is partly a question about developer experience. While we’ve typically regarded developer experience and productivity as directly correlated, many of the current AI coding assistants are forcing us to rethink that assumption. Developers using AI tools are finding that while they’re capable of producing a lot more, faster, they’re becoming fatigued and even burned out with these new workflows and modes of interaction.
This requires serious attention. As Margaret Storey, Professor of Computer Science at the University of Victoria in Canada, wrote recently, developers “need to recognize that velocity without understanding is not sustainable” and so “should establish cognitive debt mitigation strategies.” This might include things like regular human checkpoints and proven methods of sharing knowledge.
At a fundamental level, we need to both evolve our understanding of what engineering work actually entails and rethink how we measure value. Developers could never consistently code for eight solid hours a day without getting exhausted: even if AI takes over code generation, the move to working on a handful of concurrent problems with AI and the necessary context that requires isn't sustainable or conducive to good work. It’s not really about just writing code; frequent design and architecture work can lead to significant decision fatigue.
I’ve certainly experienced this as a leader; as things move faster, decision fatigue becomes a greater issue. I find I no longer have the time to do that all-important noodling on a problem that can’t be replaced by AI, unless I intentionally make that time. Will the same be true for our software engineers in future?
The staff engineer role is changing
The consequences are that the staff engineer role will change in the next year. At the retreat we talked about greater focus on the ‘middle loop’ of supervisory work. This is situated somewhere between writing code and release management, with its objectives being agent orchestration and governance.
This will no doubt be interesting work. However, for software professionals that enjoy working closely with code, the shift could be challenging. This is partly because of the inevitable cognitive load and decision fatigue, but it’s also simply because many developers really like writing code. How we support our colleagues through that transition and how their skills may be redeployed is an open question we will need to attend to this year.
It’s not just the staff engineer role that the group believes will change. It’s likely that the way we define the relationship between product management and software engineering will need to be renegotiated. How exactly this plays out remains to be seen.
The response to these issues of organizational design will likely lie in how we decide to construct our workflows in the future: where do we need the human in the loop? What decisions require human oversight? Where do agents or swarms of agents excel?