"I'm going to hire an assistant to work with you."
Imagine saying this to every developer on your team. This is the most honest way to describe the reality of AI augmentation in a modern engineering environment, and it's precisely why there are such varying levels of success and acceptance of it. The friction isn't just about the technology; it's about a fundamental shift in the nature of the work.
The Conflict with the "Craftsperson" Persona
There are many different personas of developers today, but a common and highly valuable one is the "craftsperson" or "heads-down" engineer. This is the individual who thrives on deep, focused work, preferring to dig into complex problems and own the execution from start to finish. They derive satisfaction and deep learning from the act of building.
To present this developer with the idea of an AI "assistant" can be a tough adaptation. Their workflow isn't naturally geared for this type of "co-working" or "delegation" style of engagement. They may not be accustomed to establishing high-level requirements and coordinating disparate pieces in order to accelerate through the distribution of tasks. They may prefer to do it all themselves, whether for a sense of control, a commitment to quality, or for the simple joy of learning through execution.
These are excellent attributes. But the path for a purely execution-focused role is rapidly evolving.
An Old Challenge, A New Scale
The skills required to effectively use an AI assistant—delegation, clear communication, task decomposition, and review—have historically been the domain of senior engineers and team leads. The struggle to balance hands-on technical work with these higher-level responsibilities has always been part of the journey to more senior engineering positions.
What's changed is that AI is now pushing these "senior" skills down the organizational chart. We are now facing an evolution where most "individual contributors" will need to perform more like senior engineers. It may not be a human assistant they are managing, but the mechanisms and interpersonal skills required to handle these interactions are very closely related.
The new baseline for an effective IC is shifting from "Can you build this?" to "Can you direct your assistant to build this, and then verify the quality?"
The Evolving Individual Contributor
This evolution has profound implications for how we build and manage engineering teams.
- Skill Development: We need to train engineers not just in coding, but in prompt engineering, task decomposition, and critical review of AI-generated output.
- Career Paths: The distinction between an IC and a lead becomes more about the scope of their influence and the complexity of the problems they direct, rather than a simple "codes vs. manages" binary.
- Hiring: We may need to start screening for these delegation and systems-thinking skills even in more junior roles.
The "assistant" is here to stay. The most successful teams will be those who recognize this shift and proactively equip their engineers with the skills to be not just great builders, but great directors of work.