Some developers are really changing how they work with AI. They're moving towards orchestrating agents, handing over whole tasks and figuring out how to manage the work that comes back. Others still see it mostly as very good autocomplete.
I used to explain that difference through two developer stereotypes: the hacker and the engineer. I think I was probably wrong, or at least applying that explanation well beyond the initial learning phase where it might hold up.
The hacker likes to experiment, break things, and see what can be built. The engineer is more methodical, interested in working through what's needed to make a system robust and scalable. Most developers can do a bit of both, but tend to lean towards one side or the other. It's a rough distinction, obviously.
My reasoning was that the hacker type would adapt more quickly to orchestrating agents. If you're used to trying something before you fully understand how it should work, a new way of building software probably feels quite inviting. That might well help you take the first step. I just don't think (anymore) it tells us much about how well someone will work with agents once they've picked up the skill.
I've always been quite comfortable ignoring my usual approach for a bit and just trying something, although it wasn't very conscious. If it works, I try something bigger. If it doesn't, I adjust and have another go. That helped me get started with agents. It also makes it easy for me to underestimate what that first step asks of someone else.
Getting started means temporarily setting aside a way of working you're comfortable with. That can be quite a lot to ask of someone who's spent years getting good at their job. You know how to approach a problem, what good work looks like, and where things tend to go wrong. Now you're trying a workflow where you don't yet know how to put all that knowledge to use. I can see how that challenges your idea of what it means to be good at this.
Orchestrating agents is a skill. At first, you're spending a lot of attention figuring out what to hand over, how to give useful direction, and what to check. As that becomes familiar, you can bring more of your attention back to the work itself. That's where all your existing experience becomes useful again. You can see where the agent has made a poor architectural choice, or where a passing test hasn't actually checked the thing that matters.
Once you're there, I don't think leaning towards hacker or engineer matters much to whether you can work this way. You bring your strengths into it. The experimental developer can explore more ideas. The methodical developer can use the same tools to build something robust and scalable. Getting comfortable with agents gives both a new way to do the work they're good at.
I think this matters for how companies support and train people. The few people already championing these tools may have found their way in by happily messing around until something worked. It's easy to turn that into advice: just try it, that's how I learned. But that advice leaves out the support they didn't need themselves. Someone else might benefit from working through a task with a colleague before they're comfortable trying the next one alone.
So the training needs to help people through that initial discomfort. Give them a familiar problem they can try solving in a different way, with enough support and time to get past the first awkward attempt. Help them see where their existing judgment fits into the new workflow.
And let's be honest, we will f*ing need both hackers and engineers in this era of AI coding. I'd like us to get better at helping both take that first step, so we can actually use all the experience they bring.
