# AI Disruption: Engineering Culture, Open Source, and Career Path Shifts

**Podcast:** Engineering Culture by InfoQ
**Published:** 2026-06-12

## Transcript

The decisions you're making right now about AI adoption, architecture trade-offs, and how your team works together will shape your systems for years.
Getting those calls right when the landscape is shifting this fast is hard.
QCon San Francisco has spent 20 years connecting senior engineers with practitioners who are a few steps ahead on the same problems.
This November 16 through 20, 60 plus speakers across 12 tracks will share what's actually working in production and what isn't.
No hidden product pictures, just senior practitioners helping senior practitioners.
Learn more at kukonsf.com.
Good day, folks.
This is Shane Hastie for the IncoQ Engineering Culture Podcast.
Today, I'm sitting down with Craig McLuckie.
My normal starting point with these conversations is, who's Craig?
All right.
So my name is Craig McLuckie.
I'm the founder and CEO of a startup called Stacklog.
By way of background, I've spent most of my life in enterprise technology.
I think I had most of the kind of early career impact when I moved to Google, where I got to work on what eventually became Google Compute Engine.
Myself and Joe Bader were the product leads that brought that infrastructure service capability that Google brought to the market.
And then we came up with this crazy idea, along with another engineer called Brendan Burns, to build what became Kubernetes.
You know, everyone was trying to fit the puzzle pieces together with Linux application containers, and we thought we had the puzzle box.
And so we created that open source project, which has obviously been quite successful subsequently.
And I was also privileged enough to be able to participate in the bootstrapping and early leadership of the Cloud Native Computing Foundation as a way to bring together a community, not only in support of Kubernetes, but to create innovation more broadly in the space.
I started my first startup shortly after I left Google, which I ended up selling to VMware, where I was responsible for the Tanzu portfolio, which is VMware's cloud-native applications, and spent some time there and really enjoyed my time at VMware.
And then I decided to do the crazy thing and have another attempt at building a startup, which is what I'm currently working on with Stacklock.
What's different, special about open-source communities?
The thing that's wonderful about open source is that an open source community is a way for people to come together and work on a technology that they care about, not for money, but for love.
It's a way that I think engineers in their souls like to create things.
And there's this wonderful characteristic that I think a lot of engineers share, which is they want to create something useful and they like to see it being used by the people.
And open source communities are the most pure expression of that capability.
A lot of people look at open source.
There's obviously business reasons to do open source.
It's a wonderful way to create technology that is vendor agnostic.
There's a lot of other attributes to open source.
But I think the thing that I like the most about open source is that it really is a way for people to bring their creativity, their sort of engineering staples to work on something that they love and care about that's going to see tremendous use in a broad sense.
And it is the purest expression of that kind of engineering joy as far as I'm concerned.
What's changing in the open source communities today with the advent of Generative AI?
It's tough out there, I'll be completely honest.
And I think what's happening in the open source community is a sort of echo of what we're seeing inside mainstream organizations.
But it's been extremely challenging recently.
When you think about open source community dynamics, it's effectively the collaboration of a community of the willing, a set of people that show up.
do work, work together, build relationship, have a connection, contribute.
And it's a great environment in which young engineers that want to work on more interesting or complex things than they're necessarily being assigned to at work can really let those creative juices out.
And they can get access to very rich and sophisticated mentorship that exists outside of the existing organizational structures.
And I think that's been one of the most wonderful.
aspects of open source is that it's not just a side project.
It's a way to access different people, different skills, different capabilities to work on problems that you think are enriching for you as an engineer and to actually progress your own journey as an engineer.
And one of the things that we're seeing that's become incredibly problematic for open source communities is the introduction of coding AI.
An example of something that, I think this is a pretty common pattern, but we would historically really look to welcome in additional engineers.
And so we'd go through and carefully with thought, triage the set of issues that the community is dealing with.
We would deliberately not go and fix a lot of the low-hanging fruit.
We'd mark those as good first issues and we'd leave them out there to tantalize early career developers or other people that might want to participate.
You know, the set of things that would allow them to learn the project, cut their teeth on what's being developed.
And unfortunately, we are now just overwhelmed.
You know, 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.
And so it's created this tension where the maintainers of the project accept that a big part of being part of the community is reviewing other people's code.
Now what they're finding is that they're just reviewing AI-generated slop code that they're trying to harden.
And it could be...
code that they've set up an agent to build for themselves, or it could be code that someone else has set up and hasn't necessarily gone through the process of optimizing their own prompts and building skills and at least attempting to make the code consistent with the project.
And that tension is significant.
It's definitely putting a lot of pressure on open source dynamics.
And I think there's another tension here, which is pretty obvious, which is, you know, a lot of the open source communities that we're used to are built around, you know, relatively static structured systems.
The NPM ecosystem is something that a lot of developers use.
And it is certainly, people also like to ask questions like, how relevant is this composable system when code is becoming increasingly cheap and even good code is becoming increasingly cheap to generate?
All those existing structures kind of hold in this new world where perhaps code becomes something like an intermediate language and most of the IP creation happens in that sort of requirements gathering and defining and prompt generation sphere.
So it's a very new world out there and people are definitely struggling to adjust to the new realities of how these tools are changing the way they work.
That's on the open source space.
Coming closer and within organizations, this is the Engineering Culture podcast.
What is the adoption of generative AI?
What's the impact that having on organization culture?
You know, it's all over the map.
And I think a lot of it depends on the organization's maturity, right?
Like, you could think of organizations as having kind of maturity across a lot of different dimensions.
You know, there's the operational maturity of the organization, you know, how much structure and rigor does the organization have?
How well do they define and manage their internal practices and processes?
And so that's one maturity dimension.
There's a cultural maturity dimension that organizations have, you know, around.
Is the organization set up for success in terms of being able to engage and support people with a lot of different profiles, you know, like, you know, embrace an authenticity, like an authentically diverse set of people and create an environment which can do their best work.
And what we're starting to see is this new dimension, which is the sort of AI maturity dimension.
And what I've seen as a starting point, and I would love to hear if this is something you're seeing as well as you talk to folks like myself, but.
There's this huge challenge that's emerging where these AI tools become a part of the developer's day-to-day lifecycle.
They're fantastically productive.
They behave effectively like an intern that's incredibly enthusiastic, but not necessarily very wise.
And you can set them on any task and they'll produce something and that something may or may not be good.
And so I think every individual engineer is having to start to self-identify almost as a manager, right?
Like they love writing code.
But they realize that, you know, in some ways, the most productive way for them to work is not to necessarily write the code themselves.
It's to review the product that someone else has and provide constant direction.
So they basically find themselves as effective as being a micromanager.
And that's creating a certain fatigue, you know, just an emotional fatigue on engineers.
Like you want to create, you're trying to kind of scratch this itch to generate something that's wonderful.
The thing that you got used to historically is actually doing that with your own hands and actually being in there and understanding it and the joy of that.
And now you're finding your day-to-day work being more about scrutinizing these systems.
That's what you're doing for yourself.
The problem is, you know, in immature organizations where you don't have enough structure in terms of the operational maturity, particularly as it relates to AI, I see a lot of situations where there's not a lot of wisdom being demonstrated.
So an engineer will...
Vibe code up something, which is a 3,000, 4,000 line PR, submit it to someone else and effectively put the onus on someone else in their team to do the work of actually micromanaging that agent.
And it creates a tremendous amount of tension as a starting point.
Unfacted 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, Unless you create a lot more structure and you up your maturity in terms of the process, if you can't reinforce your kind of core cultural anchors and start to drive awareness of how to use these tools, it can cause trouble for teams.
It can create a lot of friction and discontent in the early stages of adoption.
One of the numbers that I've seen was 300% more code being produced, 400% more bugs.
Yeah, something like that.
I always joke that the only thing that we're seeing growing faster than AI.
Code agent adoption is AI code agent introduced exploits in production environments.
It is definitely a little wild out there.
You mentioned the 3,000 line call request.
We've been working for the last 20 years, 30, 40 years to make our call requests smaller and smaller and smaller.
And suddenly we got this explosion.
I've thought about this a fair bit.
Certainly a lot of the engineers that I've interacted with where it's like, why are you suddenly producing the 3,000 line pull request?
We like to think that the thing that people have been trained around is the kind of granularity of the implementation, right?
Like the atomicity of a piece of work.
But I actually think what people tend to think about more is the amount of time they spend on something, right?
So like there's almost this sort of subroutine that runs in people's mind around like, okay, I've got used to working in a quanta of some number of hours to days to get to a point where something is at a point.
And now, you know, I have these tools that can just produce a lot more.
So I think that's part of it.
I think another part of it is just there's a lot of urgency that I'm seeing being introduced, particularly, you know, and this may not be true in all organizations, but there's a lot of urgency to demonstrate fluency in the use of these tools.
There's a lot of almost counterintuitive incentive structures where people are being like, hey, you know, I've seen organizations embrace heuristics around code generation as being almost a performance metric.
It gets back to the Bill Gates quote around measuring productivity by lines of code is like measuring the value of an aircraft by its weight.
These things are not equivalent.
And so I don't know the full answer, but I have to suspect that it's an interesting intersection of features, but also possibly an indicator that there's other maturity dimensions that the team needs to improve upon.
How do we design a deliberate culture in today's environment?
And what does a deliberate culture look like?
Yeah, I mean, it's something I obsess about, right?
I tend to think of culture as the operating system of a team.
And a lot of people are kind of dismissive of this nominal idea of culture.
It's the thing that HR writes on the sheet, and there's the five points on a poster and a bunch of people jumping with their hands in the air, and it's plastered all over the hallways, right?
That's not culture.
Culture is the operating system of a team.
It defines how the team processes information, and it is intended to establish a set of commonalities.
I truly believe the best teams have very high levels of diversity.
I'm not a fan of trying to create this sort of self-replicating entity where every person in the organization is effectively bringing the same strengths and weaknesses to bear.
Like a team should be a diverse entity.
But culture effectively is the common core.
It's a set of things that you can always revert to.
It's effectively the core principles that should be.
tuned for the set of activities that the team is pursuing.
So I don't think it's a one-size-fits-all story.
I think there's some organizations that have created a culture that is able to span different domains.
People like Amazon have a very interesting and novel culture.
But I do think the culture needs to be tuned to what you're trying to accomplish.
And it needs to be balanced for the set of constraints that the team has in terms of what resource is available, etc.
And so for me, I think the starting point, especially with a new team, is I do an exercise where I start to kind of interview people, especially if it's a team that you're inheriting and you want to kind of understand the culture.
And I'm trying to distill out a set of kind of core ideals that they believe is significant and is important to them, but is also important to the mission at hand.
What I'll tend to do when I'm trying to kind of, you know, get to that point is just go and identify the things that people really care about and that are objectively and intellectually important to the mission at hand.
You know, if you're in a security domain.
operating with precision and care and thoughtfulness, being paranoid.
There's a set of these markers that are necessary for where you are.
If you're in a startup, urgency, bias to action, et cetera, are really important.
And so it's starting to identify those markers.
And then I like to do a distillation of those down to just like a handful, four or five kind of core elements that then become kind of what I think of as the sort of deliberate culture anchors.
And once you've established that, there's a set of things that you as a leader need to do.
You need to talk about it constantly, right?
Like you need to talk about it when you're interviewing people.
You need to make sure that the interview processes make us allowances for this.
Because basically what you're saying is our culture describes how we assess people as being good addition and a creative addition to the team.
People can certainly learn culture, but the culture should reflect the nature of the team in some ways.
And a lot of that just can't be learned.
So it becomes an anchor for describing who gets into the team.
When you're looking at the promotion process, it should always tie back to the specifics of that culture, right?
You know, a lot of organizations that are going through engineering, you know, kind of promotion activities will have a set of levels.
This is what a suite one, this is what a suite two does.
This is what a senior suite does.
This is what a staff suite does, et cetera.
And make sure that there are effective ties in to the culture.
And then the final piece of it, and this is something I really like to do, is play back decisions that you have to make through the culture.
When you have a hard decision that you have to make, and it's not necessarily obvious, being able to relate that decision to the cultural markers or the cultural anchors that you've described for your organization is a way to constantly reinforce the culture.
And then the final piece of it is reassess.
I always say this, but hypocrisy is the culture killer.
If your team sees you behaving in a way that is incompatible with the culture, your culture is dead.
When you encounter those situations, you have a hard choice to make.
You either need to not do that, or you need to accept that your culture is not supporting the mission at hand.
And you need to deliberately change that.
You need to go back to the team and say, the culture demands that I do this.
And you can't do this on a daily basis.
You can't churn this.
But when you get to a point where it's like, I have to do this, I had openness as a core cultural element, but we're just getting crucified.
For whatever reasons, we need to focus on a proprietary thing.
There's these business justifications.
We're going to go this way.
We're not just going to go this way, but we're going to go back and update the culture and actually communicate that because the business imperatives have changed, we need to make sure that we reflect that in the sort of cultural piece.
So it needs to evolve.
And the culture will have bugs.
It has to be this weird intersection of intelligent design and kind of evolutionary pressures.
And you'll never get it right just out of the gate.
evolving cultures and being deliberate in that evolution, that takes a lot of awareness for the individual and the organization.
Yeah, it does.
And it's interesting.
And I like to think of myself as a pragmatist, right?
I'm not going to try to fit everything that you're doing into these kind of cultural anchors, right?
This cannot be procedural.
The culture is the total operating system.
Some companies have got closer to being able to describe culture as a procedural blueprint.
Again, Amazon.
I'm so impressed with what Bezos did in terms of creating a culture that's self-replicating, creates value in a lot of different domains, has incredible scaling apparatus.
It's not personally a culture that I could live or manage in, but gosh, I can respect it, right?
And I can admire it as a student of these things.
It's something that you have to be respectful of, but it doesn't necessarily work for me or the kind of work that I do.
So the way I tend to think about this, just kind of making it real, is that there's sort of implicit and explicit culture.
There's the implicit culture, which is what the team is doing.
And then there's the explicit culture, which is what are you saying the culture is.
And it's very difficult to have total coverage of everything you're doing with your explicit culture.
It's difficult to say that every decision down to which bug do I fix can kind of be tied back to culture.
The thing that you can do is make sure that your explicit culture and implicit culture are always compatible.
Like there's nothing that's being done implicitly that is contrary to the explicit culture.
And so back to the thing like, boy, that requires a lot of work.
Yes, it does.
You know, as a CEO, I think of my job as being really grounded in three things.
And this is something I borrowed from another podcast I heard.
So it's not original thought.
I can't remember who it was.
I'd love to attribute it.
But I'm just I'm repeating back something that stuck with me in my earlier journey.
I heard a CEO say this, and it was just like, holy shit, that's exactly right.
One, I set the culture of the organization.
Two, is I actually set the strategy of the organization.
I basically say, this is the domain.
This is how we can approach things.
And three is I find leaders that can execute the strategy within the parameters of the culture that I find.
And of the three things I do, culture is generally the most important and the least well understood because it really is a top-down thing.
And so I think to make it work, you have to make sure that the Leadership of the organization understands that culture is critical to the success of an organization.
The difference between a mediocre company and a great company is the strength of the culture.
And that doesn't have to be one thing.
There's a lot of great cultures out there.
There's a lot of cultures that work really well.
Even the ones I dislike, if it's a good culture to solve the problem at hand, you kind of have to respect it as a system.
You may not just agree with it or want to embrace it for your own uses.
A lot of critical thought there.
Second back, you touched briefly on promotion and career.
What's happening with career journeys today?
You know, it's interesting, and it's the cause of sleepless nights for me, because there's two sides to this.
There's a good side and a bad side, right?
Like there's a light on the horizon, and then there's a really complex thing.
I'm talking about this specifically for engineers, and I think it applies to other domains as well.
AI is obviously changing the game, providing access to this oracle that...
has access to the totality of human knowledge synthesized down into embeddings that can then be accessed at a moment's notice is definitely changing things.
The thing that scares me the most is that that classic path that an engineer takes where to be a great engineer, it's not like you just show up and you write code.
You have to take the time to write code.
And in writing the code, you start to understand the systems.
In understanding the systems, you understand not just the distributed systems, but you also start to understand the processes.
You understand how teams work.
You understand how organizations fit together.
You have opportunities to explore the boundaries between teams.
You can start to see how APIs become necessary.
But to work well in an organization, you have to combine both the contract, which is effectively the API, with the relationships so that you can do things.
There's a path for someone to go from a student to a distinguished engineer on this somewhat linear path of incremental ownership.
And a lot of the challenge we face is obvious, which is the...
a lot of the tasks that we would assign individuals earlier in their career are being displaced.
They no longer have a lot of people earlier in their career writing unit tests or fixing bugs or doing some of the stuff that occupied their attention before they started getting into distributed systems design and reasoning about the more complex parts of the system and building it at a bigger scale.
And I think what's really interesting, and this is something I don't know where this goes, because those earlier career people, They have a lot of advantages in that they have access to this incredible corpus of human knowledge at a moment's notice.
And also there's a set of new skills that are necessary to use that in its optimal way.
But 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.
And so I think it's definitely something that we need to think about.
And I wish I knew the answer because I just don't.
I think what I do know is that the engineering role is changing.
Value creation is happening at a different layer.
Code is moving more towards something that feels like an intermediate language.
The way that engineering value creation is happening is more about assessment and almost risk mitigation, you know, like making sure these things don't do anything stupid.
The profile of the person who's going to be best at that is maybe not the people that we've trained in college.
The education system may not support this.
So the world is definitely in flux.
And I don't have a good map for where it's going to end up, but I certainly think about it a lot.
What's your advice for the reasonably new team lead, technical lead, looking at how do they support their teams and looking to the future?
Right now, there's a few things that I would kind of advise, you know, like let's say you're a relatively early career team lead and you now have a team of engineers and I assume you have access to tools, co-pilot, cursor, cloud code, you know, what have you.
And you're trying to think about, you know, where you want to go.
I think the starting point is recognizing that if you yourself are not an expert in understanding these systems, you're not going to be able to serve your team.
And the temptation to start to rely more on these tools to do the work.
It's going to be constantly there.
I think one of the biggest challenges every new lead faces is that they always think that they could just do the work themselves.
At the end of the day, stuff gets weird.
Generally, the people that make it into that early lead role are some of the best engineers, the best line engineers.
They've still got those muscles.
And they are now in this interesting situation where they have to balance two things.
They have to balance understanding these tools and where value creation happens without displacing and alienating their team.
That's a very important balancing act to maintain, right?
Like you can't be in a situation where it's like, wow, I have access to cloud code.
I can set up four agents.
I can come up with an idea.
I can get something that's close enough to being hardened.
I can go hardened myself.
What am I doing with these people?
I don't know.
They're probably doing something.
That's a failure mode because what you really need to be doing is supporting them through that process.
And so I think the first thing you have to do is hold on to the notion that your role is to drive the productivity of the people and not...
fall into just doing a lot more work and treating your AI teammates as being a priority of your other teammates because they're more responsive and they do good work.
At the end of the day, you have to balance actually spending time with the tools to understand them and understand how they work so that you can mentor your team and actually be an AI maximalist yourself in your own approach with maintaining that identity that your job is not.
to produce the work yourself.
It's to support your team in producing the work product and scaling that.
The other thing that's really important is to start to maintain the culture of the team, to sort of emphasize that while we have new tools, our responsibilities are largely the same.
You know, it's not okay to produce something and then push it up the chain to me to turn your AI code and slop into quality code, right?
Like everyone has to own everything they do.
It doesn't matter whether it's a coding agent that produced it or something else.
At the end of the day, you need to feel full ownership of that before you put it onto someone else.
So you don't generate that kind of fatigue I talked about earlier around having to spend your life coding and then assessing the output of coding agents and then assess the output of someone else's coding agent because they're too lazy to do it themselves.
I think that sort of constant reinforcement is good.
And then the final thing I think which is harder is there's this letting go that has to happen.
There is...
An incredible opportunity here.
Like the rules are different.
The unit economics of work are different.
The set of challenges your team can face are different.
Like once you cross the threshold of being able to actually use these tools in a certain way, set up the appropriate guardrails, you constantly have to challenge yourself.
Like, hey, maybe we can do a lot more.
Maybe the things that we've learned in terms of our operating cadence are not there.
Maybe we can actually produce something in a lot more efficient way if we let go of some of those assumptions.
But I think probably the biggest assumption and the most significant assumption that people have to let go is when you're actually building agents themselves, when you're trying to create these things, the existing rules of traditional systems and imperative systems that everyone is used to are different.
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.
And that generally comes on the back of a lot of experimentation.
People are not going to work into this and say, oh, it's three lines in boxes, a database.
We'll stitch them together, make it work.
And then we'll figure out how to make it scale.
We'll kind of make it functionally complete.
That's not how agentic systems work.
And you have to learn that the hard way by doing and make sure that you're not assuming that, hey, I could just design it and it will work.
You've actually got to go through the hands-on.
I always think of agents are more like lawnmowers than anything else.
You have to constantly push them to do work.
And over time, they may be converted to right-on lawnmower if you build up enough expertise and competence.
in your space.
Craig, a lot of food for thought here.
If people want to continue the conversation, where can they find you?
Oh, you can find me on LinkedIn under Craig McLuckie.
I don't know how many there are, but I'll probably be the top one that comes up.
Thanks so much for taking the time to talk to us today.
Thanks for having me on.
This will be great.