Engineering Leadership In the AI Era: 4 Rethinks To Avoid AI Slop

Why Engineering Leadership Has to Rethink Right Now

I had Christian Heilmann on Stacked Sessions recently, and I'm still thinking about it.

Chris has been around the industry long enough to have watched every hype cycle since the first browser wars. He curates DevDigest, WeAreDevelopers' Friday newsletter that hits 200,000 subscribers, and moderates the WeAreDevelopers Congress. He curates, he teaches, he writes. And he's watching the AI moment with the kind of clear-eyed perspective most of us can't get from inside our own org charts.

Companies, he told me, are going to choke on their own AI-generated creativity if they don't figure this out fast.

Choke. That's the word he used. Not "struggle" or "face challenges." Choke.

So I've been pulling on that thread. Here are four things I think engineering leaders need to rethink right now, pulled straight from the conversation.

Rethink #1: Deletion Is a First-Class Engineering Skill, Not Cleanup Work

Every engineering leader I talk to is thinking about what to build with AI. Almost none of them are thinking about what to delete.

Chris reframed it for me: the helper libraries we shipped five years ago to support old browsers and old environments are now security attack vectors and indexing tax. When an AI agent scrapes your site, it doesn't skip the bloat. It indexes all of it, and your token bill reflects it.

His line, verbatim: "Deleting is now a bigger skill than creating."

If you're a VP of Product or Engineering, you should reread your roadmap. How much of your product is load-bearing versus legacy weight nobody wants to touch? Christian said it bluntly on the show: "That's always been a lie. You never get the time to delete it." Every sprint I've seen in twenty years promised future time to clean up code. That time rarely came. He's right.

Now there's a sensible business reason to finally prioritize it. AI agents cost real money to serve. Bloat is becoming a bigger line item on your AI bill.

MY ADVICE: Make deletion a sprint goal. Reward it the same way you reward shipping.

Rethink #2: Engineering Leadership Should Hire for Editing, Not Just Coding

Chris made the career-arc argument better than I've heard it. Junior developers write a lot of code. Senior developers write less, but review more. Architects and leads write even less, and spend most of their time reviewing, teaching, and explaining why something is a performance issue or a security issue.

AI just collapsed that timeline. The junior work on your team is now getting done by agents. Which means the thing that used to be earned at mid-career, the review-and-edit muscle, is now the entry-level requirement.

The best code any of us has ever written is the code we didn't write, because we thought about it first.

If you're hiring right now, test for spec-writing, review judgment, and the willingness to tell an agent (or a teammate) "no, that's not how we do this here." Those are the competencies that separate a team that ships good software from a team drowning in its own PR queue.

MY ADVICE: if you're managing an existing team, give them time to review. "Move fast, review later" has always been a lie. Now it's an expensive lie.

Rethink #3: Measure AI ROI by Backlog Velocity, Not Lines of Code

Your board is asking what your AI tooling is returning. Your CFO is looking at the Cursor and Copilot invoices. Everyone wants an ROI number.

Here's where most leaders get it wrong. They reach for lines of code, PR count, or "percent of developers using AI." Those numbers go up whether or not anything valuable happened.

Chris gave me a cleaner frame. Look at your backlog. You've been staring at it for years. Features you wanted to ship. Bugs you knew about. Tech debt you kept postponing. Is that backlog shrinking faster than it used to? Is the delivery cadence on your main product picking up?

The real ROI of AI tooling is backlog velocity and release cadence on your main product, not the volume of code being generated around it.

If your developers are using AI to spin up side projects and prototype ideas, great, that's learning. But the main product is still the revenue engine. If AI isn't moving that needle, you don't have an ROI problem with the tool. You have a focus problem with how it's being deployed.

MY ADVICE: Focus your teams on the projects that will impact revenue. Give them the safety net to take the risks where it matters.

Rethink #4: Install Guardrails Against AI Slop Before It Floods Your Pipeline

AI slop is Chris's term (by way of Simon Willison) for the flood of low-quality, AI-generated contributions clogging code repositories, open source projects, and security bug bounties. He told me about 50,000-line PRs that nobody has time to review. Typo-squatted NPM modules created from hallucinated dependencies. Security bug reports that reference vulnerabilities from Windows 95.

AI slop is already in your pipeline, whether you've acknowledged it or not. Three concrete guardrails worth putting in place this week:

1. Cap PR size. GitHub now supports stacked PRs, so oversized contributions can be split without outright rejection. Set a max line count. Enforce it.
2. Require a non-AI-generated unit test for every AI-generated feature. Christian put it bluntly: "That's like saying, 'We want to see if you learned English, so you write your own test.' It's a self-fulfilling prophecy." Use a different agent, a different model, or a human for tests.
3. Cap dependencies. Three levels deep, five dependencies per module, whatever makes sense for your stack. But cap them. AI will pull in the kitchen sink if you let it, and half of those dependencies don't exist yet.

These aren't anti-AI policies. They're the same hygiene practices that separated serious engineering orgs from hobby projects for the last twenty years. AI just made them mandatory.

MY ADVICE: Don't be so enamored with the throughput speeds that you accept poor quality. Apply the same policies as any other prior technology transformation to ensure quality and outcomes.

What Engineering Leadership Should Do Monday Morning

If I'm sitting in a VP of Engineering or CTO chair this week, I'm doing four things:

1. Adding "code deleted" to my sprint reporting alongside "code shipped."
2. Updating my hiring rubric to test review and spec-writing skill, not just coding speed.
3. Giving my finance partner backlog velocity and release cadence, not seat utilization, as the AI ROI proxy.
4. Writing the short PR and dependency policy that keeps slop from flooding my team.

Chris put it best near the end of our conversation. The companies that thrive in this moment won't be the ones generating the most code. They'll be the ones who figure out what not to generate in the first place.

Give the full episode a listen. He has a lot more where that came from.