Craig McLuckie on AI Slop, Giant PRs, and Why Culture Is Your Team's Real Operating System

Craig McLuckie has a useful way of describing what holds engineering teams together: culture is the operating system of a team. It defines how the team processes information, and like any OS it has to be designed, patched, and occasionally rewritten. In a recent InfoQ Engineering Culture podcast with Shane Hastie, the co-creator of Kubernetes and current CEO of Stacklok connected that idea to a problem every team is now living through: what generative AI coding tools are doing to the way we build software, and to the people who build it.

What's new: AI slop is breaking the onboarding path

The most concrete change McLuckie describes is happening in open source, and it is not subtle. Maintainers have spent years using a deliberate onboarding pattern: triage the backlog, leave some of the low-hanging fruit unfixed on purpose, tag those issues as good first issue, and let early-career developers cut their teeth on them. That ritual was how communities recruited and mentored new contributors.

That pathway is now drowning. "Every time we do that, within a day there'll be dozens of submissions of these slop AI generated PRs that ostensibly fix the issue, but not in a way that's consistent with the community's work," McLuckie said. The maintainer's job, already heavy on review, becomes reviewing a flood of agent-generated code that has to be hardened before it is usable. Some of it comes from people running an agent for themselves; a lot comes from contributors who never bothered to tune their prompts or make the output match the project's conventions.

The second-order effect is the one worth sitting with. The good-first-issue is no longer a teaching tool, because an agent will claim it before a human does. The structure that turned newcomers into contributors is being eroded by the same automation that is supposed to make everyone more productive.

McLuckie also raises a deeper question about ecosystem structure. Package ecosystems like npm were built around composing relatively static, reusable units. When good code becomes cheap to generate, the value of that composability comes into question. Code starts to look less like the durable artifact and more like an intermediate language, with the real intellectual property moving up into requirements, specification, and prompt design.

Why it matters: more code is not more delivery

Inside companies, the same dynamic shows up as a productivity illusion. Hastie cited a figure that has been circulating: roughly 300% more code produced, 400% more bugs. McLuckie did not flinch. "The only thing that we're seeing growing faster than AI code agent adoption is AI code agent introduced exploits in production environments," he said.

His sharper point is about what the volume actually buys you. "Unfettered deployment of these tools doesn't necessarily drive productivity, it certainly drives the amount of code that's being submitted as PRs. But when I actually start looking at the rate at which features are being burned down," the gains evaporate without matching investment in process maturity. Lines of code and shipped features are not the same metric, and treating them as interchangeable is an old mistake wearing new clothes. McLuckie reached for the Bill Gates line: measuring programming progress by lines of code is like measuring aircraft progress by weight.

There is a human cost layered on top. Every engineer is being pushed into a manager's role over their own work. The agent behaves "like an intern that's incredibly enthusiastic, but not necessarily very wise." The most productive move is often to direct and review rather than to write, which means engineers spend their days scrutinizing output instead of building with their own hands. McLuckie names the result plainly: emotional fatigue. The part of the job that produced engineering joy is being replaced by constant micromanagement of a machine.

The return of the giant pull request

One symptom captures the whole shift. After two or three decades of teaching teams to make pull requests smaller, we suddenly have 3,000 and 4,000 line PRs again.

McLuckie's theory is that the unit engineers actually optimize for was never line count. It was time. People internalize a rhythm of "some number of hours to days to get something to a point," and the tools now fill that same time budget with far more output. Add urgency to that, and the picture gets worse. He has watched organizations treat code generation volume as something close to a performance metric, creating a counterintuitive incentive to demonstrate fluency by producing more. A 4,000 line PR lands on a teammate's desk, and the burden of micromanaging the agent that wrote it gets transferred to whoever has to review it.

How to respond: design the culture on purpose

McLuckie's answer is not a linter rule or a policy doc. It is deliberate culture, treated as infrastructure.

He is dismissive of culture-as-poster, the five values plastered on a hallway wall. Real culture is the common core a diverse team can always revert to, tuned for the work at hand. A security team needs precision, paranoia, and care. A startup needs urgency and bias to action. There is no one-size-fits-all template, though he openly admires Amazon's culture as a self-replicating system that scales across domains, even while saying it is not one he would personally want to work inside.

The method he uses is concrete and repeatable:

• Distill the anchors. When inheriting a team, interview people and pull out the handful of ideals, four or five, that are both genuinely important to them and objectively important to the mission. Those become the deliberate culture anchors.
• Talk about it constantly. Wire the anchors into how you interview, because the culture describes who is a good and creative addition to the team. Wire them into the promotion ladder, so SWE1 through staff levels tie back to the culture rather than to raw output.
• Play decisions back through it. When a hard call is not obvious, relate it explicitly to the cultural anchors. That repetition is how the culture stays alive.
• Reassess, and never be a hypocrite. "Hypocrisy is the culture killer. If your team sees you behaving in a way that is incompatible with the culture, your culture is dead."

That last point has a release-management quality to it. When a business imperative forces a change, say you held openness as a core value but now need to protect something proprietary, you do not just quietly act against the stated culture. You go back to the team, explain that the imperative changed, and update the culture deliberately. "Culture will have bugs," McLuckie said. "It has to be this weird intersection of intelligent design and evolutionary pressures, and you'll never get it right just out of the gate."

He frames the maintenance burden through the distinction between implicit culture (what the team actually does) and explicit culture (what you say it is). You cannot make every decision traceable to a stated value. What you can do is guarantee they never contradict each other: nothing done implicitly should violate the explicit culture. That compatibility check is the job.

McLuckie sees this as the CEO's core work, borrowed from a line that stuck with him: set the culture, set the strategy, and find leaders who can execute the strategy within the culture. Of those three, culture is the most important and the least understood, because it only works top-down. The gap between a mediocre company and a great one, in his telling, is the strength of the culture.

The harder problem: where do careers come from now?

The part that costs McLuckie sleep is the career ladder. The classic engineering arc is not linear by accident. You write code, and in writing it you come to understand the systems. Understanding the systems teaches you the processes, then how teams work, then how organizations fit together. You learn why APIs become necessary, and that making them work in practice requires both the contract and the relationship behind it. That is the path from student to distinguished engineer, built through incremental ownership.

AI is displacing exactly the early-career tasks that path was made of: the unit tests, the bug fixes, the small work that occupied junior engineers before they graduated to distributed systems design and reasoning about scale. McLuckie does not pretend to have the answer. "I don't know how you go from where people are starting right now to being experts in at-scale distributed systems design along this alternative career arc." Today's newcomers have an unprecedented corpus of knowledge on tap and a fresh set of skills to use it well, but the bridge from there to deep systems expertise is not yet built, and the education system may not support it.

Advice for new team leads

For an early-career lead handed a team and a stack of tools (Copilot, Cursor, Claude Code, and the rest), McLuckie offers a balancing act rather than a checklist.

The first trap is the one strong engineers already know: thinking you could just do the work yourself. AI makes that temptation worse, because you genuinely can spin up four agents, generate something close to done, and harden it alone. "What am I doing with these people? I don't know, they're probably doing something. That's a failure mode." Your job is to drive other people's productivity, not to treat the AI teammate as a priority over your human teammates just because it is more responsive.

At the same time, you cannot mentor a team through tools you do not understand. The lead has to be an AI maximalist in their own practice, fluent enough to teach, while holding firmly to the identity that the work product comes from the team.

The second piece is ownership. The cultural rule has to be that responsibilities did not change just because the tools did. "It's not okay to produce something, and then push it up the chain to me to turn your AI coded slop into quality code. Everyone has to own everything they do." That ownership is what prevents the fatigue spiral of reviewing your own agent's output, then your teammate's agent's output, then hardening work nobody took responsibility for.

The third piece is letting go. The unit economics of work have changed, and clinging to old operating assumptions about cadence and scope leaves value on the table. Once you cross the threshold of using these tools well, with appropriate guardrails, you have to keep asking whether the team can do meaningfully more.

Building agents: lawn mowers, not autopilots

The biggest assumption to drop concerns building agentic systems themselves. The imperative, deterministic mental model most engineers carry does not transfer. "You're dealing with stochastic systems, and you have to spend enough time with them, you have to learn what works, what doesn't, before you can start to actually generate value." There is no clean three-boxes-and-a-database design that you make functionally complete and then scale. You learn it hands-on, through experimentation, or not at all.

McLuckie's closing image is the one to keep. "I always think of agents as more like lawn mowers than anything else. You have to constantly push them to do work, and over time they may be converted to a ride-on lawnmower if you build up enough expertise and competence in your space." Not an autopilot you switch on and trust. A tool you push, supervise, and slowly earn more leverage from. That framing applies just as well to the broader moment: the productivity is real, but only for teams that keep their hands on the handle and their culture in good repair.

You can find Craig McLuckie on LinkedIn, and the full conversation is available on the InfoQ podcast page.