Will Claude Code ruin our team?

Published: (March 7, 2026 at 09:59 PM EST)
4 min read

Source: Hacker News

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” (video):

  • 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 will 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 (link):
“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 racing toward the same layer of leverage.

In Ben Werdmuller’s piece “AI coding works now”, he advises engineers to focus on four high‑leverage skills:

  1. Crafting goals for the product
  2. Understanding what users actually want
  3. Being crystal clear about the experience and value you’re creating
  4. Designing, building, and maintaining robust software architecture

The challenge to Ben’s advice is that many 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.
  • Marketing and sales want to define how value is expressed to the customer.
  • Engineers own planning and implementing architecture—performance, scalability, security—all of which require 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 previously took colleagues decades to learn. 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 may be jockeying for position and increased animosity between team members.

What I’m hearing from software teams

I asked friends who run software teams what they’re seeing.

  • Founder: “I think you’re correct here. We’re already seeing it — mainly around PMs wanting to write code.”
  • Another founder: “We are feeling it on our team for sure. Everyone kinda feels like they can do everyone else’s job.”
  • President of an established software company: “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.”
  • Hiring impact: “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: “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 emerge with more collaboration. Instead of competing for leverage, individual contributors could find new ways to work together.

Example: Product managers and engineers could do AI‑driven pair programming. The PM focuses on customer behavior and product goals; the engineer evaluates architecture, security, and maintainability. They iterate together in real time, using LLMs.

Matt Stauffer, CEO of Tighten, describes doing exactly that:

“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 remains relevant: “All code must have a human owner who will take responsibility for it.” In this scenario, the PM and the engineer would co‑own the pull request.

37signals is famous for two‑person teams (one designer, one engineer). In an AI world, perhaps that paradigm becomes the norm.

Once the turbulence has died down, teams will need a new vision for how to work together—using AI and collaboration to build better software.

Cheers,
Justin Jackson

0 views
Back to Blog

Related posts

Read more »

RISC-V Is Sloooow

Triaging I went through the Fedora RISC‑V trackerhttps://abologna.gitlab.io/fedora-riscv-tracker/ entries, triaged most of them currently 17 entries remain in...