GenXJamerican

Someone recently posed this question in a Slack channel at work: “why pay for vended software that we can build ourselves now that we have the tools?”  They asked this question in the context of Claude Code being made generally available for internal use.  It's a fair question on the surface. These tools can be expensive, sometimes frustrating, and the capabilities of modern LLMs are genuinely impressive. But the growing power of Gen AI doesn't fundamentally change the buy-versus-build decision — here’s why.

Vibe coding is not a production strategy.

Yes, you can prototype a Salesforce-like CRM or a Slack-like messaging tool in a weekend with the right AI assistant. But if your business is going to depend on it, you're not just building a demo. You're committing to building, deploying, and maintaining something production-grade — with all the architectural decisions, security concerns, and UI considerations that entails. GenAI may accelerate parts of that process—but it doesn't eliminate any of them.

Now do the math on the opportunity cost.

Building your own internal replacement for a third-party SaaS product isn't a one-engineer side project. It's multiple engineers, sustained over time, making real decisions about infrastructure, reliability, and scale. That means:

• Salaries and benefits for the team dedicated to this effort
• Switching costs to migrate off whatever you're currently using
• Ongoing maintenance — because software doesn't maintain itself

And critically: every hour those engineers spend building your proprietary version of Slack or ServiceNow is an hour they're not spending on the software that is actually core to your business.  What advances are your competitors making at your expense because they’ve fully dedicated their people to improving their core business functionality and bought tools that are tangential but helpful?

That's the real question to ask.

Is replacing a third-party tool — one that entire companies exist to build and support — actually a better use of your engineering talent than investing in the capabilities that differentiate your product in the market?

For most companies, in most cases, the answer is no. Gen AI is a powerful accelerant. But it doesn't change the fundamental logic of what's worth building versus what's worth buying.

A friend shared this Fast Company piece in our group Slack recently on the costs to companies of replacing entry-level workers with GenAI.  Issac, the mid-level Big Tech engineer in Megan Carnegie’s piece, is like a  lot of engineers working on my teams.  He’s seen firsthand what GenAI accelerates in his own work, as well as the downsides of its incorrect outputs and the additional time necessary to fix them.  At my level, I must balance the increased demands for software delivery, a larger people leadership workload, the risks of burnout for my most-experienced engineers, and the downstream consequences of that burnout.

Contrary to the assumption that GenAI could make up the difference for fewer junior engineers, much more work rolled up to senior engineers.  Instead of growing junior developers to the point they can do more work autonomously, they’re herding AI agents and spending an extra 4.5 hours a week just fixing their mistakes—in addition to doing their own work.  When you have a dozen or two dozen direct reports, it’s much more difficult to detect and prevent burnout.

When a burned-out senior engineer leaves, you don’t just lose their knowledge and experience.  The tacit knowledge built through what they worked on with those in their teams and across teams is lost as well.  GenAI appears to be compounding the negative effects we’ve seen of repeated mass layoffs by numerous companies—loss of institutional knowledge at scale.  The vicious cycle of burned-out senior engineers being replaced by less-experienced engineers and smaller workforces overall is already leading to less-resilient systems with more frequent outages taking longer and longer to resolve.

As a people leader, replacing entry-level workers with GenAI also eliminates opportunities for me to delegate, mentor, and teach.  The vicious cycle has the paradoxical effective of devaluing me as a person who has grown institutional knowledge over the years and consistently shared it with others to help them grow professionally.  At least one study has shown that this mentoring work increases motivation and psychological well-being.  I’ve worked with dozens of engineers over the past 8 1/2 years in peer learning, people leadership, and mentoring contexts and contributed to at least 10 people getting promoted at least one level in that time.  More than any individual system I’ve led delivery of, helping engineers grow their careers to succeed at even greater levels feels great.

These costs of trying to replace entry-level workers with AI are only going to grow as experienced workers who can afford to retire choose to do so, creating a demographic cliff Carnegie’s piece measures at 4.6M more workers retiring than there will be equivalently-qualified younger workers to replace them.  Companies that keep hollowing out their future talent pipelines are placing their continued viability at risk.  Those that use GenAI to augment  their existing workforces instead will have a more sustainable future. 

I first wrote about the lead vs manager distinction in software development in 2016. A decade later the line is blurrier than ever--and GenAI is part of why.

The original distinction was simple: if you spend half or more of your time writing code, you're a lead, regardless of what's on your business card. If significantly less, you're a manager. Organizations that keep those roles separate consistently ship better software and grow better engineers.

That's still true today. But GenAI has given companies a new reason to collapse these roles--and a new set of risks when they do.

Here's what's changed for each role:

For the Tech Lead:
GenAI raises the productivity floor for individual contributors dramatically. A skilled lead with strong AI tooling can produce what used to require a small team. Companies have noticed--and some are using this to justify asking leads to absorb management responsibilities. Don't be fooled by the productivity argument. Reviewing AI-generated code at scale, governing how your team uses these tools, and maintaining architectural integrity are already expanding the lead's cognitive load. Adding people leadership on top of that isn't a productivity gain. It's a recipe for the same burnout the hybrid role produced before GenAI existed.

For the Engineering Manager:
GenAI doesn't eliminate the core of the management role--it shifts it. The administrative overhead (status updates, reporting, some forms of performance documentation) should get easier. What doesn't go away: removing blockers, developing people, judgment calls about team direction, and now--understanding AI-assisted output well enough to hold your team accountable for it. AI-assisted--not generated--because people need to remain accountable for any and all software that ships. No blaming the AI for outcomes. Managers who stay deliberately close to how their teams are using AI will have a real edge over those who don't.

The job-search advice from a decade ago still holds: scrutinize the description, ask how the role is scoped, and look at the manager's span of control. What you find will tell you whether the company has thought clearly about these roles — or is using a familiar title to describe an unfamiliar burden.