Will Claude Code ruin our team?
The first time I sat down and used Claude Code's Opus 4.5 to build software, I couldn't believe how good it was.
My next thought was: this is going to change the dynamics inside software teams.
The standoff between roles
Marc Andreessen recently described the moment as a “Mexican standoff:”
Every engineer now thinks they can be a PM and a designer.
Every PM thinks they can code and design.
Every designer thinks they can do the other two.
The risk is that many individual contributors believe they no longer need the others.
In the short term, this is going to be incredibly disruptive for team culture.
When rare skills become more attainable, people feel pressure to move "up the stack" to prove their value.
Kent Beck expressed this sentiment on X:
"The value of 90% of my skills just dropped to $0. The leverage of my remaining 10% went up a thousand."
My worry is that everyone is recalibrating toward the same 10%. Individual contributors are all racing toward the same layer of leverage.
In Ben Werdmuller's piece, "AI coding works now," he gives advice specifically to engineers. He comments, "AI coding shifts the center of gravity from implementation to judgment," and recommends that engineers focus on these four skills:
Crafting goals for the product
Understanding what users actually want
Being crystal clear about the experience and value you're creating
Designing, building, and maintaining robust software architecture
The challenge to Ben's advice is that lots of people believe they own these skills.
Company Leadership wants to own goals and strategy.
Product Managers see themselves as uniquely qualified to understand what users want.
Designers want control over crafting the user experience.
And Marketing and Sales want to define how value is expressed to the customer.
Engineers own planning and implementing architecture. Performance, scalability, security; it all requires real expertise.
With AI, all of these roles become more fluid. As more people build software and cycle time compresses, they'll start to absorb lessons that it took their colleagues decades to learn.
And ultimately, more individuals will want to own the highest-leverage identity: “In my role, I solve problems and provide value to users.”
Left unchecked, there will be jockeying for position. There might be more animosity (and jealousy) between team members.
What I'm hearing from software teams
I started asking my friends who run software teams what they're seeing.
One founder told me:
I think you're correct here. We're already seeing it — mainly around PMs wanting to write code.
Another said:
We are feeling it on our team for sure. Everyone kinda feels like they can do everyone else's job.
The President of an established software company described a similar shift:
“Our team is a Head of Product and 15 engineers. On smaller projects he's shipping a lot of PRs himself with no developer in the loop.”
But the biggest change wasn't just in who is doing the work. It was in who they’re hiring:
“Where you really see the impact on jobs with us is in the people we're no longer hiring: specialists. In this new era, generalists win.”
John O'Nolan, founder of Ghost, commented:
It’s a turbulent time, for sure — but overall I’m pretty optimistic.
The thing that hasn’t happened yet that I expect will happen in future is that, in addition to old roles being compressed, new roles emerge.
After the standoff
My hope (once the dust settles) is that we come out the other side with more collaboration. Instead of competing for leverage, I'm hoping individual contributors find new ways to work together.
For example, what if Product Managers and Engineers did more AI-driven pair programming? The PM could focus on customer behavior and product goals. The engineer could evaluate architecture, security, and maintainability. They would iterate together in real time, using LLMs.
My friend Matt Stauffer, CEO of Tighten, commented that they're doing this right now:
I demo work to my Biz Dev Manager (the product owner for this internal project), she asks for changes, and then we prompt the LLM live, together. I'm better at prompting and reviewing, she knows the domain better than me. This kind of pair programming is great, because I'm moving quickly and then she can jump off the call later when I'm reviewing, iterating, etc.
Ben Werdmuller's prescription would still be relevant: "All code must have a human owner who will take responsibility for it." In my scenario, the PM and the engineer would co-own the pull request.
37signals is famous for having two-person teams (one designer, one engineer). In an AI world, maybe a paradigm like that becomes the norm?
Once the turbulence has died down, folks will need a new vision for how to work together. How can we use AI and collaborate in ways that help us build better software?
Cheers,
Justin Jackson
Discuss this on Hacker News
Connect with me on:
🦋 Bluesky
💼 LinkedIn
🐘 Mastodon
🧵 Threads